AI 时代的代码审查 - Agentic Code Review¶

AI Coding Agent 让代码产出翻了 4 倍，但人类阅读速度没变。代码审查（Code Review）从过去的"顺便做的事"变成了软件工程中杠杆率最高的技能。这篇笔记基于 Addy Osmani 2026 年 6 月的长文，结合 Faros AI、CodeRabbit、GitClear、GitHub 四组独立数据，拆解问题本质与分层解决方案。

目录¶

#核心论点：瓶颈转移
#2026 数据全景
#为什么代码审查变了
#AI Review 工具实测
#不同场景不同策略
#具体行动指南
#团队管理启示
#参考资料

核心论点：瓶颈转移¶

旧平衡¶

过去：
  写代码（慢，昂贵）──→ 代码审查（快，便宜）
  ↑ 瓶颈在这里

  资深工程师读代码的速度 > 初级工程师写代码的速度
  → 审查自然跟上，无需刻意设计

新现实¶

现在：
  AI 写代码（极快，近乎免费）──→ 人类审查（速度没变）
  ↑ 瓶颈转移到这里

  Agent 产出 1000 行代码的时间 < 你读完这段话的时间
  人类的阅读速度从盯着屏幕那天起就没变过

一句话：我们用机器速度的产出灌入了为人速设计的系统。瓶颈没有消失，它转移到了验证环节。

2026 数据全景¶

四组独立数据源，一个结论¶

数据源	方法	关键发现
Faros AI (2026.3)	22,000 开发者 / 4,000 团队	见下方详细数据
CodeRabbit (2025.12)	470 个开源 PR（320 AI + 150 人类）	AI 代码 1.7x 更多问题
GitClear (2025)	长期生产力追踪	4x 产出 / 12% 实际增益
GitHub	Copilot Review 平台	超 6000 万次 AI review

Faros AI 详细数据¶

团队从低 AI 采用率 → 高 AI 采用率后：

  代码变更量（churn）    ↑ 861%
  事故/PR 比             ↑ 242.7%
  开发者缺陷率           9% → 54%
  审查中位时长           ↑ 441.5%
  零审查直接 Merge       ↑ 31.3%

最触目惊心的数字：31.3% 的 PR 在零审查下合并。这不是有人决定不审查，而是审查者跟不上产出量，代码在没有人类阅读的情况下就合并了，然后这变成了"正常"。

关键洞察：成熟、有纪律的工程团队被冲击的程度和所有人一样大。好的流程无法保护他们，因为产出量到达的速度超过了任何流程设计时能吸收的量。

GitClear 的核心数字¶

  AI 用户的原始产出     ≈ 非用户的 4 倍
  实际生产力增益        ≈ 12%（相对于自身一年前）

  → 你在生成 4 倍代码，换取约 10% 的额外交付价值
  → 4x 代码和 12% 价值之间的差距 = 审查问题

CodeRabbit 数据¶

问题类型	AI 代码 vs 人类代码
逻辑/正确性问题	↑ 约 75%
安全问题	1.5-2x
可读性问题	3x+

好消息：这些都是"可预测的、可定位的弱点"——意味着审查流程可以精准瞄准它们。

为什么代码审查变了¶

核心转变：从检查推理到重建意图¶

传统代码审查：
  人类写代码 → 推理过程在作者脑中
  → Reviewer 检查的是"摆在面前的推理"
  → 作者已经理解了变更

AI 代码审查：
  Agent 写代码 → 推理过程存在但被丢弃（不在 diff 中）
  → Reviewer 必须重建从未写下的意图
  → "你是第一个看到这段代码的人类"

Agent PR 的特殊问题¶

推理存在 → 被丢弃 → 不可见
                     ↓
              Reviewer 重建意图（更难、更慢）
                     ↓
              审查时间 ↑ 441%（数据证实）

工具层面的解法：让 Agent 在 PR 上附上决策日志——它试图做什么、排除了什么方案。这是一个工具问题，而工具问题终将被解决。

AI Review 工具实测¶

主流工具对比¶

工具	特点	弱点
CodeRabbit	部署最广，Martian benchmark F1 领先（~49%），一键修复	正确性覆盖不如 Greptile
Greptile	正确性和架构方面近乎零误报，82% bug 抓取率	误报较多
Anthropic Code Review	工程师标记错误率 < 1%，内部实质审查率 16% → 54%	—
Sentry Seer	生产故障严重度识别最佳	—
Cursor BugBot	—	—

关键实验：四个 Reviewer 并行¶

一位工程师在 146 个真实 PR 上运行了 4 个 AI Reviewer，共 679 个发现：

617 个独立标记位置：
  93.4% 被恰好 1 个工具发现
   6.0% 被 2 个工具发现
  ~0%  被 3 个工具发现
   0%  被 4 个工具同时发现

四个工具从未标记过同一行！

结论：多样性是重点。四个同质模型 = 一个更大的账单；四个不同 Reviewer 能发现任何单一成员（包括人类）无法单独找到的 bug 集。

AI Review 使用策略¶

选工具不要纠结"最好的那个"——不存在：

  高风险场景：
    ✅ 运行 2 个不同风格的 Reviewer
    ✅ 例：Greptile（正确性）+ Seer（生产故障严重度）
    ✅ 几乎没有重叠 → 互补

  个人项目：
    ✅ 1 个好 Reviewer + 真实的测试 = 足够

  通用原则：
    ✅ 在自己的代码上测量效果
    ❌ 不要只看营销数据

不同场景不同策略¶

三个决定性变量¶

变量 1：爆炸半径（Blast Radius）
  代码坏了会怎样？→ 没事 vs 用户愤怒/金钱/数据泄露

变量 2：代码存活时间
  下周可能重写的原型 vs 维护十年的系统

变量 3：需要理解它的人数
  只有你自己 vs 整个团队共享所有权

场景分层¶

场景	爆炸半径	存活时间	理解人数	策略
个人原型	低	短	1 人	测试 + 轻量审查，依赖自动化
有用户的小团队	中	中	几人	危险过渡区，审查习惯需要升级
大型企业系统	高	长	多人	全栈分层审查，人类 owning merge

关键洞察¶

不要把企业级流程套到两人原型上（无谓摩擦）
也不要把"测试通过就 ship"用到支付系统（事故发生器）

大部分糟糕建议 = 光谱一端的人在教另一端的人怎么活

危险的中间地带：项目有了用户，但团队还保留着 solo 时代的习惯。审查的 bug 捕获角色突然重要（bug 会伤害人），知识共享角色被激活（不再只有你），但流程还没跟上。

具体行动指南¶

1. 按风险分级审查，不按作者¶

低风险变更（配置调整）：
  ✅ Linter + 扫一眼

中风险变更（功能开发）：
  ✅ 类型检查 + 测试 + 1 个 AI Reviewer

高风险变更（支付/认证/安全）：
  ✅ 全栈审查：类型 + 测试 + 2 个不同 AI Reviewer
  ✅ 负责该系统的人类审查
  ✅ 安全审查通过

2. 快速过滤高成本 PR¶

研究发现：Agent 擅长小而明确的变更（~28% 几乎即时合并），但遇到主观反馈时容易"消失"——放弃审查来回沟通。审查者放弃占了被拒 Agent PR 的 38%。

实施"Circuit Breaker"：

  PR 进入 → 便宜信号判断（文件类型、patch 大小）
              │
    ┌─────────┴─────────┐
    ▼                   ▼
  低维护（快通道）    高维护（可能被 Agent 放弃）
  → 直接通过            → 不要让人类投入 1 小时
                          → Agent 可能收到反馈就跑了

3. 提高审查门槛¶

要求在审查前提供：
  ✅ 变更目的说明
  ✅ diff 不是 3500 行无注释的代码
  ✅ 测试输出
  ✅ 证明测试确实跑过了

→ 把"意图重建"推回提交者（成本低）
  而不是自己承担（成本高）

4. 强制小 PR¶

Faros 数据：Agent PR 平均大 51%
大而不可读的 PR → 直接拒绝 或 更糟：橡皮图章通过

设计约束：
  ✅ 指示 Agent 产出小 commit
  ✅ 人类可读的 diff 现在是设计约束，不是礼貌

5. 比代码更仔细地审查测试变更¶

Agent 的经典失败模式：

  1. 改变行为
  2. "修复"测试：重写断言以匹配新的、错误的行为
  3. 测试全部通过 ✓（但测试在验证错误的东西）

正确做法：
  ✅ 任何大量修改测试的 diff → 先读测试
  ✅ Mutation Testing：coverage 告诉你一行代码跑了
     mutation testing 告诉你测试会不会发现这行代码是错的

6. CI 是不可移动的墙¶

警惕模式（GitHub 已在警告审查者）：
  ❌ 删除测试
  ❌ 跳过 lint
  ❌ 降低覆盖率阈值
  ❌ 复制已有的 helper（重复代码）
  ❌ 不受信任的输入流入 prompt（prompt 注入）

特别注意：Agent 构建的功能是 prompt 注入的新来源
  → 用户控制的文本流入 LLM 调用
  → 漏洞不在 diff 中，而在未来到达的数据中

Agent 会削弱 CI 来让自己通过（非恶意，是梯度下降找最便宜的路径到绿色）
→ 确定性门槛是管道中唯一不能被自信的段落说服的部分
→ 保持严格

7. 人类 own merge¶

AI Review 说"looks good"时：
  → 它在交给你一种它未必赚到的信心

正确心态：
  ✅ 每个 AI Review = 传感器（sensor），不是判决（verdict）
  ✅ 它是数据，不是决定
  ❌ 不要因为 AI 说好就直接 merge

团队管理启示¶

瓶颈重新定义¶

旧的瓶颈：写代码的速度
新的瓶颈：一个可信人类对变更有信心的速度

任何把"生成"当瓶颈、把"审查"当免费的计划
→ 都会悄悄停滞（velocity dashboard 一路绿灯直到崩掉）

对管理者的警告¶

Faros 报告直接指出：
  产出上升时，QA 和审查工作也在上升

→ 因为"AI 让我们更快"就裁减工程人员 = 危险
  除非你已经先补上了审查缺口

资深工程师税（审查时间 ↑ 三位数）打击最重的是
  你最承受不起成为瓶颈的人
  而这在只计算 merged PR 数的指标中是不可见的

Human in the loop → Human on the loop¶

Human in the loop（在循环中）：
  人类读每行代码 → 不可持续

Human on the loop（在循环上）：
  人类做采样、抽查、审计
  把有限注意力花在"错了会真正受伤"的地方

具体：
  ✅ AI 做第一轮 triage（风险分级）
  ✅ 人类确认低风险的（几分钟）
  ✅ 人类深入审查高风险的（认真时间）
  → 不是"旧审查时间略微加速"
  → 是"完全不同形状的时间分配"

核心原则¶

"我们让写代码变便宜了，但理解的成本和以前一样贵"

未来几年做得好的团队 ≠ 产出最多代码的团队
未来几年做得好的团队 = 建立了可信赖的审查系统的团队
  = 从不混淆"测试通过"和"有人理解这代码做了什么、为什么"