封面图：Code Review in the Age of AI

封面图来源：Addy Osmani / Substack（见原文页面）。

原文链接：https://addyo.substack.com/p/code-review-in-the-age-of-ai?WT.mc_id=AI-MVP-5003172

AI 让写代码更快，但并没有“杀死”代码审查；相反，它把“举证责任”变得更明确了：你可以让 AI 帮你更快地产出改动，但你仍然需要用证据证明它真的能跑、真的符合预期。

作者 Addy Osmani 在文中给出的核心观点很直白：如果一个 Pull Request 里没有“它能工作”的证据（手动验证步骤、日志/截图、自动化测试结果等），那并不是在更快地交付，只是在把风险和返工推给下游。

到 2026 年初，已有调查显示，超过 30% 的资深开发者表示他们交付的代码“主要由 AI 生成”。与此同时，研究也指出：AI 在草拟功能方面很擅长，但在逻辑、安全与边界条件上更容易出错——例如在纯逻辑层面，错误率可能高出 75%。这导致两种典型工作流分化：

  • 个人开发者更倾向于用“测试套件当安全网”，在 AI 的“推理速度（inference speed）”下快速迭代。
  • 团队协作则需要更多“人类的审查与签字”，以获得上下文、合规与可维护性保障。

作者强调：AI 放大了“必须亲眼看到代码做对事情才算工作”的规则，而不是给它开了例外。

开发者如何把 AI 用在审查上

文中把常见做法归纳为几类（不同团队/个人会组合使用）：

  • 临时的 LLM 自检：把 diff/关键片段贴给 Claude、Gemini、GPT 等模型，在提交前做快速 bug/风格扫描。
  • IDE 集成：Cursor、Claude Code、Gemini CLI 等在编码过程中给出行内建议、重构方案。
  • PR 机器人与扫描器：用 GitHub Copilot 或自建 agent 在 PR 上标注问题；并配合 Snyk 等静/动态分析做安全检查。
  • 自动化测试闭环：让 AI 生成并运行测试，把覆盖率（例如 >70%）作为门槛。
  • 多模型复核：用不同模型做不同角色（一个偏生成、一个偏安全审计），尽量降低偏差与盲点。

作者指出：工作流与心态的差异，在“你是独立开发者”还是“你在团队里交付会被别人长期维护的代码”时，会非常大。

个人 vs 团队：一张速览图

个人开发者：以“推理速度”交付

作者观察到，不少个人开发者会更“信任 AI 产出的整体感觉”，只挑关键部分看一眼，把测试当作主要防线。

他引用了一位工程师的说法（见相关采访/文章），大意是“现在不怎么读代码了：看着 AI 输出流，有时瞄一眼关键点，但大部分代码不会读”。在这种模式下，瓶颈从“打字速度”变成了“等 AI 生成输出的时间”（作者将其称为“推理速度（inference speed）”）。

但作者也强调了反面：**如果没有扎实的测试实践，所谓速度收益会很快被返工吞掉。**不做审查并不会消灭工作量，只是把它推迟到更糟的时间点（线上、客户、值班）。

做得好的个人开发者，通常会：

  • 把 自动化测试当作安全网，追求较高覆盖率（比如 >70%），并用 AI 来补齐测试。
  • 尤其重视 语言无关、数据驱动的测试：如果测试足够完整，agent 甚至可以在不同语言里实现/修复同一规格，靠测试一路验证。
  • 在关键时刻仍然进行 手动验证与关键推理：跑起应用、点 UI、亲自使用功能；高风险场景读更多代码、加更多检查。

作者给出一个常用的个人工作节奏：先让 AI 写 spec.md，人类确认规格，然后进入循环：写 → 测 → 修。

他也提醒：即便追求速度，看到明显“丑陋代码”也要及时处理，不要让技术债累积成更大成本。作者在文中强调的底线与“你交付的是你已经证明能工作的代码”这类观点一脉相承。

团队协作：AI 改变了审查瓶颈，但不会替代人类判断

在团队里，AI 可以当强力助手，但不能替代质量、安全与可维护性所需的人类判断。

作者引用 Graphite 相关人士的观点（见报道）：很难想象 AI agent 会成为“真正的人类工程师签字”的替代品。原因并不是 AI 只会漏掉风格问题；更现实的挑战是：AI 让代码产量暴涨，把审查压力推到人类身上。

文中引用了多个数据点来说明这个趋势：

  • 采用 AI 辅助后，PR 规模变大（例如新增行数增加约 18%，见相关数据）。
  • 与每个 PR 相关的事故/失败率也在上升（例如事故/PR 上升、变更失败率上升，见基准报告）。

当产出增长速度超过验证能力，审查就会成为真正的速率限制器。作者的建议是：即使 agent 一次能做很大的改动，也要强制“增量化”——把输出拆成更小、更可审查的提交与 PR，让人类能更清楚地理解意图与风险。

安全：AI 的弱点非常“可预测”

作者强调，安全是人类监督绝对不可省略的领域之一。

文中引用安全研究结论：相当比例的 AI 生成代码包含安全缺陷（见Veracode 的分析）；此外，逻辑错误更常见，而 XSS 等漏洞出现频率也可能显著更高（见ACM 研究论文）。

更棘手的是，agentic tooling 与 AI 集成 IDE 还带来了新的攻击路径（如提示注入、数据外泄，甚至 RCE，见相关安全披露/报道）。因此，最佳实践往往是“混合策略”：AI 负责发现线索，人类负责验证与决策。

作者给出了一条明确规则：

如果代码涉及认证、支付、密钥、或不可信输入，把 AI 当成高速实习生；合并前必须有人类威胁建模审查，并跑一轮安全工具。

审查也是知识传递机制

团队做代码审查，除了找 bug，也是为了共享系统上下文。

如果 AI 写了代码、但提交者自己也说不清“为什么这样写能工作”，那团队的知识传递链条就断了：当值班工程师凌晨 2 点要排障时，成本会急剧上升。

作者举了一个典型案例：OCaml 维护者拒绝了一个 1.3 万行的 AI 生成 PR（见报道）。问题未必是代码质量，而是没人有精力去审这么大的改动，而且审 AI 生成的代码往往更“费脑”。结论是：AI 能把代码量灌到你面前，但团队必须管理好体量，否则审查会彻底崩溃。

让 AI 审查工具“真正有用”

作者提到，团队对 AI 审查工具的体验两极分化：

  • 好的一面：在部分场景下能捕获大量低级问题（空指针、遗漏测试、常见反模式等）。
  • 糟的一面：很多评论像“文字噪音”，泛泛而谈，反而让人分心。

所以结论是：**AI 审查工具需要认真配置。**包括调灵敏度、关掉无用评论类型、制定清晰的使用边界。配置得当时，AI 可以清掉 70%~80% 的“低垂果实”（见Graphite 的总结），把人类注意力留给架构与业务关键逻辑。

作者也再次强调“更小、更可堆叠”的 PR：即使 AI 能一次性做完大改动，也应该拆成清晰的提交，尽早提交、频繁提交（作者此前也写过类似的工作流建议，例如Going into 2026 的 LLM coding workflow）。

同时，团队要坚持“人类责任边界”：无论 AI 参与了多少，最后必须有一个人对合并负责。文中用了一句老话概括：

计算机永远不能被追责；作为人类，你必须承担责任。

PR 合同：作者欠审查者什么

无论你是个人还是团队，作者认为一个越来越通用的最佳实践是：把 AI 生成的代码当作“有用的草稿”，但必须经过验证（另见作者的文章：Treat AI-generated code as a draft）。

他总结了一个可复用的 PR 模板（也可以理解成“PR 合同”）：

  1. What/Why：1~2 句话说明做了什么、为什么做。
  2. Proof it works：测试通过、手动验证步骤（截图/日志）。
  3. Risk + AI role：风险等级，以及哪些部分由 AI 生成（例如“高风险：支付模块”）。
  4. Review focus：希望人类重点关注的 1~2 个区域（例如架构选择）。

作者强调，这不是官僚流程，而是对审查者时间的尊重，也是强迫自己“真正理解变更”的方式：如果你无法写清这几项，通常意味着你并不理解自己的改动到可以让别人批准。

核心原则（可当作团队约束）

  • 坚持“证据”而不是“承诺”：让“可运行、已验证”的代码成为基线。生成后要求 agent 跑单测；PR 必须带测试或演示证据。
  • 把 AI 当第一轮审查者，而非最终仲裁：让一个模型写、另一个模型审，人类做编排与决策；AI 更像拼写检查，而不是责任编辑。
  • 人类审最关键的部分：安全风险、是否重复造轮子（AI 常见问题）、是否可维护。
  • 强制增量化：小块更容易生成、更容易审；绝不提交你解释不清的代码。
  • 保持高测试标准：善用 AI 生成边界用例测试，但不要把测试当作“可选项”。

展望：瓶颈从“写代码”转移到“证明它能工作”

作者认为，AI 正在把代码审查从“逐行门禁”变成“更高层的质量控制”，但人类判断依然是安全关键组件。

未来的审查，会越来越像在审“作者与 AI 的对话/计划”，而不仅仅是 diff。审查者更像编辑或架构师：把机械检查交给自动化，把精力放在真正重要的风险与决策上。

对个人开发者来说，这条路会越来越刺激：工具会进一步缩短从想法到实现的时间。但即便如此，成熟的做法仍然是“信任，但验证”。

对大团队来说，围绕 AI 的治理会更正式：企业会要求“员工已审查并签字”的流程；类似“AI 代码审计员”的角色可能出现；平台也会演进为能提供更好的跨仓库上下文与策略约束。

无论技术如何进步，作者给出的底线不变：代码审查的目的，是确保软件满足需求、安全、健壮、可维护。AI 不会改变这些基本盘，只会改变实现这些目标的路径。

归根结底，AI 时代优秀的代码审查会拥抱这种变化：让 AI 加速机械劳动，但绝不放弃对责任的把关——用“proof over vibes（用证据压过感觉）”来对抗“看起来差不多就行”的诱惑（作者在文中也用到了相近的表述，并指向相关讨论）。