按账号收费，正在失去原来的价值锚点
传统 SaaS 按账号收费，是因为用户数量与软件价值大体相关。更多员工使用，通常意味着更大的业务覆盖面，也意味着供应商要提供更多权限、存储、协作和服务能力。
AI 改变了这一关系。
一个财务人员可能只拥有一个账号，却让 Agent 连续核对数千张发票；一名销售经理可能不频繁登录系统，但后台 Agent 每天都在筛选线索、补充客户信息并准备跟进建议。相反，另一位员工虽然每天打开 AI 工具，却只做少量简单问答。
此时，账号数量既不能准确代表供应商的交付成本，也不能代表客户获得的业务价值。
单纯把 AI 放进更贵的订阅档位同样存在问题。如果 AI 只是若干附加功能之一，客户很难判断额外费用买到了什么；供应商也容易陷入“功能不断增加、实际使用有限”的循环。BCG 在 2026 年关于 AI 与软件未来的报告中指出，把 AI 免费附送或仅打包进传统套餐，往往说明它对客户价值主张只是增量改善，而非真正的产品转型。
于是，AI 产品开始转向使用量计费。但从按账号直接跳到按 Token，并没有自动解决商业问题。
Token 是成本单位，不是客户价值单位
Token 能够描述模型处理了多少文本，是核算推理成本的重要基础，却很少是客户真正关心的结果。
同样完成一份供应商风险摘要，一个系统可能消耗更多 Token，因为它检索了大量无关材料、反复调用工具或在错误路径上重试；另一个系统可能用更少成本完成更可靠的结果。如果直接把 Token 账单转交给客户，效率较差的产品反而可能收取更高费用。
而且，Agent 的消耗并不稳定。任务复杂度、输入文档长度、上下文缓存、工具调用次数、输出长度和失败重试，都会让一次工作的成本变化。OpenAI 的企业费率说明也明确提示，Workspace Agent 和办公任务的最终 Credits 会随这些因素变化。
对供应商而言，Token 是必须管理的成本；对客户而言，它更像电费明细中的千瓦时，而不是购买服务的最终目的。客户真正希望知道的是：完成了一张合格的报告、核对了一笔订单、处理了一份申请，还是推动了一次有效转化。
McKinsey 7 月发布的“AI 新经济学”专题同样提出，每 Token 价格已经不能有效反映企业实际支付的生成式 AI 成本。企业需要把系统总成本与实际获得的价值放在一起判断，而不是用单一模型单价代替商业核算。
因此，更成熟的 AI 产品会同时保留两套计量：内部按模型、Token、工具、基础设施和人工复核核算成本；外部则尽量用客户能够理解和验证的工作单位表达价值。
什么才是一个合格的“可计价工作单元”
可计价工作单元不是给调用次数换一个好听的名字。它必须接近客户业务，同时能够稳定定义、客观验证和合理归因。
例如：
一个合格单位至少要回答四个问题。
第一，完成的边界是什么。只生成初稿算不算完成？是否必须引用规定的数据源、通过规则检查、写回业务系统，才计入一次有效工作？
第二，质量门槛是什么。如果输出被人工完全重做，或者缺少关键字段，不能与一次可直接采纳的结果按相同价格计算。
第三，失败如何处理。系统主动识别证据不足并转人工，可能是一次正确服务，但不一定适合按“自动完成”收费。产品需要区分成功完成、安全退出、技术失败和无效重复。
第四，结果能否归因。从生成一封营销邮件到最终签约，中间还有品牌、渠道、销售能力、价格和客户需求等大量变量。把全部营收归功于 AI 并按成交抽成，通常既难验证，也容易产生争议。
因此，“按结果收费”并不意味着越接近最终收入越好。最实用的计价单位，往往位于 AI 可以显著影响、客户可以核验、双方又能明确责任的交界处。
- 合同 AI 的单位可以是“完成一份条款审查并输出带证据的差异清单”；
- 财务 Agent 的单位可以是“核对一笔交易并正确进入通过、异常或人工复核队列”；
- 营销产品的单位可以是“生成并通过品牌与合规检查的一组可投放素材”；
- 工业运维 AI 的单位可以是“识别一次有效异常并形成可执行工单”；
- 销售 AI 的单位可以是“完成一条符合标准的线索研究与跟进准备”。
不要急着把所有产品都改成纯结果付费
结果付费听起来最能体现价值，但并不适用于所有场景。
如果业务结果周期很长、外部影响因素很多、数据由客户控制，供应商就很难独立承担结果责任。企业战略分析、研发辅助、管理决策和品牌内容，通常都不适合简单按最终收益计价。
BCG 的判断也较为谨慎：尽管结果计费受到关注，对多数 AI 应用而言，使用量计费或账号加使用量的混合模式可能更合适。常见做法是设置基础订阅，覆盖平台、权限、集成、安全和服务成本；再按有效任务、处理量或分档 Credits 计费，并通过上限、预警和预算控制降低不可预测性。
企业可以根据产品成熟度选择不同模式：
关键不是追逐一种流行定价模式，而是让收费对象与产品能够承担的责任一致。
- AI 只是辅助功能，采用账号或套餐加合理额度；
- AI 完成清晰、重复的任务，按合格工作单元或分档处理量计费；
- AI 影响结果但不能独立归因，采用基础费用加业务绩效奖励；
- AI 能够对可验证结果承担较完整责任，再考虑纯结果付费。
定价设计会反过来塑造 AI 产品
一旦按有效工作计费，产品团队不能只追求更多调用和更长使用时间。它必须关注任务是否完整、结果能否采纳、失败是否被正确识别，以及每次成功交付的总成本。
这会带来几项实质变化。
首先，产品需要原生记录工作轨迹。输入来源、模型与工具调用、规则检查、人工修改和最终状态，必须形成可审计记录，否则双方无法确认哪些工作应当计费。
其次，评估系统会成为商业基础设施。没有稳定的质量判定，就无法区分一次“生成”与一次“合格完成”。计费模型越接近结果，供应商越需要与客户共同维护验收规则、抽样复核和争议处理机制。
再次，成本优化不能损害完成质量。模型路由、缓存和上下文压缩可以改善毛利，但每次调整都需要观察任务成功率、人工返工和客户结果。低 Token 消耗并不天然等于高效率。
最后，销售方式也要改变。销售团队不能只演示功能清单，而要与客户共同确定工作单位、当前基线、质量标准、预计处理量和责任边界。产品报价因此更接近业务方案，而不是软件席位清单。
企业 AI 的商业分水岭，是能否把能力变成可验证交付
模型能力越来越容易获得，把 AI 接进产品也不再稀奇。真正困难的是把一段概率性的技术行为，封装成客户愿意持续购买的可靠工作单位。
对 AI 供应商而言，这个单位连接产品价值、交付责任、运行成本和收入增长；对采购企业而言，它则连接预算、验收、使用和 ROI。双方如果只讨论账号数或 Token 单价，就很容易在上线后陷入两种困境：供应商认为使用量增长证明成功，客户却说不清业务究竟获得了什么；或者客户要求为最终结果付费，供应商却无法控制结果链条中的大部分变量。
下一次设计或采购 AI 产品时，可以先暂时放下模型参数和价格表，问一个更基础的问题：这套系统完成什么样的一件工作，才值得记一次账？
当这件工作有明确边界、质量标准、验证证据和责任归属，AI 才真正从一项技术能力变成可规模化交付的企业产品。
