哈佛研究：AI 代码生成受评审瓶颈制约，整体交付效率未同步提升

哈佛大学近期针对 718 家企业开展的一项研究借助了 Jellyfish 分析平台，研究发现：尽管 AI 编程助手与智能体能够提升代码产出量，但并不会转化为完工工作量的同步增长，部分原因在于 AI 生成的代码加大了开发后期的工作量，尤其是代码评审环节。

研究数据的时段为 2021 年 1 月至 2026 年 3 月，覆盖 700 余家企业、70 万名员工，合计约 3 亿个工作事件。数据来源于多个渠道，包括人力资源信息、代码版本控制系统、工单管理系统、谷歌日历等日程工具，以及 GitHub Copilot、Cursor、Claude Code 等生成式 AI 工具。

研究人员采用三项指标衡量编码产出：新增代码行数、代码提交记录、合并请求。

AI 助手只会小幅提升编码产出：代码行数增加 12%，提交记录增加 9%，合并请求增加 5%；其中仅提交记录的增加具有统计显著性。AI 智能体则能在三项指标上带来显著的大幅增长：代码行数增加 30%，提交记录增加 20%，合并请求增加 23%。

论文作者基于上述数据，以每名工程师每月解决的 Jira 工单和大型需求数量评估软件交付成果；工单被视为独立的工程任务单元，大型需求对应规模更大的项目或功能。研究发现，编程助手并没有提升工单解决数量，而 AI 智能体带来了 12% 的增长，但增幅远低于代码行数 30% 的预估涨幅。

为解释这一落差，研究团队考察了完整开发流程——编码之外还包含多个环节：功能与范围规划、代码评审、测试和部署。

我们基于 Jellyfish 数据推算工时分配，并通过面向 100 名 Prolific 平台工程师的调研验证推算结果：工程师仅将 30% 至 40% 的时间用于写代码，其余时间都投入到配套的任务中。当 AI 提升编码效率时，后续配套任务就可能成为瓶颈。

具体来看，合并请求的平均评审时长增加了 49%，单条合并请求的评论数量增加了 53%，需要修改的合并请求占比翻了一倍。除此之外，参与代码评审的人员占比增加了 14%，即便引入 AI 辅助评审也没有改善这一状况。作者同时指出，合并请求相关工作量上涨并不能用单次合并请求体量变大来解释。

Reddit 用户 Prime_1 在评论这项研究结果时表示：“每一行代码都是潜在风险”。用户 markehammons 进一步延伸了这个观点，强调了 AI 幻觉带来的额外风险：

当你面对一个不可靠的合作对象时，风险更是加倍，而智能体比大多数合作对象都更不可靠。它们可能在毫无恶意的情况下做出最糟糕的事情，只是一心想要完成指派任务，却会做出各种离谱的操作。

Reddit 用户 enigmamonkey 还进一步提出，故障平均恢复时长或许会成为评估 AI 对软件开发影响的一项愈发重要的指标：

如果工程师对自己交付的代码的编写量越来越少、理解也越来越浅，我猜想故障会变得更加频繁，排查修复也更加困难。尤其是代码库持续扩张的时候——而代码库必然会扩张。

Jellyfish 是一家软件公司，提供用于衡量和分析软件工程绩效的平台。它接入了来自 GitHub 和 Jira 等工具的数据，帮助企业了解开发者生产力和软件交付情况。

查看英文原文：https://www.infoq.com/news/2026/10/jellyfish-ai-productivity/