距离上次在这里分享博客又又又快过去一年多时间了，时间过得太快了，好久不见。这次要分享的是一篇新的博客《聊聊 Kapinote 和背后的故事》
部分内容如下：
如果你需要一个完全本地的 AI 会议助手，不妨来试试 Kapinote。
为什么做 Kapinote
随着最近几年开会的时间越来越多，有的时候开会的时间甚至要大于 coding 的时间，我从去年开始就无比迫切想要把我的会议内容上下文集成到我的 agents 工作流中。
从 Claude Code 这一类的 agents 工具出现开始，我就不停的把我所有的工作流和上下文集成给 agents ，相信最近两年使用 agents 的人都会有一种体感，也就是你的 agents 能够集成的不同上下文越多，你的 AI 工作流就能够越发的自动化和流畅，实现 1 + 1 > 2 的效果。
一旦你的 agents 工作流中间缺乏了某一环的上下文，你就会感觉很难受，不仅是缺少的这一点上下文需要你手工来补充，最重要的是你的整个 AI workflow 是断的，自动化和半自动化还是有本质的区别。
所以我无比期望能够把我仅剩不多无法集成的上下文给全部打通，其中会议内容就是很重要的一环。加上英语能力不够，经常开会遗漏内容，所以从去年 11 月份开始，我就在一直和 Agents 慢慢聊 Kapinote 的原型需求。
想要做一个 AI 的会议助手，市面上的产品已经很多了，为什么还要重新造一个？要构建一个什么形态的产品？
首先肯定不是做成硬件形态的产品，例如 PLAUD AI 这种硬件软件一体的产品，首先没这个能力，其次因为隐私要求我无法用云端的商业产品，所以例如 Granola 这一类的产品形态也就直接 pass 了（在这里也给 Granola 打个广告吧，Kapinote 部分的交互逻辑都是参考的 Granola ，云端的 ASR 模型目前还是强于本地的，所以如果你能够接受云端的产品，Granola 是一个很好的选择）
按照这个要求去做排除法，会议 Bot AI 的这种形态也是直接放弃了，这类产品可以直接加入你的会议房间，虽然能够直接连接不同的会议软件，例如 Zoom 和 Google Meet 或者 Teams 这一类，并且能够记录是谁在说话，但是隐私风险无法保证。
所以走到最后只有一条路线，那就是纯本地 ASR 模型加 AI 的本地桌面端的产品形态。
但是这个方案在最开始我就遇到了一些问题，最开始我用的本地模型是 Whisper 模型，毕竟这个是最出名的 ASR 模型，但是实际测试下来感觉一般，特别是我有多语言会议内容支持的这种需求，Whisper 对于中文的支持实在是非常一般，即使拉到最大的 large 模型还是没有显著提升。
所以去年 11 月份写完了 demo 之后这个项目就因为效果不好暂停了，直到今年二月份看到 Cyronlee 的一个新的开源项目 TransFlow 给了我新的灵感，在 MacOS 端还可以去用 Apple Speech 原生的框架去做 ASR （ TransFlow 本身也是非常不错的开源项目，可以结合 Apple 本地的做会议实时翻译和转录，有需求的也可以去看看这个项目），然后我又拾起信心重新再去搜索一批 ASR 模型。
发现在暂停项目的这段时间内阿里也推出了最新的 Qwen3 ASR 本地模型，试了之后感觉效果非常不错，于是我就决定基于这两个本地模型继续做 Kapinote。如果你是中文为主或者多语言融合的会议，我非常建议你在 Kapinote 中下载 Qwen3 ASR 模型使用。
那为什么拖了这么久这个项目才开放呢，主要是最开始在去年写这个项目的时候，那时候我对于 AI 框架的认知还是 Vercel AI SDK 之类，对于 AI Agents 的思考还停留在 model + prompts + tools calling ，直到经历了年初的 OpenClaw 的大火，又在三月份重新学习了 Pi agents 等，才决定把整个 Vercel AI SDK 这一套重构成了一个小型的 harness ，把重点放在 model + context + cache + loop 。
重构改造完成后，整个项目在未来的上限会更高一点。并且可以不再强制让用户填入 API KEY 了，可以使用 BYOA （ Bring your own agents ）的方式，把你自己的 Codex ，Claude Code 等直接集成进 Kapinote，当然也可以通过 skills 直接外部连接。
全文内容属实太长，更多的内容大家可以访问我的博客《聊聊 Kapinote 和背后的故事》获取更多信息。
也可以直接在这里给出你的 feedback ，你们的每一个回复和关注都是我继续打磨产品的最大动力。
JetKwok 08-28 14:121楼