在终端里活下来的听写

试用听写工具的开发者常常撞上一种形状非常具体的失败。工具在演示里表现完美。它在备忘录里能用，在 Slack 里能用，在浏览器里能用。然后你聚焦一个终端，口述一句话，结果要么什么都没出现，要么出现的东西不是你说的，要么一半出现了、另一半莫名其妙跑进了你的剪贴板。有时它在本地好好的，你一 SSH 进某台机器它就死了。

这个模式一致到让我不认为它是某一款产品的 bug。它是这个品类插入文本的方式带来的后果 — 而它恰恰在开发者生活的地方失效。

这件事今天比两年前更要紧。如果你用声音驱动 Claude Code — 也就是我在用声音驱动 Claude Code里描述的那套工作流 — 那终端就不是众多应用中的一个。它就是那个应用。它是你的提示词落地的地方，是你的智能体等着被纠偏的地方，是整套并行任务线要么成立、要么不成立的地方。一个在终端里时灵时不灵的听写工具，对一个氛围编程者来说，就是在它唯一的本职工作上时灵时不灵。

为什么粘贴偏偏在开发者生活的地方坏掉？

这里是品类层面的机制。大多数听写工具插入文本的方式都一样：把转写好的句子放到系统剪贴板上，然后在聚焦的应用处合成一次 Cmd+V 按键。这是个合理的默认 — 粘贴是瞬时的，几乎在每一个 GUI 文本输入框里都能用，而且几乎不需要为每个应用单独做工程。

问题在于这个假设悄悄依赖的那一切。

它依赖聚焦的应用把 Cmd+V 当作“粘贴”。终端常常不这么认为 — 很多终端把 Cmd+V 用作别的功能，或者干脆什么都不做；tmux 和 vim 对粘贴意味着什么有自己的一套想法；而一个远程 SSH 会话解释一串粘贴文本的方式，本地机器无法预测。括号粘贴、复制模式、插入模式与普通模式之分：终端世界里满是那种会让一次合成粘贴落错地方、或者根本不落地的状态。

它依赖剪贴板是可用且无人看守的。剪贴板管理器会改写它。密码管理器会刻意清空或保护它 — 一个安全特性，把“粘贴我的听写”变成了“什么都没粘贴”，而且悄无声息。就算一切正常，这个工具也刚刚覆盖掉了你复制的东西。你正在窗口之间搬运的那个提交 SHA 没了，被你自己的句子取代。对一个同时照看好几条任务线的人来说，这不是小划伤；那个剪贴板本来是在干活的。

它还依赖 — 这一条会让人意外 — 你的键盘布局。当一个工具退回去模拟按键时，最朴素的做法是发送键码：也就是物理按键位置。键码要经过你的布局才映射到字符。在 QWERTY 上，“V”的键码产生一个 V。在 Dvorak 上，同一个物理位置是另一个字母。所以一个在 Dvorak、AZERTY 或 Colemak 布局上模拟扫描码的工具，产出的文本看上去像是过了一遍替换密码。用户报告说是乱码，然后以为语音识别失败了。它没有 — 语音是完美的，是插入环节把它打乱了。

这里面没有谁在使坏或者偷懒。剪贴板粘贴对 90% 的情况来说是正确的默认。只不过开发者一整天都待在剩下的那 10% 里。

“改成键入”到底是什么意思

Keebye 有一个叫 insert_mode 的设置，它有两个值：paste，也就是默认值，和 type。

模拟键入模式不粘贴。在 macOS 上它使用 CGEventKeyboardSetUnicodeString — 一个能把真正的 Unicode 文本附在合成按键事件上的 API。字符是由事件本身携带的，不经过你的键盘布局去查表。这让它在构造上就与布局无关：Dvorak、AZERTY、Colemak，不管你用什么打字，到达的文本就是被转写出来的文本，因为压根就不存在一次可能出错的扫描码到字符的翻译。

模拟键入模式的第二个性质，才是终端用户真正在意的：它从不碰剪贴板。那条代码路径上的剪贴板操作数为零。你的剪贴板内容还是你的 — SHA 活了下来，密码管理器没有什么需要提防的，剪贴板管理器也没有什么可记录的。

而且因为终端和远程会话可能被快于任何人类打字速度的文本噎住，模拟键入模式会刻意控制自己的节奏：文本以 16 个字符为一块送入，块与块之间间隔 4 毫秒。快到一句话远远不到一秒就能落地；又克制到一个跨 SSH 的 tmux 面板把它当作跟得上的按键接收，而不是一坨需要解释的东西。

粘贴模式仍然在，也仍然是默认，因为在普通 GUI 应用里处理大段文本时它确实更快 — 一条三段话的 Slack 消息作为一次粘贴到达，而不是一串分块。不过就连粘贴模式也吸取了布局的教训：那次合成的 Cmd+V 使用 V 的物理键码，所以粘贴本身不会像基于字符查表的做法那样在非 QWERTY 布局上坏掉。

给智能体工作用的实际配置很简单：把 insert_mode 切到 type，聚焦跑着 Claude Code 的终端，按住键，说出纠偏指令，松开。提示词到达的方式和按键一样，因为在终端看来，它们本来就是按键。这套配置的分步版本，包括 SSH 和 tmux 的具体细节，在给 macOS 终端用的语音听写里。

诚实说说限制

对长文本来说，模拟键入模式比粘贴慢 — 这是算术，不是缺陷。带节奏间隔的分块按键，耗时长于单次粘贴事件；如果你要往一份文档里口述好几段话，粘贴模式会更利索。这正是粘贴仍然是默认、而模拟键入需要你在设置里主动开启的原因；该用哪种模式，取决于你的文字要去哪里。

有些应用会对合成输入做限速或过滤，通常出于安全原因，而没有哪种插入策略能完全绕开这一点 — 一个拒绝合成事件的应用，会拒绝来自每一款听写工具的合成事件。

再把这篇文章在主张什么、不在主张什么说清楚：粘贴在终端里失效这件抱怨，是整个听写品类的共有模式，不是某个竞品独有的缺陷。别的工具有它们自己的答案和自己的长处 — 我们在 Keebye vs Superwhisper 和 Keebye vs Wispr Flow 写了诚实的比较，也包括它们各自在哪些方面可能更适合你。

插入是听写里不体面的那一半

语音识别拿走了全部注意力 — 模型名字、准确率宣称、语言数量。但一个听写工具有两项工作：正确地听懂你，然后把文字送到你的光标所在处，既不丢也不乱。第二项工作听起来微不足道，却正是这个品类悄悄辜负开发者的地方，因为第二项工作在 TextEdit 里很容易，在一台远程机器上、Dvorak 布局下的一个 tmux 面板里很难。

如果你的提示词要落进终端 — 而如果你在驱动编程智能体，它们就是要落进终端 — 那插入就不是脚注。它是一个你拿来演示的工具和一个你真正在用的工具之间的差别。顺带一提，相关的失败模式味道也一样：听写的第一个词在麦克风醒过来之前被吃掉，是另一个全品类的抱怨，同样有机械层面的解释，我们把它写在了听写应用为什么会吃掉你的第一个词里。

Keebye 处于 macOS 早期访问阶段。如果你的听写曾经在嘴巴和终端之间的某处消失过，在下方开始你的免费试用，打开模拟键入模式，再试一遍同一条提示词。你复制的那个 SHA 会留在剪贴板上，而文字会以键入的 Unicode 到达。