你打开 Codex，准备让它处理一个小改动：把用户设置页里的通知开关逻辑调整一下，顺手补一个测试。手已经放在键盘上，输入框里却只敲出一句“帮我优化通知设置”。这句话看起来省事，但对 Codex 来说，缺的东西很多：要改哪个页面，当前问题是什么，哪些文件可以动，哪些行为不能变，测试要跑到什么程度。

很多开发者用 AI 编程工具时，真正消耗时间的不是点开工具，而是把任务说清楚。尤其是改动牵涉到已有逻辑、兼容性、测试范围时，一句短 prompt 往往会让 AI 先猜，再改，再被你纠正。来回几轮以后，节省下来的时间又被沟通成本吃掉了。

SaySo 适合介入的地方，正是这段“我知道要做什么，但懒得完整打出来”的表达过程。你可以按 Fn，直接把任务讲一遍：

“帮我改一下用户设置页的通知开关逻辑，主要问题是现在关闭邮件通知以后，系统通知也会被一起禁用。文件范围先看 settings notification 相关组件和 hook，不要改后端接口。目标是邮件通知和系统通知互不影响，保留原来的默认值逻辑。改完以后补一个组件测试，覆盖关闭邮件通知时系统通知仍然开启的情况。跑一下相关测试，如果发现已有测试依赖旧逻辑，也一起说明原因。”

说完后，SaySo 会把这段口述整理成更适合放进 Codex 的任务描述，而不是把口头语原样塞进去。整理后的文本通常会更接近这样的形态：

目标：修复用户设置页通知开关之间的联动问题。

背景：当前关闭邮件通知后，系统通知也会被一起禁用，预期是两类通知互不影响。

范围：优先检查 settings notification 相关组件和 hook；不要修改后端接口。

要求：保留现有默认值逻辑，确保邮件通知关闭时不影响系统通知状态。

测试：补充组件测试，覆盖“关闭邮件通知后系统通知仍保持开启”的场景；运行相关测试并说明结果。

这样的输入，对 Codex 更友好。它能更快判断任务边界，也更容易在执行过程中保持方向一致。这里的关键不在于语音比键盘高级，而在于开发任务经常包含背景、约束、验收标准和测试要求。把这些内容完整打出来，很多人会嫌麻烦；但直接讲出来，反而更接近脑子里原本的思考顺序。

在实际使用里，可以把给 Codex 派活拆成四句话来说。第一句讲目标：这次要解决什么问题。第二句讲范围：优先看哪些文件或模块，哪些地方不要动。第三句讲约束：兼容性、接口、样式、性能、权限等边界。第四句讲验收：希望它补什么测试，运行什么命令，输出什么结果。

例如你可以这样说：

“这次只处理前端表单校验。目标是手机号为空时不要触发接口请求。范围在 signup form 和 useSignup hook，先不要改接口 SDK。需要保留现有错误提示样式。改完补一个测试，覆盖空手机号点击提交时不会调用 submit API，并跑相关测试。”

SaySo 的作用，是把这种自然口述整理成可执行文本。你仍然需要判断任务是否合理，也需要 Review Codex 的改动；它不会替你决定架构，也不应该替你跳过测试。但在“派任务”这个环节，它能减少很多低价值输入：少一点反复补充背景，少一点一句话 prompt 带来的误解，多一点一次说清楚的机会。

有些场景打字更合适，比如只改一个变量名，或者补一行注释，键盘会更快。SaySo 更适合那些需要解释上下文的任务：重构、排错、补测试、写文档、整理 PR、生成技术方案。任务越需要上下文，越适合先说出来。

对开发者来说，Codex 能不能顺利执行，很多时候取决于你给它的第一段指令。把需求描述写清楚，不是形式主义，而是在给 AI 缩小搜索空间。按 Fn 说出想法，话落字现，再把口头表达整理成可用文字，这就是 SaySo 在 AI 编程工作流里比较自然的位置。

官网：SaySo - Mac 与 Windows AI 语音助手 | 语音转文字，效率提升10倍
邀请码：LW8J528A