ACM Queue本月刊出一篇长文，把"AI正在颠覆软件工程"这个说法拆成八条迷思，逐条摆证据。开篇的证据最扎眼：开发者只把14%的工作时间花在写代码上，也就是说，就算AI把编码效率提升一倍，对整体产出的拉动也十分有限。这个判断本身站得住脚，但支撑它的那篇原始论文，细看之下并不像文章暗示的那么干净。
写这篇文章的是Jenna Butler、Brian Houck等六位微软研究者，他们的批评对象很明确：企业还在拿"AI生成代码行数"当KPI，微软自己就公开说过公司近三成代码由AI写成，但这类数字和软件质量、交付速度几乎没有统计学关联。问题在于，当这篇文章试图用"研究证据"去压制"营销叙事"时，它引用的核心数据来源，本身就有一处说不清楚的裂缝。
14%从哪来
这个数字出自一篇名为《Time Warp》的论文，发表在2025年ICSE-SEIP会议上，作者团队里同样有Brian Houck。研究调查了484名微软软件开发者，对比他们"实际工作周"和"理想工作周"里各项活动的时间占比。
论文的图表显示，开发者实际工作周里花在编码上的时间约为14%，而他们心目中理想的工作周里，编码占比能到25%——这本身就是个更有意思的对照：开发者不是被AI"抢"走了编码时间，而是他们本来就想少写点代码、多做点别的。ACM Queue的文章只挑了14%这一半，没提25%那一半。
图表和正文对不上的数字
再往细里看,《Time Warp》论文自己的正文叙述部分，给出的编码占比数字是约11%，跟图表里的14%不一致。ACM Queue这篇文章选用的是图表数字，但没有交代论文本身存在这处矛盾。文章在提及样本规模时，写的是"450余名"，实际数字是484人——不算错，但比原始论文更模糊。
- 风险.一篇标榜"用研究证据打败AI炒作"的文章，其核心论据来自一份图文数字不一致的原始研究，说明当前GenAI生产力研究整体还不够扎实，管理者引用类似数字时需要多问一句出处。
内循环还在提速，外循环纹丝不动
文章真正想说的，其实是"内循环"和"外循环"的错配：AI编程助手优化的是IDE里敲代码这一小段，设计、评审、测试、集成这些占据大部分工时的环节，AI基本没碰。开发者写代码写得再快，代码堆到评审队列和测试环节，整体交付速度未必变快。
>用AI生成代码行数当KPI，就像用飞机重量衡量飞行进度。
这不是一句俏皮话，而是文章反复强调的立场——微软自己都公开说过公司近三成代码出自AI之手，但这个数字既不能证明质量提升，也不能证明交付变快。对工具厂商而言，"编码提速几倍"的营销叙事，正在被自己请来的证据慢慢削弱；对工程管理者而言，继续拿代码生成量当采购和考核依据，等于把一个"效度存疑"的指标当成了决策基础。
- 建议.与其追问"AI生成了多少行代码"，不如去看设计评审周期、代码合入等待时间这些外循环指标有没有变短。
谁该重新想一想指标
对工程管理者来说，这篇文章提供的不只是"AI没那么神"这一层意思，还提醒了一件更麻烦的事：连试图纠偏的研究，证据链也可能有瑕疵。企业在评估AI工具投入产出时，如果只盯着采纳率和生成行数这类容易采集但效度存疑的数字，很可能得出和现实脱节的结论。
对AI编程工具厂商来说，"编码提速几倍"的说法接下来会越来越难单独立住，展示对评审周期、集成效率这些外循环环节的实际影响，会是更硬的说服力来源。至于Time Warp论文里14%和11%这两个数字究竟哪个更准，目前还没有看到后续的复现研究给出答案，这本身也是个值得继续盯着的变量。