聊聊 Kapinote 和背后的故事
2026年8月23日
如果你需要一个完全本地的 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 之后这个项目就因为效果不好暂停了，直到今年二月份看到同事 Siyuan 的一个新的开源项目 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 是什么
Kapinote 最重要的功能当然是帮你记录你的会议的所有内容，当你有了所有的内容后，你就可以通过不同的手段把会议上下文给到 agents 去帮你完成工作流的下一步，不管是去写邮件，还是列出会议总结，写 PPT 或者是帮助你的下一步获取足够的上下文。
除了本地的 ASR 模型的优化，Kapinote 也为了会议内容优化了很多的地方，例如会议的自动检测并且提醒，然后在会议结束的信号断了之后，可以自动开始总结的流程，防止你忘记中断会议记录，多个会议记录到一起，代价是连续的会议还是需要你手动开启录制。
录制完成后，你可以开始询问内置的 AI 助手这个会议的内容，可以让他去列你下一步要干什么，让它编写会议总结邮件，列出重要事项，当然前面的这些你可以设置成模板 prompts 自己配置，Kapinote 内置了几个基础的模板供大家使用，也欢迎大家去自己创建私有的模板，未来可能会创建 hub 让大家分享好用的会议 prompts。
说到 AI 助手，为了保证完全的隐私性，Kapinote 可以集成本地的 Ollama 模型来完成所有工作，但这也意味着你的电脑需要有比较大的内存，能够支持总结会议这些基础的功能。按照 Mac 本身只能够支持的模型来讲，我比较推荐下面这些：
- M1 ｜8 GB ｜Qwen3-8B
- M1 Pro ｜16 GB ｜Qwen3.6-8B / 14B
- M2 Pro ｜32 GB ｜Qwen3.6-14B
- M3 Max ｜64 GB ｜Qwen3.6-35B-A3B
- M4 Pro ｜64 GB ｜Qwen3.6-35B-A3B
- M5 Pro ｜64 GB ｜Qwen3.6-35B-A3B-MLX
当然，在 2026 年本地的 AI 模型效果还是比较的一般，想要支持稍微复杂一点的工作，还是得需要使用云端模型。这里也比较推荐使用 BYOA 的方式，直接接入你的 Agents 例如 Claude Code 或者 Codex 之类的都可以。目前暂时只接入了少量的几个，未来打算接入更多的 Agents。
这对应的是你可以在 Kapinote 的模型配置中选择使用 CLI 的方式接入，这样的话它会复用你已经登录好的 Codex 或者 Claude Code，你可以不需要自己去配置 API Key，并且如果你需要在公司内使用 Kapinote 的话，你也可以使用公司给你的这些 Agents，能够保证一些合规性、隐私性和安全性。
当然你也可以通过自己去配置对应的 API Key，如果是轻度使用的话，那么建议使用 Google Gemini 的 API Key，它有一些免费的使用额度，对应的链接是 Gemini API key，可以使用模型例如 gemini-2.5-flash 或者是 gemini-2.5-pro。当然你去接入一些性价比高的模型例如 Deepseek 也是完全够用的。
除了上面这几种基础的用法之外，你甚至可以通过 Skills 把你的 Agents 直接连接上 Kapinote 的数据，我通过内置的 CLI 的方式直接暴露了应用对应的 API 给到 Agents 和 Harness。
你可以在 ChatGPT 或者 Codex 中直接下载对应的 Skills，下载的方式很简单，直接向你的 Codex 或者其他的 Agent 输入 https://github.com/kapinoteai/kapinote 这个链接，然后告诉你的 Agent 帮你下载对应的 Skills 到本地。
接着之后你就可以在 Codex 里面去询问你的会议内容，或者说是让它帮你去编写邮件了。如下图所示，就是我在 Codex 中直接询问我最近会议的内容的截图：
你甚至可以给 Kapinote 去编写对应的内置 Skills，当然这个功能目前还在 Beta 阶段，可以忽略。
当然，通过外部 agents 控制的方式还是会有一些数据的风险，如果模型的能力不是很强的话，会误删掉一些数据，或者修改掉你会议本身的一些原始数据，所以的话，按照大家的使用习惯可以自行的选择。
核心功能
不管是通过内置的 AI 助手，还是外部的 agents 连接，你都可以完全无限制的访问你的数据，并且甚至可以去删除你会议本身的一些内容和直接通过 Agents 去修改总结内容。
通过 Kapinote 页面本身的功能，你可以 @ 某一个会议，或者说是 @ 多个会议，然后去询问对应会议的内容，你也可以在全局的聊天中去询问你所有的会议内容，Kapinote 本身会通过内置的 CLI 去搜索对应的会议信息，然后来回答。
你也可以通过输入 / 在页面的输入框中来使用内置的模板，所谓的模板，也就是你自己自定义的 Prompts 的功能，可以快速地完成你日常的一些工作。Kapinote 本身它内置了几个最简单的模板功能，大家如果不满意的话，也可以自行修改或者添加新的模板。
需要注意的是，模板创建需要注意选择是单个 Meeting 的模板，还是针对于多个 Meeting 的模板。
例如写邮件这种模板的话，它明显就是只针对于单个会议内容才会使用的，所以的话，它只会在单个会议的聊天框中出现。但是对于 Find the action items 这种需求它可以去跨多个会议内容使用。所以的话，这个模板的配置，它就是针对于多个会议内容使用的。（这一块的交互是参考的 Granola）
关于 ASR 模型的选择，如果你经常需要开多语言的会议，例如中英文夹杂的会议，或者是中文会议为主，可以优先选择使用 Qwen ASR 模型，如果你是英文会议为主，或者是单种语言为主，例如德语法语，那么选择 Apple Speech 是一个很好的选择，占用内存都比较少。
除此之外，最重要的功能，那就是 Custom Vocabulary 自定义词汇，因为对于会议内容来讲，像人名或者说是业务专有的上下文名词，无论是本地的 ASR 模型还是云端的 Agents 它都没有办法正确的识别，所以需要你在 Kapinote 中去配置对应的自定义词汇，这样的话，无论是在总结的时候，还是模型在回答你问题的时候，正确率都能显著的提升。所以大家如果使用 Kapinote，人名这种配置是非常重要的，大家每个人都可以需要根据不同的实际情况去应用里面自己配置。
设计与实现
Kapinote 本身通过 Rust + Tauri 构建，构建完成的下载压缩包只有 20 MB 左右，这是大部分用户都非常能接受的大小，当然，这仅适用于完全使用云端 ASR 模型和云端大语言模型的用户。
如果你完全使用本地的 ASR 和 LLM 模型的话，还需要通过应用去下载 Apple Speech 模型或者是 Qwen3 ASR 模型使用。对于 Apple Speech 来讲，大概单个语言是 400 MB 左右，对于 Qwen ASR 模型，本地存储大概需要 800 MB 左右。
当然除了技术的部分，整个 UI 的部分也是花了很多的小心思。整体的 UI 交互部分的话，其实是参考了 Granola 这个应用的交互逻辑，然后加上了很多独特的设计，因为这是第一次写桌面端的应用，所以和 Agents 聊了非常多轮，才最终定下来整体的设计风格。
这个应用包括 Web 端页面所有的 UI 部分都是 Claude Code 和 Codex 来生成的，包括 logo 的部分，例如下面的截图就是我和 ChatGPT 聊的最新版本的 logo 的选择截图。之前的那一版本在 ChatGPT 出 Image2 之后就放弃了。
还包括了这个应用内置的所有和卡皮巴拉元素相关的 Icon 也是通过 Codex 直接生成的，通过一些这种个性化的方式，可以减轻很多 AI slop。例如下面的截图就是 Codex 直接生成的所有 Icon。当前 Kapinote 会基于你会议的内容，通过 LLM 去选择对应的卡皮巴拉 icon 作为你这个会议的图标。
关于如何通过 Vibe Coding 生成一个生产级可用的应用，在这个应用的实践中也做了很多的思考，例如使用轻量级 DDD 去搭建后端，这样的话，即使我不懂 Rust，我也可以去观察它的 Domain 的行为和 Domain 之间的关系去继续和 Agent 生成质量更好的代码，并且减轻我的 review 压力。关于这一块的话，后续会有其他的博客去分享更多。
当前进展与后续计划
未来 Kapinote 的短期计划是推出后优先修复 bug，因为本地 ASR 模型本身在不同的会议场景下，例如不同的会议环境，嘈杂、多语言等环境因素都会有不同的表现，例如虽然 Kapinote 支持多达 30 种语言，但我实际测试的也只有三种语言，所以需要收集大家的反馈先修复一手。
目前 Kapinote 还只支持 macOS，一部分是因为本地模型 Apple Speech 本身是 macOS 自带的原因，不过 Qwen3 ASR 是支持带 GPU 的 Windows 的，之所以还没支持 Windows，纯粹是手里已经没有 Windows 笔记本了，没有很好的测试机。并且 Windows 现在实现 harness 的流程还不够丝滑，后续时机成熟会支持的。
未来这个项目会商业化吗？有可能会，取决于未来的本地 ASR 的效果，目前没有商业化的原因是因为虽然当前的 ASR 效果还不错，但是没有达到我的预期，并且很多语种和模型还没有仔细的测试过。所以目前是没有任何收费的，当然未来也是不会基于已有的这些功能和模型收费的，所以大家放心使用。
写在最后
Kapinote 这个项目是进入 Agents 时代以来，我的第一个完全由 Agents 来主导和完全 100% Agents 编码的项目。虽然从技术上来讲，我和他讨论了很多关于代码优化和生产质量方面保证的一些上下文。但是从体验上来讲，其实是可以做到完全不懂技术来实现这个项目的。虽然质量可能不会有现在这么好，但是能从 0 做到 1，远比从 1 做到 10 要重要得多。
所以在这个项目的实现阶段，我也不停的在思考，Agents 时代的编码和产品的未来会是怎么样的，在目前的这个阶段，代码已经不是那么重要了。无论是几个代码文件还是一个项目的整体的代码，它都可以是一次性的代码，可以随意重构，随意修改的。那么在未来可以预见的一段时间，产品本身可能也会变得不是那么重要，它可能也能被随意的生成，随意的替代，甚至变成产品本身就是 Codex 这种巨无霸产品里面的一段动态生成的一次性代码。
但如果换个角度去想，如果 agents 能够帮助我们消除 building 阶段最枯燥的那一部分，留下最有趣的那一部分给我们去随意地发挥，作为创造者而言何乐而不为呢？
即使假设会有一天，coding 最有趣的那一部分也能够被 agents 替代，我们现在就应该停止创造吗？
如果有一天，代码可以被自动生成，产品可以被自动构建，甚至一个想法可以在几分钟内变成现实，那么我们当下还要去选择创造吗？
我想创造过程本身足够有趣，这就够了。