十月初,Solidot 转载了一条来自 Ars Technica 的报道,把 AI 编程工具一年来的"生产力幻觉"摊在了桌面上。一份由哈佛经济学家 Fiona Chen 与 James Stratton 合作的工作论文,把 Jellyfish 工程遥测和 GitHub 活动数据并在一起,横跨 700 多家软件开发公司、约 70 万员工、3 亿条工作事件,从 2021 年一直追到 2026 年 3 月,想要回答一个关键问题:AI 编程智能体进入企业之后,公司到底有没有交付更多软件?
数字很直接:代码起来了,产出没起来
论文给出的结论干净到近乎残酷。引入 AI 编程智能体(覆盖 Claude Code、Cursor、Devin 这一类工具)之后,公司的代码总行数平均增加 30%,commit 数量增加 20%,pull request 数量平均增加 23%。这本来应该是"生产力大幅提升"的剧本。
但同一组数据里另一些数字并不配合:Jira 里的 issue 完成率与 epic 完成率,在统计意义上没有显著变化。也就是说,写代码变得更快,但交付的功能没有变多。
瓶颈没有消失,只是被搬到了下一站。论文披露,引入 AI 智能体之后,从 PR 提交到合并的平均耗时上升了约 49%,PR 上的评论数量上升了约 35%,revert 与返工的次数几乎翻倍。到 2026 年 3 月,80% 的公司已经启用了 AI 代码评审工具,但这些 AI 评审工具贡献的评论占比只有 23%——绝大部分代码审查工作依然由人类完成,且这部分人类工作时间被显著拉长。
三个值得展开的细节
第一,写代码便宜了,但审查昂贵了。AI 智能体能用 5 到 30 倍于普通聊天的 token 来跑"先修后测"的循环,这部分成本在 Jupyter / Jellyfish 这类遥测里被算成 PR 提交数,而评论、返工、rebase 这些下游成本却发生在工程师身上。换句话说,Gartner 在 8 月警告的"agent token 用量 5–30 倍"不是抽象命题,它直接把审查队列拉长了。
第二,Jira 维度比 commit 维度更接近真问题。Jira 的 issue 与 epic 是和具体业务目标绑定的;commit 与 PR 数量则是流程产物。Chen 与 Stratton 的论点是,后者的上升在管理学意义上是一种 "速度",而前者才是"结果"。当团队把代码行、PR 数写进 OKR 时,这层错位会被加倍放大。
第三,AI 代码评审工具的实际渗透,远比营销叙事保守。80% 公司上线了,但只有 23% 的评论是 AI 写的。这说明审查这一环节里 AI 还没有"能用",处于"上线了但用不起来"的尴尬状态。
这件事真正刺痛的,是公司在量什么
论文没有否定 AI 智能体的能力,它在意的,是组织拿什么指标在衡量它。当一家公司在仪表盘里写的是"PR 数 / commit 数 / 代码行数",AI 智能体会很漂亮地完成所有指标,但 Jira 里的真实进度会纹丝不动。反过来,把"每个 issue 的成本" / "从 PR 到 merge 的时间" / "merge 后的回滚率"当成主指标,公司才能看到 AI 到底买到了什么。
这里其实有一个更深的信号:agent 改变了工作的瓶颈形状。以前瓶颈在"一个人写多快",现在瓶颈在"评审队列多深"。如果一个组织不去重新分配人力,不让人类做合并、强制推送、删除分支这些不可逆动作,反而默认让 AI 智能体接管审查,那 49% 的合并时间膨胀只会更糟。
所以这是什么级别的研究
从 Solidot 转载的措辞看,这是工作论文,尚未经过同行评审。它的方法学强度来自样本规模——700 多家公司、3 亿事件,这套数据比任何单家公司的对照实验都有说服力,即便它使用的是 Jellyfish 自己的可观测性数据,样本选择会有偏差。
但即便带着这些保留意见,这份论文是当下"AI 编程工具到底有没有用"这个问题里,横跨面最广、争议最少的一次系统回答。它告诉我们:接下来一两年,真正能拉开差距的,不是用不用 AI 编程智能体,而是谁先把审查流程和度量体系补回来。
参考来源: