企业
企业的 AI 转型，账单的压力往往比结果的喜报先跑到面前来。
Token 费用、API 调用、Agent 请求、软件订阅，这些数字清楚、及时，很容易被放进预算表。试点扩到更多部门以后，用量开始上涨，管理层自然会问：花了这么多钱，究竟换来了什么？
这个问题完全合理。
问题在于，很多企业还没有确定计算对象，就急着计算 ROI。最后只能盯住最容易取得的数字：用了多少 Token，有多少员工登录，节省了多少工时，能不能少招几个人，甚至能不能裁掉一部分岗位。
这些数字可以参与计算，却不能单独证明 AI 的价值。
这也不意味着企业必须等到部署完成以后，才能谈 ROI。部署前，企业完全可以，也应该建立工作流基线、商业论证、预期 ROI 和试点成功标准。部署后，再用真实运行数据验证实际成功率、周期、质量、人工介入和每次成功结果的成本，得到实际 ROI。
两者的分界很清楚：部署前计算的是基于假设的预期回报，部署后验证的是实际实现的回报。
但无论在哪个阶段，都必须先回答一个更基础的问题：企业究竟在对什么东西计算 ROI？
没有明确的工作流，ROI 就没有可靠的计算对象
AI 成本之所以容易引发焦虑，首先是因为它太显眼。
每一次模型调用都可能留下记录，Token 消耗可以按天统计，软件订阅可以按席位计费，Agent 请求也能在后台查看。财务部门很容易把这些费用归入一个新的 AI 成本科目，然后与上个月、上一季度或最初预算比较。
原有工作流中的许多成本，却没有这么清楚。
等待、返工、跨部门协调、人工查找资料、管理者注意力、外包费用，以及因为成本过高而被放弃的工作……通常分散在工资、流程、管理和机会损失里。它们一直存在，只是没有以“每次调用多少钱”的方式出现在管理层面前。
于是，AI 很容易陷入一种不对称的比较：新成本被精确记录，旧成本继续藏在组织里；工具账单按月出现，原有流程究竟发生了什么变化却没有基线。
如果 AI 只被当作一个采购工具，企业最后衡量的通常也只是“用了多少”：多少人开通账号，调用量增长多少，员工自报节省了多少时间。
这些指标能够说明采用情况，无法单独说明业务结果。
没有明确的工作流边界、基线和成功结果，ROI 就没有可靠的计算对象。测量对象需要从“AI 工具”转向“被 AI 改造的工作流”。
AI 到底改变了工作流里的哪一个节点？
AI 可以参与理解、检索、生成、判断、协调、执行和质检，但这些任务的价值完全不同。
生成一段文字，不等于完成了一项营销工作；从知识库中找到资料，不等于解决了客户问题；Agent 成功调用几个工具，也不代表业务流程已经闭环。
很多项目看起来使用频繁，只是把原来的聊天窗口换成了一个更昂贵的聊天窗口。
因此，在计算 ROI 之前，企业至少要明确五个问题：
工作流从哪里开始，在哪里结束？
AI 改变了哪些任务节点？
什么叫一次成功完成？
谁对最终结果负责？
什么情况下必须人工介入？
最关键的是第三个问题。
如果 AI 生成了答案，但员工必须全部重写，这算不算成功？如果 Agent 完成了操作，却使用了错误数据，这算不算成功？如果处理速度提高，错误和返工也随之增加，企业究竟获得了效率，还是把成本转移到了下游？
不同工作流会有不同答案。有些节点可以由 AI 独立完成，有些只能提供建议，有些涉及品牌风险、财务责任或关键决策，必须由人确认。
部署前，企业应根据原有流程建立基线，并把这些定义写进商业论证和试点标准。部署后，再通过真实数据检查结果是否完成、失败如何发生、人工是否频繁接管。
这一阶段，先把“成功结果”定义清楚。至于它值多少钱，可以放到后面再算。
架构不是技术偏好，而是工作流的成本结构
工作流确定以后，技术路线才有判断依据。
企业首先要区分两类成本问题。
第一类是用量暂时失控。员工开始大量使用 AI，Agent 请求快速增长，路由和评测机制还没有跟上，账单突然变得难看。这类问题未必说明方向错误，仍可能通过成本工程修正。
第二类就比较危险：架构路线本身就不适合目标工作流。
典型情况是把 AI 转型理解成训练一个“公司自己的通用大模型”，仿佛只有拥有底座模型，企业才算建立了 AI 能力。
已经有一些失败的案例。比如，BloombergGPT 这类领域预训练，论文给出的规模约为 130 万 A100 GPU 小时、512 张 A100、约 53 天。而与此同时，前沿模型和强开源权重仍在持续迭代，这种自建通用底座的做法，很容易变成一场“昂贵的追赶”。
对大多数企业，更稳妥的顺序是先复用强模型，通过 RAG 接入企业知识，用工具连接业务系统，把 Agent 放进明确的工作流，再由 Evaluation（评测）找出真实缺口。只有当现有方案持续无法满足要求，才考虑 Fine-tuning、PEFT 或更重的专用模型。
这不等于企业永远不应该训练模型。主权与隔离要求、边缘和低延迟环境、稳定窄域任务、超大推理规模，以及能够形成产品闭环的专有数据，都可能对自己部署形成强烈的需求。
关键不在于某条路线听起来是否先进，而在于它如何改变工作流经济性：能否提高成功率，能否控制失败重试，维护成本是否合理，模型升级后是否需要反复重建。
技术路线是否正确，最终仍要由目标工作流的效果、成本和评测来判断。
Uber 的两幕剧：用量上涨以后，怎样控制单位成本？
Uber 提供了一个很有价值的对照。
第一幕发生在 2026 年初。围绕 Claude Code 等工具的快速使用，Uber 内部出现了被称为“tokenmaxxing”的用量增长。其 CTO 对《The Information》等多家媒体表示，短时间感受到“明显的 Token 和预算压力”。
Uber 并非从一开始就找到了理想的成本模型。使用率上升以后，账单就有些受不了。
第二幕出现在几个月后。
Uber 工程博客和 Q2’26 财报准备稿中，公司自述显示：在周活跃使用者增长约 7 倍、每周 Agent 请求增长约 9.4 倍的同时，整体 AI 支出自 4 月以来相对趋稳。在模型不变的前提下，每千次请求的单位成本约下降 34%，每次会话成本约下降 52%。
Uber 采用的方法包括 Model Gateway、模型路由、评测、托管 Agent、MCP 和上下文工程。重点不在这些技术名词本身，而在于 Uber 建立了一套持续观察、分配和优化 AI 用量的能力。
这套能力让企业可以在使用继续增长时，调整不同任务的模型选择、上下文和工作方式，把单位经济变成持续工程问题。Model Gateway、路由、上下文、评测和 Agent 管理，共同构成了 AI 工作流的成本控制层。
Uber 这个案例很好地说明了：AI 大规模使用以后，用量增长未必要求成本按同样速度增长。企业可以持续工程化单位经济。
当我们将工作流和成功结果定义清楚以后，企业就有条件讨论它的经济价值了。我们将在《企业 AI ROI，为什么必须从工作流开始算？（下篇）》中继续探讨。