AI Product Growth 101｜06｜Monetization：按什么收费，决定你做什么产品
AI 产品有一个直接成本：每次运行模型、检索数据、调用工具和执行任务，都要花钱。
于是很多团队自然地按 Token 或次数收费。
这对控制成本很方便，却不一定符合用户感受到的价值。
用户不想购买一百万 Token。
用户想完成一百份候选人筛选、解决五百张工单，或者让每位工程师每周少花三小时处理重复工作。
收费单位选错，产品和用户就会朝相反方向努力。
Intercom 的 Fin 是一个值得拆解的现成案例。截至 2026 年 7 月，它不是按模型调用收费，而是按 outcome 收费：一次客服问题解决、流程交接或销售线索淘汰为 0.99 美元，一次合格销售线索为 9.99 美元；失败尝试和部分升级不收费。这里最值得看的不是价格，而是它必须公开解释什么叫“解决”、用户回来追问时是否撤销计费、怎样区分成功交接与失败升级。按结果收费，首先是一项结果定义工程。
四种常见收费单位
Seat：按用户收费
Seat 适合每个用户都需要持续进入产品、协作和做判断的场景。
它简单、可预测，也符合企业软件采购习惯。
但当 Agent 替用户执行更多工作时，价值可能上升，活跃 Seat 却下降。产品越自动化，收入反而越受限。
Usage：按用量收费
调用次数、生成分钟、处理文档数和 Token 都属于用量计费。
它让收入和成本一起增长，适合开发者工具或基础设施。
问题是用户很难预测账单，也会为了省额度减少探索。更糟的是，系统低效地多跑几次，平台反而多赚钱。
Workflow：按任务收费
按完成的工单、分析的合同、生成的视频或执行的流程收费，比 Token 更接近用户语言。
任务单位容易理解，也方便团队把内部成本打包。
前提是任务边界清楚，不同任务的复杂度差异不能太大。
Outcome：按结果收费
按解决的问题、追回的收入、节省的成本或合格线索收费，最接近价值。
它也最难。
归因可能有争议，结果出现得更晚，外部因素很多，而且产品要承担更大风险。
不是所有产品都适合直接按结果收费。
选择 Value Metric
好的收费单位至少满足四个条件：
- 用户能在预算前理解它。
- 使用越多，用户获得的价值通常越大。
- 团队能够可靠测量，争议较少。
- 收入增长速度不会长期落后于服务成本。
可以把它写成一个简单检查：
收费单位是否同时连接了用户价值和产品成本？
只连接成本，产品会像云账单。
只连接价值，却无法测量，销售和财务会陷入争议。
经常需要混合定价
许多 AI 产品最终会采用两部分结构：
Platform Fee + Included Usage + Overage
基础费用覆盖工作空间、权限、集成、管理和支持。
包含用量让用户可以放心形成习惯。
超额费用保护高强度使用时的经济性。
如果任务价值差异大，还可以按工作流分层，而不是让所有调用共享一个模糊额度。
定价页应该使用用户理解的单位，同时在后台持续换算成推理和服务成本。
先算每个有效结果的成本
只看单次调用成本会误导团队。
一次便宜生成如果被用户丢弃，成本全部浪费。
一次更贵运行如果直接完成高价值任务，可能更经济。
更有用的指标是：
Cost per Accepted Outcome = 总服务成本 / 被用户接受的结果数
总服务成本不只包括模型 Token。
还包括检索、第三方工具、重试、人工审核、客户支持和失败补偿。
这个指标会把质量、可靠性和毛利放进同一张表。
不要用限额掩盖产品问题
当成本过高时，团队容易先收紧额度。
但成本高可能来自糟糕的任务设计：上下文反复上传、失败后盲目重试、每一步都调用最贵模型、结果不容易验收导致多次重新生成。
先优化工作流，再优化模型路由，最后才决定怎样调整价格和额度。
否则用户会为系统的低效买单。
小结
定价不是产品完成后的包装。
按 Seat 收费，你会优化协作和账户扩张。
按调用收费，你会优化使用量和成本。
按任务收费，你会优化流程完成。
按结果收费，你会被迫真正理解价值。
选择什么单位，就是选择团队每天看向哪里。
下一篇，我们讨论增长：当内容生成越来越便宜，真正稀缺的不再是“多生产内容”，而是让产品本身进入一张可信的分发网络。