第 6 章 / 共 10 章
把任务讲清楚：四要素提示词与计划模式
6.1 效果差距的真正来源
同样的模型、同样的仓库、同样的配置，两个人得到的结果可能天差地别。差别通常不在模型参数，而在需求描述。
对比一下：
❌ 帮我把这个接口优化一下
✅
GET /api/orders在订单量超过一万时响应要 3 秒以上。目标是降到 500ms 以内。当前实现在api/orders.py，怀疑是 N+1 查询。约束：不要改数据库 schema，不要引入新的依赖，分页逻辑保持不变。完成标准：现有测试全部通过，并补一个针对一万条数据的性能测试。
第二种写法长，但它把 Codex 从”猜你想要什么”里解放了出来。
6.2 四要素：目标、上下文、约束、完成标准
官方给出的提示词结构就是这四个要素。逐个拆开看它们各自防住了什么问题：
| 要素 | 回答什么 | 不写会怎样 |
|---|---|---|
| 目标（goal） | 你想要什么结果 | 它会优化一个你不在乎的指标 |
| 上下文（context） | 相关代码在哪、背景是什么 | 它花大量轮次在仓库里瞎找 |
| 约束（constraints） | 什么不能动、什么不能引入 | 它顺手改了十个你不想动的文件 |
| 完成标准（completion criteria） | 怎样算做完 | 它停在”看起来能跑”，测试没跑 |
这四个要素不需要写成正式格式，写成一段话也行。关键是四个都在。你可以把它当成一个检查清单：写完任务描述之后，逐条问自己有没有覆盖。
6.3 改动一大，就先要计划
对于复杂、模糊、或者你自己都描述不清的任务，正确做法是先让它出方案，你审完再执行。
进入计划模式的方式是斜杠命令：
/plan在计划模式下，Codex 会先去读仓库、提澄清问题、给出一份实施方案，在你批准之前不动任何文件。你可以直接编辑这份方案再让它执行。
什么时候该用？实践中流传一条好用的经验法则：如果这个任务预计要改超过三个文件，就先出计划。这不是官方规定的硬阈值，但它抓住了本质——改动越分散，你在事后 review 里发现问题的成本越高，而在事前 review 一份方案的成本几乎为零。
计划模式还有个隐藏价值：它会暴露你自己没想清楚的地方。当 Codex 提出”你说的’兼容旧接口’是指保留旧路径，还是保留旧的响应格式？“，通常意味着你的需求确实有歧义。
6.4 长任务：把计划落成文件
计划模式的方案存在于会话里，会话结束就没了。对于跨越几小时或几天的任务，实践中常用的做法是让 Codex 把方案写成一个仓库里的 PLANS.md 文件，每完成一步就更新状态。
这样做的好处是：新会话可以直接读这个文件恢复进度，你也能在文件上直接改优先级。
6.5 提示词和规则的分工
一个常见的低效模式是：每次任务都在提示词里粘贴一大段项目约定。
分工原则很清楚：
- 一次性的、这个任务特有的 → 写在提示词里
- 每次都一样、跨任务复用的 → 写进
AGENTS.md - 重复执行的完整流程 → 沉淀成技能，见第8章
官方最佳实践里有一句很到位的判断标准：如果你在反复使用同一段提示词，或者反复纠正同一个流程，那它多半应该变成一个技能。