同一个开发任务，用不同方式描述，结果可能相差很大。高质量任务说明并不需要很长，但必须让执行者知道为什么改、改哪里、什么不能动，以及怎样才算完成。
1. 目标：先写用户可感知的变化
目标应描述行为而不是实现。例如“订单提交失败时保留表单内容并显示具体原因”，比“重构提交函数”更容易对齐。
2. 现状：给出稳定复现路径
列出运行环境、页面地址、操作步骤、实际结果和期望结果。若问题偶发，应补充发生频率、浏览器或数据条件。
3. 范围与约束：提前划定边界
说明允许修改的模块、需要兼容的版本、不可更换的依赖，以及是否可以调整数据库结构。边界能显著减少无关重构。
4. 验收：把完成定义成检查项
把验收标准写成“当……时，应……”的句子，并加入必须通过的命令、接口响应或截图尺寸。
常见误区
- 把实现方案误当作业务目标
- 缺少真实错误信息和复现数据
- 同时夹带多个无关需求
- 没有说明测试与兼容要求
执行检查清单
- 目标只有一个主线
- 现状可由他人复现
- 范围和禁区写清楚
- 每条验收标准可测试
总结
好的任务说明本质上是一份小型工程合同。它既约束 AI，也帮助需求提出者提前发现遗漏。