代码行数找了个更好的公关：AI 效率指标背后的真相

原文来源：Lines of Code Got a Better Publicist — David Curlewis 关于 AI 效率指标如何从可验证的结果指标悄然转向不可证伪的数量指标的深度分析

你有没有注意到，最近 AI 公司宣传的方式变了？

一年前，GitHub Copilot 还在说「开发者任务完成速度快了 55%」——这是一个可以验证的结果指标。跑个对照实验就能证明或证伪。

现在呢？Google 说「75% 的新代码是由 AI 生成的」；Anthropic 说「合并到生产环境的代码中 约 80% 由 Claude 编写」；OpenAI 也说「大概 80%」；Cursor 甚至说「每天企业代码的 1 亿行以上 是由 AI 写的」。

David Curlewis 在他的博客里一针见血地指出了问题：「每一个都是数量声明。」『AI 写的代码占比』不过是代码行数换了个更漂亮的公关说辞。」

从「结果」到「数量」的悄然转变

这个变化很微妙，但意义深远。

当 GitHub 说「快 55%」时，你可以反驳：「你说的快是指什么？用什么对照？样本多大？」这是一个可以验证、可以证伪的陈述。

但当 AI 公司说「80% 的代码由 AI 写」时，你完全没法反驳。这个数字只有在 AI 采用率下降时才会下降——而只要公司还在鼓励用 AI，这个数字只会涨不会跌。它本质上不可证伪。

更值得玩味的是，所有发布这些数据的公司本身就是 AI 公司。他们有极强的动机让数据看起来漂亮。这不是阴谋论，这就是商业。

—— 广告 ——

Curlewis 整理了一系列研究，结论非常有意思：

研究	发现
Cui 等（5000 名开发者）	任务完成量 +26%，初级开发者受益最大
GitClear	AI 辅助下代码变动量上升，但重构量暴跌
METR（初期）	有经验的开源开发者用 AI 后慢了 19%，但他们自认为快了 20%
METR（2026 年 2 月跟进）	收回结论：改为「有加速但置信区间极大」；因为开发者现在拒绝不用 AI 工作了，研究设计作废
NBER（6000 名高管）	69% 在使用 AI，约 90% 报告没有可测量的生产力提升
Anthropic 随机对照实验	AI 辅助的开发者代码理解力下降 17%；无统计学显著的生产力提升

跨研究共识大概是 10% 的组织级效率提升。这不是小数字——10% 已经非常可观了。但也远没到「不再需要开发者」的程度。

如果你做技术这行够久，你会发现「代码行数」这个指标有个很尴尬的历史。

几十年来，几乎所有严肃的软件工程管理都告诉你：不要用代码行数衡量生产力。它太容易被操纵了——写 100 行废代码比写 10 行好代码容易得多。

现在 AI 公司把同样的东西包装了一下，变成了「AI 代码占比」和「每日 AI 生成行数」。同样的 vanity metric，更好的 PR。

Curlewis 还提到了几个值得警惕的现象：

成熟度模型（Maturity Models）也在变质。 SEI/Accenture 的 AI 成熟度模型、Steve Yegge 的框架、Augment 的评估工具——它们看起来像是客观的评估标准，但仔细看，最高等级通常是「多用我们的产品」。

Anthropic 内部的矛盾很有意思。 他们的市场宣传说「代码产出提升了 8 倍」，而他们的研究团队发现 AI 辅助的开发者代码理解力下降 17%。两个都是真的。这说明代码量和代码质量是两回事。

这是最让我不安的部分。

公司	动作	说辞
Block（Jack Dorsey）	裁员超 40%（约 4000 人）	「更小的团队，用我们正在造的工具，能做更多、更好。」（当时业务其实很好，毛利润在增长）
Atlassian	裁员 10%（约 1600 人）	「假装 AI 不会改变我们需要的技能组合或岗位数量是不诚实的。」

Curlewis 的质问很尖锐：「如果真的提升了生产力，为什么公司不把释放出来的产能投到创造更多价值上——更多功能、更高转化率、更高收入？为什么裁员的理由不是『我们做得太多了』，而是『AI 帮忙做了』？」

真正的逻辑链更像是：先决定了裁员，再用 AI 指标来合理化这个决定。

Curlewis 的建议很务实：

「用 AI 的方式工作，但用经过检验的方式衡量。」

具体来说：

AI 确实在改变软件开发的方式。每天用 AI 已经成为每个有追求的工程师的标配。但这不意味着我们应该抛弃几十年来积累的工程管理经验，去追逐那些听起来漂亮但实际上什么也说明不了的虚荣指标。

就像 Curlewis 在文章结尾说的：「变化不可逆转，工具确实好用。充满希望的是，我们已经知道如何衡量真正重要的东西——而这些，没有一样是按 token 数计算的。」