给并行智能体口述提示词，一条任务线一条地喂

第一次并排跑两个编程智能体的时候，你会觉得有什么地方不对，但要过一会儿才叫得出它的名字。每个智能体都很快。单独看，任何一个都是明显的净赚。两个加起来，本该是双倍的净赚。结果这一天反而比只用一个的时候更碎，等到下午收摊，完成的事情比预期还少。

原因不在智能体身上，而在它们所需要的那种输入的形状。编程智能体靠散文运转：“把这个 handler 拆开，公开签名别动，给超时那条路径加一个测试。”散文想起来便宜，送到位却很贵，因为送到位意味着在恰当的时刻把你的手和注意力放进恰当的窗口。只有一个智能体时，那个时刻和你自己的节奏是对齐的。有三个时，时刻什么时候来就什么时候来，而每一次都会打断你正在做的事。

这篇文章讲的是“送到位”的问题，不是“想清楚”的问题。它是一套在 Mac 上给并行智能体任务线口述提示词的实用工作流，连诚实的边界一起写进去。如果你还没读过用声音驱动 Claude Code，那篇讲的是单条任务线的基础；这一篇假设你已经在同时跑好几条了。

为什么并行任务线偏偏惩罚打字

一条提示词有三笔成本：想出来、送过去、之后再回来。想出来是躲不掉的，而且大多发生在脑子里。用打字送过去，意味着把焦点切到智能体的终端、找到输入行、敲下四十到八十个词、按回车。回来，意味着回到智能体叫你之前你正在做的那件事。

只有一条任务线时，送达成本很小，因为你本来大概就在看那个终端。并行任务线里，你几乎从来不在看。你正读着任务线二的 diff，任务线一提了个问题。问题很简单，答案就一句话。可要回答就得离开这份 diff，等你回来，还得把最后三十行重读一遍才找到刚才看到哪里。

把这乘上每一次纠偏、每一句“对，继续”、每一句“不是那个文件”，开销就叠起来了。并行任务线失败不是因为智能体慢，而是因为你变成了消息总线 — 而一条必须在窗口之间物理移动的消息总线，延迟糟糕得要命。

语音拿掉了送达成本的绝大部分。眼睛留在 diff 上，按住一个键，把那句话说出来，松开。文字落进智能体的输入框。你哪儿都没去。

真正跑得起来的配置

配置就在下面，我故意让它显得乏味。

热键，不是窗口。 Keebye 待在菜单栏里，监听一个可按住也可轻点的热键（默认是右 ⌘；Fn 和右 ⌥ 是另外两个选项，Esc 取消进行中的听写）。没有窗口要打开，也没有模式要进入。按住、说、松开。这件事比它听起来更重要：一个需要自己窗口的听写工具，只是又多了一条任务线。

插入到聚焦的输入框。 转写好的文字会插入到光标所在的位置。默认走粘贴，并带有理解终端的分块，好让一条长提示词不会冲垮 shell。如果你的智能体跑在 tmux 里或者跑在 SSH 那头，粘贴的表现会很难看，那就有一个需要自己开启的合成按键模式，把文字当成 Unicode 按键敲进去；什么时候该切过去，在终端里活下来的听写里讲了。

批量，不是流式。 Keebye 在松键那一刻转写，作为一次完整的发声。你不会看到字随着你说话一个个冒出来。对提示词来说这才是对的取舍：你想要的是整句话一次性、清理好地落下去，而不是眼看着它一个词一个词长出来，同时智能体的输入框里已经躺着半个念头。

全部在端侧。 转写在本地运行（默认是一个针对英语调校的模型，你也可以选择开启 25 种语言的那个）。模型下载完成后，关掉 Wi-Fi 也照样能用。给智能体写提示词这件事上，这不太关乎隐私姿态，更关乎延迟：没有往返，所以一条短提示词几乎在你松键的同时就准备好了。

一种切换任务线的节奏

最后真正留下来的工作流有三个习惯。

眼睛留在需要判断的那条任务线上。 任何时刻，都有一条任务线是你的注意力该待的地方，通常是一份 diff 或者一段测试输出。你读的就是那一条。其他几条只拿到简短的口头指令。当任务线二需要一个决定时，你瞥一眼，点进它的输入框，按住键，把决定说出来，松开，再点回来。那次点击是唯一的机械成本；句子本身是免费的。

提示词要用完整的句子说出来。 智能体处理完整句子比处理电报式碎片更好，而听写天然产出完整句子，因为人说话就是那样。“把 schema 的改动回退掉，但保留 API 的重命名，然后重跑迁移并把输出给我看”是一条相当好的口述提示词，打字打出来却只是件苦差事。

语气词被剥掉，意思不动。 Keebye 的清理默认是基于规则的：它去掉“嗯”“呃”和重复的词，你的措辞原样留着。另外还有一个可选的端侧本地 LLM 润色，让句子更利落，背后由一道忠实度防护兜着 — 当润色版出现严重的 token 丢失、失控扩写或重复时，就回退到字面的转写。那道防护是一种启发式判断，不是语义检查：它不会验证润色后的文字保住了你的意思或者某处否定。给智能体写提示词时，大多数人把润色关着；字面的转写就是你说过的话，而那正是你想让智能体去执行的东西。

语音适合做什么，按任务线分

不是每条提示词都想被说出来。用了几个月之后，大致是这样分的。

纠偏和继续：永远用语音。 “继续。”“不，是另一个配置。”“给空值那种情况加个测试再重跑。”这些是并行会话里量最大的提示词，而且全都只有一口气长。

评审反馈：大多用语音。 一边读 diff 一边把它哪里不对讲出来，是很自然的事。“这个重试循环把错误吞掉了，在 sleep 之前记一条日志，并且把尝试次数封在五次。”听写会以你说话的速度把这句接住，而你的眼睛还在代码上。

最初的任务说明：混着来。 一份又长又有结构、带文件路径和约束条件的说明，仍然更适合打字，或者先口述一个粗糙版本再编辑。散文部分用语音没问题；精确的标识符打字更省事。自定义词典在这里帮得上：把项目的模块名和反复出现的行话录进去一次，它们就不会再被转写成最接近的那个英文词。

任何带代码的：打字。 口述正则表达式是一段难受的时光。请口述指令（“写一个匹配版本头的正则”），别口述成品。

诚实的边界

其中有些是 Keebye 的，有些是整个品类的。

第一次听写的延迟。 麦克风会在一次会话的第一次听写之后预热，此后保留 500 毫秒预滚缓冲。一天里最早的那一次按住可能要付流启动的成本，而在缓冲还没接上之前说出来的词仍然可能被切掉。机制在听写应用为什么会吃掉你的第一个词里。

标识符的准确率。 蛇形命名的变量名和内部缩写，是任何语音模型都吃力的地方。词典能减少这件事，但消不掉。在按下回车做任何破坏性操作之前，先把提示词读一遍。

安全输入框。 Keebye 拒绝往密码框和安全输入框里插入文字。这是刻意的，偶尔在终端问你口令的时候会不方便。

没有语音命令。 没有“换行”“全选”这类词汇。Keebye 是一个听写工具，不是一层语音控制。任务线之间的切换，仍然靠点击或者键盘快捷键。

只有 macOS。 Windows 版本没有发布。

接下来去哪儿

如果你的智能体基本都住在一个编辑器里，Cursor 和给 Claude Code 用的语音听写这两篇指南有逐个工具的具体做法。如果你正在为这套工作流挑听写应用，Keebye vs Superwhisper 是一份诚实的比较，也写了 Superwhisper 在哪些地方更合适。

上面这一切的简版：并行智能体不需要你打得更快，它们需要你不再是它们之间最慢的那一跳。眼睛留在需要判断的那条任务线上，剩下的用嘴说。