让 AI 改代码时，最容易遗漏的部分往往在最后：代码产生了，测试却没有运行；本地页面打开了，生产环境却没有更新。交付时把这些状态分开，会让下一位接手的人少猜很多事情。
下面是一份可以直接用在项目里的验收方法。它是工作清单，不代表任何工具能保证代码没有缺陷。
一、先核对改动范围
第一份证据是文件和 diff，而不是一句"已完成"。
bash
git status --short
git diff --stat
git diff --check
git diff --cached --stat
git diff --cached --check这里有一个细节：普通 git diff 只看未暂存的已跟踪文件，--cached 看暂存区。新文件还要结合 git status 检查；如果任务是审查整个分支，需要明确基线，再比较基线与当前提交。工作区 diff 不能替代分支范围。
逐项看这几个问题：每个改动是否对应本次需求？有没有混入无关重构？新文件是否应被跟踪？有没有把密钥、账号缓存或个人数据一起放进交付内容？
二、把实际运行和预计通过分开
测试记录至少要有命令、结果和适用范围。不要把"看起来没问题"写成"测试通过"。
| 改动类型 | 最接近问题的验证 | 不能由此推出 |
|---|---|---|
| 文案和链接 | 实际显示、目标地址、格式检查 | HTTP 200 不等于内容准确或已收录 |
| 业务逻辑 | 正常、边界和失败输入 | 一个成功例子不覆盖全部边界 |
| 界面交互 | 表单反馈、键盘操作、关键路径 | 构建通过不等于按钮可用 |
| 发布配置 | 构建产物、部署结果、线上请求 | 本地通过不等于线上已更新 |
优先运行项目已有的检查。具体命令要看项目的 AGENTS.md、脚本和贡献说明，不能默认每个项目都有 npm test。
代码审查也属于这一层。OpenAI 的官方说明将仓库规则与确定性检查分开：规则能表达兼容性、数据边界等约束，测试、CI 和分支保护仍有各自职责。审查意见要处理和复核，不是测试结果的替身。
三、走一遍真实用户路径
以生成器为例，不能只确认页面标题出现：还要输入一组内容，确认结果随之更新，再检查空值或无效输入的表现。
如果任务包含上线，还要从正式域名重新打开页面。链接能返回 200、内容符合预期、页面中的按钮能使用，是不同的检查。
可以把每条路径记成：入口 → 测试输入 → 观察结果 → 仍未覆盖的情况。需要账号、权限或真实业务数据才能验证的部分，明确写"未验证"及原因。
四、交接时给出六项信息
可以把下面这段复制到下一次任务里：
text
请交接这次改动：
1. 改了什么：对应需求和主要文件。
2. 为什么这样改：影响行为的关键取舍。
3. 实际验证：运行过的命令与结果。
4. 用户路径：入口、测试输入、可观察输出。
5. 未验证项：缺少什么，会影响哪些结论。
6. 发布状态：本地完成、已提交、已部署分别说明。
未运行的检查不要写成通过，已知限制不要省略。没有自动化测试时，也可以记录实际做过的人工验证，但要把覆盖范围说清楚。下一位接手的人需要知道的是：哪里有证据，哪里还需要继续确认。
资料与可复制清单
- 完整验收清单与交接模板：nano-banana.lol/tutorials/c...
- OpenAI 官方代码审查说明：developers.openai.com/blog/custom...
本文由 Nano Banana 独立整理，非 OpenAI 官方。官方说明核对于 2026-10-15；清单属于编辑整理，没有将示例描述成特定项目的测试结果。