James Shore 讲解如何度量 AI 编程的意外后果：变更成本与建模方法

O'Reilly Radar· James Shore·2026-11-11 20:11· 39 分钟前AI 评分64

衡量 AI 的意外后果

AI 导读

James Shore 在系列第三部分讲解如何度量和建模 AI 编程的意外后果，核心指标是变更成本，其中价值增值比例是他最信任的指标。文章给出可维护性模型、代码行数流失模型、锁定和倦怠的观察方法，并提醒价值增值比例极易被操纵，应只用于评估方法而非考核人员。

正文 · 原文

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

AI 非常擅长让团队提速。但它可持续吗？可维护性、倦怠和锁定问题又该如何？

这是我关于评估 AI 对软件开发影响的系列文章的第 3 部分。在第 1 部分中，我们探讨了为何评估影响很重要，以及哪些做法不可取。在第 2 部分中，我们探讨了如何衡量 AI 对交付速度的影响。在本部分中，我们将探讨如何衡量和建模使用 AI 的意外后果。然后我们将在第 4 部分中考察业务成果，作为收尾。最后，一篇后记将把所有内容整合起来，并附上你可以与 CFO 分享的要点。

可维护性真的重要吗？

我现在就能听到这种声音：“谁在乎可维护性和倦怠这种婆婆妈妈的问题？这只是一份工作。如果工作本该有趣，就不会叫‘工作’了！忍着吧！”

所以让我说清楚：我们关心 AI 的意外后果，是因为它们具有真实的经济影响。如果代码不可维护，功能编写和缺陷修复都会耗时更久，从而挤占更有价值工作的时间。如果人们倦怠了，他们就不会全力以赴，最终会离职，带走机构知识，并导致耗时的招聘周期。如果你被锁定，而 AI token 成本上升，你可能会陷入两难：要么支付高额账单，要么削减开发。

在我交谈过的人中，大家普遍认同大量使用 AI 会产生人类难以理解的代码。但对于这有多重要，存在分歧。如果由 AI 来做维护，我们还在乎人类能否理解代码吗？

这个话题各方都有强烈观点，但实际证据不多。明确的是，维护成本和其他意外后果确实重要，但前提是确实存在成本。这正是我们需要衡量的：是否存在影响？如果存在，是否大到值得关注？

不幸的是，与我们在第 2 部分中讨论的严格速度试验不同，意外后果是渐进且模糊的。你的测量结果会充满噪声且滞后。你必须创建模型并探索情景。最终，你的决策将归结为判断，以测量和模型为依据，但不由它们驱动。

一枚戒指统御众戒

有一个理念虽不完美，却能很好地捕捉大多数意外后果。它就是变更成本。

简而言之，变更成本就像对你所做的软件变更征税。当变更成本低时，复杂的变更仍然需要时间，但可以实现。当变更成本高时，即使简单的变更也可能需要数周，而复杂的变更似乎完全遥不可及。

变更成本不易衡量，但有几个指标可以用来辅助你的判断。

价值增值比例

增值百分比是指你的软件开发工作中用于为业务带来价值的事项（例如新功能）的投入占比，与之相对的是用于非增值工作（例如修复缺陷、处理事故以及手动测试和发布周期）的投入占比。

非增值工作被称为“muda”。¹ 有些 muda 是必要的，甚至是有价值的，但这并不能让它成为增值。想象一位苛刻又脾气古怪的客户，总是问：“为什么你第一次不把它做对？”如果那位客户不愿为某件事付钱，那就是 muda。

这就是为什么修复缺陷是 muda：“我不会付钱让你修复一个本就不该存在的缺陷！”以及执行发布：“为什么不直接发布出去！这能有多难？”当然，修复缺陷可能是有价值的，发布也是必要的，但它们仍然是 muda。

我发现把 muda 进一步区分为自主性 muda 和非自主性 muda 很有用。自主性 muda 是你选择去做的工作，例如投资于降低开发成本的代码变更。非自主性 muda 是为你选定的工作，例如修复缺陷、事故和依赖升级。

你总会有一定基线数量的非自主性 muda；这是一项持续的税负，会从其他工作中占用时间。但如果它在上升，就意味着你花在增值工作上的时间在减少。你用于做重要事情的时间更少了。你的成本在增加。

当我担任工程副总裁时，增值百分比是我的关键指标之一。我把减少 muda 作为优先事项，并得到了回报。在我任职的三年里，我们将增值百分比翻了一番，这让我能够在不增加人员编制的情况下，腾出人手去开展重大的新举措。

DORA 指标

你的组织很可能已经在跟踪DORA 指标，包括变更前置时间、部署频率、变更失败率等。如果没有，它们值得考虑。与增值百分比一样，这些数字的变化是值得关注的事情。

Token 用量

Token 是实实在在的成本，完成一次变更所需的 token 越多，你的成本就越高。不幸的是，token 用量可能因许多原因而波动，而不仅仅是变更成本。尽管如此，它仍然值得关注。据经验观察，构造更好的软件更容易让 AI 处理，并且消耗的 token 更少。

Token 用量最大的差异之一在于人们的采用程度。不要只跟踪总体用量，还要关注个人用量的变化。在我见过的图表中，用量形成了帕累托曲线。曲线低端人群用量的增加可能只是代表熟悉程度在提高。曲线高端人群用量的增加值得进一步调查。

模型、harness、提示词等的变化都会影响 token 用量。这个指标仅供参考；它的用途是触发进一步调查，而不是单独使用。

至尊戒，驭众戒

在这些指标中，增值百分比是我最信任的一个。它运作在我们关心的层面上：时间都去哪儿了？

跟踪增值百分比不必成为一项沉重负担。你不需要时间表或详细的任务跟踪。诀窍是不要过度在意精确度。按一两天为粒度跟踪工作就足够了。

当我进行这项追踪时，我借用了我们的价值增量（VI）追踪。每一项都是数天到数周的工作，并且可以清晰地归类为增值或muda。但你不必使用VI；任何追踪方法都可行。

追踪不要过于细粒度。当我担任VP时，经理们每周与每个团队沟通两次，记录团队在哪个VI上工作以及有多少人参与。每个VI被归类为“muda”或“增值”，我们有许多子类别来帮助我们了解时间去向，例如“bug”、“容量投资”、“重大举措”等等。它很轻量且非常有用。

每月审查你的增值百分比。如果它下降，你不一定有问题，但值得进一步调查。

增值百分比最大的问题是它噪声很大。我的经验是趋势需要三到六个月才能显现。我花了一年时间才确信地表示我的变更成本降低努力带来了持久的结果。

滞后时间很长，但仍然值得追踪。我和我的产品伙伴发现增值百分比作为沟通产品开发中发生情况的工具非常有价值。而且，遗憾的是，改善变更成本比让它变糟要难得多。如果AI正在造成严重问题，它可能会更快显现。

One ring to bring them all

因为你的变更成本指标会有噪声和不确定性，用模型和情景规划来补充它们。你的模型不会告诉你未来会怎样，但它们会告诉你未来可能会怎样，这将帮助你管理风险。

以下是我发现有用的一些模型：

可维护性

将维护建模为开发上的强制性“税”。对于每个月的增值开发，估计下一年一定量的维护，然后之后每年持续维护量更低。（群体智慧估算可能有帮助。）然后构建一个模型，显示每月有多少工程天数可用。减去花在维护上的时间，其余可用于增值。

要建模AI的影响，应用你测量到的开发速度改进。估计AI将如何改变维护成本，并估计对人员数量的影响。然后基于不同的AI维护成本探索情景。

如果你只创建一个模型，就创建这个。我这里有更详细的解释。它包括一个电子表格，你可以用作模型的起点。

例如，使用该模型，如果AI将我们的速度提高50%，但token成本将人员数量减少25%，且维护成本估计翻倍，我可以看到尽管性能大幅提升，我只是收支平衡：

多余的代码行

代码行数不是好的生产力度量，但它们是合理的成本度量。一般来说，更多代码行导致更多维护成本。

这个模型与前一个类似，但使用代码行数而不是工程天数。使用可追溯性数据将提交分类为“增值”或“维护”。对于每个提交，测量总代码变动：更改、添加或删除的代码行数。

对于每一行增值变更，估算下一年一定量的维护代码变更，然后在此后的每一年估算一个更低的量。根据前几个月的增值变更量，建模每个月需要多少维护代码变更。（示例见此电子表格的“tmux”标签页。）

要建模 AI 的影响，请在你的速度提升试验中测量 AI 如何影响代码变更。然后将增值变更投射到未来，并建模维护变更可能如何变化。

这个模型的优势在于，你可以用（部分）实际提交数据来修正你的估算。例如，下图使用了开源项目 tmux 的真实提交数据。² 在运行模型之前，我猜测第一年每行增值对应一行维护，此后每年对应 0.1 行，结果发现这与实际数据惊人地接近。

锁定

如果 token 成本上升，你会如何应对？你会裁员吗？减少 AI 的使用？切换到能力较弱的模型？

要建模这些影响，请更新“可维护性”模型。根据人员数量减少你的每月工程产能，并根据 AI 使用的减少来估算速度提升的下降。你可能需要为维护 AI 编写代码的人类增加一组单独的估算和计算。

倦怠

随着精神疲惫加剧，生产力可能会下降，人员流动率可能会上升。我认为你无法准确建模这些影响，但你仍然可以持续关注它们。

将精神疲惫纳入你的开发速度研究，看看两种方法在精神疲惫方面是否存在显著差异。定期进行关于人们精神能量水平的单问题调查。关注实际人员流动率与历史数据的对比，并在离职面谈中留意对 AI 的抱怨。

并在黑暗中束缚它们

增值百分比有其阴暗面。它极其容易被钻空子。一旦管理者认为团队是根据他们如何分类工作来被评判的，那么为了自身利益而调整分类的诱惑将会极其强烈。

这甚至不必是欺诈行为。一位拥有优先级决定权且想要证明自己的领导者，完全可以决定推迟维护，优先做增值工作。这样做的压力本已巨大，需要异常坚强的品格才能抵抗。

（如果你真的恨你的公司，可以考虑这一点：你可以推迟维护几年而不被发现。刚好够时间在另一家公司谋得更高的头衔！然后你的继任者就得背锅，而你的老公司会纳闷为什么产品开发什么都做不成。）

对于这些问题，我没有简单的答案，只能提醒你：用这些指标来评估你的方法，而不是你的人员。没有哪个指标不能被钻空子，而这个指标比大多数指标更容易被钻空子。但它对于理解 AI 可能带来的负面影响也至关重要。用它，但要谨慎使用。

开发速度与意外后果是同一枚硬币的两面。它们帮助我们理解 AI 如何改变我们交付的规模，无论是现在还是未来。但仅仅交付更多软件还不够。我们需要产出正确的软件。接下来我们将在第 4 部分中探讨业务成果。

脚注

1. “Muda”是一个日语词，来自丰田生产系统，该系统是精益软件开发运动的灵感来源。︎
2. 非常感谢 Christophe Stjernlöf 提供 tmux 项目的原始数据。他使用 LLM 将提交分类为“增值”或“维护”。阶梯状是数据收集方式造成的产物。︎

来源：O'Reilly Radar · oreilly.com