从一个能够审完的改动开始
设想要给产品目录增加批量导入功能，AI 一次生成了上传页面、字段映射、校验逻辑和数据库修改。演示可以运行，但审阅者面对整批改动，很难判断哪些部分可靠，哪些还只是看起来完整。
这时可以先把交付拆成能单独检查的几个变化：解析文件、显示预览、确认写入。每一步都写清输入、预期结果和允许改变的范围。拆分依据是行为是否能够解释和验证，不必机械限制每次只能修改几个文件。
第一关：确认它实际改了什么
要求提交说明列出实现范围、新增依赖和遗留问题，再逐项对照代码差异。生成的说明也可能遗漏内容，因此不能只读总结。若任务只涉及导入，却顺带重写了搜索逻辑，就需要解释两者关系，或者将无关变化拆出去。
审阅时还应检查测试和构建配置的变化。为了让检查通过而删除断言、扩大忽略范围，可能会把问题藏进绿色状态里。新增依赖同样需要说明用途、维护状态和替代方案，避免一次小功能带来无法解释的长期负担。
第二关：让验收样例独立于实现
假设导入规则是同一文件中商品编码不能重复，就应先准备包含重复编码的样例，再检查系统是否给出明确反馈。不要仅让生成实现的模型顺手编写一套与实现保持一致的测试，然后用这些测试证明实现正确。
可以由需求负责人确认少量关键样例：空文件、重复编码、缺失字段、无法识别的日期，以及一份正常文件。每个样例都保存预期结果。测试失败时，先判断实现还是预期有问题，不能为了继续推进而随手修改答案。
人工审阅也应留下具体结论，例如“已检查错误行不会进入确认列表”，而不只是“看起来没问题”。独立开发者没有第二位审阅者时，可以换一次检查顺序，逐条核对验收样例，并如实标注仍未覆盖的部分。
第三关：证明将要发布的就是验证过的版本
GitHub 的保护分支文档支持把审阅和状态检查设为合并要求。但检查名称齐全仍不够，还要核实任务是否实际运行、测试针对哪个提交，以及新改动是否需要重新审阅。
发布前可以保留一份精简记录：
- 提交标识、构建产物及对应版本。
- 关键检查的执行结果和未覆盖项。
- 预览环境中走完核心流程的验收记录。
- 数据结构变化与升级步骤的检查结论。
- 决定发布的人，以及需要继续观察的问题。
如果最终版本又修改了代码，就应重新执行受影响的检查，不能借用上一版的通过记录。合并代码、生成产物和部署完成也应分别确认，避免把流程中的中间状态当成最终交付。
AI 让尝试一个实现更容易，也让短时间内产生大量变化成为可能。团队能够持续交付多少，仍取决于能否解释这些变化、验证关键行为，并把发布结论对应到一个确定的版本。这样的证据值得和代码一起交给下一位维护者。