14 篇博文 含有标签「pricing」

你的 AI 功能成本预测是基于一个 50 人的试点项目建模的。那些用户输入了三句话的提示词，因为那是人们在被要求评估测试版时通常会输入的内容。产品上线了，你突破了一万名用户，财务团队指出你的模型账单是计划书中人均成本的三倍。你去寻找 Bug。但根本没有 Bug。你的试点项目是从一个分布中采样，而生产环境是从另一个分布中采样，两者的区别在于一个长尾用户群——他们是在 Twitter 上了解到你的产品，并粘贴了从推文中截取的 30 KB 非结构化上下文。

这是每家消费级互联网公司在 2010 年代都吸取过的同样财务教训，现在被移植到了 LLM 经济学中。试点项目的中位数用户并非生产环境中的 p99.5，而一个使用平均值作为预测输入的 Token 成本模型，在面对账单时注定会一败涂地。

你的试用版提供了“每天 100 次生成”。你的定价团队模拟了一个感兴趣的用户花一周时间进行体验。但第一个将智能体（agent）指向端点的试用者，在 70 秒内就用完了当天的配额，19 分钟内用完了每周配额，并在第二天午餐前耗尽了季度的推理预算。没有人收到警报，因为唯一设置的警报只在试用用户转化为付费用户时才会触发。

试用限制在制定时并没有错。它们针对的是不再适用于当前典型用户的用法分布。在六个月前的定价审查与今天早上的新用户注册之间，用户群体已经从点击按钮的人类转向了不知疲倦的程序。仪表盘上的数字不再代表你设定它们时的含义。

失败的智能体（Agent）运行成本很低。它可能会误导查询、陷入死胡同、返回“我无法提供帮助”，而执行这些操作可能只消耗几百个 Token。但成功的运行却是一场“灾难”。它检索上下文、进行反思、调用三个工具、再次反思，最后缝合出一个自信的、长达数段的答案——其 Token 消耗是那些几乎不花钱的失败运行的五十倍。

这就是智能体经济学中令人不安的现状：你的理想路径（Happy Path）就是你的高昂路径。你所销售的结果，也就是你在营销页面上承诺的、用户为此向你致谢的结果，正是你的系统所能执行的最昂贵的操作。如果你按照过去十五年 SaaS 的定价方式——按每个席位收取固定月费——那么智能体每出色地完成一次工作，都在悄悄侵蚀你的利润。

大多数团队是后知后觉才发现这一点的。他们观察成本仪表板，看到失败的成本很低，便得出结论：提高可靠性将节省资金。事实并非如此。提高成功率只会增加你的账单。

一次 10 轮的对话成本并不是单轮对话的 10 倍，而是接近 55 倍。这是大多数团队在建模 AI 功能的单位经济效益（unit economics）时最容易犯的错误，也是为什么一个在表格上看起来有利可图的产品在生产环境中却在不断亏钱的原因。

错误在于将对话视为一系列独立的请求。事实并非如此。由于 LLM API 是无状态的，每一轮对话都会重新发送累积的全部历史记录。第一轮发送 1 个单位的上下文，第二轮发送 2 个，第十轮发送 10 个。整个会话中计费的总 Token 数是 1 + 2 + ... + N 的总和，其增长趋势为 N²/2 —— 即平方级增长 —— 而你的产品几乎肯定收取的是固定的线性价格。

那些最喜欢你产品的用户，正是那些进行最长对话的用户。他们也是在悄无声息中摧毁你利润空间的人。

打开任何采用固定订阅制的 AI 产品的单用户成本仪表盘。其形状总是一样的：一条长长的、几乎无法产生显著影响的扁平尾部，以及顶部一个细长的尖峰—— 5% 的账户消耗了 80% 的推理预算。这个尖峰对处于两端的两类用户都是隐藏的。重度用户不知道自己在补贴其他人——他们以为价格就是那个价格。轻量用户不知道他们可以要求更多——他们以为限制就是那个限制。

仪表盘始终保留在工程团队内部，因为产品经理担心暴露它会吓跑用户。但事实恰恰相反。隐藏成本的团队最终会推出无声的限流、隐藏的模型降级以及导致用户认为“这产品坏了”的答案截断。而那些将成本作为刻意的 UI 界面（而非后台管理页）展示出来的团队，则能将同样的成本上限从流失驱动因素转变为商业化杠杆。

这就是 AI 钱包。它不是一个账单页面，而是一个产品原语（product primitive）。

要发现你的 AI 功能定价模型出错了，最直接的方法就是看哪位工程师正在半夜重写截断逻辑。他们并不是在交付什么新功能 —— 他们是在修补一个 PRD 从未提及的单位经济效益（unit-economics）漏洞，而且由于产品规格告诉他们预算是无限的，这个补丁必然是对用户不友好的。在固定费用的 SaaS 方案中，任何时长超过中位数的对话都在实时抽走公司的利润。唯一的问题在于，产品团队是否能在财务部门发现之前承认这一点。

传统的 SaaS 经济模型建立在近乎零的边际用户成本之上：一旦软件构建完成，服务下一个客户几乎不会增加基础设施开支。但 AI 功能打破了这一假设。对话中的每一次交互都会消耗推理算力，其成本随着 Prompt 大小、输出长度、工具调用（tool-call）的扇出量以及检索量而增加 —— 而且对话没有自然的终点。一个重度用户可以在一个计费周期内消耗 50 倍于中位数的成本，且完全不出产品设计的正常路径。在固定定价模式下，这种用户实际上是由其他用户群供养的，而公司通常要到三个月后的销货成本（COGS）报告出来时才会发现这一点。

这就是为什么 AI 功能的定价不是一个等到发布后再处理的财务问题。它是一个架构输入，决定了产品被允许做什么。如果拒绝在产品规格中将其透明化，只意味着它稍后会被那些没有产品决策权的人以更糟糕的方式解决。

三个团队正在查看同一个事件流，每个团队都有一个名为 session_id 的列，但每个团队对什么是“会话”都有不同的定义。计费（Billing）继承了来自认证库的 30 分钟空闲窗口。评估（Eval）从聊天机器人框架中继承了“直到用户说‘再见’或停止打字 10 分钟为止”的定义。记忆（Memory）则使用 UI 在用户点击“开启新聊天”时生成的线程 ID —— 而大多数用户从不点击这个按钮。三列数据，三种语义，一个汇总仪表盘，以及三个共用一个根因但互不相关的 Bug。

这就是会话边界问题（session boundary problem）。它看起来像是一个埋点琐事，但实际上是一个披着基础设施外衣的产品问题：一段对话在哪里结束？坦诚的回答是没有单一的标准答案 —— 计费会话、评估会话和记忆会话并不是同一种对象 —— 如果一个团队选择了一个默认定义并让另外两个团队继承它，那么他们交付的就是具有相同根因的计费纠纷、评估偏见和内存泄漏。

2026 年初，Atlassian 报告了一件公司历史上从未发生过的事情：企业席位数量下降。对于一家增长模式完全依赖于扩张收入（随着客户组织增长而销售更多席位）的公司来说，这是一个结构性警报，而非偶然波动。直接原因并非客户流失或产品失败。而是 Atlassian 自身的 AI 功能大幅提高了团队效率，以至于完成同样的工作量所需的席位更少了。

这就是 AI 效率悖论：构建一个真正为用户节省时间的功能，你可能正在训练他们减少对你产品的使用。你的 AI 越有用，你的定价模型崩溃得就越快。

当公司谈论 AI 风险时，对话通常集中在那些显而易见的失败上：幻觉事实、偏见输出、以及生成内容带来的法律责任。而较少受到关注的是一个更隐蔽的结构性问题：你已经在其输出本质上是概率性的系统之上，做出了商业承诺——定价层级、SLA（服务等级协议）、面向客户的准确性声明。每次模型生成响应时，它都是在从分布中采样。而合同中从未提及“分布”。

这是一个大多数团队发现较晚的业务风险，通常是在客户抱怨同一个文档审查工作流在周一和周五给出了完全不同的结果时，或者当监管机构要求提供系统在架构上无法提供的可复现性保证时。

一个团队发布了一款面向用户的 AI 助手。他们将其定价为每席位每月 49 美元，根据一份假设“每次查询平均 500 个 token”的电子表格，目标毛利率为 70%。三个月后，财务部门指出，他们的重度用户在每个会话中消耗了 15,000 个 token。定价模型之所以崩溃，并不是因为功能失败，而是因为产品团队为他们尚不了解的东西定了价。

这并非预测失败。这是一个结构性问题：大模型驱动产品的成本基准与传统 SaaS 定价所设计的处理方式根本不同。每一次 API 调用都有不可预测且实质性的 token 成本。输入因用户、任务和时间段而异。输出以各种方式复合增长，而这些影响直到几周后才会出现在你的云账单上。一旦你引入了智能体模式 (Agentic patterns) —— 工具调用、多轮推理、子智能体编排 —— 单次用户交互的成本可能是 0.02 美元，也可能是 20 美元，这完全取决于模型的决定。

当团队发布“每个席位 $X 美元的无限 AI”订阅层级时，定价会议上没有人意识到这是一个衍生品头寸。它看起来就像一个普通的 SaaS 定价页面——一个数字、一个层级、一个行动召唤（CTA）。但现在，该页面带来的每一美元收入都暴露在供应商设定的 Token 成本曲线之下，而该供应商的路线图根本不在乎你的毛利率。你写的不是定价页面，而是一份针对 Token 波动性的裸卖空合约，而行权价就是你的供应商在下季度收取的费用。

数学计算很快就显现出结果。少数重度用户发现了工作流，并开始在他们能塞进的最长上下文中运行它。竞争对手的 UX 变化重新训练了中位数用户，让他们发送长出 40% 的查询。你的功能所绑定的前沿模型因为旧版本层级被弃用而迎来了每百万 Token 价格的上调。其中任何一项都是你在单个季度内无法通过定价页面逆转的利润事件——而且它们往往会成群结队地到来。

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

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