AI 写代码更快了，为什么整体交付没变快？哈佛研究：瓶颈卡在下游评审
哈佛大学联合 Jellyfish 平台分析了 700 余家企业、约 3 亿条工作记录，发现 AI 编程助手和智能体确实能显著增加代码产出，但真正完工的任务量并没有同步上涨。原因在于工程师只有三四成时间在写代码，AI 提速后，代码评审等下游环节反而成了新瓶颈。
研究是怎么做的
哈佛大学近期针对 718 家企业开展了一项研究，数据来自软件工程效能分析平台 Jellyfish。样本覆盖 2021 年 1 月至 2026 年 3 月、700 余家企业、70 万名员工，合计约 3 亿个工作事件。
数据来源相当多元：人力资源信息、代码版本控制系统、工单管理系统、Google 日历等日程工具，以及 GitHub Copilot、Cursor、Claude Code 等生成式 AI 工具的用量记录。
衡量编码产出用了三项指标：新增代码行数、代码提交记录、合并请求（把分支代码合入主干的申请）。
结果显示，两类 AI 工具的表现差别明显：
- AI 编程助手的提升有限：代码行数 +12%，提交记录 +9%，合并请求 +5%，其中只有提交记录的增长具有统计显著性。
- AI 智能体三项指标全面大涨：代码行数 +30%，提交记录 +20%，合并请求 +23%。
代码变多了，任务没多完成
真正关键的一步，是把“写了多少代码”和“交付了多少成果”分开看。研究者用每名工程师每月解决的 Jira 工单数和大型需求数来衡量交付：工单可以理解为一个个独立的任务单元，大型需求则对应规模更大的项目或功能。
结果并不乐观：AI 编程助手没有提升工单解决数量；AI 智能体带来了 12% 的增长，但和代码行数 30% 的涨幅相比，落差相当大。
代码产出与交付成果之间的这次“脱钩”，正是整项研究的核心问题。
瓶颈所在：写代码只占三四成时间
为了解释这个落差，研究团队把完整开发流程拆开来看——除了编码，还有需求与范围规划、代码评审、测试和部署等环节。
他们基于 Jellyfish 数据推算工时分配，并用 100 名 Prolific 平台工程师的调研结果做交叉验证，结论是：工程师真正写代码的时间只占 30% 到 40%，其余时间都花在配套任务上。 因此当 AI 把编码这一段提速，后续环节就会顶上来成为瓶颈。
评审环节的数据变化最能说明问题：
- 合并请求的平均评审时长增加 49%；
- 单条合并请求的评论数量增加 53%；
- 需要返工修改的合并请求占比翻了一倍；
- 参与代码评审的人员占比增加 14%，即便引入 AI 辅助评审也没能缓解。
作者同时排除了一个可能的解释：合并请求相关工作量的上涨，并不是因为单次提交的代码体量变大。
开发者的额外担忧：不可靠的协作方
在 Reddit 上，用户 Prime_1 用一句话概括了评审压力背后的逻辑：“每一行代码都是潜在风险。”
用户 markehammons 顺着这个思路谈到 AI 幻觉带来的叠加风险：面对一个不可靠的协作方，风险会加倍，而智能体比大多数人类协作方都更不可靠——“它们可能在毫无恶意的情况下做出最糟糕的事情，只是一心想要完成任务，却会做出各种离谱的操作。”
用户 enigmamonkey 则认为，故障平均恢复时长（MTTR，即从故障发生到恢复服务平均需要多久）可能成为衡量 AI 对软件开发影响的关键指标：如果工程师写得越来越少、对自己交付的代码理解也越来越浅，故障会更频繁，排查和修复也更困难——尤其当代码库持续扩张时，而代码库必然会扩张。
这意味着什么
Jellyfish 本身是一家提供软件工程效能度量与分析平台的公司，接入 GitHub、Jira 等工具的数据，帮企业了解开发者生产力和交付情况。这项研究也延续了它一贯的视角：只看代码行数和提交次数，会系统性高估 AI 的价值。
对使用 AI 编程、乃至尝试“氛围编程”（vibe coding，指高度依赖 AI 生成代码、人工只做轻量把关的开发方式）的团队来说，结论相当直接：引入 AI 后，吞吐量的上限很可能不在键盘这一侧，而在评审、测试和部署这些人工环节。如果这些环节的容量不跟着扩张，多出来的代码只会堆在评审队列里。
关键要点
- AI 编程助手把代码行数拉高 12%，但工单解决量没有提升；AI 智能体能带来 12% 的交付增长，仍远低于 30% 的代码量增幅。
- 工程师仅 30%–40% 的时间用于写代码，编码提速后，下游环节自然成为瓶颈。
- 评审压力显著上升：评审时长 +49%、评论数 +53%、需返工的合并请求占比翻倍，AI 辅助评审也未能改善。
- 评估 AI 效果不能只看代码产出，应转向交付成果与故障恢复等指标。