Agent prompt 并不总是短命令。它经常包含上下文、限制、观察到的失败，以及你希望 agent 做出的下一步判断。在手机上输入这类 prompt，可能比任务本身还慢。
语音输入适合进入移动端 coding 工作流，是因为工作单元已经发生变化。当你控制 coding agent 时，很多时候是在描述意图，而不是逐字符写代码。只要转写结果不会直接发送到终端，而是先进入可编辑的待输入区，语音就能成为很高效的 prompt 草稿方式。
语音可行，是因为输入变成了意图
当你控制 coding agent 时，很多输入都是自然语言。你可能会说明哪里失败、让它看哪个文件、运行哪个测试、偏好哪种取舍。这非常适合语音，尤其是在离开书桌时。
一个有用的语音 prompt 可能会变成：
支付 webhook 测试在 retry 改动后失败了。先检查 handler 和 fixture，保持外部 response shape 不变，补一个 focused regression test，然后只运行 webhook 测试。
这不是简单 Shell 命令，而是一条紧凑的开发指令。手机上说出来，通常比打出来更快。
但语音不应该直接发送
终端输入仍然需要精确。模型名、文件路径、命令名、分支、代码符号都可能被听错。转写模型可能把 src/auth/session.ts 识别成相似短语，也可能漏掉 --watch=false 这样的 flag。
因此 Redock 会先把转写结果放入待输入区。你检查、修改后，再发送到终端。这对安全和准确性都很重要：
- 你可以先修正文件路径。
- 你可以删除无意中说出的敏感上下文。
- 你可以把口语化草稿改成清晰 prompt。
- 你可以把终端输出一起粘贴进待输入区。
- 你可以在检查后决定不发送。
语音应该加快草稿，而不是取消开发者控制。
供应商选择很重要
Apple Speech 对简单听写很方便，也不需要 API Key。短中文或英文输入可以先用它。
OpenAI、火山豆包这类模型供应商，通常更适合中英混合、命令名、技术词、较长 agent prompt。Redock 支持多个供应商，是为了让开发者按准确率、延迟、地区、账号体系选择适合自己的方案。
| 供应商类型 | 适合场景 | 注意事项 |
|---|---|---|
| Apple Speech | 简单听写，无需额外配置 | 中英混合和技术词可能不稳定 |
| OpenAI speech | 多语言 prompt、技术表达 | 需要自己的 API Key 和额度 |
| 火山豆包 | 中文和中英混合场景 | 需要配置资源字段和 APP Key |
| OpenAI-compatible | 团队已有转写基础设施 | Base URL、model、API Key 要匹配 |
使用 OpenAI speech 时，Redock 需要 API Key，因为录音会发送给你选择的供应商进行转写。使用豆包或其他供应商时，需要填写对应控制台要求的字段。Redock 的职责是把转写结果放回可编辑的终端输入。
适合 coding agent 的语音 prompt
语音最好用来表达结构化意图。不要把所有信息无结构地说成一长串，可以使用一个简单模式：
- 说明观察到的问题。
- 如果知道，指出可能相关的文件或模块。
- 加上必须保留的限制条件。
- 要求 agent 执行验证步骤。
- 要求 agent 在修改前或修改后总结。
例如：
设置页在 API 返回空 profile 时崩溃。先看 profile normalization 逻辑，不要改 API client 接口。补一个空 profile 的 regression test，只运行 settings test。
这样的 prompt 对人和 agent 都更友好，因为它包含上下文、边界和成功标准。
什么时候不该用语音
语音并不适合所有输入。不要用它输入密钥、精确的一行复杂 Shell 命令、敏感生产细节，或任何你无法冷静检查后再发送的内容。这些场景更适合 snippets、粘贴或手动待输入。
如果终端内容涉及 rm、部署命令、数据库迁移或生产凭据，更要仔细检查最终文本。语音适合准备意图，不适合盲目执行危险命令。
快速结论
语音输入对移动 AI coding 有价值，是因为 agent prompt 往往是自然语言指令，而不只是 Shell 命令。Redock 把语音转写放入可编辑待输入区，让开发者先检查再发送。简单听写可以用 Apple Speech，复杂中英混合技术 prompt 可以选择 OpenAI 或火山豆包，精确命令则更适合 snippets 或手动输入。