朋友试了我推荐的 8 个会议录音工具，全部退货

English version

上一篇 《Zoom 自带的 AI 太烂》 发出去之后，朋友把列的 8 个开源会议录音工具一个一个试了一遍。

反馈很直接。

「都挺垃圾的」。

三个维度全是问题。识别质量烂——中文不准、口音不准、专业术语不准。总结质量烂——出来的笔记不像人话，重点丢了一半。UI/UX 稀烂——崩溃、卡顿、设置流程像在 1998 年的 Linux 桌面。

我懵了一会儿。8 个项目，从 11.6k 星的 Meetily 到三五个 star 的玩具，stars 跨度三个数量级，照说不可能全都不行。

然后我重新挖了一晚上。这次没看 README，看的是 issue tracker、独立 benchmark、维护者自己写的 blog。

发现的东西比想的深得多。

---

上一篇漏看的一层：Whisper 这代技术栈早就到顶了

数据先行。

AISHELL-1（中文 ASR 标准 benchmark）的 character error rate 实测：

WenetSpeech 的 test_meeting 子集（专门测多人会议场景）：

Common Voice 粤语子集：

意思是上一篇我推荐的所有 8 个项目，底层 ASR 全是 Whisper（v3 / large / Turbo / WhisperKit / whisper.cpp，都是同一家祖宗），而 Whisper 这代在中文场景已经被超车 2.5 到 4 倍。

不是这些工具的实现烂，是地基烂。

而且 Whisper 还有一个老问题——对静音段的幻觉。会议里有 30 秒没人说话，Whisper 会自动给你脑补出来一句话。Reddit r/LocalLLaMA 上吐槽这个的帖子三天能上一次首页。Parakeet（NVIDIA）训练时混了 36k 小时的噪音和非语音数据，幻觉几乎消失。SenseVoice 内置音频事件检测（背景音/掌声/笑声），实质做了一道 VAD。FireRedASR2 直接打包 FireRedVAD。

后浪们都在补 Whisper 的洞，但开源前端还在继续用 Whisper。

维护者自己都认账，不是我瞎说

为了确认上面这个判断，我去翻了 issue tracker。

结果发现，这些项目的维护者自己已经把问题摊在 issue 里了，是我上次没看。

Hyprnote/Anarlog（fastrepl 团队）。维护者 yujonglee 在他们 official blog 里直接写：

「HyperLLM-V1 summarization is fine-tuned exclusively for English.」

意思是总结模型只 fine-tune 了英文。中文用户把音频丢进去，转录可能勉强，总结直接稀烂。

Issue 2444 是一个用户提的「Please add support for Chinese」，被维护者 ComputelessComputer 关掉，回复是：

「closing this as we support custom endpoints」

意思是中文支持不在我们 roadmap 里，你自己接 BYO endpoint 去吧。

Issue 4881 更精彩——是一场用户暴动。Anarlog 在某个版本悄悄把 Parakeet V3 模型替换成了 V3 TDT，用户 dandaka 写：

「still unusable for my case, quality of transcript is awful. any plans/ETA for bringing the prev model back? Issue closed, but nothing actually changed :( No plans to get back to a working state?」

28 个评论，4 个 reaction，维护者最后没给方案。

Hyprnote 的 Launch HN 帖子下面，用户 ljosa 一句话点穿：

「the inability to tell who said what is a show stopper... You'll need to add speaker diarization for this to be useful for more than 1:1s.」

——意思是「分不清谁说的哪句话」就是 show stopper，没 diarization，超过两个人开会就完蛋。

Meetily。issue 171 标题「Quality of meeting minutes」，用户 daviddecorso 写：

「Yeah my transcriptions just became complete gibberish after some recent update. It's just random words interspersed with [MUSIC PLAYING] or [INAUDIBLE].」

更新之后转录直接变乱码。一堆 [MUSIC PLAYING] [INAUDIBLE] 标签。

issue 228 是中文模型——选上之后直接 crash app：

「Select the downloaded model, and then click 'Start Recording'. The application will crash.」

issue 233 标题「Multi-Language Support for Summaries」，12 个 reaction，11 个评论，开了 8 个月没修。

Recap（703 stars，那个我说「想法对架构对但不稳定」的项目）。issue 15 有人正面挑战它的许可证：

「The license of this software is not open-source. Please change it to a real open-source license or stop claiming this software is open-source.」

许可证是 proprietary，作者在玩文字游戏。我上一篇没看到这个，是个错误。

意思是这些项目的痛点根本不是「实现细节问题」，是架构性的局限——基础模型选错、维护者本人都没把多语言放在 roadmap、Diarization 用最简陋的算法、甚至许可证都不是真 OSS。

上次我看的是 README，这次该看 issue。README 是 marketing，issue 是真相。

一个被所有人忽视的暴力解：双轨录音

聊完了别人的问题，回到自己的诉求。

Speaker diarization 这件事难，难在哪？难在一段混合音频里要区分谁说的哪句话。所有 OSS 项目都在 pyannote / sortformer / 静音切片这条算法线上卷精度。

但你想想——Mac 上录会议，麦克风抓的是「我」，系统音频抓的是「对面所有人」。这两个信号源物理上就是分开的。

如果录的时候不混合，左声道存麦克风、右声道存系统音频，输出一个 stereo m4a 文件——

Diarization 问题就被降维成了：「左声道标 'Me'，右声道按声纹聚类标 'Speaker A/B/C'」。

准确率 100%。算法层面的 diarization 老问题直接消失。

这个想法不是我原创。Ilia Zadyabin 在 Medium 上写过 OBS dual-track 的 setup，他用 OBS 录两轨然后送 WhisperX。但他踩的坑也很 telling——WhisperX 默认会 downmix 到 mono，多轨信息直接丢失。这是 Whisper 时代的设计哲学：单输入单输出，不接受 stereo 信息。

但 Gemini 3 Pro 多模态——原生支持 stereo audio，可以在 prompt 里直接讲：「Channel L is me, Channel R is everyone else, transcribe verbatim and label speakers」。一个调用搞定转录 + diarization + 总结。

Simon Willison 11 月实测过这条路。3 小时 33 分钟的会议音频，喂给 gemini-3-pro-preview，一个 prompt 出来「转录 + 说话人识别 + 摘要 + 行动项」。总成本 $1.42。

$1.42, 三小时会议

这个数字摆出来你就懂为什么这条路是当下最优解了。

SOTA 后端早就有了，没有 polished 前端能挂

聊技术。

OSS 这边后端（ASR 模型）的迭代速度其实很快。最近 6-12 个月出的：

• Voxtral 2（Mistral，2026-02）— Apache-2.0，13 种语言含中文，原生支持 speaker diarization + 词级时间戳。直接 drop-in 替换 Whisper。
• FireRedASR2-LLM（小红书 AI 团队，2025-Q4）— Apache-2.0，独立 paper 实测 2.89% avg-Mandarin CER，超过 Doubao-ASR (3.69%) 和 Qwen3-ASR-1.7B (3.76%)。
• NVIDIA Streaming Sortformer v2 — 普通话 DER 9.2%，214 倍实时速度，CC-BY-4.0。
• pyannote-precision-2 — AMI 12.9%，DIHARD-3 14.7%，比 pyannote 3.x 降 25-30% DER。

但这里就是问题——没有任何 polished 前端能挂这些后端。

你试过的那 8 个项目，ASR backend 全是 hardcoded。Meetily 是少数支持 BYO LLM summarizer 的，但 ASR 还是写死 Whisper。Anarlog 卖点之一就是 BYO LLM，但 ASR 同样 sealed。pasrom/meeting-transcriber 提供了「3 引擎可选」，但只是在他打包好的 3 个里切，不是 hot-swap 任意 endpoint。

我让一个 sub-agent 专门审了一遍这些项目的源码——结论很直接：

「Zero polished frontend exposes a 'set OpenAI-compatible STT base URL → done' knob. ASR is bundled-with-the-binary in every mature option.」

唯一能把任意 SOTA OSS 模型 wrap 成 OpenAI-compatible /v1/audio/transcriptions 的，是 LocalAI 这种通用 proxy。它原生支持 Voxtral backend，还暴露了一个独立的 /v1/audio/diarization endpoint。但你要让 Meetily 调它，要先 PR 修 issue 431——OpenAI-compat 转录路径有 bug，直接调回来是乱码，得加特定 header。

「We are getting errors on our openai server that suggests we need to add a couple of specific headers to the api call.」

意思是真正的窗口期不在「再写一个会议工具」，在中间件层——一个标准的 ASR proxy，把任意 SOTA 模型封装成 OpenAI 兼容协议，前端各家都能挂。这层在 LLM 圈早就成熟（OpenAI-compatible API 是事实标准），但音频圈刚起步。

跟上一篇的判断不冲突。开源还是会吃掉这件事——但要先吃掉中间件，前端才能跟上。

上一篇漏掉的 4 个项目

回到工具维度。重新挖了一晚上 GitHub trending、HN、awesome-list 之后，发现有 4 个上次漏掉的，值得单独提：

Vexa（2k stars，2026-05-03）。完全不一样的 paradigm——不是本地录屏，而是 Docker bot 真的加入会议。Meet/Teams/Zoom 都支持，real-time WebSocket transcripts，自带 MCP server，多租户 API。make all 自部署。本质是一个「Otter 的开源自托管版」，自己控数据。劣势是要 GPU box，纯 SaaS 替代品。

Muesli（192 stars，2026-05-08）。Mac 原生 Swift 实现 + 多后端可选——Parakeet v3 / Cohere Transcribe 2B / Qwen3-ASR with 52 langs incl. 中文 / Whisper。Diarization 用 pyannote-via-FluidAudio 跑 Apple Neural Engine。如果你的诉求是「Mac native + 中文 + 真 diarization」，先试这个。30 分钟下载装好就能开真实会议测。

Handy（21.3k stars）。多后端 dictation 工具——Whisper / Parakeet V3 / Moonshine V2 / GigaAM v3 / SenseVoice / Breeze ASR / 自定义。Tauri 跨平台。但它不是会议工具，是 dictation 工具——没有 diarization，没有会议总结。日常听写用很顶。

Voxtral 2 模型。这个是模型本身，不是 app。Apache-2.0，13 种语言含中文，原生 diarization + 词级时间戳。是 Hyprnote issue 1354 那个用户喊了一年的「drop-in Whisper 替换」。直接拿 weights 自己跑就是了。

还有 parakeet-diarized——一个小巧的 FastAPI proxy，NeMo Parakeet + pyannote，accept diarize param，返回 verbose_json。最接近现成的 SOTA proxy 模板。

三条路径，按时间预算选

A. 90 分钟方案（强烈推荐先做这个）

复用 watch-transcriber 八成的管子，扩展到多人会议。

audiotee (CATapDescription, 无需驱动) + ffmpeg 麦克风
  → ffmpeg amerge 双轨 m4a (左 = 我, 右 = 对面)
  → Hammerspoon Cmd-Opt-R 一键 toggle
  → launchd WatchPaths 自动触发
  → Gemini 3 Pro 一调用 (transcribe + diarize + summarize)
  → claude -p 投递到笔记

audiotee 这个工具是关键——基于 macOS 14.4+ 的 CATapDescription API，无需驱动、不需要 BlackHole、不需要 BetterDisplay 那种虚拟设备。可以按 PID filter 只录 Zoom。

成本 $0.50/小时会议。Simon Willison 实测 3 小时 33 分钟会议 $1.42。

B. 2-3 天方案（坚持完全离线）

[Meetily fork] → [LocalAI on remote GPU box] → [Voxtral 2 + Sortformer]
   前端 UI            OpenAI-compat /v1/...transcriptions      SOTA 后端

LocalAI 是唯一同时暴露 /v1/audio/transcriptions + /v1/audio/diarization 的开源 proxy，原生支持 Voxtral backend。Meetily 这边要 fork 改 WHISPER_HOST 指向 LocalAI，可能要 PR 修 issue 431。

100% 本地，永久免费。但前置条件是你有 GCE devbox 或者愿意本地跑 GPU container。

C. 中文场景的混合方案

如果中文是核心场景：双轨录音 → 本地 SenseVoice 走 sherpa-onnx（CoreML 路径已成熟，Mandarin/粤语/EN/JA/KR）→ Gemini 3 Pro 做总结 + 跨说话人聚类。质量上限最高但工程最重。

闭源 SaaS 的窗口期，比上一篇说的更短

回到那个 thesis。

上一篇的判断是：「Granola 们的订阅费是在卖摩擦力，开源会吃掉这件事」。

这次发现的是：开源 alternative 的卡点也是摩擦力，只是换了形态。

不是用户那一面的「我替你装好了 BlackHole」——是开发者这一面的「中间件还没成熟，前端只能 hardcode Whisper」。

后端（SOTA OSS 模型）的迭代速度真的很快。Voxtral 2 是 2026-02 的事，FireRedASR2 是 2025-Q4，Streaming Sortformer v2 是 2025-Q3。Whisper 上一次 large 级别更新是 2023-11，差不多三年前。

差距还会继续拉大。但 OSS 前端要追上，可能要再等一两个产品 cycle——要等中间件层（OpenAI-compatible audio proxy）变成事实标准，要等前端切换 ASR backend 的成本降低。

在那之前，双轨录音 + Gemini 一调用，是最聪明的过渡方案——既绕过老 Whisper、又绕过没成熟的中间件、又绕过 polished 前端的 ASR hardcode 问题。

上一篇 《Zoom 自带的 AI 太烂》 错就错在我看 stars 没看 issue。这一篇的教训是——做工具调研的时候，README 是 marketing，issue 是真相。

录会议这件事本来就该简单。但要 OSS 真的吃掉它，可能比我想的还慢。

中间这段窗口期，DIY 比挑工具靠谱。