企业官网建设流程全解析

一、六个数字

其一，代码总量涨 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%。