R

A07 成本约束反向塑造产品

创建 2026-06-07 更新 2026-06-11 12 条双链 成本工程 专题 AI 整理

A07 成本约束反向塑造产品

你打开任何一个 AI 产品的设置页：对话有 context 上限、每小时有几十条的消息配额、免费版用几次就”今天的额度用完了”、网络一卡就悄悄换了个更笨的模型回你——这一整套你以为是”产品经理深思熟虑的体验设计”的东西，绝大部分是 token 账单倒逼出来的成本约束，只是穿了一件叫”产品决策”的外衣。 本节要解决的问题是：在 AI 产品里，成本到底是”先做完功能、上线后再交给工程去优化”的后置工程问题，还是一开始就和需求、定价、留存平起平坐的产品一等约束？本节的立场（也是整个 0413 专题的判断主轴）是后者——并给出一套”反向读产品”的方法：看到一个限制，先问它在替哪笔成本止血。

§0 为什么是”成本即一等约束”这个框架，而不是”成本是后置优化”

PM 脑子里默认装着一个 SaaS 时代的框架：成本是后置的。 先把功能做对、把体验打磨好、把留存做起来，等规模上来了再交给工程去”优化性能、降本增效”。这个框架在边际成本≈0 的软件世界里是对的——多服务一个用户几乎不花钱，所以早期可以”不计成本地堆体验”，成本曲线后面会被规模摊平。

这个框架在 AI 产品里结构性失效，因为 AI 产品的变动成本不趋零、随用量线性甚至超线性增长（见 A01 成本概念史与口径辨析）：用户每多发一条消息、上下文每长一点、模型每多想一步（reasoning token），你的账单就实打实地涨一截。于是出现一个 SaaS 没有的现象——最受欢迎的用户最烧钱：重度用户发的消息最多、上下文最长、最爱用最贵的功能，留存做得越好、DAU 涨得越猛，毛利可能反而越薄。这就是为什么”先做体验、后管成本”在 AI 里会把产品做死：等你发现账单失控，体验已经被用户的肌肉记忆锁死，砍配额就是砍留存。

所以本节用的框架不是”成本优化”（一个工程动词），而是**“成本约束塑形”（一个产品名词）**——成本约束像重力一样，在产品诞生那一刻就参与定义它的形状：能开多长的对话、能多频繁地调用、免费给多少、降级时长什么样。把成本当一等约束，意味着这些参数不是上线后才调的旋钮，而是写需求文档时就要和工程一起定的产品骨架。挡在前面的错误框架就是”成本是后置优化”——它让 PM 把 context 上限、rate limit 当成工程的内部实现细节，于是在定价会、需求评审上集体失语。

§1 四件成本倒逼的”伪产品决策”

把 brief 点名的四件套——context 上限、rate limit、优雅降级、免费额度——逐一翻译成它们真正在止的那笔血。这四件事在产品文档里都被写成”体验设计”，本质全是成本结构的投影。

表面的”产品决策”真实的成本约束它在替哪笔账止血反向读法
Context 上限（如”单次对话最多 N 万字”）KV Cache 显存随上下文线性增长、且推理成本对长 context 超线性（见 c05 - 算力物理定律与 KV Cache、KV Cache）长对话吃显存、压并发、拉高 per-query 成本；上限是在锁单用户的边际成本天花板看到 context 窗口，先想它背后的显存账和并发账
Rate limit（每小时/每天 N 条、N tokens）per-user 边际成本无封顶，重度用户能把单人成本拉到客单价以上防”少数重度用户烧穿毛利”——本质是 per-user COGS 的硬熔断（见 A02 成本对象层级辨析·per-token per-query per-task per-user per-seat）看到限流档位，反推它的人均成本红线在哪
优雅降级（高峰期换小模型/缩短回答/排队）强模型单位成本高、容量有限，峰值全量用强模型会爆预算或爆容量用质量换成本/容量，把成本曲线削平（接 A05 模型路由与 Mixture-of-models、多模型分层）看到”今天有点慢/有点笨”，多半是被路由到便宜档了
免费额度（免费版每天 N 次）免费用户是纯成本（无收入），且 AI 的免费比 SaaS 贵得多（每次调用真金白银）把”获客成本（CAC）“框进可控区间——免费额度=用 token 买的获客预算（见 R03 Unit Economics 模型·CAC COGS LTV 与盈亏平衡）看到免费额度，把它当一行 CAC 预算来读

这张表的统一句式是：每一个”限制类”产品决策，背后都站着一个成本变量。 把它打印出来贴墙上——下次评审会上有人说”我们把 context 放开到无限吧，体验更好”，你能立刻接：“那 KV Cache 显存和并发上限怎么办，per-user 成本封顶在哪？“这就是成本作为一等约束的具体战斗力。

§2 判断主轴：成本是产品一等约束，不是后置工程——90% 的人在这四处搞错

这是本节、也是全专题的命门。下面四个错位，每个都按”症状 → 为什么会错 → 正确做法 → 真实反例”四件套展开。

错位一：把 context 上限当”工程的内部实现”，需求阶段不碰

  • 症状：PRD 里写”支持超长文档对话/无限上下文”，把”具体多长”标成”工程评估”，自己不参与定。
  • 为什么会错：PM 用 SaaS 直觉——容量是工程的事，加机器就行。但 AI 的 context 长度直接挂在 KV Cache 显存与推理成本上，是线性吃显存、超线性吃钱的产品参数（c05 - 算力物理定律与 KV Cache）；它决定了单用户边际成本天花板，是定价和毛利的输入，不是工程的输出。
  • 正确做法：在写需求时就把 context 上限当成和”功能列表”同级的产品决策，和工程一起定，并明确”放长 N 倍，per-query 成本和并发上限各变多少”。
  • 真实反例：长 context 模型上市后，厂商普遍对超长上下文区间分级加价——Google 对 Gemini 1.5 Pro 采用按 context 长度分档定价：标准档 $1.25/百万输入、$5.00/百万输出，超长上下文区间走更高单价档（该长上下文阈值按 Google 文档为约 128K–200K token 量级，超过即全 prompt 按长上下文价计费）〔截至 2026-06 已核实标准档 $1.25/$5.00 与”按 context 长度分档”结构，来源：Google AI for Developers 定价页 / Developers Blog 2024-10 降价公告；具体阈值与倍率为 volatile，需定期复查〕。这说明”上下文长度”从来不是免费的体验旋钮，而是被厂商显式定价的成本变量；把它甩给工程的 PM，等于把定价权拱手让人。

错位二：把 rate limit 当”防滥用的安全栅栏”，而非”per-user 成本熔断”

  • 症状：限流策略写成”防爬虫、防 DDoS”，按”请求数”一刀切，不区分成本权重。
  • 为什么会错：限流确实有安全用途，但在 AI 产品里它的第一性目的是成本封顶——防的不是恶意流量，是”正常但重度”的用户把 per-user COGS 拉到订阅费之上（A02 成本对象层级辨析·per-token per-query per-task per-user per-seat）。按”请求数”限流会漏掉真正的成本黑洞：一次长 context + 深度 reasoning 的请求，成本可能是普通请求的几十倍。
  • 正确做法：限流维度要对齐成本维度——按 token 量、按上下文长度、按是否用 reasoning/thinking 模式分别设限，让限流栅栏的形状贴合成本曲线的形状。
  • 真实反例：主流厂商的限流早已是多维的：Anthropic 的 Messages API 同时按 RPM（请求/分钟）、ITPM（输入 token/分钟）、OTPM（输出 token/分钟）三个维度对每个模型类分别限流（来源：Anthropic API Docs · Rate limits），正是因为单看”请求数”无法封住成本；输出 token 比输入贵数倍（见 A03 Token Economics 精算），必须单独给它套笼子。更妙的是这套限流直接和成本机制咬合：命中缓存的输入 token 不计入 ITPM（且只按基础输入价的约 10% 计费）——限流的”放行口”刚好开在最便宜的那条路上，是把成本激励写进限流规则的范本（接 Prompt Caching）。

错位三：把”优雅降级”当纯体验功能，没把它接到成本/容量曲线

  • 症状：降级被当成”网络不好时的兜底交互”，由前端做个 loading 或重试，不进成本模型。
  • 为什么会错：在 AI 产品里，优雅降级的核心是用质量换成本与容量——高峰期把请求从贵模型路由到便宜模型、把长回答截短、把同步改异步排队，本质是在削平成本/容量的峰值（A05 模型路由与 Mixture-of-models）。它不是前端兜底，是成本工程的产品出口。
  • 正确做法：把降级设计成显式的质量-成本档位，并在产品上想清楚”用户能不能感知、感知了会不会流失、哪些场景绝不能降级”（医疗/法律等质量刚性区不能用便宜模型兜底——这是 Baumol 成本病的产品体现，见 §对手框架）。
  • 真实反例：ChatGPT 免费版在旗舰模型额度耗尽（或高峰期高负载）后会静默回退到能力更弱的 mini 模型继续服务，而不是直接拒绝——具体降级目标随版本演进（曾是 GPT-4o mini，后改为 GPT-4.1 mini）〔以2026-06行为·待核实当期具体目标模型，来源：OpenAI 帮助中心 / 多家用量限制评测〕。这正是”用质量换可用性与成本”的降级，是产品决策而非工程兜底。它的代价是：用户若能感知到”变笨了”，满意度和留存会受损，所以降级的可感知度本身是个要被 PM 拿捏的产品变量。

错位四：把免费额度当”营销活动”，不当 CAC 预算来管

  • 症状：免费额度由市场/增长拍脑袋定（“先给得大方点拉用户”），不和单位成本挂钩。
  • 为什么会错：SaaS 的免费用户近乎零成本，所以可以”慷慨”；AI 的每次免费调用都是真金白银，免费额度是用 token 买的获客预算，本质是 CAC 的一部分（R03 Unit Economics 模型·CAC COGS LTV 与盈亏平衡）。定大了，烧钱获客却转化不上来；定小了，体验不到价值就流失。
  • 正确做法：把免费额度当一行 CAC 来算——“每个免费用户平均消耗多少 token 成本 × 免费用户数 = 获客投入”，再对齐转化率与 LTV，让免费额度落在”能体验到价值、又不破产”的区间，并随 token 价格变化动态调整。
  • 真实反例：多家 AI 应用上线初期”无限免费/无限使用”后被迫快速收紧——这是免费额度未当成本约束管理的典型代价。一个可追溯的方向性事实：OpenAI 的 Sam Altman 在 2025-01-07 公开表示 ChatGPT Pro（$200/月）订阅在亏钱——原话”we are currently losing money on openai pro subscriptions! people use it much more than we expected”（来源：Sam Altman X/Twitter，2025-01-07；Fortune 同日报道），并提到可能转向按量计费而非统一价无限用。连付费档（且是最贵那档）都会因重度使用而成本倒挂——这恰是 §1 表里”重度用户最烧钱""统筹定价被重度用户击穿”的活证据，免费额度的成本纪律只会更紧。

§3 产品 PM 视角补盲：成本约束的三个”看走眼”点

跳出”工程 PM”视角，补三个容易被技术叙事盖过的产品/商业盲点：

  1. 用户心理模型：成本约束一旦被用户感知，会从”产品设计”变成”对用户的剥夺感”。“今天的额度用完了”在用户脑中不是”我用得够多了”，而是”这产品很抠”。所以成本约束的呈现方式是产品工艺：同样是限流，“明天再来”和”升级解锁”传递的情绪完全不同。降级也一样——用户若发现”我没感觉变化”是最佳降级，若发现”它偷偷变笨了”则是信任损伤。
  2. 商业模式：成本约束直接决定定价分层的形状。订阅制能成立的前提是”绝大多数用户的成本远低于订阅费、少数重度用户被 rate limit 兜住”——这是一种成本上的统筹（pooling）。一旦重度用户占比上升或单位成本上涨，pooling 失效，要么涨价、要么收紧额度、要么转向按量计费（usage-based）。所以”用订阅还是按量”不是纯商业选择，是成本结构能不能撑住 pooling 的函数。
  3. 合规边界：成本约束和合规会打架。端侧推理”省了 API 费”还利好隐私（数据不出端），看似双赢；但质量刚性的合规场景（如需要可审计、可解释的输出）往往要求最强模型，端侧/便宜模型兜底会触碰合规红线（见 A06 端侧与云端成本重构）。这里 PM 要识别的是：成本最优路径可能不是合规可行路径，降级策略要为合规场景留”绝不降级”的白名单。

§4 对手框架回应：成本是不是被夸大了？（接受 + 边界）

[!note] 对手立场一：精益创业 / “先上线再优化成本”派 接受：他们对的部分很硬——MVP 阶段过早抠成本会拖死迭代速度，把工程精力耗在还没验证 PMF 的产品上是浪费。“先做出有人用的东西”在大多数早期产品里确实优先于”做出便宜的东西”。 边界与赌注：但 AI 产品有一条 SaaS 没有的特性——成本是分钟级失控的。一个 prompt 注入循环、一个 agent 死循环、一次被薅羊毛的免费接口，能在几分钟内烧光一天预算（见 S03 FinOps for AI·成本可观测与归因全景）。所以本节的边界是：功能可以后优化，但成本的”熔断/降级触发器”（rate limit、预算告警、自动降级）必须在第一版就有。 这不是”过早优化”，是”过早装保险丝”——两者的区别是后者的缺失会直接把公司账户清零。

[!note] 对手立场二：“等模型降价，成本约束自会消失”派（接 G01 推理成本代际谱系总图） 接受：token 价格确实在以惊人速度下降，单看单价，今天的”贵”明天可能就不贵了。 边界与赌注：但这正是 Jevons 悖论 要反对的乐观（见 §跨域呼应）——单位成本下降会刺激调用量、上下文长度、推理深度暴涨，总账单常不降反升。更要命的是，降价的同时新增了更贵的消费方式：reasoning/thinking token 单独计费（见 A03 Token Economics 精算）让”想得更深”成为新的烧钱项。所以成本约束不会因降价而消失，只会换个地方爆——这是主动设计问题（要主动限流），不是等待问题。

[!note] failure scenario（本节判断的失效边界，诚实标注） “成本约束反向塑造产品”这条主轴，在成本占比极低的场景失效——如低频高价的 B2B 工具（一次咨询报告卖几千元、推理成本几块钱），此时推理成本相对客单价是噪声，产品决策由别的约束（合规、交付质量、客户关系）主导。在这种场景强行用成本视角解释 context 上限或限流，会误判产品意图。本节的判断成立的前提是：推理成本占客单价/订阅费的比例不可忽略（典型在面向消费者的高频 AI 应用、薄毛利的 API 转售产品里成立）。

§5 跨域呼应：Jevons 悖论——为什么”降本”反而要”限流”

[!note] 跨域资源调度：Jevons 悖论（W.S. Jevons《The Coal Question》1865） 杰文斯发现：蒸汽机效率提升（烧同样的煤做更多功）非但没减少煤的消耗，反而因为煤变”便宜好用”而刺激了总消耗暴涨。效率提升与总消耗增加可以同向。

这个 161 年前的经济学观察，直接改变了本节对”成本约束”的判断。直觉框架是：token 越来越便宜 → 成本约束会越来越松 → context 上限、rate limit、免费额度都可以放开。Jevons 悖论把这个推理整个推翻：单位 token 越便宜，用户和开发者越会”奢侈地”用它——开更长的上下文、让模型想得更深、把 AI 塞进更多场景，总 token 消耗的增速往往超过单价的降速，总账单不降反升。

这意味着一个反直觉的产品结论：正因为推理在变便宜，成本约束才更要被主动设计，而不是放开。 放开 context 上限不会因为单价降了就安全，它会立刻被”反正便宜”的长对话填满；取消 rate limit 不会因为模型便宜了就不烧钱，它会被涌入的调用量填满。Jevons 把”成本约束”从一个”等技术进步来解除的临时枷锁”，重诊为”必须长期、主动维护的产品塑形力”。这也是为什么本专题反对”等降价”派——降价不解除约束，它只是改变约束要卡在哪里。

§6 PM 决策启示：面试 / 选型 / 复现三类落地

  • 面试桌：被问”你怎么设计一个 AI 产品的限制策略”，不要答”防滥用、保体验”，要答：“我会先把每个限制接到它对应的成本变量上——context 上限对 KV Cache 显存与 per-query 成本、rate limit 对 per-user COGS 熔断、降级对峰值容量与成本、免费额度对 CAC 预算。限制的形状要贴合成本曲线的形状。“再补一句 Jevons：“越是模型降价，越要主动维护这些约束。“——这一答立刻把你和”只懂体验的 PM”区分开。
  • 选型/在岗：评审任何”放开限制提升体验”的提案，用本节的反向读法逐条质询：“放开后这笔成本怎么走？per-user 成本天花板抬到哪？毛利还撑得住 pooling 吗？“反过来评审”加限制”的提案，确认它有没有过度伤害用户心理模型（剥夺感）和留存。
  • 复现台：动手时，先用 R01 最小可运行·Token 成本计算器 把一次典型对话/任务的成本算出来，再用 R03 Unit Economics 模型·CAC COGS LTV 与盈亏平衡 反推”在当前定价下，context 上限/rate limit/免费额度该卡在哪才不亏”——把本节的定性判断变成可贴进定价 deck 的具体数字。

§7 与已有节点的关系

  • 对 m209 - 推理成本控制手册：抽象层升高 + 视角翻转。m209 站在工程视角讲”用缓存/路由/语义缓存/对话压缩怎么把成本降下来”（降本是动作）；本节站在产品视角讲”成本约束怎么反过来定义产品的形状”（约束是塑形力）。同一组技术手段（路由、限流），m209 当降本工具，本节当产品决策。不复述 m209 的降本手段清单与实测数字。
  • 对 c05 - 算力物理定律与 KV Cache：翻译。c05 给出 KV Cache 的物理公式与显存上限；本节把”显存物理上限”翻译成产品语言——“这就是为什么有 context 上限”，把物理约束接到产品参数。
  • 对 A05 模型路由与 Mixture-of-models：复用 + 上移。A05 讲路由/兜底的成本工程实现；本节把路由的产品出口（优雅降级）提炼成”用质量换成本”的产品决策，并补”降级的可感知度是产品变量”这一 A05 不谈的产品维度。
  • 对 m202 - 工程选型决策矩阵：对话。m202 在选型时把成本当一个评估维度；本节把成本从”选型时的一个维度”升级为”贯穿产品生命周期的塑形约束”——选型只是它的一个切面。
  • 对 c06 - 架构演进：Dense MoE SSM Hybrid / c07 - 量化 Quantization 与端侧部署：间接对话。架构与量化决定了”降级时能换到多便宜的模型/能否端侧化”，是本节”优雅降级""端侧分流”产品决策的技术底座（端侧细节见 A06 端侧与云端成本重构）。

§8 关联节点

核心（必读）

延伸（可选）

§9 修订日志

  • R0（2026-06-07，初稿）：按宪章 §4 十一段骨架落稿。确立判断主轴”成本是产品一等约束非后置工程”，§1 四件成本倒逼的伪产品决策对照表（context 上限/rate limit/优雅降级/免费额度 → 各自对应的成本变量），§2 判断主轴四错位（每个四件套：症状→为什么错→正确做法→真实反例），§4 两处对手框架”接受+边界”（精益创业派、等降价派）+ 1 处 failure scenario（低频高价 B2B 成本占比极低时主轴失效），§5 跨域呼应 Jevons 悖论（降本反而要限流，落地非装饰），§7 与 m209/c05/A05/m202/c06/c07 显式升级对照（视角翻转/翻译/上移/对话，不复述），§8 关联节点分核心/延伸。- R1（2026-06-07，grounding pass）：四处硬事实经 WebSearch 核实并升级——①Anthropic Messages API RPM/ITPM/OTPM 三维限流已确证（来源 Anthropic API Docs），并补入”缓存输入 token 不计入 ITPM、按基础价约 10% 计费”这一更强的成本-限流咬合证据；②Gemini 1.5 Pro 按 context 长度分档定价已确证（≤128K 走 $1.25/$5.00 标准价、>128K 走更高档，来源 Google AI for Developers / Developers Blog 2024-10），具体倍率仍标〔以2026-06·待核实〕；③ChatGPT 限额耗尽静默降级到 mini 模型已确证（曾 GPT-4o mini→后 GPT-4.1 mini，来源 OpenAI 帮助中心/评测），当期具体目标模型标〔待核实〕；④Altman 表态纠正并升级：原稿误记为 ChatGPT Plus（$20），实为 Pro（$200）亏钱，已补 2025-01-07 X 原话与 Fortune 来源，并接回 §1”重度用户最烧钱”主轴。剩余待核实项（2 项，均为 volatile 价/口径，已就地标注非编造）：Gemini >128K 的具体加价倍率、ChatGPT 当期降级目标模型版本。
  • 2026-06-11 P3.1 接地修复：§2 反例的 Gemini 1.5 Pro 分档定价经 WebSearch 复核——标准档 $1.25/$5.00 与”按 context 长度分档”结构确证（来源 Google AI for Developers / Developers Blog 2024-10），长上下文阈值据 Google 文档为约 128K–200K token 量级（原稿写死 128K，已放宽为”128K–200K 量级”并注明阈值/倍率为 volatile），整句〔以2026-06定价·待核实〕升级为〔截至 2026-06 已核实标准档与分档结构，需定期复查〕。Altman “Pro $200 亏钱”为 2025-01-07 历史表态、不随时间漂移，维持。

R0 初稿要点：按宪章 §4 十一段骨架落稿。确立判断主轴”成本是产品一等约束非后置工程”，§1 四件成本倒逼的伪产品决策对照表，§2 判断主轴四错位（四件套），§4 两处对手框架”接受+边界”+ 1 处 failure scenario，§5 跨域呼应 Jevons 悖论，§7 与 m209/c05/A05/m202/c06/c07 显式升级对照，§8 关联节点分核心/延伸。