AI 写代码越来越快，但 review 反而更重要。因为 AI 生成的代码常常“看起来完整”，却可能漏掉业务边界、测试证据、安全风险和项目约定。

小团队最容易踩的坑是：AI 写完，开发者看一眼能跑，就直接合并。短期省了时间，长期会变成无法解释的技术债。

这篇文章讲一套适合 1-5 人小团队的 AI 代码审查流程：AI 可以参与 review，但最终判断仍然由人负责。

AI 代码审查不是多跑一个工具

很多人以为 AI code review 就是把 diff 丢给另一个模型，让它说有没有问题。这样当然有用，但还不够。

真正稳定的流程应该回答四个问题：

  1. 这段代码为什么被改？
  2. 改动范围是否收敛？
  3. 有什么证据证明它有效？
  4. 哪些风险必须由人判断？

如果 review 只输出“建议优化命名”或“代码看起来不错”，它对合并决策帮助很小。

三层 review 流程

推荐把 AI 生成代码的审查分成三层。

层级负责人目标输出
生成者自查写代码的 AI / 使用者解释 diff 和验证结果改动摘要、验证命令
AI 预审另一个 AI 或 review prompt找 correctness、安全、测试缺口高风险问题清单
人工复核开发者 / owner判断业务意图和长期维护是否合并、是否拆分

这三层不能互相替代。生成 AI 最了解它刚做了什么，但也最容易自我合理化；第二个 AI 能补充视角，但不了解团队真实取舍；人负责最终判断。

第一层：让生成 AI 解释 diff

AI 改完代码后，不要马上让它继续修。先让它解释当前 diff。

可以直接要求：

1
2
3
4
5
6
7
请基于当前 diff 输出：
1. 改了哪些文件；
2. 每个文件为什么改；
3. 哪些行为发生变化；
4. 哪些范围没有改；
5. 运行了什么验证命令，结果是什么。
不要再修改文件。

好的 diff 说明应该能让 reviewer 快速建立地图，而不是重新读完整代码。

信息为什么重要
文件列表判断是否越界
行为变化判断是否满足需求
未改范围防止误以为覆盖了更多问题
验证命令判断证据是否足够
风险点引导人工重点看

如果 AI 解释和 diff 不一致，以 diff 为准。

第二层：用另一个 AI 做预审

第二层不要让 AI 评价“代码风格”。它应该只找影响合并的确定性问题。

推荐 prompt：

1
2
3
4
5
6
7
8
9
10
你是代码审查者。请审查下面 diff。
只关注：
1. correctness bug；
2. 安全风险；
3. 数据丢失或权限问题；
4. 缺少必要测试；
5. 明显无关改动。

不要评论命名、格式、个人风格。
如果没有确定问题，明确说没有发现确定性阻塞。

输出建议用表格：

严重程度文件证据为什么是问题修复建议
blocker----
warning----

这样可以避免 AI review 变成噪音。

第三层：人工复核业务和架构

人工 review 重点不应该重复 AI 已经扫过的机械问题，而是看 AI 不擅长的部分。

人工必须判断：

  • 需求是否真的被满足；
  • 这个实现是否符合现有架构；
  • 是否改了不该改的边界；
  • 是否破坏产品语义；
  • 是否引入后续维护成本；
  • 是否需要拆成更小 PR；
  • 是否值得现在合并。

例如，AI 可能把重复逻辑抽成一个通用函数。看起来更“优雅”，但如果两个业务路径未来会分开演化，这个抽象反而是技术债。

PR 模板怎么写

AI 生成代码的 PR，最好比普通 PR 多一个“AI 参与说明”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
## Goal
这次改动解决什么问题？

## Scope
改了哪些文件？哪些范围明确没有改？

## AI assistance
AI 做了哪些部分？人做了哪些判断？

## Verification
- [ ] 单元测试：
- [ ] 构建：
- [ ] 手动验证：

## Review focus
请重点看：
- 业务边界
- 安全/权限
- 测试是否足够
- 是否有无关改动

这个模板能减少 reviewer 的不确定性。

不同改动类型的审查证据

改动类型必须提供的证据
UI 文案页面截图或本地页面验证
表单校验正常路径和错误路径测试
API 行为请求示例、响应、错误码
数据库相关测试库验证、迁移/回滚说明
SEO 页面构建后 HTML title/description/canonical
CLI 工具真实命令输出和退出码
安全逻辑权限场景和反例测试

证据越具体，AI 生成代码越容易被信任。

什么时候不该合并

下面情况出现时，不要合并：

  • AI 无法解释为什么改某个文件；
  • diff 里有多个无关目标；
  • 没有真实入口验证；
  • 测试只覆盖 mock，不覆盖行为；
  • 安全或权限逻辑没有人工确认；
  • reviewer 看不懂关键实现；
  • 为了让测试过而改了测试预期；
  • 改动和原始需求不一致。

小团队最怕的不是慢，而是把不可解释的代码合进去。

和 Claude Code / Cursor / Copilot 怎么配合

不同工具适合不同位置：

工具更适合
Copilot写小段代码、补样板、局部建议
Cursor编辑器内上下文修改
Claude Code多文件任务、跑命令、记录验证
独立 review prompt审查 diff、找缺口

如果任务由 Claude Code 完成，可以继续看 Claude Code Git 工作流；如果你需要完整小团队流程，可以看 小团队 AI 编程工作流。

AI 代码审查检查清单

合并前逐项确认：

  • 原始需求清楚；
  • 改动范围收敛；
  • AI 解释了 diff；
  • 有第二层 AI 预审；
  • 人工看过业务边界；
  • 真实入口验证通过；
  • 测试覆盖失败路径；
  • 没有无关文件；
  • commit message 能解释原因；
  • 不涉及未确认外部操作。

FAQ

AI review 能不能替代人工 review？

不能。AI 可以提高覆盖面，尤其是发现明显 bug、遗漏测试和安全风险；但业务取舍、架构边界和长期维护仍要人判断。

是否需要两个不同模型互审？

不是必须。关键是角色分离：生成代码的模型不要直接给最终质量结论。你可以用同一个模型的新会话，也可以用不同工具。

小团队没有 PR 流程怎么办？

至少保留 diff 说明、验证命令和人工检查清单。即使一个人开发，也应该让 AI 产物先经过一次 review。

总结

AI 代码审查的目标不是让模型给你盖章，而是让 AI 生成代码变得可解释、可验证、可维护。小团队只要坚持三层 review：生成者自查、AI 预审、人工复核，就能在使用 Claude Code、Cursor、Copilot 提速的同时，避免把不可解释的代码合进项目。