718 家企业、3 亿条工作记录：AI 写的代码多了 30%，交付却没跟上

如果一个团队用 AI 多写了 30% 的代码，交付会快 30% 吗？哈佛大学一项覆盖 718 家企业的研究给出的答案是：不会，甚至可能更慢。

一分钟速览

• 数据覆盖 2021 年 1 月至 2026 年 3 月，700 多家企业、约 70 万名员工、3 亿个工作事件
• AI 编程助手：代码行 +12%、提交 +9%、合并请求 +5%，仅提交增幅具统计显著性
• AI 智能体：代码行 +30%、提交 +20%、合并请求 +23%，工单解决量 +12%
• 合并请求平均评审时长 +49%，单条评论数 +53%，需要返工的占比翻倍
• 工程师只有 30% 到 40% 的时间真正用于写代码

产出涨了，交付没涨

研究用三项指标衡量编码产出：新增代码行、提交记录、合并请求。AI 助手带来的提升是温和的，智能体则是大幅的——代码行增加 30%。但换成“每名工程师每月解决的工单与大型需求”来看，智能体的提升只有 12%，助手则几乎没有提升。

30% 对 12%，这个落差就是问题的核心。多出来的代码没有等比例变成可交付的功能，而是堆在了流程的某个环节。

瓶颈转移到了评审

研究者把开发流程拆开看：规划、编码、评审、测试、部署。编码只是其中一段。数据显示，合并请求的平均评审时长增加了 49%，单条合并请求的评论数增加了 53%，需要修改后重审的比例翻了一倍。参与评审的人员占比也上升了 14%。

更值得注意的是，引入 AI 辅助评审并没有改善这一状况。这意味着问题不只是“评审人手不够”，而是“需要被判断的东西变多了”。代码量上涨，风险面同步上涨，评审者要花更多时间确认逻辑、边界和副作用。

研究还排除了一个解释：合并请求工作量的上涨，并不是因为单次提交的体量变大。

“每一行代码都是潜在风险”

社区讨论里有一句话被反复引用：每一行代码都是潜在风险。当代码由不完全可靠的合作者生成，风险会加倍——它可能在没有恶意的情况下，做出最糟糕的操作，只因为一心想完成任务。

这也解释了为什么“AI 写得更快”没有转化为“团队交付更快”。软件不是文本生产，写完不等于完成；可维护性、可观测性、故障恢复，都要在后期付费。

有工程师提出，故障平均恢复时间可能会成为衡量 AI 影响的关键指标：如果工程师对自己交付的代码写得越来越少、理解越来越浅，故障会更频繁，排查也更困难，尤其当代码库持续膨胀时。

企业该怎么用这份结论

第一，别用代码行数考核 AI 的 ROI。它是产出指标，不是交付指标。第二，把预算往评审、测试、可观测性上挪一点——AI 省下的时间，很容易在下游被吃掉。第三，对高风险模块设置“人必须读懂”的门槛，而不是“测试通过即可”。

这项研究也有边界：数据来自使用 Jellyfish 平台的企业，样本偏向已有工程度量的公司；不同语言、不同团队成熟度的差异没有完全展开。

趋势判断

AI 编程的下一阶段，竞争点不在生成速度，而在“下游吞吐”。谁能把评审、测试、发布这条链路也智能化，谁才能真正拿到生产力红利。否则，多出来的代码只是把队列排得更长。