作者： The Pragmatic Engineer

编译：深潮 TechFlow

深潮导读： AI 写代码越来越快，但审查代码的还是人。这个矛盾正在演变成一场危机：工程师被 AI 生成的 PR 淹没，要么疲于应付审查不仔细，要么干脆看 AI 没报错就点通过。大厂纷纷自建工具应对，但目前没人有标准答案。

嗨，我是 Gergely ，这是 Pragmatic Engineer Newsletter 的一期免费增刊。每期我都从资深工程师和工程领导者的视角报道大型科技公司和初创公司。今天我们讨论过往 The Pulse 期刊四个话题中的一个。完整订阅用户一周前就收到了这篇文章。如果这封邮件是转发给你的，你可以在这里订阅。

我听到许多工程领导者最关心的一件事是如何应对持续增长的代码审查负载。这个话题已经存在一段时间了，现在这类对话似乎越来越多。

对我来说，这始于今年 1 月，当时 Opus 4.5 和 GPT 5.4 开始在大多数公司写出更多更好的代码。大约从那时起，总监级别的人开始讨论软件开发的瓶颈正从编码阶段转向审查阶段。

AI 代码审查工具的爆发

2 月以来， AI 代码审查工具出现了爆发式增长来应对负载增加，专门的 AI 代码审查工具如 CodeRabbit 、 Greptile 、 Qodo 、 SonarQube （现在还有 Gitar ）的实验和采用呈爆炸式增长。还有编码工具本身提供的工具，比如 Claude Code review 、 Cursor review 、 GitHub Copilot review 。然后之前不涉及代码审查但对代码库有上下文的工具也在加入这个领域，比如 Sentry 的 Seer AI reviews 、 Linear code reviews 。

大厂自建内部工具： Uber 的 Code Inbox

大公司正在构建内部工具来改善代码审查体验。 Uber 的 Code Inbox 就是一个案例：

智能分配是 Code Inbox 内的一项功能，用于推进审查进程：

图：Code Inbox 的智能分配（Smart assignment）设置，用于推进审查流程。来源：The Pragmatic Engineer

还有风险档案功能，用于评估变更的影响，并鼓励开发者对高风险变更格外注意：

图：Code Inbox 的风险档案（Risk Profiles）功能，估算代码变更风险并提示重点关注。来源：The Pragmatic Engineer

我们报道过 Uber 如何使用 AI 进行软件开发，而且不只是 Uber ： Cloudflare （ AI Code Reviewer ）、 Faire （ Fairey ）、 HubSpot （ Sidekick ）以及许多其他公司也构建了工具来使他们的代码审查流程更流畅，因为他们发现内部实现比集成供应商的方案效果更好。

从「审查」转向「验证」

另一种方法是思考如何验证代码，而不是审查代码。说起来容易做起来难；理论上，彻底的测试应该能够验证代码按预期工作。但多少测试才算「彻底」？我们说的是什么类型的测试？集成测试和端到端测试也包括吗？模糊测试呢？形式化方法呢？如何验证新测试按预期覆盖了功能？我们如何将所有这些与可观测性连接起来？

过度审查正在拖垮工程师

过多彻底的代码审查正在让工程师精疲力竭，并导致审查质量下降。我听到很多传闻说开发者们看到其他人不再能够用心审查代码，如果 AI 代码审查没有实质性意见，他们就直接通过了。与此同时，那些像以前一样投入同样精力和时间进行代码审查的开发者感到被发给他们的 AI 垃圾 PR 淹没了。

问题存在，方案仍是实验

问题存在，但解决方案感觉更像是实验。