每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/
当我们第一次听说有公司在内部建立「Token 消耗排行榜」时，就隐约觉得针对 AI 支出的反弹迟早会到来。结果没过几个月，这种反弹果然出现了。
过去几周里，行业新闻几乎都围绕着同一个话题打转：Uber 的 AI Token 开销大幅超出年度预算；企业收到远超预期的 Claude 账单；管理层开始追问编码 agent 到底创造了多少价值；当然，也少不了针对这种担忧本身的反驳。我们同样听到不少故事：一些 CTO 和工程副总裁开始冻结预算，对所有新增 AI 支出进行层层审批，并要求给出极其详细的合理性说明。
说到底，用 Token 数量给员工排名，和用代码行数给工程师排名一样荒谬。即便假设所有人都抱着最好的动机在使用这些工具，消耗更多 Token 也不意味着创造了更多价值。问题不在于数字高低，而在于你测量的是错误的指标，因此也会据此做出错误的预算决策。
接下来会发生什么，其实并不难预测。
企业会开始收缩 AI 支出，给每个员工设置使用上限，让团队提交预算申请来争取 Token 配额。到了今年年底，预算冻结很可能会成为一种普遍现象。但从我们的角度来看，这恰恰是理解 AI 支出的错误方式。
当然，你不应该为了炫耀数字而无限制地增加开销；同样，你也不应该因为此前盲目追求 Token 使用量、结果出现超支，就转而把 AI 的使用限制到寸步难行的程度。事实上，把 AI 支出看成一个单独的数字，本身就是一种误导。
不同的 agent、不同的新工具、不同的实验项目，对企业产生的价值完全不同。把所有 AI 成本揉成一个总数，就像把所有员工薪资加总之后当成唯一管理指标一样没有意义。更合理的做法，是把每一种 AI 工具都视为服务于特定团队或特定业务能力的投入。当你从这个角度出发时，关于 AI 预算的许多规则都会变得截然不同。过去一段时间里，无论是从我们自己的实践，还是与数百个工程组织的交流中，我们都逐渐形成了一些相对明确的原则。
限制，也需要被限制
企业当然需要预算管理。我们并不是在鼓吹毫无约束的使用模式，更不是认为每个月几亿美元的 Claude 账单会成为新常态。但企业必须明白一点：限制本身也需要边界。
如果一个组织从毫无限制地使用 AI、任由账单飞涨，突然转向每一笔开销都需要层层审批和严格论证，这不仅会给团队带来巨大的组织震荡，也会直接打击员工尝试新工具的意愿。大家刚刚建立起新的工作习惯，管理层却又要求全部推翻重来，这种反复本身就会产生巨大的摩擦成本。
更重要的是，不同类型的 AI 使用场景本来就应该被区别对待。
那些已经被证明能够稳定创造价值的工具------例如编码 agent------与仍处于探索阶段的新产品，本来就不应该使用同一套预算规则。如果组织根本没有为实验预留预算，那么它迟早会在技术变革中落后。
而压制实验，大概是企业最容易犯、同时也最不必要的错误之一。
尽管 AI 的发展速度已经非常惊人，但我们对于它的应用边界其实仍然知之甚少。大量潜在场景尚未被发现，大量工作流程也还没有形成成熟实践。如果企业从一开始就严格控制预算，那么团队根本不会有机会去理解这些工具真正能够做到什么。
我们已经见过这样的情况：一些工程团队明明相信某个新工具能够解决现实问题，而且其成本甚至只有现有解决方案的百分之一甚至千分之一，却依然被禁止采购。与此同时，他们仍在为解决同样的问题支付更高昂的人力成本，或者继续向 OpenAI、Anthropic 支付更高的费用。
这种情况还暴露出另一个长期存在的问题：软件预算和人力预算往往被人为地割裂开来。
传统企业习惯把招聘和采购视为两套完全不同的决策体系，于是经常会出现一种奇怪的现象：团队明明还有招聘名额，却始终招不到合适的人；与此同时，他们又被禁止增加软件开销。事实上，agent 并不会一比一地替代工程师，但它们确实能够承担大量重复劳动，让人们把精力集中在自己最擅长的事情上。
当企业限制实验的时候，本质上是在假设世界不会发生变化。它们限制的不只是预算，而是组织适应新技术的能力。如果把解决产能问题的手段完全寄托在增加人手上，那么你实际上选择的是成本最高、效率最低的一条路。
当然，没有人希望预算失控。但如果因为害怕超支，就假装周围的技术环境没有发生变化，那么最终得到的只会是竞争对手越来越大的领先优势。
自研还是采购：问题其实没变
关于未来是不是应该自己开发所有软件，最近已经有太多人发表过意见。
我们过去也讨论过自研与采购之间的取舍，因此这里不打算重复那些论点。不过，这个问题与预算讨论密切相关，因为许多人低估了自研软件所带来的隐性成本。
现实情况是，自研项目出现预算超支的概率，通常远高于直接采购成熟产品。
原因并不复杂：人类天生不擅长处理沉没成本。
一旦投入资源开发出原型系统，人们往往会倾向于继续投入，而不是停下来重新评估是否值得继续。这种心理机制会让预算失控变得越来越严重。
如今已经成为行业共识的是：借助编码 agent，任何人都能在几分钟内、花费几分钱做出一个看起来相当不错的 Demo。
真正困难的部分从来不是 Demo。
真正困难的是把 Demo 变成产品。
从原型到生产环境之间的距离，远比大多数人想象得遥远。
你不仅需要投入大量时间解决稳定性问题、补齐边界条件、修复各种意料之外的缺陷，还需要持续消耗大量 Token 去帮助系统完成这些工作。更关键的是，当绝大部分代码都由 agent 生成之后，一旦系统出现故障，团队里很可能没有人真正知道发生了什么。于是你不得不继续调用 Claude 或其他模型，让它们帮助排查问题，而这又会进一步增加成本。
这也使得预算与 ROI 的计算变得异常复杂。
这些支出究竟应该归类为工程投入还是运营成本？
哪些费用属于预期成本？
哪些只是系统尚未成熟阶段的额外负担？
工程师在这个项目上投入的时间应该如何估算？
与其他项目相比，这些资源是否值得？
对于任何一家并不以软件开发为核心能力的企业来说，准确估算这些问题几乎是不可能完成的任务。而这些估算误差最终又会反过来污染所谓的「AI 预算」。
在项目早期，Token 开销看起来微不足道；但当系统进入生产环境，开始面对维护、升级和新功能开发时，无论是 Token 成本还是工程师成本，都会迅速变得难以解释。
比过去任何时候都更重要的，是优先级
我们越来越频繁地看到工程团队陷入一种新的分心状态。
前段时间我们分享过一个案例：某个团队在多个方案之间来回切换，尝试各种可能性，却迟迟无法推进真正重要的工作。
从某种意义上说，这种现象并不令人意外。因为今天的工程团队确实拥有前所未有的能力，他们几乎可以尝试任何想法。
问题在于，大量实验最终可能什么都没有留下。
特别是在现成解决方案已经存在的情况下，反复重复实验往往只是昂贵的分心行为。它不仅消耗时间，也会不断推高 Token 成本。而这些价值可疑的实验项目，显然不应该与真正能够帮助业务发展的系统混为一谈。
这类问题往往比表面看起来更加隐蔽。
许多实验一开始只需要几美元，但如果缺乏明确目标，很快就会演变成上千美元的无底洞。我们自己也经历过类似情况。
因此，我们并不是主张为了控制预算而停止使用 agent，而是强调：在启动任何实验之前，团队必须清楚自己想解决什么问题，以及这个目标与 Token 消耗之间存在怎样的关系。
给团队保留探索空间当然很重要，但探索本身并不等同于创造商业价值。如果把两者混为一谈，那么围绕 AI 的所有决策最终都会失去方向。
AI 不是预算表上的一个科目
归根结底，整场讨论都围绕着同一个问题：企业究竟应该给 AI 工具预留多少预算？
这是一个真正意义上的百万美元问题。
我们见过各种不同的做法：完全没有限制的自由使用模式------虽然这种做法正在迅速消失；把所有 AI 预算都归属于工程团队；或者为整个组织设立统一的 AI 预算池。
然而无论采用哪一种方式，它们都有一个共同问题：
都把 AI 当成了预算表上的一个独立项目。
而这正是问题所在。
今天的讨论其实早已不是「AI 是否会留下来」的问题，而是我们应该如何理解 AI 所创造的价值。
帮助产品团队更快发布功能所产生的价值，与尝试复刻一个第三方工具所产生的价值完全不同；而自动生成销售邮件文案所带来的收益，又是另一种完全不同的价值。
把这些全部归入「AI 支出」这个统一类别，就像把研发投入、市场营销和客服成本统统记在同一个会计科目下一样荒唐。
不同的 agent 创造价值的方式不同，创造价值的规模也不同，因此评估它们的方法自然也应该不同。
当然，这并不意味着每一个 AI 项目都必须拥有立刻能够量化的 ROI。
企业完全应该为那些可能产生价值、也可能最终失败的实验保留预算。
至于这个预算应该有多大，以及需要多严格地控制，则取决于不同企业自身的情况。
但无论如何，把所有 AI 支出都塞进同一个篮子里，然后一会儿拼命放大这个数字、一会儿又急着把它压缩下来，都只会把企业带向错误的方向。
AI 不是预算表上的一个数字。
它更像是一种新的生产能力。
而真正值得管理的，从来不是 Token 本身，而是这些能力最终为组织创造了多少价值。