代码多写30%，交付原地踏步：瓶颈卡在评审

代码产出涨了约30%，交付量却没动。两份在2026年相隔数天发布的研究，指向了同一个不太舒服的结论。

哈佛一份工作论文分析了700多家软件公司、约3亿个工作事件。团队采用AI编码智能体后，每位开发者产出的代码量上升约30%；但这些公司最终交付的成品软件，在统计上没有显著变化。

贝恩对近300位资深技术负责人的调查，从另一个方向印证了同一幅图景：开发者完成的任务多了约21%，花在代码评审上的时间却涨了约91%。

打字变快了，交付没变快。原因集中在一个地方——代码评审。

这篇论文题为《企业中的AI：软件生产的瓶颈》，作者是哈佛经济学家Fiona Chen与James Stratton。研究把Jellyfish分析平台的工程遥测数据与GitHub活动数据配对，覆盖718家公司、超过72.5万名从业者，时间跨度从2021年1月到2026年3月。按论文的定位，这是首次从公司层面、而非单个开发者层面，大规模实证观察编码智能体到来后发生了什么。

具体数字是这样的：

• 人均代码行数上升约30%，按基线每工人月约5017行计算，相当于每月多出约1494行。
• 提交数上升约20%，拉取请求上升约23%。
• 作为“已交付工作”代理指标的问题解决率与史诗完成率，没有统计显著的增长。
• 拉取请求从提交到合并的时间上升49%，按基线7.03天计算，约多出3.45天
• 被打回要求修改的拉取请求占比接近翻倍。
• 每个拉取请求的评审评论数上升35%。
• 被分配做代码评审的员工占比上升14%。

最后一组数字就是机制本身。智能体生成代码的速度，超过了组织消化它的速度，多出来的部分堆在评审队列里。论文作者写得很直白：代码评审成了瓶颈。他们的建议同样直白——要兑现AI带来的收益，需要在下游评审能力上做配套投入，而不是继续加大代码生成。

有一个细节值得单独拎出来。到2026年3月，数据集里80%的公司已经在跑AI代码评审工具，但只有23%的评审评论由AI生成。工具买了，人的约束并没有被移除。

贝恩的调查从管理者一侧说出了同一件事。其2026全球技术报告于9月29日发布，调查了近300位资深技术负责人，结论与哈佛数据几乎逐项对应：开发者用AI工具完成的任务多约21%；评审AI产出的时间上升约91%；开发者同时处理的工作流多了47%。

负责人对一到两年内发布周期加快148%、开发者生产力提升95%抱有预期，而组织当下实际拿到的只有20%到27%。

贝恩合伙人、该报告作者之一Purna Doddapaneni对CIO Dive说：“瓶颈已经从写代码转移到了信任代码。每一处改动仍然必须被理解、评审、测试和加固，而这些工作大部分仍然要经过人。”

预期收益与实际收益之间的这道缺口，一句话就能概括：产出在个人层面上升，到了组织层面，就按最慢的那个人工检查点的速度沉淀下来。

如果评审是瓶颈，AI评审工具看起来就是现成的答案。但这个品类的第一份排行榜，展示的恰恰是反面。

10月5日，GitHub上线ReviewBench，一个面向代码评审智能体的开放基准，由19种语言、187个公开开源仓库中的219个真实拉取请求构建，参照了1.039亿个真实GitHub拉取请求的分布。首期榜单上，GitHub Copilot的代码评审智能体以40.1%的grounded F1分数领先。

这个数字值得再读一遍。在一个由自家厂商设计并托管的基准上，得分最高的智能体，按该基准奖励的精确率与召回率平衡口径，只覆盖了标准答案认定重要内容的一半不到。

另一侧的数据来自Faros AI的2026遥测，覆盖4000多个团队、2.2万名开发者：AI采用率高，伴随的是平均拉取请求体积上升51%、每位开发者的缺陷数上升54%。

于是当前的循环是这样的：智能体写出更大的拉取请求，更大的拉取请求评审更久，AI评审员抓到的问题不到一半，多出来的评审负担落回人身上。贝恩报告中提到，亚马逊的内部应对是把最多70%的代码评审推给AI。这在亚马逊的规模和投入下或许可行；对多数团队来说，对数据的诚实解读是：AI评审是一道过滤器，不是替代品。

为什么偏偏是评审先撑不住，值得说清楚，因为答案决定了力气该往哪使。

• 评审是串行的、由人把关的。生成随算力扩展，评审随“能说出这句代码是对的”的人数扩展。给前者加算力，对后者毫无帮助。
• 评审需要的上下文最多。智能体能凭一句提示写出一个看似合理的函数；判断这个函数是否该进这个代码库、是否重复了已有实现、是否破坏了只存在于维护者脑子里的某条不变量，需要的上下文塞不进提示词。
• 信任无法并行。一个团队可以合并五条AI生成的分支，但如果没有人真正理解其中任何一条，团队就是用开发速度换来了运维风险。哈佛数据里接近翻倍的打回率说明，评审者正在以高得多的比例拒绝这些工作。没有信任的量，只是队列。
• 更大的差异块会击穿评审者的注意力。关于代码评审的研究多年来一直显示，变更集越大，缺陷发现率下降越陡。Faros测到平均拉取请求体积上升51%至154%不等。评审环节的输入质量，恰好在量上升的那一刻变差了。

如果团队上了编码智能体、拉取请求正在变老，可以按顺序过一遍下面这份清单。每一条都对应数据里确实坏掉的那一环。

1. 给生成的拉取请求体积设上限。定一条硬规范，比如改动约400行，要求智能体把工作拆到堆叠的拉取请求里。这是杠杆最大的一条，因为它把差异块恢复到人类评审真正能抓到缺陷的尺寸。
2. 把评审能力当资源来预算，而不是当人情。按哈佛数据，如果智能体把产出抬高30%，团队大约要把多出14%的时间挪到评审上。这段时间必须从某处明确划出来；如果从哪儿都不划，队列就会吸收它，合并时间随之拉长。
3. 给评审深度分级。不是每处改动都值得同等审视。自动生成的样板代码、测试脚手架和文档可以走轻量关卡；涉及鉴权、支付、数据迁移和并发的改动，无论出自谁或什么工具，都要资深的人来看。
4. 把AI评审当前置过滤器，永远不要当闸门。ReviewBench那个40%的F1就是预期设定。让AI评审员剥掉机械性的评论——风格、死代码、明显的bug——把人的注意力留给设计与正确性。任何有风险的改动，都不要让一个绿色的AI评审代替人工批准。
5. 盯合并时间和打回率，别盯提交数。如果看板在庆祝提交数和代码行数，它奖励的正是搞坏流水线的那种行为。每个拉取请求的合并时间与返修率，才能告诉你评审跟不跟得上。
6. 把评审标准写进给智能体的提示里。多数返修循环来自智能体不知道团队规矩。把约定、错误处理模式、禁止写法编码进智能体的指令，是从源头打击接近翻倍的返修率。

这些研究没有说AI编码智能体没用。它们说的是，行业买下了流水线的前半段——生成，现在正在为忽视后半段——验证——付出代价。写代码从来不是唯一的约束，它只是那个能被一个对话框放松的约束。

在这批数据里真正拿到收益的团队，不是生成代码最多的那些，而是把资源再投回评审能力、把差异块保持得小、把AI评审当作第一遍而非判决的那些。贝恩自己的数字显示，组织当下拿到的只是负责人预期收益的五分之一到四分之一。差距几乎全部位于代码编辑器的下游。

软件的下一次真实生产力跃升，不会来自一个写得更快的模型。它会来自让信任变得可扩展：更好的评审工具、更小的变更，以及工作从生产代码转向认证代码的工程师。几份报告在这一点上是一致的。接下来，是流程要跟上。