Goodhart 定律回归：AI 重新发明了衡量不了生产力的指标

TL;DR

2026 年，一家中等规模的工程团队开始用 AI 生成代码后，每个工程师每天平均触发 80-120 次 AI 代码补全。但没有人能说清楚这些代码是好是坏。管理层做了一个「理性」的决定：开始数提交数。这个决定听起来荒谬，却是 AI 时代的必然——因为真正的产出（代码质量、系统健康度、工程师的判断力）无法被低成本衡量。

Key Insight: 1975 年，Charles Goodhart 发现了后来以他命名的定律：「当一个指标变成目标，它就不再是一个好指标。」AI 让这个定律以新的形式回归——不是因为我们选择了错误的指标，而是因为真正重要的产出在结构上就无法被衡量。

决策疲劳：一个不被承认的危机

Stack Overflow 的 2025 年开发者调查揭示了一个被低估的现象：

84% 的开发者使用或计划使用 AI 工具
但对 AI 准确性的信任从 2023 年的 42% 下降到 33%
66% 的开发者将「看起来对但实际不对」的 AI 方案列为最大痛点
45% 的人表示调试 AI 生成的代码比预期花的时间更多

Stack Overflow 高级分析师 Erin Yepis 这样描述这个发现：

「最令人惊讶的发现是：开发者对 AI 的偏好发生了显著转移。虽然大多数开发者使用 AI，但他们对 AI 的喜爱和信任都在下降……我原本预期随着技术进步，信任会增长。」

这个数据揭示了一个被忽视的事实：AI 生成的代码越多，需要做的判断就越多。

当一个工程师每天触发 80-120 次 AI 代码补全，他面临的不只是更多的代码——而是更多的「这段代码是否值得保留」的判断。每一个判断都需要时间、判断力和上下文理解。而判断力是有限的——它在一天中会随着使用而消耗。

这就是决策疲劳的本质。

为什么 AI 让判断变得更稀缺

这里有一个违反直觉的现象：AI 让「写代码」变得更快了，但它让「判断代码」变得更慢了。

原因在于：生成和评估是两种不同的认知过程。

生成是模式匹配——AI 在训练数据中寻找相似的模式，重新组合，产生输出。这个过程可以很快，因为它是并行的、自动化的。

评估是情境理解——你需要知道这段代码在做什么，它是否正确，是否会产生技术债务，是否与系统的其他部分兼容。这些判断需要上下文理解，需要经验，需要对系统整体的理解——而这些无法被加速。

METR（一个研究 AI 系统能力的非营利组织）在 2025 年做了一个随机对照实验，发现了一个令人不安的结果：

有经验的开发者预期 AI 会让他们快 24%
实际测量结果：使用 AI 的高级开发者慢了 19%

研究者 Joel Becker 这样解释：

「AI 建议的方向是对的，但细节与实际需求不匹配。」

对于经验丰富的开发者来说，审查和纠正 AI 建议的时间超过了 AI 生成代码节省的时间。他们不是在「用 AI 写代码」，而是在「审查 AI 写的代码」——而审查是一个更慢的过程。

Goodhart 定律：1975 年的预言

1975 年，英格兰银行经济学家 Charles Goodhart 在一篇论文中发现了后来以他命名的定律：

「任何被观察到的统计规律，一旦被施加控制目标的压力，就会倾向于崩溃。」

后来，Marilyn Strathern 将其简化为更常用的表述：

「当一个指标变成目标，它就不再是一个好指标。」

Goodhart 的原意是讨论货币政策——当中央银行试图控制货币供应量来影响通胀时，货币供应量的统计规律就会失效，因为银行会开始关注数字而不是真正重要的东西。

但这个定律在管理学领域几乎是公理。

在制造业，「废品率」是一个有效的质量指标——但一旦废品率成为目标，工人开始隐藏废品而不是减少废品。在销售，「订单数量」是有效的业绩指标——但一旦订单数量成为目标，销售开始用折扣和关系而不是产品质量来冲数字。

在软件工程，「代码行数」曾经是一个糟糕的代理指标——但当 AI 让代码生成变得极其便宜时，这个糟糕的指标以新的形式回来了。

为什么衡量知识工作是不可能的

Peter Drucker 在 1999 年写道：

「知识工作者的生产率是最大的挑战。」

他认为知识工作与制造业有本质的不同：

产出是无形的——质量无法通过产出来衡量
过程就是工作——思考的过程无法被直接观察
知识工作者必须是自我导向的——外部测量会破坏内在动机
投入的质量比产出的数量更重要

Drucker 的核心观点是：知识工作应该用结果（results）来衡量，而不是用活动（activities）来衡量。但问题在于，对于知识工作，结果往往是长期的、间接的、难以归因的——而活动（代码行数、提交数、工时）更容易被衡量。

这就产生了一个结构性的悖论：最容易衡量的产出（活动）往往最没有价值，最有价值的产出（判断质量、系统健康度）往往最难衡量。

制造业的产出是可以计数的——零件、成品、装配线速度——因为这些是线性可测量的。但软件工程的产出不是线性的：一个正确的架构决策可以让项目少走三个月弯路；一次好的代码审查可以阻止一场生产故障；一个简洁的设计可以省下几千行维护代码。这些都是产出，但它们都不体现在「提交数」里。

AI 时代的新版本问题

当代码生成变得极其便宜时，问题变得更严重了。

GitHub CEO Thomas Dohmke 在 2025 年说，GitHub Copilot 已经帮助生成了 46% 的代码行数。这个数字本身不算问题——问题是它让「代码行数」从一个描述性指标变成了一个竞争性指标。

当一个工程师每天可以用 AI 生成 500 行代码，而另一个只能写 50 行，谁的「生产力」更高？

传统上，我们会说 500 行的工程师更有产出。但如果 500 行中有 300 行是没人仔细看过的技术债务，而 50 行是一个经过深思熟虑的架构决策呢？

这就是 Goodhart 定律在 AI 时代的回归：衡量的指标不再描述现实，而是改变现实。

当「代码行数」成为竞争指标，工程师开始用 AI 生成更多的代码——不是为了解决问题，而是为了提高指标。AI 成了「刷 KPI」的工具，而不是提高代码质量的工具。

Stack Overflow 的调查数据显示了这种转变的后果：开发者对 AI 的信任在下降，调试 AI 生成代码的时间在增加，「看起来对但实际不对」的代码成为了最大的痛点。

决策疲劳的结构性影响

MIT 的研究提出了一个概念：「认知劳动的弹性需求」。

就像更便宜的煤炭导致更多煤炭消耗，更便宜的认知劳动（AI 代码生成）导致更多的认知劳动被消耗。

这里的关键是「弹性需求」：当某物的成本下降，需求量会增加——如果价格弹性大于 1，需求量的增加会抵消价格下降的影响，导致总支出不变甚至增加。

对于代码生成：

AI 让代码生成的成本趋近于零
这意味着更多的代码被生成
但每行代码被判断的成本没有下降，甚至因为数量的增加而上升
最终，判断力成为了瓶颈——不是生成力

这就是为什么 METR 发现高级开发者使用 AI 后变慢了：他们的时间从「生成」转移到了「判断」，而判断是一个更慢的过程。

对于初级开发者，AI 可能确实是加速的——因为他们没有足够的经验来判断代码是否正确，任何能跑起来的代码都是有帮助的。但对于有经验的高级开发者，AI 增加的不是生产力，而是需要审查的东西。

工业时代思维的持久性

这里有一个更深的问题：为什么组织在面对无法衡量的产出时，会本能地选择衡量容易衡量的产出？

答案是：工业时代的成功模式。

制造业的产出是可以立即观察的：零件要么合格要么不合格，成品要么卖得动要么卖不动。投入和产出之间的关联是直接的、线性的。这种可观察性让管理变得简单：你只需要设定目标，然后衡量结果。

但这个模式在知识工作中失败了。几十年来，我们试图将制造业的指标体系应用到知识工作——代码行数、工时、项目数量——但这些指标衡量的都是活动的量，而不是活动的质。

Drucker 早就指出了这个问题：

「知识工作者的生产率不是由投入的数量决定的，而是由产出的质量决定的。但质量是难以定义的，更难衡量。」

问题是：如果你无法衡量质量，你就会用数量来代替。而数量是可以被 AI 无限放大的——这正是我们目前在经历的。

什么才是真正的产出？

一个更接近真实产出的指标体系应该包括：

事后指标（lagging indicators）：

代码变更后的事后故障率
技术债务的增长速度
关键决策从提出到落地的时间

结构性指标：

系统可维护性评分的变化趋势
代码审查中发现的深层问题的比例
架构决策的持久性（一年后是否还需要重构）

但这些指标都有一个问题：它们很难收集，有很长的滞后周期，容易被操纵。

更关键的是：它们无法在短期内用于评估个人绩效。这意味着在 AI 时代，大多数组织依然会使用代码行数、提交数这样的即时指标——因为它们符合工业时代的思维方式，而且 AI 让它们更容易被获取。

这就是为什么 Goodhart 定律没有被 AI 击败——它只是换了张面具。

一个值得思考的问题

当我们用代码行数来衡量工程师的生产力时，我们实际上是在衡量什么？

答案是：我们正在衡量「有多少代码被写出来」，而不是「有多少价值被交付」。

价值是时间的函数。一段代码在短期内可以工作，但在长期可能会成为技术债务。一个正确的架构决策在短期内不体现在任何指标里，但在未来会省下几千行重写。

AI 让生成代码变得几乎免费，但这没有改变这个基本事实——它只是让衡量变得更加失真。因为更多的代码被生成，而更多的代码意味着更多的噪音淹没信号。

管理者迟早要面对一个事实：你最优秀的工程师的价值，不体现在他们生成了多少代码，而体现在他们阻止了多少糟糕的代码进入系统。

而这个问题，在 AI 时代，比以往任何时候都更难回答——也更需要回答。