Lines of Code Got a Better Publicist：AI 代码量指标的公关胜利与工程真相

背景

回顾十五年前（作者自述自 90 年代末入行，这类故事通常始于那个时代），在一家 SaaS 公司里有两位高级开发人员。其中一位编写的代码行数比另一位多出 40%。这位开发者是否更优秀？对业务的影响是否更大？另一位是否应该去更新简历？

答案显然是否定的。当时业界已经达成共识，我们需要关注的是实际交付了什么、对客户、收入和可靠性产生了什么影响。代码行数（Lines of Code, LOC）、PR（Pull Request）数量……我们花了数十年时间才认识到，用这些指标来衡量开发人员是典型的错误做法，以至于今天如果有人再提出这种建议，只会引人发笑。

然而，2026 年的行业宣传海报上，情况却发生了逆转。各大科技巨头和 AI 厂商纷纷打出了以“代码量”为核心的宣传语：

• Google：75% 的新代码由 AI 生成。
• Anthropic：约 80% 的合并生产代码由 Claude 编写，工程师每季度交付的代码量增加了“8 倍”。
• OpenAI：据报道也约为 80%。
• Cursor：“每天生成超过 1 亿行企业级代码”。

每一家都在强调体量。“AI 生成的代码占比”不过是给代码行数换了一个更好的公关包装。作者指出，持怀疑态度的编辑会注意到，这些发声者均为某种形式的 AI 供应商，推动采用率对它们至关重要。

核心内容

从“结果导向”到“体积导向”的倒退

几年前，行业的主张在性质上有所不同，而不仅仅是规模上的变化。GitHub 的核心主张是，使用 Copilot 的开发者完成任务的速度提高了 55%。尽管该研究备受争议，但它是一个**结果导向（outcome claim）**的主张：大胆、可证伪、关乎价值。如果它是错的，你可以证明它是错的。

相比之下，2026 年的主张“不可能失败”。这正是其精妙之处：“75% 的代码是 AI 编写的”这一说法可能是真的，并且会随着时间推移不断上升，无论实际效率是否提高（如交付速度、故障减少、客户满意度等）。体积数字只有在采用率停滞时才会让人失望，而采用率是我们普遍认可的现实指标。因此，主张变得更大，但含义却更少。

被忽视的证据复杂性

结果导向的证据变得复杂，这是行业转变的关键原因：

1. 早期积极证据：Cui 等人的研究仍是支持采用的最强证据之一，涉及近 5,000 名开发者，任务完成量增加 26%，初级开发人员获益最大。这一点几乎没有争议。
2. 负面或复杂证据：
   • GitClear 显示，随着 Copilot 采用率的深入，代码变更率（code churn）上升，重构工作崩溃。
   • METR 的一项被广泛引用的研究发现，经验丰富的开源开发人员在自有代码库中使用 AI 时速度慢了 19%，尽管他们自认为快了 20%。
3. METR 的立场反转：2026 年 2 月，METR 实际上推翻了之前的结论。其后续估计显示速度有所提升（尽管误差范围极大），并完全放弃了原有的研究设计。原因是开发人员现在拒绝在没有 AI 的情况下工作，且无法可靠地自我报告代理式工作（agentic work）的时间。METR 的最新立场是：AI 可能在 2026 年确实加快了开发速度，但我们已无法清晰地衡量其幅度。
4. 企业层面的数据：NBER 对约 6,000 名高管的调查显示，69% 的企业正在积极使用 AI，但近十分之九的企业报告称没有可衡量的生产力影响。跨研究的共识集中在组织层面约 10% 的收益。这并非毫无价值，但也远未达到“不再需要开发人员”的地步。

虚荣指标的 AI 化

这种趋势不仅限于 AI 厂商。卡内基梅隆大学软件工程研究所（SEI）和埃森哲最近推出了“AI 采用成熟度模型”，包含五个级别和八个维度，并引用了“95% 的组织未看到回报”的统计数据。Steve Yegge 的“AI 辅助开发的 8 个级别”根据你使用的工具和监管程度来排名。每个工具供应商都推出了成熟度阶梯，其最高级别通常是“更多地使用我们的产品”。这些阶梯衡量的是采用强度，却将其包装为成熟度。

一个典型的例子是 Augment 调查了 219 位工程领导者，询问他们如何定义“AI 原生工程”，结果得到了 219 个不同的答案。

最讽刺的案例来自 Anthropic。他们既提出了“交付 8 倍代码”的主张，又发布了一项年度最严谨的研究之一：一项随机对照试验（RCT）发现，AI 辅助开发人员在理解自己刚交付的代码时，得分低了 17%，且没有统计上显著的生产力增益。作者每天使用 Claude，深知其产品优秀，但 Anthropic 的研究部门在更新数据，而市场部门在计算体积。这两件事同时存在，而这正是问题的核心。

裁员背后的逻辑

这些数字并非装饰，它们直接影响预算、绩效预期和人员编制计划。

• Block (Square)：2 月，Jack Dorsey 裁掉了超过 40% 的员工（4,000 多人），明确将 AI 作为核心论点：“一个显著更小的团队，使用我们正在构建的工具，可以做得更多、更好。”
• Atlassian：几周后裁掉了 10%（约 1,600 人），同时承认假装 AI 不会改变所需技能组合或角色数量是“不诚实的”。

关键细节在于：Dorsey 在同一公告中表示，业务强劲且毛利润正在增长。当一家公司声称“AI 让每个人更高效，因此我们需要更少的人”时，作者希望看到证据，并认为目前不存在这样的证据。

如果一家公司获得了免费的“人头增加”（即因效率提升而释放的人力），为什么不利用它更快地为客户交付更多价值？这应该体现在 MAU（月活跃用户）、转化率和收入上。选择裁员表明，生产力主张只是在为已经出于其他原因（如过度招聘、投资者压力等）做出的决定做公关工作。

作者的立场

作者明确表示，这并非反 AI 文章。他认为每位工程师都应每天使用 AI，保持好奇，尝试新工具。行业已经吸收了高级语言、IDE、自动补全、敏捷和 DevOps，总有人怀念“旧时光”。这次的区别在于速度：你可以延迟采用“云”几年并生存下来，但面对 AI，你可能只有几个月的时间。工作方式已经改变，且不会回头。

然而，采用是起跑线，不是记分牌。我们早已知道如何衡量工程交付：DORA 指标、可靠性、有意义变更的频率，以及最终的收入和客户价值。这些都是经过战斗考验的“老派”指标。为什么我们要抛弃这些，转而使用荒谬的 AI 虚荣分数？

关键要点

• 指标倒退：行业从衡量“业务结果”（如交付速度、价值）倒退为衡量“AI 生成的代码量”（如占比、行数）。这是一种公关策略，而非工程评估。
• 证据的模糊性：
  • 早期研究（如 Cui et al.）显示初级开发者效率提升。
  • 后续研究（如 GitClear, METR）显示代码质量下降、重构减少、资深开发者效率可能降低或难以测量。
  • 企业级大规模调查（NBER）显示，尽管广泛采用，但近 90% 的企业未报告可衡量的生产力提升，共识仅为组织层面约 10% 的收益。
• 成熟度模型的虚伪：所谓的“AI 采用成熟度”往往只是衡量工具使用深度，且最高级别通常指向购买更多产品，而非实际的业务成果。
• 裁员的真实动机：AI 效率提升常被用作裁员的理由，但缺乏证据表明释放的人力未被用于增加业务价值（如收入、用户增长）。裁员更多是出于财务优化或投资者压力，而非纯粹的技术效率。
• **Anthropic