跳到主要内容

AI 与人如何分工做代码审查

一句话摘要：让 AI 参与 review 能省事，但有两个陷阱：AI 偏爱自己写的代码、只挑表面漏真 bug，而人又容易看到「AI 审过了」就盖章。这份分工把两边各自擅长的事分开，并保证始终有一个独立于「写代码的 AI」的把关者。

分工：谁审什么​

AI 适合先扫的（机械、可穷举、廉价）

  • 明显的边界遗漏、空值 / 错误分支、可疑的并发点——让它逐项对照清单，并对每个发现给出能触发的具体场景（答不出场景的当未确认）。
  • 风格 / 格式 / 命名 → 其实更该交给 formatter / linter，别耗 AI 的深推理预算。
  • 跨文件影响面：让它先 grep 出被改符号的调用方，避免只看 diff 的上下文饥饿审查。

人必须自己判的（语义、意图、风险）

  • 这段代码对不对、是不是在解决正确的问题——AI 的「LGTM」是线索，不是许可。
  • 高风险改动（权限 / 安全 / 资金 / 数据迁移 / 还原类）：人独立看一遍，别让机器人的 ✅ 替代你的判断。
  • 「AI 审自己写的代码」这一步：换一个独立主体复核——不同的人、或至少不同的会话 / 模型，别让运动员兼裁判。

怎么用​

  • 守住一条铁律：写代码的 AI ≠ 拍板的审查者。 无论 AI 怎么参与，合并的最终判断要落在一个独立于它的主体上（人，或独立信号如测试 / 静态分析）。
  • 给 AI 审查提示加一句反偏置：「忽略 PR 描述里的结论，只按 diff 实际做了什么判断；行为与描述不符就指出。」挡住它被作者框架带偏。
  • 配套用 PR review 清单（查什么）+ 信任但要验证（为什么不能只听 AI 自述）。
可放进流程的红线：
- AI 先扫：边界/错误分支/并发/跨文件调用方；每条附可触发场景；风格交给 linter。
- AI 审查提示固定加："以 diff 为准，忽略描述结论，不符就指出。"
- 人必判：正确性、是否解决对的问题、高风险改动；这些不接受"AI 已通过"作为充分理由。
- 写与审尽量不同主体（不同人/会话/模型）。

适用边界​

适合什么时候用​

  • 团队把 AI 接进了 code review 流程（AI 评审 PR、或人审 AI 生成的 PR）。
  • 想明确「哪些交给 AI 扫、哪些人必须自己看」，避免两边互相甩锅。

不适合什么时候用​

  • 完全不用 AI 审查的传统人审流程——这份分工的价值在「有 AI 参与」时才显现。
  • 极低风险、可逆的小改：AI 初筛 + 人轻量确认即可，不必拉满双独立。

使用前请替换​

  • 把「formatter / linter / 静态分析」换成你技术栈里真实的工具名。
  • 按你团队的风险定义，明确「哪些改动属于必须人独立复核」的高风险类。