任务说明 · 实用指南
给 AI 编码工具写任务说明：让结果可检查
一份好任务说明，能让执行者知道要改变什么，也让你知道怎样判断它完成了。诀窍是把抽象愿望改写成可以观察的行为。
先写使用场景，再写修改目标
以下案例完全虚构：你有一个读书清单页面，读完一本书后仍要从长列表里寻找未读项目。真正的目标是快速看到未读书籍。先说明这个场景，再提出“增加全部、未读、已读三个筛选项”，执行者才能理解筛选为何存在，避免自行扩展成推荐系统。
把说明拆成五个部分
- 现状：列表按加入时间排列，每本书已有阅读状态；当前没有筛选入口。把观察到的事实与尚未确认的判断分开写。
- 目标：点击“未读”后，只展示未读书籍；切回“全部”后恢复完整列表。优先写用户动作和可见结果。
- 范围：沿用现有页面和数据结构；本次不增加账号、云端同步或推荐功能。说明哪些内容必须保留。
- 边界：没有匹配项时显示“暂无未读书籍”；筛选不改变书籍状态；刷新页面后回到“全部”。
- 交付：提供修改文件、验证步骤、实际验证结果和已知限制；需要新增依赖或修改存储方式时，先说明原因。
把模糊要求改成验收条件
错误示范：“优化一下读书页面，要好看、好用、没有问题。”
改进后可以写：“准备三本未读和两本已读的示例书。初始显示五本；点击未读显示三本，点击已读显示两本；连续切换不会新增或丢失记录；在窄屏下，筛选按钮和书名仍可操作、可阅读。”这里的数字是测试用例预期，不代表已经完成验证。
给材料，也给不确定性
附上相关文件位置、现有截图或一份脱敏示例即可，不必把整个项目倾倒给工具。如果不知道状态字段叫什么，直接标注“请先查明现有字段，不要新建重复字段”。密码、访问令牌和真实个人资料都不应成为任务说明的素材。
执行结束后看证据
收到“完成”时，逐条对照验收条件。请执行者区分代码检查、实际运行和未执行的检查，并提供能复做的步骤。对于示例页面，你可以亲自切换三次筛选，再修改一本书的状态，确认筛选结果及时变化。失败时补充实际现象，不要只要求“再修一下”。
这套方法的适用边界
它适合目标相对明确的小功能、页面调整和局部修复。如果你连用户是谁、问题是否存在都不确定，应先用草图或访谈澄清需求。涉及付款、权限或不可逆数据变化时，任务说明还要明确审批点、恢复办法和验证环境，不能用一份通用模板代替专项评审。