一、六个数字其一代码总量涨 30%提交数涨 20%PR 数涨 23%。其二issue 与 epic整个功能的解决率没有统计显著变化。这是全篇关键的一条产出增加了交付没有。其三PR 从提交到合并的平均时间涨了 49%。其四需要返工的 PR 占比近乎翻倍每个 PR 的评论数涨 35%做代码审查的人占比涨 14%。其五到 2026 年 3 月80% 的公司用上了某种 AI 代码审查工具但 AI agent 只贡献了 23.3% 的审查评论与 10.8% 的 PR。质量控制仍然绝大多数由人完成。其六研究者自己的解释是编码环节的效率被下游环节吸收了。二、瓶颈从哪一步移到了哪一步过去两年的默认假设是「写得慢」。数据说写得已经快了卡住的是下一步看懂别人或 agent写的代码、判断能不能合、合并之后出问题谁修。这也解释了另一个看起来矛盾的现象AI 生成的 PR 数量上去了但被合并的比例反而低。研发效能平台 LinearB 的数据显示人工提交的 PR 合并率是 84.4%AI 提交的只有 32.7%agent 提交的 PR 平均要等 17.6 小时才被人认领无辅助工作的 PR 是 3.4 小时。等待时间本身就是成本而且在账面上看不出来。需要注意 LinearB 卖的就是研发效能工具它的数据要按「卖什么就强调什么」打折看。但方向上它与哈佛那份研究一致。三、三条旁证其一沃顿与 MIT 的研究9 月 8 日发布追踪 10 万以上 GitHub 开发者编码活动从补全带来的 40%升到同步 agent 的 140%、异步 agent 的 180%但只转化成软件项目 50%、发布 30%。结论一样约束点在写代码之外。其二贝恩 2026 全球技术报告AI 让开发者多完成约 21% 的任务但代码审查时间涨了 91%。同样的提醒这是研究机构发布的报告口径需打折看方向与哈佛一致。其三一份面向工程负责人的调查显示开发者每周花 9.8 小时写代码、16.9 小时调试35% 的生成代码在没被完全理解的情况下进了生产79% 的负责人说发布周期并没有更快。四、边界说明这部分别跳过其一这是观察性研究不是随机对照实验。它不能证明 AI 无法提高生产力只能说明在这批样本里效率增益没有传导到交付环节。其二数据截至 2026 年 3 月。工具在快速迭代半年前的结论要按半年后的工具重新验证一次。其三代码行数不等于软件质量。用行数衡量产出本身就是个粗糙指标这一点对 AI 和人类开发者同样成立。五、能立刻做的四件事其一把团队的观察指标从「代码行数、PR 数」换成「PR 从提交到合并的时长」。前者涨了不代表交付好后者涨了一定是问题。其二给审查环节排预算。既然审查时间的增长是真实发生的它就应该出现在排期里而不是当作「顺手看看」。其三限制单次 AI 提交的规模。返工率翻倍的直接原因通常是「一次给太多、人看不过来」。小步提交对 agent 同样成立。其四别把 AI 审查工具当成人审的替代。数据显示它目前只覆盖了一成多的 PR把它定位成初筛更符合实际。一句话收尾AI 编码的收益是真的只是它现在停在交付链的中段。谁先把中段打通谁才拿得到那 30%。