> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # AI 不是一个预算条目 - URL: https://www.hubwiz.com/blog/ai-is-not-a-line-item/ - Published: 2026-06-08T00:46:08.000Z - Updated: 2026-06-08T02:41:47.000Z - Description: 用一个数字来衡量所有 AI 支出，是灾难的根源。 - Author: admin - Tags: INDUSTRY, #Import 2026-10-14 14:41 当我们开始听到一些公司维护内部 token 数量排行榜的消息时，对 AI 支出的反弹似乎就不可避免了。仅仅几个月后，这种反弹果然来了。 过去几周的头条新闻充斥着各种讨论：比如 Uber 公司[大幅超出了全年的 AI token 预算](https://www.forbes.com/sites/janakirammsv/2026/05/17/uber-burns-its-2026-ai-budget-in-four-months-on-claude-code/?ref=hubwiz.com)，意外的 [Claude 超额使用](https://x.com/Polymarket/status/2060034216906068131?ref=hubwiz.com)，以及[你是否能够衡量编程代理带来的影响](https://www.businessinsider.com/uber-coo-andrew-macdonald-ai-token-spending-harder-justify-2026-5?ref=hubwiz.com)。当然，还有[对反弹的反弹](https://x.com/simonw/status/2060209010486493500?ref=hubwiz.com)。我们自己也有所耳闻——一些 CTO 和工程副总裁正在冻结预算，对所有新的 AI 支出实施极其严格的审查。 Token 排行榜并不比根据代码行数来给工程师排名更明智。即使你假设每个人都是出于最好的意图行事，使用更多的 token 并不意味着你完成了更多的工作。你在衡量错误的东西，也在以错误的方式分配预算。 接下来发生的事情在一定程度上是可以预见的。企业将会缩减 token 支出，设定每位员工的限额，并要求各团队提交 token 分配的预算申请。到今年年底，预算冻结将成为普遍做法。但从我们的角度来看，这完全是错误的方式来处理 AI 支出。你不应该为了炫耀数字有多大而增加支出，也不应该因为害怕超额而限制 AI 的使用——*因为你之前一直在疯狂消耗 token*。事实上，把你的 AI 支出当作一个数字来思考本身就是错误的思路。 不同的代理——以及对新工具的不同实验——对你的业务将产生不同的影响。把所有 AI 支出用一个数字来衡量，和把所有薪资支出用一个数字来衡量一样不合理。相反，你应该考虑每个 AI 工具对其购买的团队或功能的影响。从这个角度来看，AI 支出的合理规则就开始显得截然不同了。我们从自身的经验以及与数百家工程组织的交流中，总结出了一些已经开始成形的规则。 ## 1、有限度的限制 企业需要预算，我们并不是在提倡不受约束的使用或者让 5 亿美元的 Claude 账单成为新常态。但是你需要对如何设定限制本身设定限制。从使用无限制和巨额账单，到极端审查和每一笔开支都需要 justification（解释），这种转变既会造成组织震荡（我需要多久改变一次我的工作习惯），也会阻碍实验。AI 的不同用途——比如已经被证明有价值的编程代理与实验性的新工具——应该被明确区别对待。如果你没有用于实验新工具的预算，你将会落后。 阻碍实验可能是最大且最完全可以避免的自摆乌龙。虽然变化的步伐非常快，但仍然有大量尚未被发现或理解不够充分的应用领域，而激进地设定预算限制意味着你的团队将无法了解什么是可能的。我们已经听到一些工程团队分享说，他们不被允许在任何新的 AI 工具上花费——即使他们相信我们的解决方案能解决他们面临的实际问题，而且成本比他们用人力解决问题（或者用 OpenAI、Anthropic）要低 1 到 2 个数量级。 这也需要重新审视你对软件预算与人力预算的思维方式。传统上，软件预算和薪资预算是被区别对待的，但我们已经看到一些案例：团队有开放的名额却找不到高质量的人才，同时却被阻止在软件上投入更多资金。代理不会一对一地替代人类，但它们会承担繁琐的工作，让人们能够专注于自己最擅长的事情。 当你限制实验时，你是在拥抱一个静态的世界观。你在限制团队适应最新技术的能力，而仅依赖人力是解决产能问题最困难的方式。你当然不想让你的预算失控，但坐视不管、假装周围的技术没有在变化，从而给你的竞争对手创造优势，这也是行不通的。 ## 2、自建与外购：算账的方式（并没有那么）不同 关于[你是否应该从现在开始自己构建所有软件](https://x.com/buccocapital/status/2059953927840305459?ref=hubwiz.com)，已经有大量的讨论。我们之前已经讨论过[自建与外购的算账方式](https://frontierai.substack.com/p/enterprise-ais-teenage-years?utm%5Fsource=publication-search)，所以我们不会在这里重复那些论点，但自建与外购的决策确实与预算讨论密切相关。在内部构建产品比直接购买现成的产品更容易导致预算超支。人类通常非常不擅长处理沉没成本，所以一旦你投资构建了一个原型，很自然地会加倍投入——但那正是你的预算超支最可能加剧的地方。 编程代理让构建一个"足够好"的演示变得简单得令人发指，这已经是一个老生常谈的话题了。它只需几分钟，花费几乎为零。但是将那个演示转变为一个有用产品所需的迭代和时间，并没有那么简单——也没有那么便宜。你既要在这个产品化过程中花费宝贵的时间，又要消耗大量 token 来修复你在几分钟内构建的演示中没有预料到的所有 bug 和边界情况。更重要的是，当编程代理编写了大部分代码时，没有人会在它出问题时知道发生了什么。这意味着 Claude 将消耗大量 token 来排查问题。 这就是预算论证和 ROI 计算变得特别困难的地方。这是工程支出还是运营成本？其中有多少是预期的，又有多少会随时间推移而提高稳定性？你如何计算人类在这个问题上花费的时间，而不是花在其他问题上的时间？对一件并非你核心专长的软件，正确地估算复杂性和分配预算不可避免地会是嘈杂和不准确的——而这种不准确性会波及影响你其余的"AI 预算"。Token 成本在构建阶段看起来很小——但当你进入产品化、维护和新功能阶段时，token 和薪资的数学计算就会变得很难证明其合理性。 ## 3、优先排序比以往任何时候都更重要 我们注意到工程团队越来越容易分心——几周前我们[分享过一个轶事](https://frontierai.substack.com/p/enterprise-ais-teenage-years)，讲述了一个工程团队在各种可能的解决方案之间跳来跳去。在某种程度上，这是可以理解的，因为工程团队现在确实几乎可以做任何事情。但运行大量最终收效甚微的实验（尤其是当有现成解决方案可用时）是一种昂贵的分心。这再次推高了 token 成本——那些价值存疑的预算实验不应该与真正能帮助团队的系统混为一谈。 这也许乍一看是一个更微妙的挑战。每一个没有经过深思熟虑的潜在实验，都可能从 5 美元的起点迅速变成 1,000 美元的无底洞。我们自己就经历过这种情况。虽然我们不主张为了控制预算而关闭所有代理的使用，但清楚你在试图完成什么——以及这与你的 token 使用有何关联——是至关重要的。给团队留出实验的空间是有价值的，但这与直接为业务增加价值是两回事。把两者混为一谈会导致关于"AI"的错误决策。 ## 4、AI 不是预算中的一个条目 整个对话背后的问题是 AI 工具的预算应该是多少，这是一个字面意义上的百万美元级别的问题。我们看到了相当广泛的方法——完全没有限制（这正在迅速成为过去式），一切都归工程部门，或者每个组织一个 AI 预算。但在所有这些情况下，AI 都被当作预算中的一个条目——这是错误的方法。 这不是一个关于 AI 是否会继续存在的问题，而是关于我们如何思考 AI 所增加的价值的问题。AI 在推动直接影响你收入的产品功能方面所增加的价值，与你在实验重建第三方工具时它所增加的价值截然不同——也不同于它在撰写冷邮件文案时所增加的价值。把所有这些都当作"AI 支出"是误导性的。不同的代理将以不同的方式增加不同数量的价值。 这也不意味着你应该把每一个 AI 代理都当作能立即产生可衡量 ROI 的工具来对待——你绝对应该分配预算来实验那些*可能*增加价值（也可能不会）的东西。这个数字有多大以及它的计量有多严格，可能因企业而异。但无论哪种方式，把所有 AI 支出放在一个篮子里，然后把那个数字推到最高或者匆忙地压到最低，都是灾难的根源。 --- 原文链接：[AI is not a line item](https://frontierai.substack.com/p/ai-is-not-a-line-item) 汇智网翻译整理，转载请标明出处