15 · 提示词写法：任务、上下文与验收标准

如何说明目标、提供上下文、约束改动范围和定义验收标准，用可复用结构减少返工与误改。

很多人觉得 Claude Code 用不好，问题多半出在「没说清楚」。这一篇讲怎么把任务说清楚。

一个高质量的任务描述，通常有四个部分。

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

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

三是「范围约束」：哪些能动、哪些绝不能碰。特别是「别改 XX」「只动 YY」这类限定，能大幅降低误伤。

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

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

「可复用结构」是加分项：如果你有常用的任务模板，或者项目里已有 CLAUDE.md，让它先读规则再干活，效果会稳很多。

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

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

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

延伸阅读：学完这一篇，你可以看本组里的下一篇，把相邻的概念连起来读；也可以跳到更后面的组学 MCP、子代理、Skills 这些更深的能力。知识是网状的，多跳几篇会理解更深。

一页速览：如果只能记三件事，① {一}。② {二}。③ {三}。其他细节以后需要再翻这一篇查。