AI 产品的毛利，是用户一次次点出来的。
传统 SaaS 的定价有个默认前提：多服务一个用户，几乎不多花钱。所以席位制、版本制、固定订阅都能放心用，团队的精力放在获客、留存和扩张上。
生成式 AI 把这个前提拆了。上下文长度、输入输出 token、检索、工具调用、模型档位，每一项都随用户行为浮动，用得越狠，账单越厚。
所以同一份订阅，放在 AI 产品里毛利可能差得很远。第二节的算例会说明：重度用户占比从 5% 涨到 10%，就能把一个看起来 70% 的毛利率拉到 50% 左右。
很多团队进场时先问“用户愿意为 AI 多付多少钱”。这个问题要问，但不该排第一。更早要算清的是：每类用户、每种任务、每条模型路径到底花了多少钱，这笔钱会不会随用量非线性上涨，用户得到的价值和成本是不是同一个方向。
最常见的误区，是把 AI 当作传统 SaaS 的一个高级功能，在现有套餐上加个“AI Pro”或“AI 附加包”了事。市场教育初期，这招管用；等竞争加剧、模型供给变多、用户预期成熟，粗放加价就撑不住了。
所以定价不只是“按 token 收还是按订阅收”。按什么计费、用什么衡量价值、成本上限在哪、怎么升级、哪些复杂度藏在后台，要一起想。这些都是 PM 的日常决策，拖到“商业化最后一步”再补，基本来不及。
一、成本跟着使用走，价值却未必跟着成本走
传统软件也有边际成本，但很平缓。用户多点一次按钮、多导出一张表，单位服务成本几乎不动。生成式 AI 不一样：上下文一拉长、模型一换大、工具链一变长、输出一变多，一次请求的成本就成倍放大。
麻烦在于，成本放大和付费意愿常常不同步。
举个例子：用户 A 只想把一份 3 万字的合同改得通顺些，整份合同塞进上下文，一次请求的推理成本大约 ¥0.6；用户 B 用一句 50 字的提示词，让模型从一张销售表里找出流失最集中的区域，成本不到 ¥0.02，却可能帮他保住一个季度的业绩。
两者成本差 30 倍，价值方向正好相反。
难点因此叠了三层。第一层，成本是动态的，同一个功能在不同用户、不同场景下的成本结构完全不同，不能只按“功能高不高级”分层。
第二层，用量会爆发。用户一旦把 AI 接进自动化流程、批处理或团队协作，调用量可能几周内翻几倍，当初合理的固定价马上开始侵蚀毛利。
第三层，价值分布极不均匀：有人偶尔尝鲜，有人把 AI 当成核心生产工具。定价分不清这两类人，要么让重度用户付得太少，要么把轻度用户挡在门外。
代理类功能会把第二层放大。用户眼里是“一次任务”，后台可能是规划、检索、调用三个外部工具、自检、重写，一共 8 次模型调用。假设单次调用平均 ¥0.05，一次任务就是 ¥0.4；如果自检失败触发两轮重试，就变成 ¥0.5 以上。
用户付的是“一次任务”的钱，团队扛的是“十次调用”的账，而且失败重试越多，用户体验越差，成本反而越高。价值和成本在这里是反着走的。
三件事同时成立，任何单一方案都会露馅。只做订阅，盖不住高用量成本；只按量收，非技术用户望而却步；只卖附加包，底层的经济账照样没算清。成熟的团队把这些矛盾当作产品定义的一部分，不会把它们推给“以后再说”。
二、先把成本账算到每一类用户，再谈价格
竞品扫描和用户访谈都有用，但要排在成本建模后面。不少团队先照着市场流行做法定个月费，等用户量上来，才发现某一群人的用法把成本结构整个打穿。价格一旦成了市场预期，再大改就很难。
成本模型至少回答四个问题。第一，成本由哪些变量驱动：模型大小、上下文长度、输入输出 token、检索链路、缓存命中率、工具调用次数、多模态处理，还有实时性带来的资源占用。
第二，哪类任务最容易出异常。最复杂的任务反倒不常出事，出事的多是看起来价值不高、但请求长、重试多、批量跑的那类。第三，单位任务的成本是稳定的，还是长尾明显。第四，规模扩大后，哪些成本会降，哪些反而会涨。
经济建模工具的价值就在这里：它逼着团队把流量、推理负载、模型路由和长期成本曲线摆到明面上。
只看平均值是最常见的坑。来看一组数字（本文算例都是为说明结构设的假设值，不是市场报价）：一款写作工具有 1 万名付费用户，每人每月 ¥99，月收入 99 万元。平均每人推理成本 ¥30，毛利率看起来有 70%。
拆开一看，5% 的重度用户（500 人）消耗了 60% 的 token。总推理成本 30 万元里，这 500 人花掉 18 万元，人均 ¥360，是售价的 3.6 倍；其余 9500 人人均只有约 ¥12.6。重度用户每人每月亏 ¥261，靠轻度用户补贴。
只要重度用户占比从 5% 涨到 10%，总成本就升到约 47 万元，毛利率从 70% 掉到 50% 左右。
所以成本模型必须按用户、任务、工作流拆开算：轻度用户什么曲线，高频生成用户什么曲线，企业自动化用户什么曲线。
模型路由是最直接的降本杠杆，也最该写进模型。继续用这款写作工具：假设 70% 的请求是改错字、调语气这类简单任务，换成单价只有大模型十分之一的小模型，质量几乎看不出差别；剩下 30% 的长文生成仍走大模型。
混合后的单位成本变成原来的 0.7×0.1 + 0.3×1 = 0.37 倍，月推理成本从 30 万元降到约 11 万元，毛利率从 70% 升到约 89%。
代价是要维护一个路由规则和一套质量评测，一旦路由判断错，简单任务被送去大模型还好，复杂任务被送去小模型，用户就会觉得“变笨了”。所以路由上线时要同时盯两个数：成本降了多少，复杂任务的重写率涨了多少。
自建或私有部署会把成本曲线换一个形状。调 API 时，成本是纯变动的，用多少付多少；租 GPU 跑开源模型时，成本变成台阶式的固定成本。
比如一台推理服务器月租 ¥3 万，满负荷每月能处理约 1000 万次简单请求。利用率 30% 时，每次请求摊到约 ¥0.01；利用率 80% 时，降到约 ¥0.004。
省钱的前提是流量稳定到能把机器喂饱，而且团队有人能维护模型和推理服务。流量波动大、峰谷差几倍的早期产品，台阶式成本反而更危险：低谷时机器闲着照样付钱。
一个常见的做法是基线流量走自建，峰值溢出走 API。
供给侧也在动，而且两个方向都有。同等能力的推理单价这几年一直在往下走，听起来是好消息，但用户的用量往往涨得更快，新功能又会把请求推向更大的模型和更长的上下文，总成本未必自然改善。供应商调价、模型下线、被迫换到更贵的替代模型，也可能让一个今天健康的价格几个月内失衡。
能主动压成本的手段还有两类。一是缓存：系统提示和知识库很长的产品，每次请求都在重复发送同一大段输入，命中缓存的这部分计费通常远低于正常输入，省下的往往是一大块。二是批处理：夜间报表、批量摘要这类不着急的活，走异步批量接口一般比实时调用便宜。把哪些任务能缓存、哪些能走批处理标清楚，成本曲线会平很多。
成本模型也不是测一次就完。比较稳的做法是每个月用真实用量回填假设，再做几组敏感性测试：输出平均长度多三成会怎样，重度用户占比翻倍会怎样，整体换一个模型家族又会怎样。
算准是做不到的，要的是提前知道价格在哪些情景下会崩，好在额度、缓存和降级路径上留出余地。
三、按量计费最贴近成本，也最容易吓跑探索
从经济逻辑看，收费越贴近真实消耗，收入和成本越同步，所以按用量计费正在成为主流。但这不等于要把 token 单价直接摆给用户。
最直接的是按 token 收费，在以 API 为主的产品、开发者工具和技术用户集中的平台上很常见。输入、输出、总量都能计费，透明，也和底层成本高度一致。缺点同样明显：大多数非技术用户不懂 token，更不愿意每用一次都面对不确定的费用。按 token 计费更适合当后台的记账语言，不一定适合当前台的价格。
按请求收费，比如每次摘要、每张图、每份报告一个价，简单直观，适合任务边界清楚、输入规模稳定的产品。
放到大模型场景就有问题：同样是“一次摘要”，文档长度可能差几十倍。比如摘要一份 2 千字的周报，成本约 ¥0.03；摘要一份 6 万字的招股书，成本约 ¥1。
如果统一定价每次 ¥0.5，前者收入是成本的 16 倍多，后者每次亏一半。用户很快会发现长文档最划算，成本结构就被最贵的那部分用法主导。
粒度太粗，要么自己扛波动，要么靠严格限制防亏，最后伤了体验。常见的折中是按档计价：5 千字以内一个价，5 千到 3 万字一个价，再往上走企业额度。
更现实的是混合方案：后台按真实消耗管理，前台用一个好懂的单位来包装，可以是积分、算力额度、AI 点数，或者对应具体任务的消耗包。本质都是把技术复杂度藏起来，同时保留成本和用量之间的联系。
选哪种前台单位，可以先看用户是谁。用户是开发者、自己写代码调接口，直接按 token 报价最省事，他们本来就按 token 估算预算，藏起来反而显得不透明。
用户是运营、销售、法务这类非技术岗位，就用任务或积分来报价，并在界面上实时显示“本月还剩多少”。
同一家公司两类用户都有时，常见做法是双轨：API 按 token，应用按积分，两边底层用同一张成本表换算。
按量计费真正的阻力往往在心理和采购上。纯按量收费会制造“计价表焦虑”：每次调用都像在花钱，用户下意识少试，而多试恰恰是他们发现价值、形成依赖的前提。
企业客户还多一层顾虑：采购和财务更愿意为一个能写进年度预算的确定数字签字，而不是一张随团队用量起伏的账单。
这就是为什么即便按量最合经济逻辑，大多数成功的产品仍在外面包一层可预测的结构：先给一个含额度的固定价格，让用户心理上“已经付过钱”，超出部分再按量算。
四、订阅还在，只是要装进额度
订阅不会消失。它仍是个人和企业最熟悉、最好做预算、最贴合销售和采购流程的结构。要讨论的是怎么改。
过去的版本按功能分层：基础版、高级版、企业版，对应更多功能、更多权限、更大团队。到了生成式 AI，这种分层还有用，但不够了，因为成本不只看“给不给”，更看“用多少、用多深、用哪个模型”。
新订阅通常要加上 AI 用量上限、月度积分、算力预算或模型档位。订阅从功能包变成了功能包加资源包。
比较成熟的做法，是在订阅里含一定的月度 AI 额度。用户保留熟悉的价格预期，不用每次调用都想钱；企业用额度挡住高成本使用，不让固定订阅变成无底洞。
高档位再解锁更长上下文、更快推理、更强模型、多模态或行业模型，价格层级反映的就不只是功能多少，还有智能深度和资源强度。
额度定多少，不该拍脑袋。一个可用的起点是看用量分布：把含额度定在大约第 75 百分位用户的月用量附近，四分之三的用户一整月都碰不到上限，感受不到计量；剩下四分之一才进入超额区间。
超额单价再按“单位成本 × 2.5 到 3 倍”来定，覆盖成本波动和支付、客服等杂费。以后文的算例为例，每积分成本 ¥0.08，超额价 ¥0.25 大约是 3 倍。
这两个参数要每季度按真实分布重算，用户结构一变，百分位就会漂移。
订阅加超额会越来越常见：底座可预测，用户放量时按量补差，不必马上换套餐。它降低了第一次购买的门槛，用户真正放量时又能收到增量，也更容易对接企业的采购预算。
但它把一个治理难题推给了产品：超额默认自动扣费，还是先提醒、再限流？
自动扣费保住了体验的连续性，用户却可能在月底看到一张远超预期的账单，哪怕每笔都合理，信任也会受损。先限流再让用户加购，预算可控，代价是恰好在用户最依赖、价值最高的时候打断他。
可以用一条规则来定默认值：面向个人和小团队，默认限流并提醒，因为可预测比连续更重要；面向已经把产品接入关键流程的企业客户，默认在合同约定的上限内自动扣费，并在用到 80% 时通知管理员，因为突然停服造成的业务损失，往往比一张偏高的账单更难接受。
这个默认值是产品决策，不能留给计费系统随手配置。
五、积分是翻译层，也是一本负债账
很多生成式 AI 产品里，积分正在成为连接后台成本和前台体验的那一层。它把技术复杂度翻译成用户听得懂的消费语言。
积分最大的好处是灵活。它可以映射 token，也可以映射推理时长、请求数、模型档位倍数、图像生成强度，甚至不同任务的复杂度。
比如一张图消耗 50 积分，一次长文档总结消耗 30 积分，一次高级模型分析消耗 80 积分。用户不用懂背后的计算，只要知道“我还能用多少”“多用一点要多少钱”。
对企业客户，积分还天然适合加购和调配：额外积分包、季度补充包、团队共享积分池、跨产品通用钱包，或者按项目、部门调拨额度。
比席位制更能反映实际用量差异，比直接按 token 收又更容易过采购。不少 B2B AI 产品最后落在“订阅 + 积分 + 超额”的组合上。
共享积分池的好处，用一个具体团队最容易看清。一家 50 人的团队，每人一个席位、每人每月 1000 积分，合计 5 万积分。
实际用下来，10 个人每月用 3000，40 个人只用 300，合计 4.2 万。如果积分按人分配，那 10 个重度用户每人都要超额 2000，团队一个月多付 2 万积分的超额费，而另外 40 人有 2.8 万积分白白过期。
改成团队共享池，同样 5 万积分刚好够用，客户不再觉得被“罚款”，厂商少了一笔超额收入，却换来续约时最难得的一句话：账单可预期。
积分也有风险。规则太复杂，用户觉得不透明；消耗规则老在变，用户会失去信任；积分和价值脱节，它就退化成又一个看不懂的收费术语。
运营上还有两个细节直接决定积分是帮收入还是伤信任。一是过期：设过期能加快消耗、带动复购，却让“以防万一”才买的用户觉得被罚；永不过期对用户友好，却会攒出一大笔待兑现的负债。
二是映射错位：底层成本降了，积分消耗规则迟迟不调，用户迟早会算出同样的钱换到的服务在缩水；反过来，降价也要参照服务内容和同类产品的价格锚点，贸然调整同样会引发混乱。
积分体系上线后，要像一个小经济体那样定期校准。
一个“订阅 + 积分 + 超额”模型的毛利算例
假设套餐 ¥200/月，含 1000 积分，超出部分每积分 ¥0.25；后台每积分的真实推理成本约 ¥0.08。
- 轻度用户，当月用 600 积分：收入 ¥200，成本 600×¥0.08=¥48，毛利 ¥152，毛利率 76%。
- 重度用户，当月用 2000 积分（含 1000，超额 1000）：收入 = ¥200 + 1000×¥0.25 = ¥450；成本 2000×¥0.08=¥160；毛利 ¥290，毛利率约 64%。
- 若取消超额、保持纯固定 ¥200：同一个重度用户成本仍是 ¥160，毛利只剩 ¥40，毛利率 20%；用量再翻一倍（4000 积分，成本 ¥320）毛利就转负。
“固定锚点 + 超额按量”的意义就在这里：保住了价格的可预测性，又不让少数重度用户把毛利打穿。
还有两笔小账可以顺手算上。按微信支付、支付宝约 0.6% 的标准商户费率，¥450 的账单手续费约 ¥2.7，对毛利影响不大；但积分包拆得越碎、单笔越小，退款和对账的人工成本占比就越高。
另外，如果底层模型继续降价，一年后每积分成本从 ¥0.08 降到 ¥0.04，轻度用户的毛利率会升到 88%，这时是让利给用户还是留作利润，就是一个需要摆上桌面的定价决策。
积分还有一个常被忽略的会计问题：用户买了却没用掉的部分。
按照国际财务报告准则第 15 号（IFRS 15），预收款先记为合同负债，用户消耗积分时再确认收入；预计永远不会被使用的部分（行业里叫 breakage，即沉淀额度），只有在企业能可靠估计时，才可以按用户实际使用的节奏同比例确认。
“积分过期带来的利润”不能凭感觉计入当期，财务团队需要有历史数据支撑的过期率估计。
六、价值指标定天花板，高级能力是利润池
成本模型决定价格低不到哪里，价值指标决定价格能高到哪里。
只围绕成本定价能保住毛利，却常常大大低估用户愿意为结果付的钱，尤其在 AI 直接改变结果、而不只是提升效率的场景里。
价值指标回答的是“用户因为 AI 得到了什么”：处理了更多文档，自动化了更多任务，省下了时间，减少了差错，提高了转化，或者更快拿到能执行的结论。
答案清楚了，产品才有机会从按消耗收费走向按价值收费。
比较稳的原则是“成本为底，价值为顶”：先用经济模型和服务成本测出不能突破的下限，再用价值指标、付费意愿研究和价格实验去找上限。
好的价值指标要过三道关：客户能自己数得清，随客户得到的好处一起增长，团队能在系统里准确记录。
“节省的工时”听起来最贴近价值，但客户数不清，也很难对账；“处理的文档数”好记录，却和好处只是大致相关；“已解决的工单”“已签署的合同”这类结果型指标三关都能过，所以常被用来做价值定价的计费单位。
成本定价和价值定价差多远，算一笔就知道。一款客服 AI 按“已解决工单”收费。客户原来靠人工处理，每单综合成本约 ¥15；AI 每解决一单，推理加检索成本约 ¥1.2。
如果按成本加成定价，比如成本的 3 倍，每单 ¥3.6，客户省了 76%，厂商毛利率 67%。如果按价值定价，定在人工成本的三成，每单 ¥4.5，客户仍省 70%，厂商毛利率升到 73%。
差别不大的一笔单价，乘以每月几十万单，就是完全不同的公司。
前提是“已解决”有双方都认的定义，比如 48 小时内客户没有重开工单；定义含糊，按结果收费会变成每月对账吵架。
基础 AI 能力商品化得很快，利润池往往在“哪种能力只在更高档位解锁”。
第一类是更强的模型：更长上下文、更高质量推理、更快速度、多模态或行业微调模型。前提是用户真的感受得到这种差异，光写在文案里不算。
第二类是自动化深度。单轮问答的溢价空间有限，一旦 AI 能跑多步骤任务、跨系统调用、批处理或半自主的代理流程，付费意愿会明显上升，因为它开始像一个“数字员工”。
第三类在企业市场尤其关键：治理与合规。很多企业更在意的是可控和可审计，生成质量好一点反倒排在后面：审计日志、数据驻留、提示词过滤、定制评估集、SLA、专属算力池、访问控制。
在国内面向公众提供生成式服务，内容标识、日志留存和审核流程本来就省不掉。对面向企业的产品，这些不只是合规成本，也是企业版能多收钱的理由。
第四类是定制化：私有微调、专属向量库、行业知识注入、私有数据管线。这类能力不适合放进通用套餐，更适合做大客户的专项收费。
最难拿捏的是基础层留多少。基础版太好，没人升级；故意做弱，价格敏感的用户会直接流向对手，尤其在免费和低价替代品越来越多的市场里。
可持续的分层靠使用深度自然形成门槛：用户把产品嵌进核心流程后，对上下文长度、稳定性、自动化和治理的需求会自然上升。这样推动的升级，比靠阉割基础功能逼出来的稳得多，也不容易在价格战里被迫回退。
七、定价实验要同时盯收入和成本
变现已经是产品设计的一部分，定价实验也要像功能实验一样系统化。很多团队调价时还停留在静态思路：改个月费、改个版本名、加个附加包，然后看收入。
这远远不够，因为 AI 定价会同时影响激活、使用深度、留存、升级、成本和满意度。
更成熟的做法是把定价当成一套实验系统：测价格敏感度，重排档位，模拟积分消耗路径，看不同人群的升级和流失，也看模型质量变化会不会改变付费意愿。
关键是不能只看收入端。一个方案让收入暂时上涨，却把高价值用户逼得不敢多用，或者招来一大批高成本、低价值的用户，长期看未必更好。
一条实用的判定规则：价格实验的主指标是单个付费用户的毛利额，护栏指标有两个，一是重度用户的周活跃度，二是新用户首周的调用次数。
主指标上升、两个护栏都没有下滑超过 5%，才算赢；主指标上升但新用户调用量明显下降，说明计价表焦虑在抑制探索，应该先调额度设计，而不是直接上线。
5% 只是起点，团队要按自己的数据波动来定。
要让这条规则能执行，数据得先接上。很多团队的计费系统和推理日志是两套账：财务看得到每个客户付了多少，工程看得到每个请求花了多少，却没人能在一张表里看到“这个客户这个月赚了还是亏了”。
把两边按客户 ID 和月份拼起来，做一张按客户排序的毛利表，是所有定价实验的前置工作，通常一两周就能搭好。
B2B 产品还有一个现实约束：付费客户少，价格实验很难跑出显著结果。几百家客户分成两组，每组一个月只有十几家新签，任何差异都可能是噪声。
这时更可行的是按新客分批：老客户保持原价，新签客户按季度切换方案，同时记录销售在报价阶段听到的异议。慢一点，但不会因为一次随机波动就推翻整套定价，也避免了同一时间两家客户拿到不同价格的尴尬。
失败通常有迹可循。毛利率逐月下滑但收入在涨，多半是重度用户在扩张，额度定得太宽；超额收入占比突然冲高、随后流失上升，说明默认自动扣费伤了信任；积分包复购率很低、大量积分在过期前没被用掉，往往是积分映射太贵，用户觉得不划算。
每种症状对应一个先查的参数，比全盘重做定价要省事得多。
也有人主张干脆按席位收费：简单、好卖、采购熟悉，AI 成本交给规模和模型降价去消化。
这个主张在一种情况下是对的：用户之间用量差异小，而且推理成本只占售价的一小部分，比如低于 10%，这时额度和积分带来的复杂度确实不值得。
可一旦重度用户的成本超过售价，就像第二节那款写作工具，席位制等于让轻度用户替重度用户买单，迟早要改。判断标准很简单：先看成本分布的长尾有多长，再决定要不要计量。
定价本身就是产品战略
落到执行，顺序是：先按用户和任务算清服务成本，找出会打穿毛利的长尾用户；再定一个用户看得懂的价值指标，token 只留在后台；然后用积分或额度把消耗包起来，按用户画像定好超额的默认处理；最后把更强模型、更深自动化、治理与定制做成升级台阶。
少了哪一步都会出问题。没有成本模型，额度就是拍脑袋；没有超额规则，重度用户会悄悄吃掉毛利，就像算例里 ¥200 的纯固定套餐，用到 2000 积分时毛利率只剩 20%。
每个季度用真实用量回填一次成本模型，再据此复核积分映射和档位边界。第一次做，不妨从最小的一步开始：拉出上个月用量最高的 5% 用户，把他们的账单和推理日志放进同一张表。这张表里亏钱的人有多少，决定了上面哪一步最急。