AI 多写了 30% 的代码,软件却没多交付一行:哈佛 718 家企业研究找到了瓶颈

哈佛研究人员用 718 家企业、3 亿条工作事件的数据研究了 AI 编码工具的真实影响：代码智能体让代码行数增加 30%、PR 增加 23%，但 Jira 问题与特性的完成率没有统计学上的显著变化。效率去哪儿了？答案指向代码评审——评审时长增加 49%，需要修改的 PR 接近翻倍。

过去两年，关于 AI 编码工具的讨论大多围绕一个词：更快。补全更快、写函数更快、生成测试更快。厂商的演示里，生产力的提升往往是百分之几十甚至成倍。

但「写得更快」和「软件交付得更快」是不是同一回事？最近哈佛大学的一份工作论文给出了目前为止最接近真实答案的证据：不是同一回事。

一份少见的大规模研究

论文作者是哈佛大学的研究人员 Fiona Chen 与 James Stratton，数据来自工程分析平台 Jellyfish——企业用它来跟踪工程团队的活动。这份数据的规模在同类研究里相当少见：

• 约 3 亿条工作事件（commit、pull request、Jira 工单、日历活动等）
• 覆盖 718 家企业、约 72.6 万名员工
• 时间跨度 2021 年 1 月至 2026 年 3 月

研究把两类工具分开处理：AI 编码助手（在人写代码时做补全，如典型的行内补全工具）和 AI 编码智能体（根据提示自主编写并提交代码）。利用各企业引入工具的时间差，研究者用双重差分法比较了引入前后的变化。（来源：论文原文 PDF^[1]、Ars Technica 报道，2026-10^[2]）

一个背景数字：到 2026 年 3 月，样本中 95% 的企业已经引入了 AI 编码智能体——也就是说，这不是一个「早期采用者」的小样本，而接近于行业现状的横截面。

代码暴涨，交付没变

先看代码产出，结论非常清晰。引入 AI 编码智能体后，平均每家企业：

如果只看这三个数字，「AI 让团队产能大增」的结论似乎已经成立。但研究接着问了一个更关键的问题：这些多出来的代码，有没有变成真正交付的软件？

衡量口径换成了 Jira 里的两个指标：Issue 的解决（一段代码工作部署上线才算）和 Epic 的完成（整个项目或功能完成）。结果是：两者都只有微弱的正向变化，在统计学上不显著。研究者进一步测算，可以基本排除智能体带来超过基线 12% 以上的产出增长。

换句话说：代码多了三成，交付的功能没有显著变多。 多出来的代码，在到达用户之前被什么东西挡住了。

瓶颈找到了：代码评审

研究把镜头对准了软件生产流程的下一环节——代码评审（code review）。引入 AI 智能体之后：

• PR 从提交到合并的平均时长增加 49%（相对基线约 7 天）
• 需要修改才能合并的 PR 占比接近翻倍
• 每个 PR 的评审评论数量增加 35%
• 从事代码评审工作的员工占比 增加 14%

这些数字拼起来是一个自洽的故事：智能体在上游高速生成代码，评审环节作为质量关卡，处理量和处理难度同时上升，整体吞吐被拉回原点。研究者的表述是，写代码阶段的效率提升「被生产流程下游的约束吸收了」。

论文还给出了一个解释性的模型：软件生产由「写代码」和「评审代码」两个互补阶段组成。AI 一方面提高写代码的生产力，另一方面改变了进入评审环节的草稿代码的质量——更多的代码量加上更不确定的质量，共同推高了评审的需求。而在一个典型团队里，工程师只有约 30%–40% 的时间在真正写代码（基于对 100 名工程师的调查），其余时间花在评审、沟通、规划等配套任务上——写代码环节提速，配套环节自然成为新的限速点。（来源：论文原文 PDF^[3]）

AI 评审工具为什么没接上

一个自然的疑问是：评审慢，那就用 AI 做评审。数据显示这条路目前还没走通。

到 2026 年 3 月，样本中约 80% 的企业已经在用某种 AI 代码评审工具，但全部评审评论中只有 23.3% 由 AI 智能体产生，全部 PR 中只有 10.8% 与 AI 智能体相关——绝大多数验证工作仍然由人完成。研究还特别指出，评审时长的增加在引入 AI 评审工具之后依然持续存在。

这里有一个值得注意的不对称：生成可以大规模并行，评审不行。 生成端的边际成本趋近于零，而评审是一种带有责任属性的判断——它要求一个能对结果负责的人理解这段代码做了什么、为什么这么做、出问题时谁来承担。这部分工作目前既没有被自动化替代，也没有随生成端同步提速。

数据还显示，引入 AI 工具后企业没有出现统计学上显著的就业变化（研究结合 Jellyfish 的活跃员工数据与 LinkedIn 信息做了交叉验证）——既没有大规模减少，也没有相应扩张。

这份研究真正提醒了什么

这份研究没有否定 AI 编码工具的价值——三成的代码产出提升是真实且显著的。它提醒的是另一件事：用错指标，会得出错误的结论。

对工程管理者来说，如果用代码量、commit 数、PR 数来衡量 AI 工具的收益，会系统性高估其价值——这些恰恰是 AI 最容易拉高的指标，也恰恰是离「软件交付」最远的指标。真正的约束在评审管道：评审容量、评审工具、评审流程的设计。不解决这一环，生成端的收益很难转化为交付端的收益。

对行业叙事来说，这项研究提供了一个校准：微观层面的速度提升，不能直接外推为宏观层面的产出增长。这与此前多项研究的发现方向一致——AI 对个体任务的加速是清楚的，对组织级产出的影响则取决于流程中其他环节是否同步调整。

对普通读者来说，可以记住一个简单的判断框架：评估任何一类 AI 工具的效果时，先问它优化的是瓶颈还是非瓶颈。如果一个环节本来就不是限速点，把它提速只会让下一个环节更堵——就像给一条畅通的路拓宽车道，堵的永远是下一个收费站。

写在最后

这份研究的时间窗截至 2026 年 3 月，研究者也明确指出：工程组织仍在适应新的工作流，随着团队更合理地决定何时、如何使用自主智能体，生成速度与评审时长之间的平衡可能会演变。也就是说，现状不是终局。

但方向已经很清楚：AI 编码的竞争，正在从「谁写得更快」转向「谁能让写出来的东西更快通过验证」。 生成端的军备竞赛已经打了两年，下一阶段的故事大概率发生在评审、测试与验证这些长期被当作「配套环节」的地方——那里才是眼下真正卡住软件交付的地方。

对正在引入 AI 编码工具的团队，这份研究的建议可以压缩成一句话：别只数生成了多少代码，去量一量你的 PR 平均要多久才能合并。

引用链接