用你自己的语言口述代码评审

大多数开发者工具里都烤进了一个不出声的假设：代码是英语的，所以开发者也必须是。关键字是英语。库名是英语。报错信息是英语。于是推论就来了：给开发者的听写可以只有英语，没人会介意。

代码评审立刻就把这个假设打破了。一条评审意见不是代码。它是一句写给某个人的话，而在非常多的团队里，那个人和你共用同一门第一语言。一支罗马尼亚团队评审一个 Rust 服务，就是用罗马尼亚语给英语的标识符写意见。波兰团队用波兰语做同样的事，德国团队用德语。代码留在英语里，关于代码的对话不在。

听写对评审意见异常地合适，因为评审是一种阅读活动，而打字会打断阅读。但前提是它在意见实际所用的那门语言里能工作。这篇文章讲的就是怎么让它工作：Keebye 在端侧覆盖哪些语言、语言锁定是怎么表现的、边界在哪里。如果你想看“这为什么重要”的论证，给开发者的听写为什么不该只有英语已经论过了；这一篇是实操的续集。

为什么评审意见是理想的听写对象

评审意见有三个性质，让它比开发者写的几乎任何其他文字都更适合语音。

它短。大多数意见是一到三句话。那是一口气、一次热键按住、一次发声。

它是散文。跟格式僵硬的 commit message 或者语法必须精确的配置文件不同，一条评审意见就是你会怎么把问题说出口。“如果 socket 一直不应答，这里会无限重试；给它封个顶。”说出来的版本和打出来的版本几乎一样。

它发生在你眼睛正忙的时候。你在读一份 diff。你一停下来打字，就丢了自己读到哪儿。听写让你继续读，同时把意见说进你已经点进去的那个输入框。

现在再加上语言这个维度。如果你的团队用波兰语评审，一个只有英语的听写工具就逼你选：用英语评审（不自然，而且同事读起来可能更慢），或者打字（把好处丢掉）。两个都不是你想要的。

Keebye 实际支持什么

这里有两个端侧引擎是相关的，而它们值得说得精确。

默认引擎是针对英语调校的。它快，是大多数人在用的那个，也不是你会想用来写一条波兰语评审意见的那个。把它对着非英语的语音，它会产出语音上说得通的英语 — 而那不是你说的话。

第二个引擎 Canary，覆盖恰好 25 种语言：保加利亚语、克罗地亚语、捷克语、丹麦语、荷兰语、英语、爱沙尼亚语、芬兰语、法语、德语、希腊语、匈牙利语、意大利语、拉脱维亚语、立陶宛语、马耳他语、波兰语、葡萄牙语、罗马尼亚语、俄语、斯洛伐克语、斯洛文尼亚语、西班牙语、瑞典语、乌克兰语。它需要自己开启，下载一次，之后就跟 Keebye 里的其他一切一样离线运行。不是一百种语言；是二十五种，列在这里，而如果你的语言不在名单上，这篇文章今天还帮不了你。

还有一个选项是把 Apple 自带的语音识别用作引擎，那会把你 Mac 上的语言支持带进来。那是一条特性不同的独立路径；这篇文章余下的部分讲的是 Canary。

锁定语言，别让它去猜

对非英语的评审来说，单独最重要的设置就是语言锁定。

自动识别听起来像是对的默认值，对开发者却是错的默认值。评审意见里挤满了英语标识符：函数名、包名，以及 “null”“async”“callback” 这些词。一条八成罗马尼亚语、两成英语 token 的意见，恰好给语言识别器送上它最不会处理的那种混合信号。它会在句子中间翻车，或者干脆判定整句都是英语，而你会拿到一份自信地错着的转写。这种失败在自动识别老是猜错：锁定你的语言里有详细的走查。

在 Canary 上，Keebye 让你显式设定语言。锁定罗马尼亚语，模型就按罗马尼亚语解码；你句子里的那些英语标识符会被当成借词处理，而不是被当成“你切换语言了”的证据。对某个不常见标识符的识别仍然可能不完美，但语言本身不再是一次抛硬币。

有一个行为上的细节值得知道：锁定的语言是为下一次发声读取的。你改了锁定，接下来要做的这次听写就用新的；已经松键的那一次不会被重新转写。实践中就是一句话：先切，再说。如果你一天里用两种语言评审，这次切换很便宜。菜单栏托盘里放着 11 种语言的快速切换短名单，Settings 里放着全部 25 种。

一段口述出来的评审

在一支用罗马尼亚语评审的团队里，一段评审是这样的。

你打开 pull request。托盘上已经显示着昨天锁定的罗马尼亚语，所以什么都不用做。你读第一个文件。第三个 hunk，一个没有上限的重试循环。点进意见框，按住右 ⌘，用罗马尼亚语把意见说出来，松开。文字落下，“嗯”和一次说错的开头被基于规则的清理去掉了，而标识符 reconnectSocket 完好无损，因为你一周前把它加进了自定义词典。

下一个文件。你想留的这条意见是一段代码建议，不是散文。这条你打字。口述 diff 在任何语言里都是糟糕的体验。

再往后，另一个团队的贡献者加入了这个讨论，用英语写。你想用英语回。点托盘，从短名单里挑英语，下一次发声就按英语解码。回完，再切回来。

这些都不需要窗口。Keebye 待在菜单栏里；热键在哪个应用有焦点就在哪个应用里生效 — 打开评审的浏览器标签页、桌面 Git 客户端，或者跑着某个 CLI 评审工具的终端。

诚实的边界

二十五种语言，不是全部。 如果你用土耳其语、日语、阿拉伯语，或者任何在 Canary 名单之外的语言评审，第二个引擎覆盖不了它。Apple 自带的引擎也许可以，取决于你系统的语言支持，但那是一个行为不同的引擎。

托盘短名单是十一种。 英语、罗马尼亚语、法语、德语、西班牙语、意大利语、葡萄牙语、荷兰语、波兰语、俄语、乌克兰语离你两次点击。其余十四种在 Settings 里。如果你日常的那一对里包含比如捷克语和芬兰语，那其中一边要走 Settings。

标识符仍然是标识符。 任何语言的语音模型都会在 snake_case_names 上吃力。反复出现的那些，词典能帮忙；剩下的靠手改。发出去之前先把意见读一遍。

没有实时转写。 Canary 在松键那一刻转写，作为一个批次。你不会在说的时候看到字。对一条一到三句话的评审意见来说，这几乎察觉不到。

润色是可选的，默认是字面的。 如果你开启端侧本地 LLM 润色，它会把句子结构收拾干净，而当输出出现严重的 token 丢失、失控扩写或重复时，一道忠实度防护会回退到原始转写。那道防护是一种启发式判断；它不检查你的意思有没有活下来。在一条否定被翻转就会改变结论的评审意见里，大多数人把润色关着，让基于规则的清理干活。

这件事落在哪里

如果语言锁定是你最在意的功能，Keebye vs Wispr Flow 从语音在哪里运行、语言怎么被处理这两点上比较了它们，也写了 Wispr Flow 在哪里更合适。至于“手还在 diff 上时用语音输入”这个更宽的话题，给构建者的一条真正的输入通道讲日常，给 Mac 用的语音听写讲配置。

“开发者只用英语”这个假设从来就不成立，它只是对工具来说很方便。用自己的语言、用嘴、用永远不离开这台机器的语音处理来做评审，不是一个小众请求。只要工具允许，写软件的人里会有相当大的一部分这么做。