一句话结论
研究显示，AI编程工具大幅提升代码产出量，但下游评审、测试等工作量激增形成瓶颈，整体生产力并未同步提升。
关键要点
- 研究覆盖718家企业、70万名员工及3亿个工作事件，数据时段横跨2021年1月至2026年3月。
- AI助手仅带来小幅代码产出提升，其中代码行数增加12%，提交记录增加9%，且仅提交记录的增幅具备统计显著性。
- AI智能体大幅拉升编码指标，具体表现为代码行数增加30%，提交记录增加20%，合并请求增加23%。
- 引入AI智能体后，软件交付层面的Jira工单解决数量仅实现12%的微弱增长，远低于代码产出的预期涨幅。
- 代码评审环节压力陡增，合并请求的平均评审时长增加49%，单条请求的评论数量增长53%，需修改的请求占比翻倍。
背景与事实
哈佛大学近期联合Jellyfish开展了一项规模庞大的软件研发效能研究。该研究依托Jellyfish提供的分析平台，深入剖析了生成式人工智能在真实企业环境中的效能表现。研究团队收集并处理了从2021年1月至2026年3月期间的海量数据，覆盖了700余家企业的70万名员工，合计涵盖了约3亿个独立的工作事件。
研究数据并非局限于单一的代码管理工具，而是采取了多源交叉验证的方法。数据来源广泛，不仅包含了企业内部的人力资源信息和工单管理系统，还接入了代码版本控制系统、谷歌日历等日程安排工具。尤为重要的是，研究全面涵盖了当前主流生成式AI工具的使用轨迹，包括GitHub Copilot、Cursor以及Claude Code等智能编程助手与智能体。研究人员通过追踪代码行数、代码提交记录以及合并请求这三项核心指标，构建了衡量编码产出的量化体系。
在评估实际业务交付结果时，研究团队引入了更为宏观的视角。他们以工程师每月解决的Jira工单数量和大型需求数量作为最终生产力指标。在Jira系统中，工单被视为相对独立且粒度较小的工程任务单元，而大型需求则对应着具有更复杂商业逻辑、规模更大且周期更长的项目或核心功能模块。通过这种从“代码产出”到“业务交付”的双层漏斗分析，研究试图揭示AI工具在提升微观效率时，对宏观生产力产生的非线性影响。
研究结果表明，不同的AI工具在提升编码产出方面存在显著的差异。传统的AI编程助手（如代码补全类工具）仅能带来编码产出的边际改善。数据显示，使用这类助手后，代码总行数增加了12%，提交记录增加了9%，而合并请求仅增加了5%。统计检验证实，在这三项指标中，仅提交记录的增幅达到了统计学意义上的显著性水平。相反，基于大语言模型的AI智能体则展现出了截然不同的爆发力。智能体在三项编码指标上均引发了大幅增长：代码总行数激增了30%，提交记录提升了20%，合并请求的数量增加了23%。
然而，当研究团队将视角从“写了多少代码”转向“解决了多少问题”时，落差便显露无遗。分析发现，使用AI助手的团队在每月的工单解决数量上并未表现出任何正向增长。尽管AI智能体带来了编码数据的繁荣，但对应的软件交付成果——即Jira工单解决数量——仅实现了12%的增长。这一12%的实际业务增幅，与AI智能体所拉动的30%代码行数涨幅形成了强烈的反差。为了验证并解释这一现象，研究团队进一步对软件开发的全生命周期进行了拆解，并引入了一组来自Prolific平台的100名受访工程师的调研结果。调研结果印证了团队通过Jellyfish平台推算出的工时分配模型：在真实的软件研发工程中，工程师仅将30%至40%的时间用于纯代码编写，其余大量时间均被分摊在功能设计、范围规划、测试验证、部署运维以及代码审查等配套任务中。
影响分析
从工程实践与行业生态的宏观视角来看，这一研究结果对当前的技术管理与开发者日常行为具有深刻的启发意义。这并非是对生成式AI技术的否定，而是对其作用边界的一次精准校准。对于中文开发者与行业从业者而言，这一分析判断揭示了软件工程是一个由多个相互依赖环节串联而成的复杂系统。当前企业和个人在引入AI工具时，往往过度聚焦于其“生成”能力的飞跃，却系统性地低估了其“下游消耗”的连锁反应。
当AI极大地缩短了指令到代码的时间，原本由编码任务占据的时间比例迅速下降，而代码评审、多轮测试等人工审核环节的耗时占比则被动放大。评审时长的49%增加和需修改请求占比翻倍，意味着人类工程师必须投入更高的认知成本去审查AI生成的庞杂代码。对于技术管理者而言，这意味着传统的开发流程亟需重构。如果继续沿用旧有的质量控制与团队协同模式，仅仅是引入智能体不仅无法实现预期的降本增效，反而会因为下游瓶颈导致代码合并周期拉长，团队交付压力加大。开发者必须从单纯的“代码生成者”向“系统架构把关人”与“质量审核者”转型，提升自身对AI幻觉及代码潜在缺陷的甄别与防御能力。
适用边界
该研究的结论具有特定的前置条件与适用边界，在以下场景中其推论的普遍性可能会受限。首先，本研究的结论高度依赖于数据中揭示的“工程师30%至40%时间用于编码”这一工时基线。在极少数完全依赖高度自动化、低复杂度且具备完美自修复能力的边缘计算或特定嵌入式场景中，若下游配套任务占比极低，AI对整体生产力的提升可能会更加直接。其次，研究数据时段跨越了2021年1月至2026年3月，这涵盖了人工智能从早期代码补全到当前自主智能体演进的全过程。对于尚未完全普及AI智能体、仍主要使用基础代码补全工具且团队评审机制仍极为松散的企业，其瓶颈表现可能与此研究描述的“评审环节激增”存在差异，但基本逻辑依然成立。
孤本观察
这项研究打破了部分行业观点中“AI能够线性提升软件生产力”的迷思。从编辑视角判断，其核心价值在于将软件工程从单一维度的“编码能力”强制拉回了“系统交付”的完整视角，揭示了底层算力效率与上层人类认知审核效率之间日益扩大的结构性鸿沟。
常见问题
研究覆盖了多少家企业、员工数量及工作事件？
研究覆盖718家企业、70万名员工及3亿个工作事件，数据时段横跨2021年1月至2026年3月。
AI编程助手与AI智能体在代码行数、提交记录及合并请求上的具体增幅分别是多少？
AI助手使代码行数增加12%、提交记录增加9%、合并请求增加5%；AI智能体使代码行数增加30%、提交记录增加20%、合并请求增加23%。
使用AI智能体后，代码评审环节的平均评审时长、评论数量及需修改请求占比发生了怎样的变化？
合并请求的平均评审时长增加49%，单条请求的评论数量增长53%，需修改的请求占比翻倍。
研究中工程师将多少比例的时间用于纯代码编写？
工程师仅将30%至40%的时间用于纯代码编写，其余时间分摊在功能设计、测试验证及代码审查等配套任务中。
来源：InfoQ 中文 AI