开发者的语音输入：语音写代码、AI Prompt 与终端命令
开发者每天会花很多时间写那些“不是代码”的东西，而且这个时间往往比想象中更多： Pull Request 描述、Code Review 评论、解释架构决策的 Slack 消息、文档、 Commit message，以及给 ChatGPT、Claude 或 Copilot Chat 的 AI prompt。
这些东西本质上都是自然语言。每次你都得从“写代码”的脑内状态切换到“写 prose”， 这种上下文切换会打断编码流。而且，它们几乎都比打字更适合直接说出来。
上下文切换的问题
你正在深挖一个调试现场，终于找到了根因，想顺手留一条代码注释， 解释为什么这个修复成立，好让未来的自己会感谢现在的自己。 但从“读汇编”的思维模式切到“写英文”是有成本的。于是你最后只写了一句敷衍注释， 或者干脆不写。
语音输入会直接消除这层摩擦。按住一个键，把你脑子里的东西说出来，松开。 注释就出现了。你不需要离开编辑器，不需要把手从键盘上挪开超过一秒， 也不需要中断思路。
语音输入在开发者工作流里的位置
代码注释和文档
好的代码注释解释的是 why，而不是 what。 但 “why” 注释要求你把推理说清楚，而这恰恰是语音最擅长的事。 像 “we retry here because the upstream API returns 503 during deployments, which happen every Tuesday at 3am UTC” 这样的注释， 说出来比打出来快，而且产出的文档质量也明显高于一句 “retry on failure”。
AI prompt
如果你在用 ChatGPT、Claude、Cursor 之类的工具，你其实一直都在写 prompt。 好的 prompt 往往很长，包含上下文、约束、示例和具体指令。 打一段 200 词的 prompt 通常要两三分钟，说出来大约只要 45 秒。
OnType 的 Compose 模式在这里特别有用。你可以自然地把 prompt 说出来， 包括中途修正和补充说明，AI 改写引擎会把它整理成结构清晰、表达明确的 prompt。 场景检测还会识别你当前处在 AI 对话界面里，并针对 prompt 质量优化输出：分离上下文和指令、显式写出约束、移除口语痕迹。
Git commit message 和 PR 描述
“fix bug” 这种提交信息，本质上就是不想做上下文切换的产物。 有了语音输入，你可以轻松口述一条真正有信息量的 message： “fix race condition in the connection pool where two goroutines could acquire the same connection if the health check timed out during a resize event.” 这句话说完只要四秒。
Slack 和异步沟通
在 Slack 里解释一个技术决策，经常要写三段话。语音输入能把这件事压缩成 30 秒口述。 OnType 的 Compose 模式在这里同样好用：你可以把原始解释连同岔开的思路和改口一并说出来， 改写引擎会把它整理成一条干净、结构化的消息。
终端和 CLI 输入
OnType 可以直接在终端模拟器里工作，比如 iTerm2、系统 Terminal、Warp 等。 这意味着你可以口述长命令参数、heredoc 内容，甚至交互式 prompt 的输入。 文字会像在其他应用里一样，直接出现在当前光标位置。
为什么它必须是系统级的
有些语音工具只能在自己的窗口里工作，或者只支持特定应用。 对开发者来说，这种限制基本等于失去意义。整个价值点就是你不需要离开当前上下文： 编辑器、终端、或者已经打开 GitHub PR 的浏览器页面。
OnType 是系统级可用的。你在 VS Code 里按热键，文字就进 VS Code。 你在 iTerm2 里按热键，文字就进 iTerm2。你在 Firefox 的 GitHub 评论框里按热键，文字也会出现在那里。不需要从单独听写窗口复制粘贴，也不用切应用。
为什么它必须是设备端的
开发者经常处理专有代码、内部文档和保密项目细节。 如果你把讨论实现细节的语音发送给云服务，相当于平白多造了一个数据暴露面。
OnType 的默认引擎完全运行在你的 Apple Silicon Mac 上。 你的音频，包括所有内部 API 名称、架构决策讨论和未发布功能代号， 都会留在你的设备里。
开始使用
如果你每天有超过一小时在写那些“不是代码”的内容， 就去下载 OnType，试一周。设备端引擎是免费的。 工作流的变化是立刻可感知的：按住键、说话、松开、继续写代码。