编码代理提速后，代码审查成了瓶颈

上周，一篇 78 页的求职论文发布，为那场大家一直凭感觉争论的问题带来了实地数据。这篇论文由 Harvard 的 Fiona Chen 和 James Stratton 撰写，使用的是工程分析平台 Jellyfish 的专有数据集。摘要把结论说得很直接：AI assistant 和 AI Agent 都能提高编码生产率，但这些提升并没有完全转化为软件产出或就业增长。具体到 Agent，原因在于代码审查出现了瓶颈。

我读了论文全文，而不是相关报道，因为要判断这些结论是否可信，唯一的依据就是研究方法。

他们测量了什么？从 2021 年 1 月到 2026 年 3 月，覆盖 718 家企业、约 70 万名员工的约 3 亿条工作事件。研究将五种来源的数据合并成一个面板数据集：HR 记录、GitHub 上的版本控制活动、Jira 任务管理数据、Google Calendar，以及 GitHub Copilot、Cursor 和 Claude Code 的生成式 AI 使用遥测数据。因果识别采用交错双重差分设计，利用不同企业在不同时间采用这些工具这一事实。这是一种实实在在的识别手段，和询问开发者是否觉得自己变快了，完全不是一回事。

Assistant 和 Agent 不是同一种干预

论文把两者分开研究，而这一区分是全文最有价值的部分。

AI assistant，也就是自动补全类工具，使代码行数增加了 12%，commit 数增加了 9%，pull request 数增加了 5%。其中只有 commit 数的变化具有统计显著性。Assistant 几乎没有影响审查流程：审查时长在 9.34 天的基准上减少了 0.38 天，而变更请求和评论数量的变化都很小，也不显著。

AI Agent 则是另一回事。它们使代码行数增加了 30%，commit 数增加了 20%，pull request 数增加了 23%，而且全部具有统计显著性。随后，审查流程出现了变化。

审查时长，也就是从 pull request 创建到合并的天数：增加了 3.45 天，相比 7.03 天的基准增长了 49%。

收到正式变更请求的 PR 占比：在 0.13 的基准上增加了 0.12，接近翻倍。

每个 PR 的审查评论数：在 1.66 条的基准上增加了 0.58 条，增长了 35%。

如果你的推广计划一直把“AI 编码工具”视为同一类东西，数据说明，你正在对两种截然不同的情况取平均。Assistant 时代的吞吐量提升比较温和，审查流程消化得了。Agent 时代的吞吐量提升大得多，而审查流程明显消化不了。

审查变慢，并不是因为 diff 更大

对于这些审查数据，最直观的质疑是：PR 变大了，审查者当然会留下更多评论。作者检查过这个解释。以新增代码行数衡量的平均 PR 大小，无论使用 Agent 还是 assistant，都没有显著变化。Agent 对应的估计值为 -67.99，标准误为 126.91，基准值为 1167.97。

也就是说，平均 diff 大小没变，审查负担却上升了。这排除了规模这一解释，将问题指向变更到达的速度和构成：提交过来的变更多了，其中更多变更属于需要人真正推敲意图的那一类。论文引用了一名初级工程师的话，任何平台团队的人听了大概都会觉得熟悉：某个项目只有一名高级工程师有权批准变更，而他每周只能审查一次。在一些 AI 生成的 commit 引发故障后，团队又增加了规则，要求 AI 生成的代码必须经过高级工程师批准，进一步收紧了这个瓶颈。

产出没有变化

接下来这部分，值得放进汇报幻灯片。论文用 Jira issue 和 epic 的解决情况作为已完成软件的代理指标，结果发现，引入 AI 工具后，这些指标没有出现统计上显著的变化。作者还检查了这些任务的构成是否转向了更小、更简单的工作。也没有。就业人数同样没有显著增加或减少，按资历划分后也是如此。

论文的模型部分解释了原因。软件生产分为前后相接的两个阶段：先编写代码初稿，再在交付前验证。AI 提高了第一阶段的生产率，也可能提高 bug 率。如果验证能力固定不变，新增的代码初稿就只能摊薄原有的单位代码审查时间，因此，在不增加漏检 bug 所带来的预期损失的前提下，能够通过验证的代码比例会下降。当缺陷检测的边际收益递减更明显，以及审查原本就在总成本中占据更大比重时，这种收益折损就更大。这套形式化分析，说的正是大多数团队都感受过的事：你加速的那个阶段，本来就不是制约因素。

你的 AI 审查工具，十个 PR 才碰一个

这是我会放进幻灯片的数字。截至 2026 年 3 月，样本中近 80% 的企业已经在代码审查流程的某个环节使用过 AI 工具。采用已经基本普及。

实际使用却没有。所有审查评论中，只有 23.3% 由 AI 生成；只有 10.8% 的 pull request 收到过至少一条 AI 生成的评论。因此，审查阶段几乎人人都装了工具，却仍然几乎所有工作都由人完成。

这里有两种解读。一种是 AI 审查工具还不成熟，覆盖率以后会提高。另一种是，团队刻意让人来承担阅读代码的工作，因为把有问题的变更交付出去，代价太高；论文也提出了这种可能。无论是哪一种，如果你购买审查工具，是因为它承诺能解决审查瓶颈，那么 10.8% 的覆盖率就是你的起点。你应该测量自己团队的数据，而不是假设一次 demo 的表现可以推广到日常工作。

我们此前分析有关审查提速的说法时，也讨论过 AI 审查评论究竟有没有价值。简而言之，人们归功于 AI 审查的大部分周期缩短，来自消除了等待审查者的时间——这确实有效；而让阅读代码本身变快，通常并没有发生。

在自己的仓库里应该测量什么

论文给管理者的建议是：不要再相信中间指标。代码行数和 commit 数，恰好就是 AI 加速的那个阶段的指标。它们无法告诉你瓶颈在哪里。具体来说，我会接入以下测量：

按工具类别拆分推广。Agent 和 assistant 应该放在不同的分组里，因为它们带来的审查负担不同。如果仪表盘把两者混在一起，你看到的平均值对哪一类都没有代表性。

跟踪审查时长、变更请求占比，以及每个 PR 的评论数，并将平均 PR 大小作为控制变量。如果审查负担上升，而 diff 大小不变，你看到的就是论文描述的瓶颈，而不是变更规模造成的表象。

统计覆盖率，也就是 AI 审查工具实际发表评论的 PR 占全部 PR 的比例。厂商不会把这个数字放在定价页面上，但它决定了工具究竟有没有发挥作用。

始终保留一个产出指标。无论你如何定义“完成的工作”——关闭的 issue、部署次数，还是完成的功能——都要在扩大 Agent 使用规模时持续观察。如果产出没有增长，说明你遇到了处理能力问题，再买更多代码生成能力，只会让问题更严重。

对于第三步的覆盖率测量，比较哪些工具很重要。CodeRabbit、Greptile、Qodo、Kodus 等工具，在单个事先准备好的 diff 上都能做出漂亮的 demo。真正拉开差距的是：在不让审查者被信息淹没的前提下，它们能覆盖实际 PR 流中的多大比例，以及如何将确实需要人工处理的 diff 分流给人。这是可以测量的属性，你可以用已经人工审查过的 PR 构建一个小型 eval 集。我们的九支柱工具目录标准依据公开文档给工具评分，但它无法告诉你自己的覆盖率。只有你自己的遥测数据才能回答。

一个让人不太舒服的解读

样本中的企业真金白银地投入 Agent，换来了多出 30% 的代码，却没有在流程另一端获得可测量的更多软件产出。这不是在说 Agent 没用，而是在说，瓶颈转移了，组织架构和指标却没有跟着变。

Ars Technica 对同一项研究的报道，将其描述为一把双刃剑。我认为，更有用的理解是：瓶颈一直都在下游，现在你终于能从数据里看到它了。论文自己的结论是，要评估 AI 的回报，就必须评估整个流程；要真正获得收益，就得把人力和注意力转移到刚刚成为瓶颈的阶段。Jellyfish 也发布了一份研究摘要，值得快速浏览，看看厂商一方如何解读自己的数据。

对于任何在这方面开展 eval 的人，结论是：停止只评估生成工具，开始测量整个流程。生成代码的部分已经变快了。决定代码最终能否交付的那个部分，才是你应该重点测试的对象。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。