AI 应用怎么收费，客户才知道自己买到了什么？

客户想知道审查一份合同要多少钱，供应商却告诉他：取决于模型用了多少 token。

这个答案对工程团队有用，对采购却未必有用。合同长短、上下文、重试次数都会影响消耗，而客户购买的是一份可以使用的审查结果。

a16z 的 Tugce Erten 和 Sarah Wang 在《You are not a model. Don’t price per token.》中建议，把计价单位放到产品实际交付的价值层。理解这一点，需要把供应商的成本和客户的购买理由放在一起看。

Token 能解释成本，客户还需要理解工作 #

Token 适合计量模型输入和输出。直接购买模型访问的人，通常也需要控制这部分用量。

应用往往还做了资料检索、工具调用、流程编排与结果检查。以一个假想的合同审查产品为例，模型费用只是交付成本的一部分，客户还关心是否漏掉条款、出处是否正确、建议能否用于下一步谈判。

如果账单随着内部重试次数增加，客户可能会问：为什么系统多试了几次，也需要我多付钱？这说明计价单位同时在分配责任。

Credits 好用的前提，是有清楚的含义 #

原文调查的 50 位技术型 AI 买家中，27 人偏好与可识别工作绑定的 credits，14 人偏好 token。这个小样本提供了一个线索，不能推广为所有企业的偏好。

Credits 可以把不同复杂度的任务放进同一个预算单位。但它需要说明对应什么工作。审查短合同需要多少额度，大型资料包怎样估算，系统失败是否退还，执行中超出预估怎么办？

若这些规则不清楚，把 token 改名成 credits 并不会让客户更容易做预算。相反，稳定的任务定义和价格表，才让采购能够比较几家产品，也让团队能够追踪各部门的使用。

按结果收费，需要先定义结果 #

Outcome 定价听起来直接：问题解决了才收费。难点在于，哪些状态可以算解决？

以客服为例，用户暂时没有继续追问，可能是满意，也可能只是离开了。一周后重新打开工单，这次应不应该收费？如果助手只是把问题交给人工，结果应该怎样归因？

这些都需要提前约定。质量门槛、观察窗口、返工规则和争议处理，会影响产品承诺，也会影响供应商挑选什么任务来做。

一个更容易验收的交付物，有时比一个难以归因的宏大结果更适合作为早期计价基础。例如先对完成且通过审核的风险清单收费，积累证据后，再讨论是否承诺更深的业务结果。

价格还要经得住昂贵的任务 #

客户希望支出稳定，供应商却面对变化的交付成本。少数复杂任务可能需要很多重试、第三方数据或人工审核。

因此，平均毛利之外，还要看成本最高的那部分任务。一个套餐整体看来盈利，也可能被少数使用方式拖累。

解决办法可以包括任务规模边界、昂贵服务单列费用，以及执行前的超额确认。原文也保留 token 透传等混合方式的空间，并非绝对禁止 token。关键是让客户明白，哪些费用买的是服务，哪些费用来自可变资源。

好的账单，是工作结果的另一种表达 #

对于 AI 应用，计价设计会倒逼产品说清楚自己的价值。

如果很难描述“这一笔钱买到了什么”，任务定义或验收机制可能也还不成熟。反过来，一份能对应输入、完成工作、验收结果和费用的记录，有助于客户评估续费，也能帮助供应商定位失败成本。

选择 token、credits 还是 outcome，最终都应回到一个具体问题：客户能否预先理解支出，事后确认交付，并在发生问题时知道责任如何处理？计价单位只是这份约定的表达方式。

---

本文结合 Tugce Erten、Sarah Wang 于 2026 年 8 月 27 日发布的 a16z 原文 展开讲解。合同与客服场景为假设；调查未公开完整抽样方法，也不能据偏好推出具体购买意愿。