13 · 提示词写法：目标、上下文与验收

如何向 Codex 说明目标、提供上下文、限定修改范围、写清验收标准，用可复用结构减少返工。

很多人觉得 Codex 用不好，其实问题多半出在「没说清楚」。这一篇讲怎么写提示词，让它少猜、少返工。

一个高质量的任务描述，通常包含四块。

第一块是「目标」：你最终想要什么结果，用一句话说清楚。比如「把登录接口从旧的校验方式迁移到新的」，而不是含糊的「改一下登录」。

第二块是「上下文」：它需要知道的背景信息。这个项目是什么、相关文件在哪、有没有什么约定。背景给足，它才不会瞎猜。

第三块是「范围」：哪些东西能动、哪些绝对不能碰。特别是「不要改 XX」「只改 YY 目录」这类限定，能大幅降低它误伤的概率。

第四块是「验收」：做完之后，你希望看到什么才算合格。比如「跑通这个测试」「编译不报错」「给出改动清单」。验收标准越清楚，你后面审查时越有依据。

把这四块套成一个模板，就是「我要 X，背景是 Y，只动 Z，做完要能 A」。每次任务都照这个套，哪怕复杂任务也不会漏。

还有一个加分项：给它提供「可复用的结构」。如果你有一套常用的任务描述模板，或者项目里已经有 AGENTS.md，让它先读规则再干活，效果会稳很多。

最后强调：别怕写长。写清楚要花的时间，远小于它返工浪费的时间。宁可多写两句，也别让它猜。

一个自查清单：当你读完这一篇时，可以问自己三个问题——它解决的是什么具体问题？我当前的工作/学习里有没有这个场景？下一步我该学哪一篇？把这三个问题答清楚，你就知道自己有没有真正吃透。

五分钟练习：① 找一个一分钟能完成的代码任务 ② 用这一篇的方法描述给 Codex ③ 看它执行时有没有触发你刚学的那个机制 ④ 验证结果是否符合预期。这一轮做下来，你对这一篇的理解会深 3 倍。

与其他篇的关系：这一篇是本组的基础。如果你跳过了前面几篇，建议先回去看，否则这里有些概念可能看着突兀。如果都看过了，那你可以直接进入更后面的实战环节，把这里学到的东西用上。

复盘清单：每做完一个任务，可以花一分钟复盘——目标说清楚了吗？范围限定了吗？结果验证了吗？审查过 diff 了吗？下次哪里能更好？这 5 步能让你的 Codex 使用从「能用」进化到「好用」。