夜雨聆风【导读】MIT 和 NBER 一篇覆盖 10 万名 GitHub 开发者的研究揭开了 AI 编程工具的残酷真相：自动补全、交互式 Agent、自主 Agent 三代工具让代码提交量累计暴涨 180%，但实际发布的软件只增加了 30%。中间那 150% 的差额去了哪里？答案藏在审查、测试、集成、发版这条没人提速的流水线里。
AI 写代码飞快，软件却没多出来？
先看一组来自 Rohan Paul 在 X 上的总结：
"Code volume surges by 300%, but output increases by only 30%: The AI dividend meets an awkward reality."
「代码量飙升 300%，产出只增长 30%——AI 红利撞上了一堵尴尬的墙。」
▲ Rohan Paul 在 X 上转述 MIT 研究核心发现，引发开发者广泛讨论
这段话背后，是一篇 MIT 经济系和沃顿商学院联合发表的 NBER 工作论文，编号 w35275，标题直接把问题摆在桌面上：
Writing Code vs. Shipping Code——写代码和交付代码，根本是两回事。
10 万开发者的数据，三代 AI 工具的成绩单
这篇论文的作者是 Mert Demirer（MIT 经济系/NBER）、Leon Musolff（沃顿/NBER）和 Liyuan Yang（MIT），2026 年 5 月以 NBER Working Paper 形式发布。
他们做了一件以前很少有人做的事：把 10 万名 GitHub 开发者的活动数据和他们使用 AI 工具的遥测数据拼在一起，用匹配事件研究法（matched event study），追踪 AI 编程工具采用前后的变化。
▲ NBER 论文页面：Writing Code vs. Shipping Code，2026 年 5 月发布
研究把 AI 编程工具分成三代：
- 第一代：自动补全
（比如 GitHub Copilot 初版）——代码提交量增加约40% - 第二代：交互式/同步 Agent
（比如本地运行的 Claude Code）——累计增加约140% - 第三代：自主/异步 Agent
（比如远程运行的 OpenAI Codex、GitHub Agent）——累计增加约180%
光看这组数字，效果惊人。从补全到 Agent，每一代都在让开发者写出更多代码、提交更多 commit。
但论文接下来的发现，才是真正让人坐不住的。
180% → 50% → 30%：从代码到发布，红利层层蒸发
论文提出了一个「生产层级」（production hierarchy）模型，把软件生产拆成一层一层：代码行数 → 文件修改 → 提交（commits）→ PR → 项目数 →实际发布（releases）。
结果是这样的：
自主 Agent 在 commit 层面带来的180% 累计增幅，传导到项目数量时只剩50%，到实际发布时只剩 30%。
▲ 论文摘要：180% 的 commit 增幅到 releases 只剩 30%，elasticity of substitution 仅 0.25
换句话说，AI 帮你多写了将近两倍的代码，但最后多发布出来的软件只有三成。
中间那超过一半的"额外努力"，被审查、集成、测试、修复边缘情况、合并冲突和发版流程消耗掉了。
论文给这种现象起了个名字叫「弱链条假说」（weak-link hypothesis）：整个链条的产出取决于最慢的那个环节。AI 加速了写代码，但审查、QA、产品决策、部署——这些还是人在做，还是原来的速度。
替代弹性 0.25：AI 和人类工作是强互补
论文还估算了一个关键参数：AI 产出与后续人类工作之间的替代弹性（elasticity of substitution）只有 0.25。
这个数字什么意思？
如果替代弹性接近 1 或大于 1，说明 AI 多干一份，人可以少干一份，两者可以互相替换。但 0.25 意味着强互补——AI 多产出的每一行代码，背后都需要人类投入对应的审查、测试和集成工作。AI 写得越多，人类要跟进的工作反而越多。
"Large task-level AI productivity gains have therefore translated only partially into shipped and used software thus far."
「AI 在具体任务层面的巨大效率提升，到目前为止只部分转化成了已经交付和被使用的软件。」
这和很多人的直觉相反。大家以为 AI 写代码更快，团队就能更快交付。但现实是：代码产出加速后，瓶颈转移了——从"写不出来"变成了"审不过来""测不完""合不了""发不出去"。
四大应用商店的证据：App 多了，用户没多
论文没有只停留在 GitHub 数据上，还把视角拉到了下游——四大应用商店：Apple App Store、Google Play Store、Chrome Web Store 和 SourceForge。
结果发现：自 2025 年中以来，新上架的 App 数量确实有明显增长。
但是，这些新 App 在上架后三个月内的总使用量，在四个商店里都没有增加。
▲ 论文数据：从代码活动到实际发布，每往下一层，AI 带来的增幅都在衰减
这意味着什么？AI 降低了"做一个 App"的门槛，但没有降低"做一个有人用的 App"的门槛。市场上多了一批软件供给，用户却并没有因此用上更多新东西。
供给增加了，需求没跟上。
生产层级：AI 在上游泛滥，下游依然靠人
论文最有价值的贡献之一，是把"AI 编程效率"这个笼统说法拆开了。
传统 benchmark 测的是：模型能不能写对代码、能不能过 SWE-bench、能不能自动提 PR。但企业真正关心的从来不只是"代码写没写"，而是整条交付链路：
需求对不对 → 代码写没写 → PR 能不能审 → 测试过没过 → 集成顺不顺 → 部署安不安全 → 用户用不用。
▲ 论文 Table 5：Autocomplete、Sync Agent、Async Agent 在各生产层级的效果对比
AI 目前加速的主要是链条的前半段——写代码和提交代码。但从 PR 审查开始，每一步都需要人类判断。代码写得越多越快，积压在审查和测试阶段的工作量就越大。
Rohan Paul 把它翻译成了一句大白话：
"AI can write code faster, but humans are still needed to decide what to build, check if the code works, connect it with the rest of the product, fix messy edge cases, and actually ship it."
「AI 能更快地写代码，但决定做什么、检查代码对不对、把它和产品其他部分连起来、修复那些恶心的边缘情况、最后真正发布——这些还是得靠人。」
下一个战场：从写代码到交付代码
这篇论文的启示很明确：AI 编程工具的下一个大机会，可能已经不在"写代码更快"上了。
如果模型只是继续提高生成代码的速度，收益递减几乎是必然的。代码堆得再多，审查跟不上、测试跟不上、产品决策跟不上，最终就是在生产流水线上制造拥堵。
真正能释放红利的方向，可能在于：
- Review Agent
：让 AI 帮忙做代码审查，缩短 PR 审批周期 - 测试生成与 CI/CD 自动修复
：把测试覆盖率从人力瓶颈变成自动化流程 - Release Management
：让发版流程跟上代码生产的速度 - 产品分析和用户反馈闭环
：从"能做"到"该做"的决策也需要工具辅助
打个比方：AI 把"打字员"变成了高速打印机。但如果审稿、装订、发行、读者购买这一整条链条没提速，纸张堆得再高，书也不一定卖得更多。
▲ RePEc/IDEAS 独立学术索引同步收录了这篇论文
冷静看待：这篇论文的边界
最后要提醒的几点：
第一，这是 NBER Working Paper，发布用于讨论和评议，还没有经过同行评审。它的数据和方法论值得认真对待，但不能直接等同于"MIT 已经证明 AI 编程 ROI 只有 30%"。
第二，研究样本主要是 GitHub 上的公开和部分私有仓库开发者。企业内部的闭源项目、内部工具、AI 辅助的维护和质量提升，不一定都能反映在 releases 和 marketplace 使用量上。
第三，"代码量增 300%"是 X 上流转时被简化的说法。论文原始口径是自动补全约增 40%，交互式 Agent 累计增约 140%，自主 Agent 累计增约 180%，指向的是 coding activity 指标，不能笼统理解为"所有代码量统一增了三倍"。
第四，这是观察性研究（matched event study），有对照组检验和预趋势分析，但不是随机对照实验。因果推断要谨慎。
但即便打上这些折扣，核心发现依然成立：AI 加速了软件生产链条的上游，但下游的人类密集型环节正在成为新的瓶颈。
代码写得快了，审查、测试、部署、产品决策这些"最后一公里"跟不上——这个问题，比"模型能不能写代码"重要得多。
— END —
