如何把任务讲清楚：背景、目标、约束、验收标准

编程代理的输出质量，很大程度上取决于你下达任务的质量。"帮我优化一下这个项目"这类模糊指令，几乎必然带来范围漂移和返工。本节给出一套可直接照抄的任务描述结构：背景、目标、范围与约束、具体动作、验收标准，并说明如何用计划模式和澄清提问把需求在动手前对齐。

一、模糊指令为什么会跑偏

代理没有读心能力，它只能依据提示词、已读取的文件和对话历史推断意图。下面三种常见写法会显著提高返工率：

• 目标过大过泛："把代码优化一下"没有指明优化什么、按什么标准判断完成，代理容易做大面积、无重点的改动。
• 缺少范围约束：不说明只改哪些文件、不要动哪些模块，代理可能跨文件连带修改，增加审查成本。
• 没有验收标准：没有"怎样算做好"，代理只能凭主观感觉收尾，结果往往与你的预期不一致。

二、清晰任务的五个要素

要素	要回答的问题	作用
背景 Context	这是什么项目、当前遇到什么现象或问题	让代理先建立上下文，避免误判技术栈与约定
目标 Goal	最终要达成什么可描述的结果	锁定方向，避免中途发散到无关改动
范围与约束 Scope	改哪些文件/模块、明确不要改什么、有无风格与兼容性要求	控制改动边界，防止越界和连锁修改
具体动作 Action	希望代理先做什么（先调研、先出方案、还是直接改）	指定工作节奏，尤其"先出方案不要改代码"
验收标准 Acceptance	如何验证完成：测试、构建、具体行为、边界条件	让"完成"可检验，而非主观判断

三、可直接套用的任务描述结构

不需要华丽措辞，按下面顺序把要素说清楚即可（这是自然语言提示结构，不是终端命令）：

背景：这是一个 <技术栈/项目类型> 项目，当前 <现象或现状>。
目标：希望实现 <可描述的结果>。
范围：只处理 <具体文件/模块>；不要改动 <明确排除项>；保持 <兼容性/风格> 要求。
动作：先阅读相关文件并给出修改方案，暂不直接改代码；方案确认后再动手。
验收：<测试命令/构建结果/应满足的行为/边界条件> 全部通过才算完成。

一个贴近真实的示例：

背景：这是一个 Node.js + TypeScript 的工具库，某工具函数在空数组输入时返回 undefined 而不是约定的空结果。
目标：让该函数在空输入时返回空数组，并补充对应测试。
范围：只修改 src/ 下该函数及其测试文件；不要改动导出签名和其他模块；保持现有导出名称不变。
动作：先定位实现与现有测试，列出修改计划，确认后再编辑。
验收：npm test 全绿，空输入返回 []，原有非空用例不回归。

四、先计划、后动手：用计划模式对齐方案

对中等以上复杂度的任务，建议先让代理出方案而不是直接改源码。可在会话中进入计划模式：

/plan 为空输入返回空数组并补测试

计划模式下代理以读取和探索为主，在你批准方案前不会修改源码；它会列出准备改动的文件、思路和风险点。你据此确认、补充或否决，再让它进入实现。若代理对需求有疑问，会通过选择题形式发起澄清（AskUserQuestion），此时应直接回答关键分叉（技术选型、兼容性、优先级），不要让它替你拍板重要决策。

五、首轮不必完美：用多轮迭代补充约束

• 首轮给主干：目标、范围、验收先写全，细节可以边做边补。
• 二轮补边界：看到初步方案后追加"注意不要破坏某个行为""对入参做类型保护"等具体约束。
• 方向跑偏时即时纠偏：发现改动偏离目标，明确指出"暂停，这块不在范围内，回到目标 X"。
• 上下文过长先整理：多轮讨论后可用 /compact 保留要点继续；换不相关子任务用 /clear。

六、新手常见误区对照

误区写法	后果	更稳妥的做法
"随便帮我重构一下"	范围不可控、改动巨大、难审查	指定具体函数/模块，并给出不改的边界
一次塞入"修 Bug + 加功能 + 写文档"	目标互相干扰、回归风险高	拆成连续的单一任务，逐个验证
让代理自行决定关键技术选型	方案可能不符合团队约束	在约束中写明技术栈/依赖/兼容性要求
只说"让它更好用"	无验收标准，无法判断完成度	给出可运行的验收命令或明确行为标准