AI Coding Agents 产出更多代码就更高效吗？2026 研究解读

评估编码 Agent 试点的研发负责人、工程效能与平台团队，可以从本文清单选出适合自己的指标。
如果你负责代码审查，也可以重点核对 PR 队列是否变长、返工是否增加。

最后更新于 2026 年 10 月 13 日；研究数据与统计结果核对自作者 2026 年 8 月 4 日版本工作论文，近期讨论背景参照 2026 年 10 月 9 日发布的报道。 (作者公开的工作论文)

1AI Coding Agents 效率研究 2026：研究指标不等于团队效率

哈佛大学 Fiona Chen 与 James Stratton 的论文《Artificial Intelligence in the Firm: Bottlenecks in Software Production》当前版本标注为 2026 年 8 月 4 日，是一篇工作论文，并非适用于所有公司的通用结论。作者使用工程分析平台数据，研究企业采用 AI 编码 Assistant 与 Agent 后，编码活动、软件产出及审查流程如何变化。样本覆盖 718 家企业、725,938 名员工；论文摘要称其数据包含约 3 亿条工作事件，时间范围从 2021 年至 2026 年 3 月。(论文样本、研究设计与指标定义)

论文将 Assistant 与 Agent 分开处理：Assistant 主要响应开发者的即时输入，提供代码建议；Agent 则能够接收较高层级任务，规划并执行多步操作。研究根据平台接口数据及 GitHub 记录识别工具使用，因此，研究中的采用时间和团队日常实际使用强度并非完全相同的概念。它报告的是特定样本中的企业采用关联，不是对每个人使用 Agent 后效率变化的直接实验。

关键区别在于“代码活动”与“已完成工作”不是同一个结果变量。作者以代码行数、提交、PR 衡量编码活动，并用 Jira 工单和 Epic 是否完成来观察软件产出。论文称，Agent 采用后，代码行数、提交和 PR 分别增加 30%、20% 和 23%；但工单与 Epic 完成量没有统计显著增长。对 Agent 而言，作者的估计排除了高于基线均值 12% 的软件产出增幅。以上均为论文作者估计，不是对任意团队的承诺。(论文中的结果与作者估计)

近期媒体报道让这项研究再次受到关注，但讨论热度不能替代研究边界。Ars Technica 的报道也提醒，论文样本数据截至 2026 年 3 月，之后工具能力和团队经验可能继续变化。因此，“代码增加而已完成工作未显著增加”适合用作团队核查问题，不宜改写成“所有 Agent 都无效”。(Ars Technica 对研究的报道)

2研发负责人：活动量上升，不代表需求交付同步加速

如果你负责研发管理，先问一个与采购和扩容决策直接相关的问题：新增代码是否变成用户实际拿到的功能？代码行数会受实现方式、生成代码风格和测试文件数量影响；提交和 PR 数量表示改动活动，也不能单独说明需求已经验收、部署或产生业务价值。GitHub 对 PR 协作流程的说明同样把它定位为提议、讨论与合并改动的流程，而不是已发布功能的计数器。

这里有几类容易被活动指标遮住的成本：

• 未完成的需求仍占资源。 PR 已提交，不代表验收条件满足；如果需求仍待测试、审批或部署，代码增长就可能只是在交付链条前段堆积。
• 工作切分可能改变计数。 一个需求被拆成多个 PR，活动量会上升，但完成的用户问题未必更多。反过来，一个大型改动也可能只形成少量提交。
• 返工会吞掉生成阶段节省的时间。 如果 Agent 生成后需要更多解释、修正或重新验证，编码环节更快并不能保证全流程更短。
• 不同团队的发布约束不一样。 高风险代码可能需要更严格的审查、测试和权限检查；跨团队依赖、测试环境和发布窗口也会影响从改动到上线的时间。
• 数据权限影响判断是否完整。 论文依据特定平台及代码托管记录识别活动；如果你所在团队的工具链、任务系统或 Agent 使用记录覆盖不全，指标看上去改善或恶化，都可能只是观测范围改变。

所以，软件研发交付指标要把“做了多少改动”与“完成并交付了什么”分开。DORA 对交付表现的框架关注从代码提交到生产部署的变更前置时间、部署频率、部署失败恢复时间，以及变更失败率和部署返工率；这些指标有助于看出流转效率和稳定性，但仍需结合具体服务与团队背景解释。(DORA 指标定义与使用指南)

3代码审查者：生成更快，队列可能更长

对代码审查者而言，研究最值得带回团队核验的不是“Agent 好不好用”，而是审查环节有没有接住新增改动。作者报告，Agent 采用后，PR 从提交到合并的平均时间增加 3.45 天，相对样本基线 7.03 天增加 49%；需要修改的 PR 占比接近翻倍，每个 PR 的评论数增加 35%。这些变化是论文样本的估计，不代表你的 PR 必然变慢同样幅度。(论文中的 PR 审查结果)

对照列表比单看平均审查时间更有用：

• 如果排队时间上升、审查轮次也上升： 先按 PR 大小、风险等级和变更类型拆分，再检查 Agent 是否生成了难以理解或难以验证的改动。
• 如果 PR 变多，但审查等待时间没变： 观察审查者投入是否同步增加，以及是否有重要任务被挤到队列后面；平均时间不变并不能证明负担没有转移。
• 如果评论数增加、但修改请求比例下降： 区分讨论性评论、风格建议和阻断合并的问题，避免把评论总数直接当成质量缺陷。
• 如果合并更快、上线故障或部署返工增加： 不能把更短的 PR 周期单独报成效率改善；应一并核对变更失败率和部署后返工。

AI 编码 Agent 代码审查的效果也不能仅由工具是否已部署来推断。论文提到，样本中采用 Agent 后审查流程的瓶颈仍然存在；截至 2026 年 3 月，近 80% 的企业曾在代码审查中使用 AI 工具，但 AI 生成的评论约占全部审查评论的 23.3%，至少收到一条 AI 评论的 PR 占 10.8%。也就是说，采用率不等于审查工作已被自动化。(论文关于 AI 辅助审查的估计)

4工程效能团队：按里程碑建立可复核的试点

下面这份清单不是论文验证过的通用处方，而是把研究发现转成你可以执行的团队核查步骤。试点前先固定口径；否则，前后数据变化可能来自团队范围、需求类型或流程定义变化，而不是 Agent 本身。

试点前：定义基线

• [ ] 固定试点团队和任务范围。 记录参与团队、主要代码库、需求类型，以及纳入或排除的工作；中途扩大范围时，单独标记新的观察段。
• [ ] 冻结指标定义。 约定什么算“已完成需求”、PR 从哪个状态开始计时、部署成功如何认定，以及返工如何归类。若定义发生变化，不要直接把新旧数据做前后对比。
• [ ] 记录同期流程变化。 标记审查轮值、测试门禁、发布窗口、人员调整和权限策略的改变，避免把同时发生的变化都归因于 Agent。

试点中：观察三条信号线

• [ ] 交付结果： 跟踪已完成需求、工单或 Epic 完成情况，并记录从变更开始到部署的周期；同时观察部署频率和失败后的恢复情况。
• [ ] 审查流程： 按 PR 类型和风险拆分首次响应等待时间、提交至合并时间、修改请求比例与审查轮次；不要只看平均值，也要识别长尾等待。
• [ ] 质量信号： 对照部署后故障、回滚、紧急修复和返工；检查变化是集中在 Agent 参与任务，还是整个团队都出现同样趋势。
• [ ] 活动量只做解释变量： 代码行数、提交和 PR 用来说明改动产出变化，不作为最终效率结论。

SPACE 开发者生产力框架强调，开发者生产力不只是活动量或交付系统效率，不能用单一指标概括。DORA 的 2025 年报告也将 AI 的影响放在组织实践与团队能力中讨论，而不是仅凭工具采用率判断成果。对你来说，这意味着要把交付结果、质量、审查流转与开发体验并列观察，再解释为何变化。(SPACE 开发者生产力框架；DORA 指标框架)

试点复盘：按条件决定扩围或调整

• 交付改善、审查稳定、质量没有恶化： 可以按相同任务边界逐步扩展，同时保留回看机制。
• 活动量增加，但需求完成和部署周期没有改善： 暂缓扩大覆盖，先定位审查队列、测试反馈或依赖协调等瓶颈。
• 合并速度提高，但部署返工或故障增加： 先恢复足够的测试和审查门禁，再评估是否继续使用。
• 数据覆盖不完整，或试点同期改了流程： 暂不对工具效果下结论；补齐记录或重新建立可比较的基线。

关键不是把一项指标定成团队排名，而是让每个里程碑都能回答：更多活动是否减少了用户等待，审查者是否接得住，质量信号是否维持在团队可接受范围。交付指标应结合具体应用和服务背景理解，而不是脱离场景作统一解释。

5管理层：把研究当试点问题，不当停用结论

这项哈佛工作论文既不足以推出所有 Agent 无效，也不能证明更多代码必然有用。它更适合成为你启动试点复盘的理由：如果代码活动已经增加，但 Jira 完成量、审查等待和部署质量没有一起变好，就先查清楚新增工作卡在哪一步，再决定是优化 PR 切分、增加审查能力、调整 Agent 任务范围，还是暂停扩围。

交付指标与开发者生产力框架能补足观察角度，但也不能替代团队自己的业务目标。你的团队应先确定要缩短哪类需求的交付时间、允许什么质量风险，再判断 Agent 是否带来净收益；否则，即便各项活动数字都上涨，也很难说明客户更早拿到了什么。

6常见问题：研究结论怎么用在团队里

前面的清单适合制定试点记录方式；以下问题则补上研究指标含义、审查变化与团队验证之间的区别。解读时，记住论文报告的是样本中的估计，团队自己的前后对照才决定下一步是否扩围。

AI Coding Agents 写得更多，为什么交付的软件不一定更多？

因为代码生成之后还要审查、测试、合并并部署，任何一环排队都可能抵消生成速度。论文所用的代码行、提交和 PR 是活动指标，Jira 工单与 Epic 完成情况更接近已完成的软件工作；两组指标不能互相替代。要验证团队有没有改善，应把活动量与交付结果并列记录。

哈佛 2026 年的 AI 编码研究测量了什么？

研究观察了代码活动、Jira 工单与 Epic 完成，以及 PR 审查时长、修改请求、评论和审查参与情况。样本来自特定工程分析平台，工具采用通过平台接口与代码托管记录识别；因此结果描述的是样本企业的变化，不能直接当作所有团队、所有工具或所有任务的通用预测。

AI 编码 Agent 会拖慢代码审查吗？

论文样本中，Agent 采用与 PR 合并等待时间增长、修改请求增加和评论变多相关联；这提示审查负担值得纳入试点，但不能说明 Agent 是你团队审查变慢的唯一原因。先按 PR 体量、风险、审查轮值和发布约束分层，再看变化是否集中在 Agent 参与的改动。

团队怎样判断 AI 编码工具是否真正提高交付效率？

在试点前固定团队范围、指标定义和观察窗口，同时追踪已完成需求、提交至部署周期、审查队列和部署后质量。记录同期的人员、流程与发布策略变化；如果只有代码行数或提交数增长，就先不要把它报告为交付效率提升。

这项研究最实用的落点，是把“多写了多少代码”改成一组可验证的团队问题。若你正准备进行小范围 Agent 评估，可继续查看 vpstix 博客中围绕试点验收与质量评估的相关指南；若需要设计审查环节，也可在 vpstix 帮助中心查找使用说明与支持信息。本文不把研究结论转成工具采购建议：先用自家基线确认交付与质量是否改善，再决定是否扩大试点。