a16z 合伙人 Tugce Erten 和 Sarah Wang 最近提出的观点非常直接： “You are not a model. Don’t price per token.”
a16z 合伙人 Tugce Erten 和 Sarah Wang 最近提出的观点非常直接：“You are not a model. Don’t price per token.”
我认为，这句话讨论的不只是定价技巧，而是 AI 应用公司能否建立自己的价值捕获层。
你卖哪一层，就在哪一层定价
模型公司卖的是推理能力。输入和输出多少 Token，大体对应消耗多少计算资源，因此按 Token 收费很合理。
但 AI 应用已经不只是模型调用。一个成熟的 Agent，可能要连接企业数据、搜索系统、第三方 API 和内部工具，经过多轮推理、执行、检查和重试，最后交付一项可以直接使用的工作。
客户购买的不是几百万 Token，而是一份客户研究报告、一项已经测试通过的代码修改、一条跑通的数据管道，或者一个得到解决的客服问题。
所以，定价首先要回答的不是“用了多少算力”，而是“卖给客户的究竟是哪一层价值”。模型卖推理，应用卖工作；如果商业结果清晰可量化、可归因，还可以进一步卖结果。
Token 不只是计量单位，也是价值锚
应用公司按 Token 收费，最大的风险不是计费复杂，而是主动把自己定义成模型 API 的加价代理商。
一旦客户接受了这个价值锚，就会自然追问：为什么不用更便宜的模型？为什么你的 Token 比模型 API 贵？我自己调用是否更划算？
此时，企业真正投入的数据、工作流、工具集成、产品体验、可靠性和自动化能力，都会被压缩成“模型成本加价”。模型降价后，客户也会要求产品同步降价。
技术进步带来的效率红利，本来可能沉淀为应用公司的利润，最后却变成了价格折扣。
这正是定价的战略意义：它决定客户如何理解产品，也决定模型越来越便宜之后，利润由谁获得。
最难的是从“模型”到“结果”的中间层
模型和商业结果两端都比较容易理解。模型可以按 Token 收费；能够明确创造结果的产品，可以按已解决的咨询、合格销售会议或处理完成的理赔收费。
多数 AI 应用现在处于中间层：它们已经在交付工作，却还不能证明最终商业结果完全由自己创造。
这一阶段没有适用于所有产品的统一计价单位。真正要找的是：客户能够理解、供应商能够稳定测量的价值单位。
语音 AI 可以从通话分钟走向已解决会话，Coding Agent 可以从席位走向已完成任务，销售 Agent 可以从使用权限走向合格线索或预约会议。价格单位应该随着产品价值所在的层级移动。
企业讨厌的不是按量收费，而是无法预测
素材引用的一项 a16z 调查显示，在 50 位技术型 AI 买家中，27 人更偏好与可识别工作绑定的 Credits，14 人更偏好 Token。
这个结果并不说明企业拒绝 Usage Pricing。企业真正难以接受的，是无法理解和预算的用量。
业务负责人能估计每月要处理多少客户咨询、合同或数据任务，却很难预判每项任务需要多少上下文、几轮推理、多少次检索和重试。
如果要求客户用 Token 编预算，就是把产品内部的技术复杂度转移给客户。好的软件应当吸收复杂度，而不是让客户承担一份额外的计算成本管理工作。
Token、模型调用和任务成本仍然可以向客户透明，用于报告、预算和 FinOps。但透明不等于必须把它们设为收费单位。客户可以看见成本，却应当按照价值购买产品。
Credit 不能只是 Token 改名
把“1 Credit”定义成固定数量的 Token，并没有改变价值锚，只是换了一个名字。
真正有效的 Credit 应该对应客户能够识别的工作，例如一次简单 Bug 修复、一次完整合同审查或一份客户研究。后台调用几个模型、用了多少上下文，应当是供应商自己的成本管理问题。
一个可用的 Credit 体系至少要做到三点：隐藏基础设施复杂度，解释不同任务的相对成本，并让同一个 Credit Pool 覆盖多种工作。
最直接的检验方法是：客户能否用几句话说明一个 Credit 买到了什么。如果解释不清，说明它还不是价值单位。
Clay 的启发是拆开不同的成本结构
Clay 早期以数据 enrichment 为主，用 Data Credits 计价顺理成章。随着产品扩展到工作流编排、AI research 和自动化，价值开始更多来自平台完成的工作，原有定价就出现了错位。
它后来的调整，把第三方数据成本与平台工作拆开：Data Credits 对应数据，Actions 对应 enrichment、AI tasks、API 调用和工具编排。成本稳定的模型可以包含在固定价格中；昂贵且波动较大的 reasoning models，则按实际 Token 成本传递。
我认为这个案例最值得借鉴的，不是某个具体比例，而是一个原则：不同的成本结构，没有必要强行塞进同一个计价单位。
正常使用应当足够从容，避免客户因为害怕超量而不敢使用；高强度、成本明显更高的使用，则需要单独计量。这样既保持体验，也保护毛利。
定价必须同时管理价值和成本
传统 SaaS 增加一些使用量，服务器成本未必明显变化。AI Agent 每增加一批任务，却可能同时增加模型推理、搜索、第三方数据、工具调用、重试和人工审核成本。
因此，AI 公司既要问客户愿意为一项工作付多少钱，也要知道完成这项工作要花多少钱。
Credit 可以把两者分开：客户价值决定一个 Credit 值多少钱，任务成本决定完成任务消耗多少 Credits。二者相关，但不应机械绑定。
当模型路由、缓存、Prompt 优化和基础设施改进降低成本时，如果客户购买的是工作，效率提升就能沉淀为毛利；如果客户购买的是 Token，降本很容易被要求同步让价。
一家 AI 应用公司的经营杠杆，恰恰来自客户价值与底层成本的解耦。
Outcome 是方向，但不能跳过归因
Credit 更像从“卖计算”走向“卖结果”的过渡阶段。只有当产品能够稳定证明自己创造了某项商业结果，才适合采用 Outcome Pricing。
客服 Agent 可以按已解决问题收费，销售 Agent 可以按合格会议收费，保险 AI 可以按已处理理赔收费。但结果定价的前提是归因清楚。
如果一个销售机会来自多方协作，或者客户问题本来就可能自行解决，强行按结果收费只会制造争议。
更现实的顺序是：结果能够清晰归因，就卖结果；结果暂时不能归因，就卖完成的工作；工作也难以抽象时，再退回可理解的使用量。
AI 定价最终会是组合，而不是单选题
未来的 AI 产品很可能同时使用多种方式：Seat 卖访问权限，Credits 卖标准工作，Token pass-through 承接昂贵且不可预测的计算，Outcome fee 分享能够明确归因的商业结果。
多种计价单位并不是问题。真正的问题，是把计价单位放错了产品层级。
从 SaaS 到 Copilot，再到 Agent，软件出售的东西正在从使用权变成生产力，进一步变成已经完成的工作。Token 仍然重要，但它更适合留在基础设施、成本核算和运营管理层。
对 AI 应用公司而言，真正的护城河不只在模型、数据和工作流里，也可能藏在定价中。谁能准确地定义、计量并呈现自己替客户完成的工作，谁才有机会掌握 AI 应用时代的定价权。