7 篇博文 含有标签「unit-economics」

每个人都在看的成本仪表盘是一个周滚动平均值，而那个平均值正在对你说谎。并不是说数字本身是错误的——它是计费事件流的忠实算术平均值——而是它隐藏了底层的成本曲线形态。周五晚上到周一早上之间的 token 消耗方式，与周二上午 10 点到周四下午 4 点之间截然不同。周六凌晨 3 点活跃的群体与周二上午 11 点活跃的群体并非同一拨人，这些群体的单用户经济效益（per-user economics）差异巨大，但没人记录这一点，因为仪表盘通过平均值将其抹平了。

大多数团队第一次发现这一点，是在周末自动化脚本烧光预算的时候。一个 LangChain 智能体在周五晚上陷入了无限对话循环，运行了大半周才被人发现，导致产生了一张五位数的账单，周一早上不得不向财务部门解释。事后回顾将其视为一次性事件——糟糕的重试逻辑、缺失的预算上限、没有触发值班报警。但是，那个隐藏了失控循环的仪表盘，同时也隐藏了同一现象的稳态版本：每周都会出现的非工作时间流量基准，其单位经济效益在结构上比工作时间基准更差，而周平均值让这一切变得不可见。

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

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

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

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

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

发布前的成本模型通常是一张精美的电子表格。它假设通过代表性的提示词（Prompt）运行模拟流量，并在测试过的缓存命中率和干净的工具调用路径下运行。但发布后的现实是，一旦功能真正开始运作，这些假设都将不复存在。模拟流量未涵盖的意图恰恰是用户最常使用的。工程团队没收到会议通知的营销活动所带来的流量，最终落在了路由树中成本最高的分支上。在第三周，使用量超过中位数 40 倍的重度用户群体才会开始出现。

这类问题在全行业内已屡见不鲜：调查显示，约 80% 的企业对 AI 成本的预测偏差超过 25%，并报告在成功发布后的几个月内，成本通常会增加 5 到 10 倍。这些数字中关键的细节是“成功”二字。失败的 AI 功能才能维持在预算内。成本偏差是由功能的成功运行驱动的，而不是因为团队做错了什么。这使得它成为一个规划产物（planning artifact）问题，而不是工程问题 —— 而大多数团队依赖的规划产物，即每月账单，其实是最糟糕的检测器。

当财务团队第一次要求 AI 产品团队预测单位经济效益（unit economics）时，对话往往如出一辙。团队打开推理仪表盘，指着每月的 token 支出说：“这就是我们的销售成本（COGS）。”CFO 乘以预估业务量，在图表上画出一条线，并询问毛利率曲线何时能跨过 70%。六周后，当实际损益表（P&L）出炉时，仪表盘上的推理数字是正确的，但毛利率却比预测低了 20 个百分点。没人撒谎。推理费用其实只占 Agent 实际成本的一半。

另一半成本分散在 AI 团队中无人负责的各个分项中。向量数据库的账单在悄无声息地增长，因为检索量随使用量增加，而重新索引的成本计入了计算费用，而非存储费用。可观测性平台的发票则从平台团队的预算中支出。嵌入重构（Embedding regeneration）表现为 CI 成本。遥测数据存储被归入数据仓库。人工审核则计入客户成功（customer-success）的人员成本。这些项目单独看都不起眼 —— 这正是为什么整合后的数字会让所有人大吃一惊。

我认识的一个团队在上个季度通过将支持邮件分类流程从顶级模型（frontier model）迁移到中级模型，将推理费用降低了 40%。CFO 还专门发了感谢信。六个月后，客户支持团队增加了两名全职员工（FTE），平均解决时间上升了 35%。没有人把这些点联系起来，因为这些“点”分布在不同的仪表盘上：推理费用在平台团队的仪表盘上，而支持工作量在运营团队的仪表盘上。在所有人都在追踪的唯一指标上，这次迁移看起来是一次胜利。但指标错了。

这就是“单 Token 成本”（cost-per-token）陷阱。你的账单告诉你花了多少钱在 Token 上，但它无法告诉你每个“正确”任务花了多少钱，因为推理供应商根本不知道在你的领域里什么是“正确”。他们卖给你的是原始算力。而你买的是结果——或者你以为你买的是结果。这两个单位之间的差距，就是 AI 单元经济（unit economics）悄然崩溃的地方。如果不去衡量正确的分母，团队就只算了一半的账，而在另一半的交付上处于盲目状态。

一位开发者在每月 200 美元的套餐下跑出了超过 35,000 美元的计算费用。这是对单一用户 175 倍的补贴——由那些本可以愉快地使用 19 美元档位的普通大众买单。这是每一个“为什么本季度我们的 AI 毛利率是负的？” Slack 讨论串背后支撑的数学逻辑。问题不在于那一个用户；而在于那一类用户的长尾效应遵循幂律分布，而幂律分布加上固定费率计费，再加上真实的单位成本，构成了一个任何增长都无法修复的结构性毛利压缩器。

当这种情况出现在财务审查中时，下意识的反应就是收紧：严格的 Token 上限、埋在服务条款（TOS）里的“公平使用”措辞、每周限流、为免费层级悄悄降级模型。这些手段在止损方面确实有效。但它们也会疏远你所依赖的那些布道者用户，因为触及上限的人正是那些真正搞清楚了如何从你的产品中提取价值的人。标准的做法是向错误的群体致以一份向后兼容的道歉。