同样一句话交给 Codex，结果可能差很远。差别不在它，在你怎么写。一个说得清楚的任务，会把目标，背景，范围，约束，验证方式和交付要求都带上。

六个要素

目标是第一位的，一句话说清你想要的结果，比如修复登录页刷新后状态丢失的问题。

背景补充现象和上下文，说明用户刷新页面之后需要重新登录。

范围限定它能动哪些文件，比如只改 auth 模块和相关的测试。

约束写明禁止事项，不改数据库 schema，不引入新的依赖。

验证给出跑什么命令或者检查什么结果，比如运行 pnpm test auth。

交付要求它最后怎么汇报，说清根因，改了什么，测试结果和剩余风险。

模糊和清晰差在哪

模糊的写法是帮我优化登录逻辑。这句话里没有一个可验证的点，它只能猜。

清晰写法会展开成一段话：请修复登录页刷新后状态丢失的问题。背景是用户登录后刷新页面会回到未登录状态，期望刷新后仍能恢复。范围是优先检查 src/auth 和相关测试，不改数据库和后端接口。验证是运行 pnpm test auth，如果需要新增测试，覆盖刷新恢复状态的场景。交付是说明根因，改动了哪些文件，验证结果和剩余风险。

同一件事，后面这种写法它基本不会跑偏。

大任务拆成三步

大任务不要一次交出去。先让它只读分析，找出影响面。再让它给出切分方式和验证方式。最后分步实施，每次只做一个能验证的改动。

第一步的指令可以这么写：先不要修改代码，阅读某个模块，分析目标会影响哪些文件、接口和测试，然后输出影响面，推荐实施步骤，每一步的验证方式，以及第一阶段的最小改动建议。

让它主动暴露不确定

有一句话值得常备：如果需要推测，请明确标注推测。如果官方文档、代码和测试之间有冲突，请先停下来说明冲突。

这句话在文档更新，版本升级，依赖迁移和跨模块改动这几类任务里特别有用。它宁可停下问你，也不该猜着往下做。