夜雨聆风6月8日，一篇NBER工作论文（#w35275）在开发者圈刷了屏。MIT斯隆管理学院和宾夕法尼亚大学的研究团队做了一个前所未有的实验：他们追踪了约10万名开发者的GitHub活动数据、微软Copilot订阅遥测和四大应用市场（App Store、Google Play、Chrome Web Store、SourceForge）的月度面板数据，试图回答一个问题——
"AI让写代码变得这么容易，软件产出真的变多了吗？"
答案是：代码量确实翻了17.3倍。但最终发布的软件版本，只涨了30%。
代码暴增741%，软件发布只涨20%
"我感觉自己一天能写过去一周的代码量。"一位开发者在NBER论文的评论区写道。
这不是错觉。研究数据显示，使用AI编程工具后，开发者的代码行数平均增长了741%（第二代同步代理阶段），代码提交量增长了140%。Claude Code的提效幅度更是达到199%，远超OpenAI Codex的94%和GitHub Sync Agent的43%。
但到这里，故事才刚刚开始。真正的问题在后面。
同样是在同步代理阶段，这些暴增的代码经过层层转化后——独立文件增幅只有187%，代码提交109%，合并请求65%，独立项目26%，最终版本发布增幅是20%。
这就像你往一个漏斗里倒了一大桶水，但最后流出来的只有一个小杯。水没消失，它只是被卡在了漏斗的某个环节。
MIT团队把这个现象命名为"生产漏斗"（Production Funnel），并提出了一条令人警醒的结论：即使AI能一秒写出全世界的代码，只要人类审查、测试、协调这些上游环节不做出改变，软件发布率的提升上限仅为26%。
（来源：NBER Working Paper #w35275, MIT Sloan & UPenn, 2026年5月）
四个瓶颈，哪里漏得最多
第一个瓶颈：AI写得多，但人类Review不过来
研究团队通过CES生产函数模型计算出了AI对人工的替代弹性——仅为0.25。
0.25是什么意思？经济学家用这个数字衡量一种技术能在多大程度上替代人工。1.0意味着完全替代，0意味着完全互补。0.25意味着AI每替代一个单位的人力劳动，只能完成约四分之一的工作。剩下的四分之三，仍然需要人来做。
换句话说，AI写的代码越多，需要人类审查的代码也越多。而且不是线性关系——代码越多，审查的边际成本反而越高。
你看过AI一口气生成500行代码吗？确实震撼。但Review那500行代码需要多久？读懂逻辑、发现隐藏Bug，有时候比从头写一遍还费劲。
第二个瓶颈：测试和集成没有同步提速
MIT的数据里还有一个更细的发现：合并请求（PR）增幅只有65%，而代码提交增幅是109%。
这中间的差距去哪了？卡在了Code Review和CI/CD流水线上。
一个AI辅助的开发者可能一天提5个PR，但团队里的其他成员一天能Review多少个？通常不超过3个——而且还得是精力充沛、注意力集中的前半天。PR积压后，合并周期变长，代码合并冲突增加，整个节奏反而被打乱了。
第三个瓶颈：工具选错，效率砍半
三种AI编程工具在同一任务上的提效差距，最高达到4.6倍：
| 工具 | 提效幅度 |
|---|---|
| Claude Code | 199% |
| OpenAI Codex | 94% |
| GitHub Sync Agent | 43% |
数据来源：MIT & UPenn联合研究，NBER Working Paper #w35275，2026年5月
199%和43%的差距，不是Claude Code的参数比Copilot多这种技术层面的差异，而是产品设计哲学的差异。Claude Code的设计更偏向"少写但写对"，在代码生成阶段就降低了后续审查的成本。
研究还发现：当Claude Code用户升级到底层模型Opus 4.5后，效率出现了一次与使用时间无关的跳升。而早期Copilot用户，在24周内的效率曲线始终平盘——工具的结构性差异，比模型参数重要得多。
第四个瓶颈：AI帮得最多的，恰恰是最不需要帮的人
数据揭示了一个反直觉的事实：
| 开发者类型 | 自动补全提效 | 同步代理提效 |
|---|---|---|
| 低活跃/低技能 | 85% | 217% |
| 高活跃/高频提交 | 21% | 62% |
数据来源：同NBER #w35275研究
低活跃开发者的提效幅度是高活跃开发者的3.5倍。AI编程最大的普惠价值在于帮那些"写得少"的人"写得多"。但问题是：如果你本来就是一个高产开发者，AI对你的边际提升反而是最小的。
这也是"代码暴增但软件不涨"的另一个解释：AI正在让更多人开始写代码（这正是代码暴增17倍的原因），但这些新增代码要转化为可用的软件，还需要一个成熟的工程流程——而流程的提速，不是靠多写代码能解决的。
还有一个值得注意的副作用：供给增加但需求没跟上。MIT数据显示，三大应用市场中"僵尸应用"（几乎无人下载/评分）的比例显著上升——App Store中评分数低于10的应用从79%升至86%，Chrome Web Store中下载量低于10的扩展从18%升至31%。
三个突破口，从"写代码"到"交软件"
面对这个"生产漏斗"，该怎么做？MIT团队在论文中给出了三个方向，我结合实际情况拆解为可操作的步骤：
Step 1：找出你的瓶颈环节
先做一个简单的自检。过去一个迭代周期里，你的团队在哪个环节花的时间最多？
- 如果卡在Review：不要增加Reviewer数量，而是减少AI单次生成的代码量。Claude Code的/goal模式和Codex的Plan Mode都支持分步生成+分步审查，每次50-100行为一个检查点。
- 如果卡在测试：让AI写测试，而不是用AI写完代码再手动补测试。目前Claude Code在TDD流程中的集成度最高，能自动在每次代码变更后触发测试生成。
- 如果卡在集成：检查一下你的CI/CD是否支持并行测试。代码量暴涨后，串行测试流水线是最大的隐藏瓶颈。
Step 2：选对工具比追新模型更重要
Claude Code（199%）vs GitHub Sync Agent（43%）的差距说明，同样是AI编程工具，选错一个可能让你的效率打折一半以上。
但选工具不要只看基准评分。留意一个关键指标：这个工具的架构是否在帮代码"做减法"？更少的样板代码、更少的重复生成、更精确的单文件修改——这些设计决策直接影响"代码到软件"的转化率。
选工具的优先级应该是：转化效率 > 代码生成速度 > 模型基准分。
Step 3：为"下游智能体"做好准备
MIT论文里提出了一个关键概念——"下游智能体"。简单说，就是能自主完成代码审阅、集成测试、上线决策的AI Agent。
这个概念听起来还很远，但基础设施已经在铺了。GitHub Copilot Coding Agent已经能端到端地从一个issue生成PR；Claude Code正在实验室测试自动Code Review功能。
如果你是技术管理者，现在可以做的准备是：把团队的Code Review规范标准化、把测试用例模板化、把部署流程声明式化。一旦下游智能体成熟，有标准化规范做底子的团队，集成速度会比其他人快一个数量级。
一句话总结
AI编程让你一天写出过去一周的代码量——但一天写出来的代码，还是需要一周来Review、测试、上线。在你解决"下游"问题之前，"上游"流出来的水，只会越积越多。
三个行动建议，再重复一遍：
- 检查你的生产漏斗，找出最窄的环节（Review/测试/集成），先解决那个
- 选工具时把"代码转软件的转化率"放在"生成速度"前面
- 现在就开始标准化Review规范、测试模板和部署流程，为下游智能体铺路
如果这篇文章让你对AI编程的"生产漏斗"有了新的认识，点个赞让更多人看到。关注「AI上效率」，持续追踪AI工具的真实生产力，不吹不黑。
