开发者工作流
在 Mac 上用语音辅助编程
说清一个问题、描述一项修改，或口述一条评审意见。把脑中的背景和思路整理成编程助手能理解的提示词。
这份工作流程由 Openbroca 编写，Cursor、Claude Code 和 Codex 作为输入目标示例。
实用原则
口述问题、相关背景、约束条件和预期行为，补充示例与评审要点，再把草稿用于编辑器或编程助手。
语音输入在哪些开发任务中最有价值？
语音输入并不适合更快地键入程序的每个字符，它适合输入围绕代码产生的大量自然语言。现代开发包含解释 Bug、规划改动、审查 Diff、填写 Issue，以及向 AI 编程工具说明预期结果。它们都是完整想法，而完整想法正是语音擅长的内容。
Openbroca 可以把语音输入带到你已打开的编辑器或聊天输入框。按下快捷键，说出草稿，整理后的文字就在当前应用中继续使用。
AI 编程提示
说明目标、相关文件、约束、边界情况和预期测试。结构清楚的任务说明比一连串零散命令更有用。
Bug 复现记录
趁操作过程仍然清楚时，依次说明做了什么、实际发生什么、预期结果以及运行环境。
代码审查评论
用自然语言解释风险和希望修改的行为，再用键盘补充精确符号与行号。
文档与发布说明
先说清用户可见行为，再在检查阶段统一术语与代码示例。
日报与交接
记录决定、阻塞和下一步，不必为了排版每句话而中断思路。
一套可重复的语音辅助编程流程
把听写看成编程工具之前的一层输入方式，而不是编程工具本身。安全流程必须在语音和实际动作之间保留人工检查。
- 1
先聚焦准确的目标输入框。
点击提示框、Issue 正文、审查评论或文档。除非准备逐字符检查后再按回车，否则不要直接对着活跃的终端提示符听写。
- 2
先说最终结果。
先说明工作完成后应该满足什么，再补充范围、约束、相关文件、不做什么和需要通过的检查。
- 3
自然说出改口后的决定。
需求在说话过程中改变时，要明确说出最终决定。文字整理可以去掉一部分口头语和改口，但你仍需确认最终约束没有丢失。
- 4
用键盘修正精确 Token。
包名、参数、正则表达式、大小写敏感标识符和路径，都应该手动检查和修正。
- 5
检查后再提交或执行。
重点检查否定词、删除类动词、路径、数字、密钥和验收条件，然后再发送提示或执行命令。
示例：把凌乱想法整理成编程任务说明
趁思路清楚时，一次说出目标、限制和改口后的决定，再确认整理后的任务说明是否保留了最终要求。
Openbroca 示意流程
口述草稿
“在 auth callback 里面先检查 state 再换 code，不对，应该先确认 state 只能用一次，不要加新 endpoint，然后补一个重复使用的回归测试。”
整理后的文字
“在现有 auth callback 中，先验证 state 有效且只能使用一次，再交换 code。不要新增 endpoint。补充回归测试，证明已经消费的 state 无法再次使用。”
以下为整理前后的示意例子。
在不同编程工具中沿用同一表达结构
无论在 Cursor、Claude Code、Codex、Issue 系统还是审查表单中，都可以先说清同样几件事：要改什么、相关文件、限制条件和验证方法，再用键盘补充精确路径与代码片段。
| 目标位置 | 适合用语音 | 保留给键盘 |
|---|---|---|
| AI 编程对话框 | 目标、文件、约束、边界情况、测试 | 精确代码片段与敏感值 |
| 编辑器或文档 | 解释、评论、ADR、发布说明 | 标识符、标记细节、代码块 |
| Pull Request 审查 | 风险、理由、期望行为 | 行号和替换语法 |
| Issue 系统 | 复现步骤、预期结果、环境 | 确认不含密钥后的日志 |
| 终端 | 先在安全文本框中起草命令 | 最终命令、路径、参数与执行 |
教会项目术语，但不要发送过量上下文
个人词典适合保存仓库名、产品名、缩写和生僻库名，只需添加反复识别错误的词。Openbroca 的词典可以为语音识别和文字整理提供首选拼写；可选的屏幕上下文则能使用可见术语帮助判断人名和专有词。
提供上下文不等于发送一切。密码、访问 Token、私钥、客户记录和未公开秘密都不应进入口述文本。不需要屏幕上下文时应关闭该功能。产品使用云服务并需要联网，因此在工作仓库采用前，应根据公司规范检查 数据处理政策。
哪些场景仍然应该使用键盘？
代码和命令中的每个符号都可能影响结果。斜杠、引号、转义和大小写，通常更适合用键盘输入并检查。命令可能删除数据、Token 必须保密，或标识符短到直接输入更快时，也应使用键盘。
代码与正则表达式
用语音解释转换目标和示例，用键盘输入最终语法。
Shell 命令与数据库迁移
先在不会自动执行的文本框中起草，确认路径与参数，再主动粘贴。不要让听写结果在写入后立即运行。
密钥与客户数据
不要口述，应使用经过批准的密码管理器、Secret Store 或安全流程。
极小修改
修正两个字符通常比重新听写更快，也更可靠。
如何判断语音输入是否真的提高编程效率？
不要只测每分钟字数，应测量从产生想法到得到一段愿意提交的提示、评论或说明所需的总时间。转写很快但需要大量修复，并不是真正快速的工作流。
如果第一次使用系统级听写，可以先阅读完整的 Mac 语音输入指南；如果正在比较 AI 听写产品，可查看带来源与限制说明的 Openbroca 与 Typeless 对比。
- 1
选择十个真实任务。
至少包含 AI 提示、Bug 报告、审查评论、技术解释和一个含项目术语的任务。
- 2
固定麦克风与环境。
环境不同会让工具比较失去意义。
- 3
记录完整耗时。
把听写、等待、键盘修复与最终检查全部计入，而不是只测识别延迟。
- 4
记录后果严重的错误。
错误的否定词、路径、数字或安全约束，比标点外观更值得关注。
- 5
只在真正占优的任务中保留语音。
很多开发者最终会采用混合方式：语音负责自然语言和规划，键盘负责精确实现。