AI 写完代码后，我只看这 8 个验收点

AI 能很快给出一份看起来完整的改动，但“代码已经生成”和“任务已经完成”是两件事。验收时如果从第一行读到最后一行，很容易被实现细节带走；更有效的方式，是先确认它有没有守住任务边界和系统契约。

下面八项可以作为提交前的固定检查。每项只记录“通过、失败、待确认”，并附上文件、测试结果或截图等证据。没有证据的“应该没问题”仍然算待确认。

1. 需求是否真的闭环

把原始需求拆成可观察行为：输入是什么，用户做什么，系统应该返回什么，失败时怎样提示。逐条对应到实现和验证方式。AI 常会完成最显眼的主流程，却遗漏空状态、权限不足或取消操作。

2. 改动范围是否克制

查看差异文件列表，确认每个文件都与任务有关。重点寻找无关格式化、顺手重构、自动生成文件和依赖锁定文件的大面积变化。范围越大，越难判断回归来自哪里；必要重构应与功能变化分开说明。

3. 接口与数据契约是否保持

检查函数参数、返回值、API 状态码、数据库字段、事件名称和配置键。调用方是否同步更新，旧数据能否继续读取，新增字段是否有默认值。类型检查通过，并不代表运行时数据一定满足契约。

4. 边界与失败路径是否明确

至少覆盖空值、极端长度、重复请求、超时、网络失败、部分成功和非法输入。异常不能被静默吞掉，也不要把内部错误原样暴露给用户。资源申请之后，还要确认连接、文件句柄和临时状态能被正确释放。

5. 测试是否验证行为

先运行项目已有的测试、静态检查和构建命令，再看新增测试是否会在实现被破坏时失败。只断言“函数被调用”通常不够，应验证用户可见结果、状态变化和错误分支。若某项无法自动测试，要记录可重复的人工步骤，而不是省略验证。

6. 安全与隐私是否守住

检查输入校验、鉴权位置、权限边界、日志内容和密钥处理。数据库查询、HTML 输出、文件路径和命令执行尤其需要关注注入风险。新增依赖要说明用途，确认没有把令牌、个人信息或完整请求体写进代码与日志。

7. 代码是否便于下一次修改

命名应表达业务含义，重复逻辑应有合理归属，注释解释“为什么”而非复述代码。避免为一次需求引入过度抽象，也不要留下无法解释的常量、失效分支和大段生成式样板。阅读入口应清楚，关键决策应能从代码或文档中找到。

8. 上线、观测与回退是否可行

确认配置、迁移、发布顺序和兼容窗口。失败时能否关闭新功能或回退版本，数据变更是否可逆；上线后又通过什么日志、指标或用户现象判断功能正常。涉及外部服务时，还要考虑限流和降级行为。

可复制的验收记录

任务：
变更范围：

1 需求闭环：通过 / 失败 / 待确认；证据：
2 改动范围：通过 / 失败 / 待确认；证据：
3 接口契约：通过 / 失败 / 待确认；证据：
4 边界失败：通过 / 失败 / 待确认；证据：
5 测试行为：通过 / 失败 / 待确认；证据：
6 安全隐私：通过 / 失败 / 待确认；证据：
7 可维护性：通过 / 失败 / 待确认；证据：
8 上线回退：通过 / 失败 / 待确认；证据：

遗留风险：
最终决定：接受 / 修改后接受 / 拒绝

也可以把这份清单交给 AI 做第一轮自查，但最终验收者仍要查看真实差异和命令输出。清单的意义不是保证代码永不出错，而是把“感觉能用”改成一组可以回答、可以举证、也可以明确拒绝的问题。