交出去的任务，最怕的结果不是失败，是它说做完了，你信了，上线才发现没做完。一套稳定的执行流程能把这种坑堵住。

一轮完整的任务要六步

顺序大概是这样：把任务写清楚，让它先建图，小步执行，检查 diff，跑验证，记录结果。少了哪一步都容易出问题。

第一步，任务写清楚

目标，背景，范围，验证和交付这五样别省。目标是你最终想得到什么，背景是相关文件、报错和业务规则在哪，范围是这次允许改哪里，验证是跑什么命令或者看什么结果，交付是它最后怎么汇报。

只读的任务也要写清楚。可以这么写：请只读分析当前项目的文档结构，不要修改文件，指出首页，学习路线，侧边栏之间不一致的地方，输出问题列表，涉及文件，建议调整顺序。要允许它改文件，就再明确一句：请更新某个文档里的下一步链接，只改这一个文件，完成后说明改了哪里，不需要运行构建。

第二步，先让它建图

稍复杂一点的任务，先让它只读分析，误改会少很多。你不确定相关文件在哪，任务涉及多个目录，要重构导航和文档结构，或者担心它改动范围过大，这几种情况都适合先建图。

让它输出当前结构，关键文件，风险点，建议步骤，还有需要你确认的决策。

第三步，小步执行

一次只处理一个明确阶段。先移动文件，再更新导航，然后修内部链接，最后跑检查。

小步的好处是每一步都能看 diff，方向不对也容易退回去。

第四步，检查 diff，别只看总结

改完不要只看它给的总结，去看 diff。重点看几件事：有没有改到不相关的文件，有没有删掉仍然有价值的内容，链接是不是指向新路径，标题层级有没有乱，配置文件是不是只动了必要的部分。

diff 太大的时候，可以让它按文件解释目的，分清哪些是移动文件，哪些是链接更新，哪些是正文修改。

第五步，跑验证

验证方式看任务类型。文档链接这一类，搜旧路径、检查相对链接。前端页面，跑构建、打开看截图。代码修改，跑单元测试和类型检查。配置修改，查当前状态、跑一次最小任务。发布任务，检查访问地址，日志，状态码。

验证失败之后别急着扩大修改范围。先判断失败属于哪一类：是本次改动造成的，还是环境依赖问题，还是这个项目本来就有的老问题，又或者是外部服务和网络的问题。只有第一类才该继续动本轮的代码。

第六步，失败之后怎么接

保留当前的错误输出，让它解释错误从哪来，要求它把本次改动导致的和环境已有问题分开说，只修和本次目标直接相关的地方，修完重新跑一次最小验证。

可以这么问：构建失败了，请判断这是本次改动导致还是环境依赖问题，不要修改文件，先给出证据和下一步建议。

什么时候算做完

目标文件按要求改好了，没有越界改动，关键链接和命令都验证过了。如果验证失败，失败原因记录清楚。最后它能说清改了什么、验证了什么、还剩什么风险。

到这一步仍然需要你自己 review。它负责加速执行和整理证据，接不接受由你判断。