向 Codex 下达清晰任务的方法

代理的产出质量很大程度取决于任务表达。下达清晰任务就是把背景、目标、边界、验收标准和参考材料一次讲透，减少来回试探与越界发挥。本节给出结构化模板与常见改写对照，适用于 codex 交互会话与 codex exec 非交互任务。

一、好任务的五个要素

要素	要写清的内容	缺失的后果
背景	项目现状、要解决的问题或痛点	代理只能猜测上下文，方案容易跑偏
目标	具体要达成什么结果，一句可检验的目标陈述	输出宽泛、无法判断完成与否
范围约束	改哪些、不改哪些、禁止引入的依赖与改动面	夹带重构、越权修改、范围膨胀
验收标准	如何算完成：测试、行为结果、不得出现的问题	交付无客观标准，全凭感觉接受
参考材料	关键文件路径、现有约定、运行/测试命令入口	盲目探索、重复读取、结论缺依据

二、从模糊到清晰的改写对照

模糊指令（不推荐）	结构化指令（推荐）
"帮我优化一下这个模块"	"背景：模块 A 存在两处重复参数校验；目标：合并重复逻辑、保持对外行为不变；约束：只改 src/validate 下文件、不新增依赖、不改动公开函数签名；验收：现有测试全部通过、diff 不含命名重构。"
"写个功能"	说明功能用途、输入输出、边界条件、可接受的实现范围与对应测试要求。
"把代码改得规范点"	明确依据哪份既有风格约定、限定目录、列出必须统一的具体项（命名/缩进/注释），避免大面积无依据重写。

三、可直接套用的任务模板

背景：（项目与问题现状，关键文件路径）
目标：（本次要达成的单一结果）
范围约束：
  - 只允许修改：（文件/目录清单）
  - 不允许：（改签名、加依赖、联网、删测试、调整其他模块）
验收标准：
  1.（可运行的测试/构建要求）
  2.（行为不变或目标行为达成）
  3.（diff 范围控制要求）
参考：（现有命令、相关文件、约定文档位置）
先给出方案，我确认后再实现。

四、多轮迭代中的任务补充

1. 先总后分：第一轮给整体目标与边界，后续轮次补充细节、纠正方向，不必一次堆砌全部信息。
2. 纠偏要具体：不说"不对、重来"，而指出"保留 A、撤销 B、原因是 C、改为 D"，降低反复成本。
3. 小步提交目标：把大任务拆成可独立验证的小目标逐轮推进，每轮都能运行检查。
4. 显式要求先方案：对中等以上任务，结尾要求先输出文件清单与步骤，确认后再动手（呼应计划模式）。

五、FAQ

问题	处理建议
任务写多长合适	要素齐全即可，不必长篇；关键是目标可检验、边界明确、材料定位清楚。
一次塞多个不相关目标	拆成多个会话或多轮小任务；混题会导致上下文交叉、结论互相干扰。
代理总做计划外修改	在约束段显式否定不允许项，并要求先列文件清单；发现越界立即叫停收窄。
codex exec 非交互任务怎么写	把五要素写进单条任务描述，命令与验收前置明确，因无人值守更要把范围和退出条件写死。

六、动手练习

• 练习：把一句模糊需求用五要素模板改写成结构化指令，再按"先方案、后实现、列验收"的顺序下达，对比产出的可控程度。