James Shore 解析如何评估 AI 对软件开发的真实回报

O'Reilly Radar· James Shore·2026-10-28 18:54· 40 分钟前AI 评分56

你在 AI 上的投入物有所值吗？

AI 导读

James Shore 在 O'Reilly Radar 发表系列文章首篇，介绍如何量化 AI 对软件开发的组织级影响，分四部分覆盖交付速度、负面后果和业务结果建模。

正文 · 原文

以下文章最初发表于 James Shore 的 Successful Software 博客，经作者许可在此转载。

软件开发已成为 AI 自动化的最大受益者。我最近与一位 CIO 交谈，他的组织有 170 人，他测得 AI 带来了 2.1 倍的生产力提升。

这种生产力是有代价的。他手下 AI 使用量最大的用户每人每月在 token 上花费 21,000 美元。另一位工程负责人则每位工程师每月花费六到八千美元。

这不是一笔小钱。最终，它必须从某处来，而且很可能来自你的人员预算。现在我们谈论的是对真实人们生活的真实后果。但不采取行动也会带来真实的业务后果。

如果你要做这些选择——而且总会有人要做——它们必须是好的选择。所以你需要知道的不仅仅是成本，还需要知道收益。你在 AI 上的投资回报好吗？有没有另一种使用 AI 的方式会更好？

你怎么知道自己得到了什么？轶事般的报告比比皆是，但这些轶事背后的推理往往，说得客气点，并不理想。有些说法纯属虚构。

考虑到利害关系，这是个问题。

在本系列文章中，我将向你展示如何评估 AI 对贵组织软件开发的影响。全文分四部分外加一篇后记：

为什么你需要量化影响

各地的工程领导者都感受到用 AI 做更多事情的压力。但哪种方法最好？有很多人对该做什么持有强硬观点，但共识不多，硬数据更少。

即使有硬数据，也不是放之四海而皆准的。最适合内部 IT 开发团队的方法未必最适合初创公司，最适合新产品的方法也未必最适合一个精巧的遗留系统。

更快的方法也未必更好。如果每个人完成的工作量翻倍，但你在 token 上花了太多钱，以至于不得不把员工裁掉一半，你真的看到任何 ROI 了吗？如果更温和的速度提升能让你控制成本，你实际上可能过得更好。

你不能仅凭直觉做出这些权衡。在一项著名的 METR 研究中，工程师们以为 AI 让他们快了 49%，而实际并非如此。¹ 你必须衡量影响，才能知道自己实际得到了什么。

不要忽视成本

成本比影响容易衡量得多，但成本本身也并非没有挑战。最大的挑战是补贴。为了争夺市场份额，大型 AI 公司正在提供大幅折扣。一位工程负责人告诉我，每个团队成员花费数千美元的 token，而订阅费用仅为 200 美元。Anthropic 和 OpenAI 不断提供折扣和其他促销活动。总有一天，这些补贴会结束，价格会上涨。

真的会吗？开放权重模型和本地推理正在对 token 成本施加下行压力。专用推理芯片可能让 token 更便宜。路由器承诺将你的提示词导向最适合该任务的最便宜模型。随着模型能力增强，完成相同任务所需的 token 可能减少。所有这些因素实际上都可能推动价格下降。

在计算 ROI 时，不要假设今天的成本就是你应该建模的成本。无论你认为价格会上涨、下降还是保持不变，都要明确你的假设，并考虑对乐观和悲观两种情景进行建模。

还有一个问题：采用 AI 不是拨动开关那么简单。人们需要时间来学习如何应用它。与任何重大转变一样，变革管理不容低估。在重大变革期间，生产力往往先下降后上升。这也会增加成本，意味着早期的测量结果可能具有误导性。

着眼长远

本系列第 2 部分展示了如何衡量交付速度。但这只是全貌的一部分。如果你交付的功能数量翻倍，但维护成本也翻倍，团队的整体生产力会先飙升，然后一落千丈。

工程师倦怠也是一个问题。一位采用规范驱动开发的工程负责人告诉我：“每个团队都在报告倦怠。”我要说一句显而易见的话：倦怠的人无法产出优秀的工作。他们不会在该反对时反对，不会报告问题，最终会离开，带走宝贵的组织知识。

第 3 部分展示了如何衡量 AI 使用带来的这些意外后果，包括可用于预测未来问题的技术。

最后，更快地交付软件价值才是关键。将缺陷修复率翻倍，不会产生与将竞争性新功能交付率翻倍相同的结果。就此而言，“仅仅因为我们可以”就交付考虑不周的功能，实际上可能让你的产品更糟。

第 4 部分展示了如何建模、预测和衡量业务成果。

不要衡量代码行数

首先，不该做什么：不要走捷径。

禁止清单上的第一项：代码行数。工程负责人半个多世纪以来就知道，代码行数与生产力并不对应。在其他条件相同的情况下，用 1,000 行代码实现的功能，其维护成本低于用 10,000 行代码实现的功能，且更不容易出现缺陷。

AI 以冗长著称。如果你衡量代码行数，你衡量的是垃圾，而不是生产力。不要这样做。拜托。

也不要衡量拉取请求

拉取请求（PR）的情况几乎同样糟糕。它们是工程师请求审查自己代码的检查点，而且完全是随意的。一名工程师（或 AI）可以选择提交一个 10 行的拉取请求，也可以提交一个 10,000 行的拉取请求。它可以是一个功能、一个缺陷修复，或者只是一个微小的代码改进。拉取请求的数量与生产力之间没有内在关联。

诚然，工程师通常会提交一致且合乎逻辑的 PR。因此，从某种意义上说，一连串的 PR 确实反映了某种开发节奏，PR 的增加可以反映生产力的提升。

但 AI 颠覆了这一现状。它能非常快速地生成大量代码，这可能使工程师的跟进能力不堪重负。如果没有严格的工程师监督，PR 就不再反映一致的开发节奏，这意味着 PR 数量不再是可靠的指标。

当然，当人们认为 PR 被用来衡量生产力时，他们就会受到诱惑去钻空子，提交超出实际需要的更多 PR。

衡量方法，而非衡量人

这就引出了古德哈特定律：“一旦某项衡量指标成为目标，它就不再是好的衡量指标。”关于这个话题，我最喜欢的书是 Robert D. Austin 的《衡量与管理组织中的绩效》：

渐渐地，随着员工屈服于走捷径的压力，衡量指标会（或者更准确地说，是被推着）与真实绩效脱节。衡量出的绩效呈上升趋势；真实绩效则急剧下降。这样一来，衡量体系就失灵了。

——Robert D. Austin

不要建立一个绩效衡量项目后就放任它一直运行。相反，要用这些指标来判断某种特定的 AI 方法效果如何。你可以定期重复这些测量，但无论如何，都不要用它们来衡量团队或个人的绩效。衡量方法，从中学习，然后停止衡量。

关于不该做什么，已经说得够多了。在本系列中，我们将量化 AI 的影响，而且我们会做得正确。这要从衡量交付速度开始。接下来是第 2 部分。

脚注

参与者自评速度快了 20%，但实测却慢了 19%。这项研究发表于 Anthropic 的 Opus 4.5 开启的编码能力大幅提升之前，所以你不应据此认为 AI 能力不足。但你应该据此认识到，生产力自评并不是可行之道。︎

来源：O'Reilly Radar · oreilly.com