Anthropic 内部调查：七成公司无法衡量 AI 工具实际回报

Anthropic 对 132 名内部工程师使用 Claude Code 的情况做了调研。每天合并的 PR 数量上升了 67%。每日使用率从 28% 攀升至 59%。自报的 productivity 提升在 20% 到 50% 之间。但随后有人查看组织的交付仪表盘，发现交付指标纹丝未动。

这个差距正是本文要探讨的全部主题。一个工具可以被频繁使用，使用者对它的评价很高，却在一个企业真正依据运转的财务数字上不留痕迹。背后的测量问题比任何一家公司的 coding assistant 都要大。McKinsey 发现，30% 的领导者能说清 AI 释放的时间最终去了哪里。另外 70% 说不清。十个组织中有七个有人在任务上花的时间变少了，却完全不知道这是否转化成了任何成果。从另一个角度问，答案同样单薄：Gartner 2025 年的调查中，22% 的领导者表示他们的 AI 工具产生了显著价值——这个比例与 McKinsey、Deloitte 和 ServiceNow 各自用自己的方式测出的结果落在了同一区间。

使用量和 token 是成本，不是回报

有两个数字被当作 ROI 问题的答案来报告，但它们都回答不了那个问题。

Adoption 告诉你是否有人在用这个东西。它是一个先行指标，而且是有用的指标，但一个 adoption 很高却没有可衡量产出的工具产生的是 activity，不是 value。Token spend 告诉你这个工具运行起来花了多少钱。它应该放在计算里——放在成本端——密切关注它根本无法说明它产出的工作是否值得做。

这两个指标从仪表盘里都很容易拉出来，这恰恰就是它们被报告的原因。真正重要的数字藏在更外围的一步，而且需要真正的工作才能得出：公司是否创造了或节省了一个站得住脚的美元。以下所有内容说的就是你如何在不自我欺骗的前提下得到那个数字。

所以当一份商业案例落到某张桌子上，声称节省了多少美元时，诚实的问题不是 AI 是否有帮助，而是那个数字是不是真的。在我看过的大多数案例里，那个数字是被夸大的，而且通常同时在两个不同的地方被夸大。

夸大之一：把弹性工时算成硬美元

几乎每一份 AI 商业案例都会做这样一个计算。工具每周为每个人节省了两个小时。把这些小时数乘以这些人的时薪，在整个团队层面加总，然后把总额报告为节省的金额。

这些小时数通常是真的。那些美元通常不是真的，因为预算没有变。没有人被裁员，没有承包商被终止，没有哪个预算科目消失。发生的事情是一群拿固定工资的人每周略微轻松了一点，而公司付给他们的钱和以前完全一样。

释放的时间在三种情况下变成真金白银：时间被重新投入到产生价值的工作上，或者它让你避免了本来要招的一个人，或者让同样的人力产生了更多可销售的东西。如果这三条都不成立，那这个节省就是 soft 的，而 soft 的节省在面对能看到预算没有下降的 CFO 时是站不住脚的。

这正是开篇那 70% 回来的时候。如果十个领导者中有七个说不清释放的时间去了哪里，那么市面上流通的大多数"节省小时数乘以时薪"的数字都是没有人追踪到结果弹性工时，被包装成了硬美元。修复方法并不复杂。把每个声称价值的美元标注为硬或软，两类分开报告。总数变小了，但也更难被驳斥了。

夸大之二：把日历时间算成劳动时间

第二种夸大更难察觉，我在工程类案例中最常看到。一个功能"以前花了三周"，"现在花一周"，于是案例把节省的两周时间按工程师的费率折算成美元。

问题是三周从来就不是三周的工作。其中有些是工单在队列里等待，有些是在等 review，有些是依赖还没有发布。Cycle time——从需求到交付的日历跨度——和 labor time——一个人实际花费的小时数——不是一回事。把日历跨度按时薪率折算成美元，无中生有了一笔没有人真正付出的劳动。

速度仍然值得报告，但应该以速率的形式报告：这类工作现在快 40% 地流转。它只有在"更快"捕捉到了真实的东西时才能变成钱——最常见的是因为东西更早交付而更早到达的收入。当不是这种情况时，更快的周期仍然是值得报告的真正改进，但不是一个可以折算成美元的数字。

在信任自报速度这件事上有一个相关的陷阱。我所知道的对同一批开发者有无 AI 情况进行计时的唯一对照研究 METR 发现，测出的速度反而慢了 19%，而自报的速度提升了 20%。开发者确信自己更快了。时钟不同意。无论你把 ROI 建立在其上的基础是什么，都不应该是问人们"你认为节省了多少时间"的调查。

什么真正产生了美元

剔除那些夸大之后，AI 工具产生金钱的机制只有两种，每种通过不同的桥梁转换成美元。

第一种是加速：某人以更短的时间完成了一个他已经做过的任务。桥梁是节省的小时数乘以那个人的时薪成本。如果一个任务从四小时降到了两个半小时，每月发生八十次，那就是每月 120 小时，按他的时薪成本你得到了一个真实的数字。然后减去返工，因为生成的输出如果需要人重新做，就从来没有节省过那看似节省的时间。

第二种是避免的工作：一个任务完全不再发生了。知识库解决的一个 support ticket 是人类永远不会去触碰的 ticket。这里的桥梁不是时薪率，而是一次完整互动的全成本：功能每月总成本除以它处理的互动数。如果 support 每月花 20,000 美元，处理 2,500 个 ticket，每个避免的 ticket 值 8 美元，而这个 8 美元已经承载了工具和 overhead，而不只是一个人的工资。在这里用加速桥梁——时薪率——会少算。

以上都是举例的算术，不是来自任何客户的数字。重点是结构：选机制，选匹配的桥梁，不要混用。

没有人写下的分母

回报需要一个成本来除，token 最终归属的位置就在这里。AI 工具每月的总成本是建设成本按其运行月数分摊，加上 token 花费，加上基础设施，加上维护，加上对其输出的任何人工审核。一个花了 150 小时建设、将运行两年的项目，这个月不是 9,000 美元的冲击；而是分摊到整个生命周期中每月几百美元。Token 成本比看起来简单：测量一个输出平均消耗多少 token，乘以每 token 价格，你就有了每个输出的稳定成本，可以拿来和那个输出产生的价值对标。

一个项目可以承载很多指标，但它只有一个 ROI。每个指标给同一个分子加上自己那一块价值，每一块都除以同样的总成本。这要求的一种纪律是避免重复计算：如果一个 token 成本已经放在了一个单位数字里面，它就不应该再放进分母；如果两个指标从两个角度描述同一个节省的美元，你只保留其中一个。

数学是确定性的，这就是为什么它被跳过的原因

我在之前的一篇文章中论证过，AI 属于财务分析的边缘地带，而绝不属于算术本身。测量你自己的 AI 的回报是从另一面看到的相同形状。计算是确定性的：减法、乘法、时薪、一个总额。不需要任何模型，也不应该信任任何模型来做这个。

它被跳过的原因不是难度。而是诚实的数字几乎总是比夸大的数字小，而小数字更难带进预算会议。一个站得住脚的小数字经得起审查，一个令人印象深刻的大数字经不起，而当领导者第二次被发现把弹性工时报成硬美元时，整个项目的信誉都要为之买单。

但 Agentic AI 不是应该免于 ROI 吗？

对面有一个严肃的论点，Gartner 提出了它：早期的 agentic AI 是实验性的，那些在接触它之前要求有成熟商业案例的组织，有被那些把它当作需要迭代的东西来对待的组织超越的风险。这个论点在它适用的范围内是对的。你不会把一个两周的实验挡在一个正式的 ROI 模型后面，而假装你能预测真正新事物的回报是一种打扮成预测的猜测。

但两面不同的主张被混在同一个旗帜下。"实验前不要要求商业案例"是站得住脚的。"不要测量它产生了什么回报"不是，而第一条经常被用来为第二条辩护。一个从不测量结果的实验不是实验，是一笔没有后续的购买。早期工作不要用 ROI 来卡门的理由是给自己留出空间去发现价值——而这只有在你接下来检查你是否找到了价值时才有意义。在开始时让 agentic AI 免于商业案例是合理的。永远让它免于测量就是这样——让看到真正价值的公司比例一直停留在一成的原因。

从哪里开始

在任何东西部署之前先捕获基准线，因为旧的方式一旦消失你就无法重建它以前花了多长时间。从请求到交付，完整地测量一个真实工作单元，包括等待时间，看那个数字是否移动了。停止报告已部署的座位数、完成的任务数、提交的 prompt 数和自报的速度，开始报告那个和客户或预算挂钩的唯一数字。把每个声称的美元标注为硬或软，并在百分比旁边报告净美元数，因为百分比会随着你放进分母的东西而变动，而净数字不会。

在运行的每个流程上做到这些，并写下每个流程需要什么才能真正改变预算科目——这是一次工作流审计。它比拉一张使用量图表花的时间长。但这也是唯一能产生一个你可以捍卫的数字的做法。

这个问题引出的问题

如何给节省的时间赋予美元价值？ 用节省的小时数乘以节省时间的人的时薪。只有当这些时间被重新部署、避免了一次招聘或产生了更多可销售 output 时，才将其计为真实节省。否则它是一个弹性数字，应该被标注为弹性数字。

Token 花费应该算作 ROI 的一部分吗？ 作为成本，算在分母里，绝不算作收益。如果想要一个数字和价值对标，可以追踪每个有用输出的单位成本，并确保没有在两个地方重复计算同一个 token。

一个项目可以有多个 ROI 吗？ 不行。一个项目只有一个 ROI。多个指标可以各自给同一个分子加上不同价值切片，都除以同样的总成本。如果你最终为一个工具得出了两个 ROI，你要么重复计算了，要么把两个项目混在一起了。