为什么又造了一个语音输入工具
我每天的工作有大量文字输出——写代码注释、回邮件、写文档。手指敲键盘的速度早就成了瓶颈，于是开始认真研究 Mac 上的语音输入方案。
试了一圈下来，发现一个让我不太舒服的事实：市面上最流行的几个方案，没有一个真正在用 macOS 的能力。
Whisper 需要下载几个 GB 的模型，加载时吃掉大量内存，而且它对我屏幕上正在做什么一无所知。我在写 Swift 代码时说「optional」，它给我识别成了普通英文单词。
讯飞语记 和类似的云端方案，需要把音频传到服务器。作为一个每天处理客户邮件和内部文档的人，我没办法接受语音数据离开自己的电脑。
macOS 自带的听写 功能还行，但不支持自定义、没有会议模式、不能根据上下文优化识别。
这些工具有一个共同问题：它们跑在 Mac 上，但完全没有利用 macOS 的能力。把它们放到 Windows 上也一样能工作，Apple Silicon 的神经引擎、Vision 框架、Core ML——这些苹果花了数年打造的端侧能力，一个都没用上。
直到 macOS 26 发布了 SpeechAnalyzer 框架——一个系统级的端侧语音识别引擎，跑在 Neural Engine 上，毫秒级延迟，不联网，不收费。我意识到，现在是时候做一个「真正属于 Mac」的语音输入工具了。
设计原则：每一层都用 Apple 原生框架
ambient-voice 不是在 Mac 上套了一个通用引擎，而是从底层开始，每个功能模块都选择 Apple 原生框架来实现：
| 功能 | 框架 | 为什么选它 |
|---|---|---|
| 语音识别 | SpeechAnalyzer | Neural Engine 端侧运行，毫秒延迟 |
| 屏幕截取 | ScreenCaptureKit | 系统级窗口捕获，权限可控 |
| 文字识别 | Vision OCR | 端侧 OCR，速度和精度都够用 |
| 文字注入 | AX API + CGEvent | 原生辅助功能接口，兼容所有 App |
| 说话人分离 | FluidAudio（CoreML） | 端侧推理，不需要云端 |
| 热键监听 | CGEventTap | 系统级键盘事件捕获 |
全原生意味着三件事：
第一，数据不出设备。 所有处理都在你的 Mac 上完成。没有网络请求，没有数据上传，没有遥测。你的语音、你的屏幕内容、你的文档——全部留在本地。对于重视隐私的 Mac 用户来说，这不是加分项，是底线。
第二，零额外成本。 不需要订阅，不需要按量付费，不需要 API Key。Neural Engine 已经在你的 Mac 里了，你买硬件的时候就已经为它付过费了。
第三，随系统升级自动变好。 macOS 27 的 SpeechAnalyzer 如果比 26 更准确，ambient-voice 会自动受益，不需要更新任何代码。这就像潮水涨了，船自然就高了。这种架构上的便利是第三方引擎给不了的。
核心机制：上下文偏置——不是纠错，是预防
这是我认为 ambient-voice 最有价值的设计，也是它和其他语音输入工具本质不同的地方。
传统的语音识别思路是：先转写，再纠错。你说了一段话，引擎给你一个结果，然后用后处理模型去修正错误。
ambient-voice 的思路正好相反：在转写的时候就介入，让引擎在识别阶段就做出正确选择。
具体流程是这样的：你按下右 Option 键开始说话。这个瞬间，ambient-voice 同时做两件事——
- 用 AVCaptureSession 采集音频，交给 SpeechAnalyzer 开始实时转写
- 用 ScreenCaptureKit 截取你当前焦点窗口的内容，用 Vision OCR 提取可见文本中的关键词，注入 SpeechAnalyzer 的
AnalysisContext
也就是说，在你说出第一个字之前，识别引擎就已经知道你屏幕上有什么了。
举个实际使用中遇到的例子：我在回一封讨论 OKR 的邮件，说「把留存目标改一下」。如果没有上下文偏置，「留存」很可能被识别成「留村」——这是中文语音识别中极其常见的同音词错误。但因为 ambient-voice 在我开始说话的时候已经看到了屏幕上的「留存率」「OKR」「季度目标」，识别引擎在做同音词选择时直接命中了正确的词。
再比如写 Swift 代码的场景：我说「声明一个 optional 变量」，普通识别引擎不知道我在写代码，会把「optional」当作日常英语处理。但 ambient-voice 看到了屏幕上的 Xcode 和 Swift 代码，把 Swift 关键词注入了识别上下文，「Optional」被正确识别为 Swift 的类型。
这种体验的差别是：你不再需要说完以后回头改字了。 用了一个月下来，我几乎忘了语音输入还有「纠错」这个步骤。
越用越准：自动蒸馏的数据闭环
ambient-voice 有一个让我觉得特别巧妙的设计：它会自己变好，而且你什么都不用做。
每次你用语音输入，转写结果会自动保存在本地。注入文字之后，系统会开一个 30 秒的观测窗口——通过 AX API 监测你在焦点应用里有没有做修改。如果你把「人工智能」改成了「人工职能」，这条修改就会被记录为一条纠错训练数据。
后台有一条蒸馏管线在工作：一路用 Whisper 重新转写你的原始音频（作为高质量参考），另一路用 SpeechAnalyzer 的原始输出配合本地小模型做纠正。两路结果合并加权后，通过 QLoRA 微调本地 Qwen3 模型，导出为 GGUF 格式跑在 ollama 上，用于文本润色。
重点是：这个过程完全自动，强模型蒸馏为主，用户纠错只是可选的辅助信号。 你不需要手动标注任何东西，不需要训练任何模型，甚至不需要知道这个过程在发生。你只会感觉到，用了两周之后，识别结果比第一天更准了。
会议模式：端侧说话人分离
除了日常的语音输入，ambient-voice 还支持会议转录场景。
按 ⌘M 开始录音，屏幕上会出现一个悬浮面板实时显示转录结果。录音结束后，FluidAudio 在本地通过 CoreML 进行说话人分离——它能识别出会议中有几个人在说话，以及每段话分别是谁说的。
最终输出是一个 Markdown 文件，带有时间戳、说话人标签和完整文本。你可以直接放进 Obsidian、Notion 或者任何 Markdown 编辑器。
整个过程不联网，不上传，会议里所有人的声音和内容都留在你的 Mac 上。对于涉及敏感信息的商务会议，这个特性不是「有了更好」，而是「没有就不能用」。
对比：ambient-voice vs 现有方案
| ambient-voice | Whisper 本地 | 讯飞/云端 | macOS 听写 | |
|---|---|---|---|---|
| 处理位置 | 端侧（Neural Engine） | 端侧（CPU/GPU） | 云端 | 端侧 |
| 隐私 | 数据不出设备 | 数据不出设备 | 音频上传服务器 | 数据不出设备 |
| 成本 | 免费 | 免费 | 按量付费 | 免费 |
| 内存占用 | 极低（系统框架） | 几 GB（加载模型） | 低（客户端） | 低 |
| 上下文感知 | ✅ 屏幕 OCR + 偏置 | ❌ | ❌ | ❌ |
| 自我进化 | ✅ 自动蒸馏 | ❌ | ❌ | ❌ |
| 会议模式 | ✅ 说话人分离 | ❌ | 部分支持 | ❌ |
| 系统升级受益 | ✅ 自动 | ❌ 需手动更新 | ❌ | ✅ |
如果你只是偶尔用语音输入发微信，macOS 自带的听写够用了。但如果你每天大量用语音输入写文档、写代码、开会，ambient-voice 的上下文偏置和自我进化机制会让你体验到明显不同的准确率。
使用门槛和安装
需要说明的是，ambient-voice 目前处于早期阶段，有一定使用门槛：
- 系统要求：macOS 26（Tahoe）及以上 + Apple Silicon（M1 及以上）
- 安装方式：目前是 git clone + make install，还没有 Homebrew Cask 或 DMG 安装包
- 开源协议：MIT，完整源码在 GitHub
坦白说，如果你不熟悉命令行，现阶段上手会有些门槛。但如果你是 Mac 开发者或者习惯用 Homebrew 的用户，安装过程很顺畅。后续计划推出 Homebrew Cask 和 DMG 包。
写在最后
我做 ambient-voice 的初衷很简单：Mac 上的语音输入应该用 Mac 的能力。
苹果在 macOS 26 里放了一整套端侧 AI 框架——语音识别、OCR、端侧推理、音频分析——这些能力就摆在那里，只是还没有人把它们串起来做成一个完整的产品。
ambient-voice 是一个尝试。它不完美，有些地方还在打磨，但核心机制——屏幕上下文偏置、自动蒸馏进化、全端侧处理——这些设计我认为是正确的方向。
如果你也觉得语音输入应该更懂你在做什么，欢迎来 GitHub 试用和反馈。
