你是否曾被告知在工作中更多地使用AI，仿佛纯粹的使用量就是被奖励的标准？团队通常依赖活动指标来衡量AI的使用情况。但当这些指标成为成功的代理而非仅仅是活动的指示器时，挑战就来了。例如，如果我在销售团队中专注于通话量，我可能每周都能达到活动目标。但仅凭通话量并不能告诉我是否达到了季度最低目标。

今天，我们将探讨团队在AI方面面临的类似挑战。在过去一年中，许多团队通过采用指标来衡量AI的使用情况：有多少人使用AI？消耗了多少Token（令牌）？而Token是AI模型处理文本的基本单位。将Token消费作为衡量AI使用和成本的常见方式，使得Token消耗成为参与度的代理指标。

一些团队鼓励更广泛的AI使用，认为大量的消费会带来更好的结果。这就是“Tokenmaxxing”，即最大化AI的使用量，相信更多的活动等于更多的价值。作为采用信号，这确实有效；但随着AI扩展到日常基础设施中，一个问题出现了。正如IBM咨询SVP Neil Dhar所指出的那样，在缺乏真正指标的情况下，团队创建了使用仪表板，人们很快学会了操纵这些数据。

随着AI演变为能够完成工作的系统，这种方法变得越来越有限。代理式AI系统所做的远不止生成代码。它们规划工作流、分析存储库、调用工具、测试解决方案，并在多个系统之间协调工作。能力更强的代理自然消耗更多的Token，但仅凭Token消费无法区分活动和可衡量的结果。团队可以看到AI使用量增加，但并不清楚产生的价值是什么。

因此，团队开始提出一个不同且困难的问题：当我们必须为所有这些付费时，我们实际得到了什么？仪表板显示使用量不断增长，Token数量持续攀升，但这种活动与系统级结果之间的联系仍然不清楚。这种消费和价值之间的差距引发了下一阶段的对话。随着AI成本的增加，团队通过关注最明显的指标——Token消耗来应对。

围绕限制使用、限制新模型、缩小上下文窗口和减少提示词的新政策应运而生。但最小化Token陷入了与最大化Token相同的陷阱。两者都假设Token消耗是主要的衡量指标，但都没有测量运营结果。通常会发生的情况是：团队消除了明显的低效之处，如过大的工具目录或陈旧的上下文。

这很有道理，但随后他们继续削减并开始移除关键信息，如任务描述、领域约束和架构上下文。例如，为了节省Token而剔除架构上下文，AI可能会生成在孤立环境中有效但在更广泛系统中崩溃的代码。你节省了500个输入Token，但现在你要花费5,000个Token进行调试和返工。成本并没有消失，只是转移了。

团队为较低的输入Token而庆祝，同时在工作流的其他地方支付相同的复杂性成本。那么我们应该优化什么？“Valuemaxxing”是由Nebus首席营收官Mark Boroditsky提出的术语，它将对话从消费转移到结果上。团队不再问“我们用了多少Token”，而是提出不同的问题：完成了多少次部署？节省了多少开发人员时间？避免了多少返工？解决多少漏洞？

这些是确定AI是否创造了可衡量结果以及增量Token使用是否合理的指标之一。Token消费植根于高质量的软件和SDLC（软件开发生命周期）中的成功结果。现在让我们再进一步，随着模型成为基础设施，这种区别变得重要起来。

访问优秀的模型不再是最主要的差异化因素。系统的有效性更多地转向围绕模型构建的系统，包括上下文管理、工作流编排、治理以及优化。如果结果比Token更重要，那么系统就比模型更重要。这就是为什么模型编排也变得比模型选择更重要的原因。

IDC预测，到2028年，70%的大型AI部署将在多个模型之间工作，而不是依赖单一模型。开发人员和平台领导者都对价值最大化负责。对于开发人员来说，AI效率正在成为一种新的工程技能。开发人员应该像思考云资源、数据库或应用程序性能一样思考AI的使用。

目标不是少用AI，而是更有效地使用AI。良好的上下文卫生、执行前的规划以及理解成本与结果之间的权衡，都有助于产生更高质量的结果。对于平台领导者来说，责任则不同。平台领导者需要对成本和结果都有可见性。他们需要衡量价值而非数量，奖励效率，并为团队提供理解影响、跟踪结果的工具。

建立AI效率文化需要问责制、可见性以及跨工程工作流的共享指标。平台也是方程的一部分。开发人员和领导者不能独自承担AI效率的责任。他们使用的平台应该帮助将AI消费与结果联系起来。管理控制提供预算、治理以及对AI使用情况的可见性。

分析帮助团队将AI消费与运营结果联系起来，而不仅仅是Token数量。同时，工作流能力、技能和工具集成减少了不必要的工作并保留了交付高质量结果所需的上下文。随着模型效率的提高和成本的转移，AI的经济性将继续变化。

第一章是关于采用，下一章是关于价值。Token消费帮助团队了解是否使用了AI；而Valuemaxxing则帮助团队理解AI如何创造价值。