Coding Agent 最容易制造一种错觉：代码改完、页面能开，就等于任务完成。专业的完成标准还包括变更范围、测试证据、diff 审查和回滚能力。
这次选择一个小任务，例如“给现有表单增加空值提示，并补一条测试”。不要用第一次练习升级框架、迁移数据库或重构整个项目。
准备安全仓库
开始前确认：
- 使用练习仓库、独立分支或工作树。
- 当前改动已经提交，
git status清楚。 .env、密钥和生产配置不在任务材料中。- 已知道项目的标准测试命令。
- 有明确回滚方式。
如果仓库里已经有你尚未提交的改动，先保存或隔离。不要让 Agent 在混合状态下判断哪些文件属于本次任务。
第一步：Ask 理解项目
选择代码开发场景和仓库工作区，先使用 Ask：
请只读分析当前项目：说明技术栈、启动命令、测试命令，以及与表单校验相关的文件。不要修改文件或安装依赖。最后列出你仍不确定的地方。
通过标准： 回答与 package.json、README 和目录结构一致，没有声称执行未发生的命令。
第二步：Plan 限定改动
目标确认后提交计划：
目标：当邮箱为空时显示“请输入邮箱”，并补一条对应测试。请先列出准备修改的文件、每个文件的变化、要运行的测试和回滚方式。不要改样式系统、依赖版本或其他表单字段，等我确认后再执行。
审查计划时检查：
- 改动文件是否符合预期。
- 有没有不必要的依赖安装。
- 测试命令是否真实存在。
- 是否承诺保留现有行为。
- 是否包含 diff 检查。
第三步：Craft 执行
确认计划后执行。允许范围只覆盖当前仓库和必要命令，不授予整个主目录权限。
运行过程中留意：
- 是否突然修改锁文件。
- 是否启动长时间后台进程。
- 是否尝试读取
.env。 - 是否因为测试失败而扩大修改范围。
出现上述情况时暂停，先让 Agent 解释原因。
第四步：验证测试证据
WorkBuddy 应报告：
- 实际运行的命令。
- 测试数量和结果。
- 若失败，失败原因和处理方式。
- 未执行的检查。
不要接受“理论上可以工作”。如果环境无法运行测试，产物必须明确标记“未验证”，你需要在本地补跑。
第五步：查看 diff
重点检查：
| 检查项 | 问题 |
|---|---|
| 文件范围 | 是否只改了计划中的文件 |
| 代码逻辑 | 是否真正满足空值校验，而不是写死结果 |
| 测试质量 | 是否验证用户可见行为 |
| 无关变化 | 是否重排格式、改锁文件或删除注释 |
| 安全 | 是否写入 token、路径或调试数据 |
让 Agent 给出摘要有帮助，但最终 diff 要由你自己查看。
第六步：要求交付说明
请总结本次修改：列出变更文件、用户行为变化、已运行测试、未验证项和回滚方法。不要继续修改代码。
这份说明可直接作为提交说明或代码审查背景，但仍需人工校对。
常见失败
Agent 一上来就改代码
确认当前模式是否为 Craft。重新用 Ask 或 Plan 开始，并明确“等我确认后执行”。
测试失败后修改越来越多
暂停任务，要求回到最初 diff，解释失败属于代码、环境还是现有问题。不要允许它为了通过测试删除断言。
项目太大，理解不准确
缩小工作区或先指定相关目录、README 和关键入口。大仓库应分阶段理解，不把所有文件一次塞入上下文。
生成了无关文件
检查缓存、构建产物和日志是否应被忽略。删除前先确认不是用户原有文件。
完成检查
- 任务在可回滚的独立状态中完成。
- Agent 先理解、再计划、最后执行。
- 实际变更与计划文件一致。
- 测试命令和结果可以核对。
- git diff 没有无关变化或敏感数据。
- 交付说明包含未验证项和回滚方式。