Uber AI 预算超支暴露采用与回报之间的鸿沟

据报道，Uber 到 4 月便耗尽了其 2026 年 AI 预算，暴露出鼓励员工使用 AI 与控制这种采用成本之间的矛盾。Uber AI 预算事件如今成为更广泛企业讨论的焦点：使用量增加何时能证明生产力提升，而不只是支出增加？

Business Standard 在 11 月 8 日重新审视了这一矛盾，称企业正转向支出控制、更小型的模型，以及更具选择性的任务分配。Bloomberg 早在 6 月便报道了 Uber 的使用上限。因此，眼下的问题是正在展开的支出调整，而非一项刚刚宣布的公司政策。

对企业采购方而言，核心博弈在于采用目标与可衡量的业务回报之间。Anthropic 的 Claude Code 正处于这一矛盾的中心。一款编程助手可能在采购方尚未确定额外支出是否带来更快发布、更优软件或减少其他工作之前，就已广受欢迎。

Uber AI 预算事件已从采用转向问责

Bloomberg 于 6 月 2 日报道，在年初超出预算后，Uber 推出了 AI 使用上限。该报道特别提到包括 Claude Code 在内的工具。

这为支出问题确立了更早的公开记录，也将最初的公司动态与 11 月更广泛的讨论区分开来。读者不应将最新报道解读为 Uber 本周又实施了一轮限制的证据。

Business Standard 在 11 月的报道中，将 Uber 与其他重新评估企业 AI 成本的公司并列。其报道描述了市场对更小型模型及在模型之间分配工作的系统日益增长的兴趣。

已有记录的变化是：在采用速度超过最初支出假设之后，企业开始转向控制消耗。

公开报道并未完整交代 Uber 的内部经济状况。它无法证明原始预算是否充足、涵盖了每一项支出，或已完成工作的全部价值。

这些缺失的信息很重要。预算耗尽可能反映浪费、出乎意料地有用的软件、不切实际的预测，或几种因素的组合。仅凭超支本身，无法区分这些解释。

预算也是在实际需求明朗前作出的组织决策。员工发现有价值的应用场景，可能令支出超出保守预测，但这并不意味着他们作出了不经济的选择。

反过来，广泛的热情也无法证明额外支出能够获得回报。用户可能偏爱某个工具，却忽略审查时间、集成工作，或同事必须解决的错误。

这让管理层面临一个比员工是否喜欢软件更棘手的问题。真正相关的问题是，其收益是否超过完整的运营负担。

这种负担不止于生成答案。一项拟议的代码变更仍需审查、测试、集成和维护。只有后续阶段能够保留这种收益，更快的起草才能改善交付效率。

因此，相关报道支持对支出治理进行审视，而非判定编程助手已经失败。它也挑战了“采用本身已足以证明成功”的假设。

当领导层在部门获得明确支出责任之前便鼓励试验时，这一区别尤其重要。单个决策可能看似合理，但其合计成本可能超出预期。

设想一个说明性的工程团队案例：团队正在调查一个棘手缺陷。多名开发者可能各自要求助手检查同一代码仓库并提出解决方案。每次请求都有合理目的。

但公司仍需知道，这些重叠的调查是否产生了不同的价值。统计活跃用户只能显示参与情况，却会遗漏重复劳动。

这正是 Uber 案例凸显的问责缺口。采购决策与生产力判断无法无限期地彼此割裂。

财务团队接手了使用仪表盘无法回答的问题

支出压力并不局限于一家科技公司。FinOps Foundation 的 2026 年行业调查显示，98% 的受访者如今都在管理 AI 支出，而两年前这一比例为 31%。

FinOps 是将技术支出与业务责任和价值联系起来的实践。其不断扩大的 AI 职责表明，这类成本越来越需要财务与工程团队协同管理。

该调查覆盖了 FinOps 社群中的 1,192 名受访者。这是一个有意义的从业者样本，但并不代表每一家企业，也不能证明普遍存在财务困境。

调查结果还反映出强劲的 AI 投资，以及组织寻求优化节省以资助进一步采用的情况。因此，财务审视可能支持扩张，而非意味着收缩。

眼下的压力落在必须解释支出及其所购买业务成果的领导者身上。

工程经理面临相互竞争的指令。他们需要员工发现有价值的应用场景，却必须避免将无限制试验视作一种运营模式。

财务领导者面临不同的信息问题。账单会显示支出，却很少说明助手究竟消除了工作、转移了工作，还是创造了额外义务。

采购团队必须根据不确定的需求评估商业承诺。一份合同可以让购买使用量变得更容易，却无法让衡量由此产生的工作变得更容易。

当预算限制打断有价值的活动时，产品领导者将承担后果。突然出现的支出上限可能会在项目进行到一半时改变交付假设。

这些压力汇聚于“每项被接受成果的成本”，即产出达到预期标准所关联的全部费用。这一标准必须包含质量。

对于软件团队而言，被接受的成果可能是一项经过审查、上线后未引发额外缺陷的变更。生成的代码只是中间产物。

对于客户支持业务而言，被接受的成果可能是一项被正确解决的请求。一段流畅却引发再次联系的回复，并不能提供同等价值。

对于知识工作者而言，有用的成果可能是一份附有可追溯证据的准确简报。一份需要大量核验的快速草稿，代表的是不同的经济命题。

这些例子说明了为什么通用的使用目标会带来问题。不同任务有不同的风险、审查要求和弥补错误的机会。

一个减少支出却增加人工修正的部门，未必改善了其经济效益。它只是将成本转移到了一个更不显眼的类别。

反之亦然。当更高的模型支出消除了先前消耗稀缺员工注意力的瓶颈时，它可能是合理的。

这使归因成为企业讨论的核心。企业需要将消耗与对此负责的团队、工作流程和结果关联起来。

归因不意味着要将每位员工的每次请求都视为财务例外。过度的审批摩擦可能消耗软件原本承诺节省的同样工作时间。

更大的变化在于责任何时进入流程。在使用量演变成会计意外之前，支出假设越来越需要成为产品和工程决策的一部分。

这正是企业 AI 治理不能止步于仪表盘的原因。可见性能够指出资金流向；评估工作本身才能确定这些钱是否花得其所。

模型路由改变了经济性，但也增加了一层决策

11 月的报道指向模型编排，即协调工作流程中模型与工具的控制系统。模型路由则决定由哪个模型处理特定任务。

这一区别很重要，因为组织并不总是需要在每一步使用同等能力。文档分类与解决复杂例外情况，对能力有不同要求。

较小的模型或许足以处理范围明确的分类任务。涉及歧义或复杂推理时，能力更强的模型可能仍不可或缺。

选择性使用模型为预算压力提供了一个合理回应，但其价值取决于完整的工作流程。

这改变了 Anthropic、Microsoft 和 Google 等供应商之间的比较方式。企业采购方必须评估每项服务适合置于何处，而非为所有活动选择同一个模型。

这并不能确立这些公司之间的通用排名。真正相关的比较取决于采购方的实际工作负载、集成要求和对错误的容忍度。

一个在独立评估中表现良好的模型，仍可能在业务流程中制造问题。其输出可能需要更多审查，或交付速度过慢。

路由本身也引入判断。系统必须决定哪些请求足够简单，可以走要求较低的路径，哪些则需要更强的能力。

错误分配可能抹去预期节省。发送给能力不足模型的复杂请求，可能需要重复处理、升级，或人工修复。

过度谨慎的分配则存在相反问题。将常规工作交给资源消耗最高的选项，虽然保留了能力，却削弱了路由在财务上的合理性。

因此，经济问题并不止于为首次请求选择的模型，还包括该选择失败后会发生什么。

一个说明性的文档工作流程可以让这种权衡更具体。系统可能先识别文档类型，然后提取信息，最后标记含糊段落供审查。

只有早期步骤能够可靠地识别自身局限性时，这种安排才有帮助。一个未被注意到的分类错误，可能污染后续的所有环节。

组织也会承担维护工作。提示词、评估示例、升级规则和模型行为都可能随时间改变。

这些义务是与更简单部署方案进行比较的一部分。复杂系统不会仅仅因为单次请求看上去更便宜，就自动变得经济。

这正是上下文与知识工作相关的地方。上下文是模型为理解并完成请求而接收的信息。

发送无关材料可能加重工作流程负担，却不改善结果。发送的信息过少，则可能迫使员工重复解释或纠正误解。

同样的实际问题也出现在可搜索知识库中。找到正确的源材料与生成答案，是工作的不同部分。

这种关联并不能证明任何特定产品能够节省成本。它说明了为什么采购方应将信息检索与模型选择一并考察。

因此，Uber AI 预算之争超出了支出上限本身。它提出了一个设计问题：哪些工作值得投入额外算力，哪些不值得？

Agents 可以同时扩展能力与消耗

AI agent 是一种反复使用模型和工具来完成任务的系统。这种重复活动改变了请求与消耗之间的关系。

一次聊天交互可能在给出答案后结束。Agent 则可以检查文件、运行验证、重新考虑方法，并在返回结果前继续工作。

Anthropic 在其 2025 年 6 月对 multi-agent research system 的说明中明确指出了这种权衡。该公司报告称，在自身评估中，token 消耗增加的同时，性能也有所提升。

Token 是模型处理或生成的文本单位。Anthropic 表示，其 agents 通常消耗的 token 数量约为聊天交互的四倍。

该公司的数据表明，其协调多个 agents 的 multi-agent systems 消耗的 token 数量约为 15 倍。这些数字描述的是其研究系统。

它们并不是 Claude Code、所有 agent 产品或当前企业部署的通用衡量标准。将其直接套用于 Uber，会夸大证据所能支持的结论。

更强大的自动化可能需要更多计算，因此，更低的消耗并不必然是正确目标。

Anthropic 的说明支持一个更狭窄的结论：某些架构会有意投入更多资源来完成更困难的工作。其经济合理性取决于最终创造的价值。

这为预算超支叙事提供了有益的平衡视角。当系统能够完成更简单的软件无法处理的工作时，公司理性地提高消耗是可能的。

难点在于区分有效的持续执行与无效的重复操作。二者都可能产生很长的活动记录和高额账单。

一个示例性的编程 agent 可能会在提出修复方案后运行测试，发现另一项故障后再调整方法。这些额外工作可以避免不完整的修改。

另一个 agent 则可能反复修改代码，却始终没有识别根本问题。看似相近的活动，可能产生截然不同的结果。

当多个 agents 并发运行时，这一区分会更加困难。并行工作可以缩短实际耗时，却会增加总消耗。

因此，管理者需要区分员工投入的注意力与机器活动。系统运行得更久，并不意味着开发者在整个期间都被占用。

同样，员工表面上的时间节省也未必涵盖转移给其他团队的审查工作。工作流程的两端都很重要。

这让聊天助手、编程 agents 与协同 agent 系统之间的简单比较变得复杂。在表面上类似的用户请求下，它们可能完成了不同数量的工作。

商业案例必须明确说明发生了什么变化。系统是完成了此前不切实际的分析、减少了员工瓶颈，还是仅仅生成了更多材料？

质量也应纳入评估。当一次成本更高的运行避免了会产生重大下游后果的错误时，它可能更可取。

承认这些益处与审查账单之间并不矛盾。真正的矛盾出现在组织一方面要求雄心勃勃的自动化，另一方面却按照员工只交换简短消息的方式进行预算。

预算预测必须反映产品实际执行的工作。否则，成功采用本身就可能触发紧急限制。

生产力证据难以得出简单结论

对支出上限最有力的反对意见很直接：它们可能在抑制浪费的同时，也压制有用的工作。没有支持性证据，限制措施无法区分二者。

对无限制支出的最有力反对意见同样直接：员工的主观感受可能与可测量的结果不同。满意度与生产力相关，但回答的是不同的问题。

独立 AI 评估机构 METR 在一项使用 2025 年初工具的研究中说明了这种区别。当允许使用 AI 辅助时，参与研究的资深开源开发者完成任务的时间增加了 19%。

该研究涉及 16 名开发者和 246 项任务。其狭窄的研究场景很重要，包括参与者对既有项目的熟悉程度，以及当时可用的工具。

这并不能证明当前的编程助手会拖慢每一位开发者。将较早的结果视作当下普遍适用的结论，会歪曲这项研究。

METR 在 2026 年 2 月 24 日发布的 productivity measurement update 又增加了一项复杂因素。研究人员称，后续实验数据对当前生产力影响给出了不可靠的估计。

一些开发者因不想在没有 AI 的情况下工作而避免参与。参与者也保留了某些任务，造成了选择偏差问题。

METR 认为开发者获得的收益可能比以前更大，但强调其规模仍不确定。这正是测量挑战的证据。

无论使用量增长还是预算超支，都不能判定 AI 是否创造了净价值。

这种不确定性直接影响对 Uber AI 预算事件的解读。公开记录支持存在支出控制问题，但没有提供完整的生产力收支表。

可信的评估需要审视可比工作，包括完成工作所需的时间和质量要求。被挑选出来的成功案例无法提供这种比较。

被挑选出来的失败案例同样无法提供。棘手事件可以暴露弱点，却很难说明其在全公司范围内的平均影响。

任务选择也是另一个障碍。员工往往会为预期 AI 能提供帮助的工作选择使用 AI，因此与未使用 AI 的工作进行比较会更加困难。

随着工具进步，工作本身也会改变。团队可能会尝试更具雄心的项目，而不是更快完成完全相同的项目。

这可以创造价值，却不会明显减少每项任务所需的工时。它也可能掩盖更高的雄心是否带来了有用结果。

个人收益与组织收益之间的差异带来更多不确定性。开发者可以更快推进工作，但共享审查能力可能成为新的瓶颈。

例如，更多拟议修改可能会增加高级审查人员面对的队列。公司随后需要评估整体交付，而不能只看起草速度。

这些是分析上的可能性，并非关于 Uber 的已报道发现。它们说明，消耗数据不能代替对软件交付的评估。

怀疑态度应同时适用于财务控制和供应商的主张。更低的账单并不能证明一项政策提高了生产力。

限制措施同样应根据结果接受评估，正如扩张措施一样。否则，企业可能只是用支出目标替代采用目标，并重复同样的测量错误。

三项信号将显示支出纪律是否改善结果

下一阶段应通过可观察到的变化来评判，而不是再进行一轮关于 AI 转型的笼统论断。有三项信号尤其值得关注。

第一项是雇主是否将支出政策与交付成果联系起来。当对限制措施的公开说明同时涉及质量、已完成工作和员工能力时，它会更有价值。

如果一家公司在减少不必要消耗后仍展现出稳定或改善的交付表现，将增强选择性控制的合理性。仅仅支出下降，仍会让生产力问题悬而未决。

反之，若有证据表明限制措施延误了有价值的项目，则会削弱无差别上限的合理性。政策的实际影响比表面上的严格程度更重要。

第二项信号是供应商如何打包和治理 agent 活动。买方应关注那些能将消耗归因于具体任务和工作流程的产品更新。

对重复操作、升级处理和任务完成情况提供更清晰的控制，将帮助企业理解自己购买的是什么。其价值仍需在实际工作中验证。

供应商关于效率的主张应区分资源使用减少与能力下降。一个完成工作更少的系统，并不一定变得更高效。

第三项信号是关于已完成工作的更强证据。包含审查、修正和下游质量的评估，将弥补使用情况仪表板未能解决的缺口。

在可比任务上的重复观察将增强信心。若结果仅限于生成内容或员工感受，当前的大部分不确定性仍会保留。

下一项有意义的发展，是更清楚地建立消耗与被接受工作的联系，而不只是进一步提高采用率。

未来几个月里，这些信号提供了一种更扎实的方式来评估企业 AI 预算控制。它们也为不同部门可能得出的不同结论留出了空间。

编程团队、研究小组和支持运营不必得出相同结论。它们的任务、错误成本和自动化机会各不相同。

因此，企业买方不应将另一家公司的支出决策当成现成答案。Uber 的经历指出了一个问题，而每个组织仍需自行调查。

这同样适用于供应商。预算审查可以奖励那些更容易证明其益处的产品，即使这些产品需要大量计算。

它也可能暴露那些表面上的成功依赖于衡量活动而非结果的部署。随着基于 agent 的工作流程承担更多责任，这一区别将变得重要。

企业内部下一场有价值的讨论，应让预算负责人和对完成工作负责的人参与其中。先从一个输出可以被评估的工作流程开始。询问员工完成了什么、哪些内容需要修正，以及 AI 进入流程后发生了什么变化。比较所需的全部投入，包括审查和后续工作。当证据仍不完整时，应保持问题开放。Uber AI 预算事件提供了要求这种核算的理由，但不预设答案必须倾向于扩张或限制。在将另一个采用里程碑视为业务成果之前，不妨提出一个更具体的问题：有哪些有用工作达到了可接受的标准，组织为此付出了多少成本？