从代码生成到可靠交付

代码已经生成，只说明实现有了候选方案。一次可靠的交付，还需要回答三个问题：它是否解决了原问题，是否影响了已有行为，以及后来的人能否理解这次改动。

先看改动边界

审查从文件列表和差异开始。逐个确认修改与任务目标的关系，尤其留意无关格式化、依赖更新、配置变化和删除操作。跨文件改动应能串成一条清楚的路径：输入在哪里进入，经过哪些处理，最终如何呈现或保存。

不要只让 Agent 复述自己写了什么。可以要求它从调用方、失败路径和兼容性三个角度重新阅读代码，并指出尚未证实的假设。必要时，由另一轮独立审查补充不同视角。

按风险选择验证方式

先运行最相关的检查，再根据影响范围扩大验证。测试应覆盖用户能观察到的行为或容易退化的逻辑；简单样式调整通常可以通过预览直接确认，关键计算则需要可重复的断言。

区分不同层次的证据

构建通过说明产物能够生成，测试通过说明已覆盖的断言成立，页面打开说明该路径可以访问。它们分别回答不同问题。验证搜索功能时，还要实际输入关键词、检查结果、打开目标文章，才能证明主要使用流程成立。

交付记录
改动：用户现在可以完成什么？
依据：本次解决的问题如何复现？
验证：检查了哪些场景，结果是什么？
限制：哪些环境或路径尚未验证？
回退：如何恢复到改动前的状态？

留下可继续维护的结果

最终说明应连接问题、改动和证据，避免只有“已优化”“测试正常”这样的结论。若某项检查受环境限制，明确记录影响范围和补验方法。提交前再次检查文件差异，确保没有混入临时文件和无关改动。

如果验收时经常争论“这算不算完成”，回到任务说明补充标准。清晰的验收条件能够同时改善实现、审查与沟通。