AI 代码评审清单：让智能体先跑一遍的六道关卡与人工终审边界

评审 AI 写的代码，不要从第一行 diff 开始读。 GitHub 给出的顺序是：先看 CI 是否被削弱，再查有没有重复造轮子，最后才追关键路径——这个顺序是省时间的关键，因为最贵的缺陷往往藏在最便宜就能查出来的地方。

先认清你在评审什么

2026 年 1 月的研究《 More Code, Less Reuse 》给出了一个反直觉的结论：智能体生成的代码在每次改动中引入的冗余和技术债，比人写的更多，但表面看起来更干净，评审者也更容易放行。 GitHub 的数据同样说明问题：Copilot 代码评审累计处理超过 6000 万次，五分之一以上的评审已经有智能体参与。

智能体是个高产、字面化、遵循模式的贡献者，它不知道你们的事故史，也不知道那些没写进仓库的运维约束。它的代码”看起来完整”，这本身就是最危险的失效模式。

六道关卡：十分钟检查顺序

第 1 关：扫描分类（1–2 分钟）

• 看文件清单和 diff 体积，判断是窄任务（文档、 CI 、小改动）还是复杂任务（多文件、逻辑、性能、测试）。
• 这一分类决定后面每一关要花多少深度，先分类再动手。

第 2 关：先看 CI 改动（2–3 分钟）

在读任何业务代码之前，先看所有触碰 .github/workflows、测试配置、覆盖率阈值、构建脚本的改动。任何削弱 CI 的改动都是硬性阻断。智能体跑挂 CI 时有一条明显的捷径：删掉失败的测试、跳过 lint 、给命令加 || true、下调覆盖率阈值。有些智能体真的会走。

必查四项：覆盖率阈值是否被改？有没有测试被删除、改名或标记跳过？工作流是否不再在 fork 或 PR 上运行？有没有步骤被新增条件挡住？

第 3 关：扫重复工具（3–5 分钟）

搜新增的函数、 helper 、模块，逐个在仓库里查重，凡是重复实现了既有能力的全部打回。智能体很少主动确认”这个功能是不是已经有了”，典型症状是两个名字不同、实现几乎一样的函数。

第 4 关：追一条关键路径（5–8 分钟）

挑最重要的一处逻辑改动，端到端走一遍：输入 → 变换 → 输出，重点看边界条件、权限校验、异常分支。这一关无法跳过，也是唯一真正需要你带着系统上下文去做的部分。

第 5 关：安全边界（8–9 分钟）

如果 PR 涉及调用大模型或处理不可信输入，逐条过：工作流权限是否最小化（permissions: read-all 是合理默认值）？不可信内容进提示词前是否被清理和转义？分析步骤和执行步骤是否分离、生产操作是否有人类审批门？模型输出有没有被直接 eval 执行？

第 6 关：要证据（9–10 分钟）

任何非平凡的逻辑改动，都要求一个”在改动前会失败”的测试。写不出这个测试，说明修复是不完整的，或者理解本身就是错的。高风险改动还要有回滚方案。

哪些该交给 AI，哪些必须留给人

给 AI 评审下明确的契约

“帮我看看这段代码”只能换来泛泛而谈。有效的做法是写清评审契约：只检查正确性、授权、错误处理和验收标准；忽略格式和与改动无关的问题；每条发现必须指出代码位置、失效场景和证据；使用只读工具，不改代码；说明跑了哪些检查、哪些没跑。

另外一条硬规矩：写代码的会话和评审的会话必须是两个。自审有用，但不能当作独立证据——新会话至少要拿到原始 issue 、验收标准、最终 diff 和验证结果。

和已有流程串起来

评审前的方案确认可以参考AI 编程的 Plan/Act 分离工作流，把”改什么”在动手前定死，评审时只需核对其是否按方案执行；安全类缺陷的深入排查可以接上AI 代码安全审查里的检查项；如果你们已经在做规范驱动开发，评审契约可以直接写进规格驱动开发的模板里。