AI 功能定价：工程团队总是跳过的单位经济学框架

Cursor 在 2025 年实现了 10 亿美元营收，却亏损了 1.5 亿美元。客户支付的每一分钱都直接流向了 LLM API 供应商，工程、支持和基础设施开销无从覆盖。这不是一个规模化问题——而是一个单位经济学问题，在酿成危机之前始终隐而不见。

大多数构建 AI 功能的工程团队都在犯同一个错误：把推理成本当作一个无关紧要的小项，上线固定费率订阅，然后假设经济账迟早会算对。但它永远不会自己算对。可变推理成本的行为方式与软件中任何其他 COGS 都截然不同——一旦你最重度的用户发现了你最昂贵的功能，那些适用于传统 SaaS 的定价架构就会让你流血不止。

这套框架的目的，是在上生产之前把账算清楚，而不是在利润率危机爆发之后。

为什么可变推理成本会打破 SaaS 假设

传统 SaaS 定价建立在一个简单前提上：每增加一个用户的边际成本接近于零。托管便宜，带宽便宜，数据库读取便宜。你按价值定价，而不是按成本定价，随着量的增长，毛利率也会扩大。

AI 推理颠覆了这一逻辑。每次 API 调用都有真实的、可变的成本，并随用户行为直接扩大。一个对话功能使用中端模型每次查询可能花费 0.005 美元。听起来微不足道——直到你算一下在 10 万月活跃用户、每人平均 20 次查询时会发生什么。仅这一个功能每月就产生 1 万美元的推理成本，还不算基础设施开销、降级模型、可观测性工具和重试逻辑。

从试验到生产的成本乘数持续让团队感到意外。测试中每次调用成本 0.50 美元的功能，进入生产后通常落在 3–5 美元——一旦计入以下因素：错误重试、输出验证循环、对话历史带来的上下文填充，以及调试所需的可观测性技术栈。按试验基准定价的团队都是以最惨烈的方式发现这一现实的。

在 Agentic 工作流中，情况会更加极端。一次简单的单次推理调用可能花费 0.02 美元，而同一任务通过一个自我修正、调用工具、验证自身输出的 Agent 来完成，可能花费 0.50–2.00 美元——25–100 倍的乘数。如果你按单次调用成本定价，每月收费 20 美元，一个重度 Agentic 用户可以在几小时内消耗掉你全部的月收入。

构建按工作流的成本模型

解药是在工作流层面而非 API 层面进行成本建模。在上线任何 AI 功能之前，你需要一张成本表，回答三个问题：一次激活的成本是多少，第 90 百分位激活的成本是多少，以及当用户每天运行 500 次时会发生什么？

从每个工作流的四个成本维度开始：

模型选型是最大的杠杆所在。现代 LLM 的价格区间跨越 100 倍。判断客户意图的分类任务，不需要与复杂多步推理任务相同的模型。将简单操作路由到经济型模型（Claude Haiku、GPT-4o mini），将高端模型保留给真正需要的任务，可以在几乎不影响质量的情况下将平均推理成本降低 60–80%。

Token 管理是第二个杠杆。输入 token 比输出 token 便宜——通常便宜 4–5 倍。每一个在不损失质量的前提下能从提示词中去掉的 token，都是直接的成本节约。常见的浪费来源：系统提示中冗余的重复指令、不必要的对话历史填充、以及 RAG 检索时拉入的上下文远超模型实际使用量。

提示词缓存的使用率不足，但回报极高。当你的系统提示和注入文档在多次调用中保持不变时，缓存 token 的成本仅为标准输入价格的 10–15%。通过仅仅将提示词结构调整为静态内容出现在动态查询之前，运行大型文档分析流水线的团队已借此将 LLM 成本降低了 50–90%。

批处理为非实时工作负载提供两大主要 API 供应商均提供的 50% 固定折扣。文档处理、数据增强、后台摘要——任何不需要立即同步响应的任务，都可以通过批量 API 处理，立即将成本减半。

你的成本模型应输出：每次工作流激活的中位成本、第 90 百分位成本，以及每用户的每日成本上限——一旦超出，就是值得调查的异常信号。

重度用户补贴问题

以下是让固定费率 AI 订阅崩溃的数学逻辑：

假设你以每月 20 美元提供一个 AI 写作助手，用户群大致分为三组：

• 轻度用户（80% 的客户）：每天 5–10 次查询，实际推理成本每月 1–2 美元
• 普通用户（18%）：每天 50 次查询，实际推理成本每月 15–20 美元
• 重度用户（2%）：每天 300–500 次查询，实际推理成本每月 100–200 美元

在典型的 AI SaaS 分布中，前 20% 的用户消耗了 80% 的算力。前 1–2% 的用户可能占总推理成本的 40–50%，却与其他人一样每月只支付 20 美元。

在传统 SaaS 中，轻度用户不会交叉补贴重度用户，因为边际成本可以忽略不计。在 AI 中，他们是实打实地、一美元对一美元地补贴。以 1,000 名客户为例：800 名轻度用户产生约 1,600 美元的推理 COGS，而 20 名重度用户产生约 3,000–4,000 美元。营收：20,000 美元。推理 COGS：约 5,600 美元，再乘以 2 倍的基础设施系数 = 约 11,200 美元。毛利率：约 44%。勉强可以接受——但前提是你已经对此建模。

现在考虑当你的产品获得牵引力，重度用户比例从 2% 升至 5% 时会发生什么。订阅价格不变，功能集不变——但 COGS 占营收的比例会急剧跳升。很多团队只有在利润率转为负值之后才发现这一变化。

解决方法是尽早识别重度用户，并设计定价来要么捕获他们的价值，要么限制他们的用量。每周追踪每用户成本。对任何推理成本超过所在套餐平均值 2 倍的账户发出标记。如果你的前 10 名用户消耗了中位用户的 50 倍，你就面临一个只会持续增长的补贴问题。

用量上限设计：软限制、中限制、硬限制

无限 AI 功能是负债，而不是差异化优势——除非你已明确对"无限"的成本进行建模和定价。

可持续 AI 功能的标准模式采用三级阈值系统：

软限制（预算的 80%）：向用户发送通知，不降级服务。这在不产生摩擦的情况下建立透明度，同时让重度用户浮现出来——他们可能会自愿升级到更高套餐。

中限制（预算的 95%）：开始限速。路由到更便宜的模型层级，降低请求速率，或返回稍慢的响应。用户仍可继续工作，但经济风险得到控制。透明地实施时，大多数用户能够接受。

硬限制（预算的 100%）：暂停新请求。对于消费者产品，这通常意味着付费墙或追加销售提示。对于企业用户，则触发人工审查再恢复。

关键是，这些上限应在多个粒度级别上同时执行：

• 按订阅套餐的月度预算
• 按功能的每日限额（防止单个工作流在一天内消耗一个月的配额）
• 按用户的每小时速率限制（捕获失控脚本和自动化循环）
• 按调用的输出 token 上限（防止单次请求生成无限量的响应）

按调用的输出 token 上限经常被忽视。一个在开放式任务下不设输出限制的 Agent，可能在单次响应中生成 50,000 个 token。按高端模型费率计算，那是 3 美元一次调用，而不是 0.06 美元——如果用户每天运行 100 次这样的调用，你的定价模型就成了一纸空文。

执行应在一个集中网关中进行，在推理调用到达供应商 API 之前拦截所有调用，而不是分散在各个功能的独立实现中。如果每个功能各自独立地执行限额，用户只需同时使用多个功能，就能轻松突破任何单个上限。

能在规模化中持续的货币化架构

目前有五种定价架构正在被证明是 AI 功能的可持续选择。它们并不互相排斥——最强的实现往往结合了多种方式的要素。

混合基础费用 + 用量计费：订阅底线覆盖轻度和中度使用，超出规定配额后启动超额定价。这是最容易沟通和实施的模型。关键在于将配额边界设置在中位用户永远不会触达的地方（减少摩擦），同时让重度用户可靠地触达（创造货币化机会）。

积分系统：将 token 成本抽象为积分单位。一个积分的 COGS 通常定价为 0.01 美元，并加收 50–100% 的加价。不同功能根据其实际推理成本，每次激活消耗不同数量的积分。优点是积分价格在心理上比 token 价格更容易接受，并且可以在不改变订阅价格的情况下调整单个功能的积分成本。缺点是不透明，可能会让想了解自己在为什么付费的技术用户感到沮丧。

按套餐分层访问与模型分级：低级套餐只能访问经济型模型，高级套餐才能解锁高端模型。这种方式很优雅，因为套餐之间的成本差异与模型层级之间的实际成本差异紧密对应，使利润率管理变得直接。它也创造了清晰的升级动机——如果用户想要更好的质量，他们为此付费，你不需要交叉补贴质量提升。

基于结果的定价：按成功完成收费（每处理一份文档、每生成一个 commit、每解决一张支持工单），而不是按推理调用收费。这将你的定价与 token 成本完全脱钩，非常适合能够可靠衡量结果的场景。利润率风险从"这次调用花了多少？"转变为"我们能否足够高效地交付结果？"Replit 的 Agent 定价正在朝这个方向演进——简单运行 0.06 美元，复杂运行 3–5 美元。

带时间限制的软上限与购买选项：每日 token 预算按滚动周期重置，当用户触达上限时可一键购买超额包。这对消费者产品效果好，前提是冲动购买是可行的，且用户的每日使用量差异较大。

导致 AI 功能经济学崩溃的六个错误

先发布，再定价。 一旦用户在某个价格点上采用了一项功能，再改变经济逻辑极为痛苦。应与功能开发同步设计定价，而不是在之后。

COGS 幻觉。 推理成本只是你真实 COGS 的一部分。监控、可观测性工具、降级模型基础设施、重试逻辑，以及 AI 相关 bug 带来的支持负载，都有所贡献。生产环境中的真实 COGS 通常是原始推理成本的 1.5–2.5 倍。

单一模型依赖。 如果你硬编码了单一供应商，而他们提价或更改模型阵容，你的利润率就会一夜之间改变。从一开始就实施多模型路由，让你无需更改产品即可将负载转移到更便宜的替代方案。

无限套餐，没有熔断机制。 即使是"无限"套餐也需要一个软限制，触发人工审查。一个用户运行查询循环，一天就能产生 10,000 美元的推理费用。

忽视 Agentic 成本爆炸。 Agentic 功能每个任务的成本比单次推理高出 5–30 倍。如果你按对话式交互成本定价了订阅，然后推出了一个会循环、调用工具、自我修正的自主 Agent，对于采用 Agent 的用户，你实际上已经将自己的利润率削减了 10–30 倍。

不考虑利润率的对标竞品。 在不了解竞争对手成本结构的情况下照搬其定价是危险的。他们可能有优惠的 API 合同、锁定在旧价格上，或者干脆是在亏本运营以抢占市场份额。你的价格底线是 COGS 除以目标毛利率。低于这个数字，你就是在付钱请用户使用你的产品。

上线前需要构建的东西

在任何 AI 功能进入生产之前，以下三样东西必须存在：

成本模型电子表格：每次激活的中位成本、第 90 百分位激活成本、在三种使用强度（轻度、中度、重度）下 1,000 MAU 的预估月成本。如果重度用户场景看起来不可持续，在设计阶段就解决，而不是在事故复盘中。

按用户维度的成本看板：按用户和按功能拆分的推理支出可见性，至少每天更新一次。这是补贴问题和失控使用模式的早期预警系统。

分级执行网关：在任何代码进入生产之前，就要有集中的上限执行机制，包含软限制、中限制和硬限制三个阈值。事后把这套机制叠加到现有功能上既痛苦，又常常需要破坏性变更。

跳过这些步骤的团队都会发现同样的模式：产品获得牵引力，重度用户自我筛选进来，利润率被压缩，团队面临一个两难选择——要么降级一个用户喜爱的功能，要么在每个活跃用户身上亏钱。两种结果都不好。单位经济学框架并不光鲜，但它是一个能规模化的功能与一个在财务注意到 COGS 趋势后被悄悄下线的功能之间的分水岭。