以单次对话成本为产品契约：当定价驱动架构设计时

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

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

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

定价模型决定架构

选择一种定价模型，你就隐式地选择了一套架构约束。人们很少从这个角度来描述决策，但其下游效应是机械发生的。

固定的人均定价告诉工程团队：封顶最坏情况。团队最终会实施激进的截断、硬性的会话限制、针对重度用户的模型降级，以及在没人批准的情况下以牺牲质量为代价的 Prompt 压缩技巧。设置上限是因为，在顶级模型上进行一次 200 轮的对话所消耗的推理成本，比用户支付的整月费用还要多，而十个这样的用户就能抹掉整个客群的毛利。

按对话或按会话计费告诉工程团队：优化可预测性。团队将倾向于使用上下文窗口化、摘要提取和工具调用批处理，以将每个会话的成本波动控制在定价档位可以吸收的范围内。成本上限现在是一个已知的常量，而不是一场无底线的赌博，架构也随之变得更从容，只要每个会话的预算允许，就可以使用更丰富的上下文。

按解决率或基于成果计费告诉工程团队：优化完成度。团队现在有动力投入任何必要的推理资源来真正完成用户的任务，因为收入只在成功时产生。这使得会话平均变得更长、更贵，但每个成果的利润更高 —— 并且它将运营风险转移到了供应商身上，这正是采用这种模式的团队必须围绕解决率而非 Token 量来重建成本监控系统的原因。

对于一个定价先行、工程指令后补的产品，这三种架构都无法事后修补。它们不是“实现细节”，它们就是产品本身。如果一个团队针对一个中位数对话成本为 4 美元 Token 的功能推出了 20 美元/月的套餐，那么他们与采用基于成果计费的团队所构建的并不是同一产品的不同版本 —— 他们构建的是两个架构迥异的产品，且其中一个注定会失败。

“定价即架构”在实践中意味着什么

一旦选定了定价档位，原本 PM 习惯性丢给工程团队的几个决策，就变成了需要明确、用户可见的产品决策。

截断策略。 如果上下文窗口是控制成本的杠杆之一，那么“助手还记得对话早期的哪些内容”就不是一个实现选择，而是一个带有用户体验（UX）的功能。当助手不再记得 12 条消息前的内容时，用户会察觉到。相比于“我们静默地丢弃了最旧的回合”，“我们将超过 20 分钟的回合进行了摘要，并在记录中标记了摘要”是一个更好的答案。两者的工程工作量大致相当，但只有一个是团队能在用户面前理直气壮交付的产品。

按档位限制上下文。 长上下文窗口作为一种能力出售，却作为一种成本消耗。默认的失败模式是给每个档位都提供相同的 200K Token 窗口，眼看着低价档位的重度用户耗尽资源，然后发一封道歉信，生硬地加上回溯限制。产品规格层面的做法是，将上下文预算定义为该档位价值主张的一部分 —— 入门级提供 32K 滑动窗口加摘要，中级提供 128K，高级提供全量窗口 —— 并围绕这种差异设计 UX，而不是寄希望于用户不会去对比。

会话重置。 “我们每 30 轮重置一次对话”是工程团队在发现成本曲线垂直上升且还没人注意到时采取的补救措施。“我们在自然的原子任务边界启动新会话，且用户的历史记录在长期记忆中仍可查询”则是同样的运营行为，但包装在了用户可以理解、且定价档位可以支撑的产品规格中。相同的代码路径，不同的心理模型，在触发时会产生截然不同的客户结果。

作为能力的摘要 vs 作为成本控制的摘要。 两者都存在。在代码库中看起来一模一样。区别在于 PRD 是否说明了它应该发生。一个被设计进产品功能的摘要（“助手会对长对话进行摘要以保持响应速度”）是用户乐于接受并给出高评价的；而工程团队为了保住成本底线而偷偷塞进去的摘要（“助手偶尔似乎会忘记对话的前半部分”）则是用户会抱怨的。实现方式相同 —— 唯有规格说明中的定性不同，而只有在 PM 撰写文档时将单位经济效益纳入考虑，这种定性才会发生。

PRD 中本应列出的预算指标

一个具备定价意识的产品规格书包含了大多数 PRD 目前所缺失的数据。其底线要求是：目标单次对话成本（cost-per-conversation）、告警阈值，以及一份规定当会话超出预算时优先削减哪些项的降级阶梯（degradation ladder）。

单次对话成本预算并非抽象概念。它们是由定价模型计算得出的：如果入门级方案是 19 美元 / 月，且公司需要 70% 的毛利率来覆盖基础设施和运营开支，那么每个活跃用户每月的推理预算就在几美元左右，而单次对话成本预算则由此除以预期会话数得出。如果规格书写着“我们预计每个活跃用户每月进行六次对话”，而计算结果是每次会话 50 美分，那么设计该功能的团队就拥有了一个硬性的设计约束——上下文大小、模型选择、工具调用深度、检索扇出（retrieval fan-out）以及预算耗尽后的拒绝策略，都成为了规格书中允许调整的变量。

告警阈值是预算在生产环境中自我执行的方式。在生成式 AI 成本控制工具中，一种成熟且行之有效的模式是在会话预算达到 70% / 90% / 100% 时触发告警，系统随后会切换到更廉价的模型、拒绝进一步的工具调用，或者在达到硬上限时优雅地结束会话。当会话达到 100% 时，是进行模型降级还是重置会话，这是一个用户会感知到的产品决策；它理应在规格书中占据一席之地。

降级阶梯使权衡变得明确。当一次会话接近预算上限时，执行顺序至关重要：先停止检索，然后总结旧的轮次，接着降级到更小的模型，再拒绝新的工具调用，最后结束会话。每一步都有其质量成本，用户会以不同的方式察觉到，而以错误的顺序叠加这些步骤，在相同成本下会产生更糟糕的 UX。明确列出这一阶梯的 PRD 才能确保在整个代码库中实现一致的交付。而没有明确说明的 PRD，最终会导致三名工程师在不同的代码路径中各自实现一套不同的阶梯。

为什么这个问题显现得晚且杀伤力大

目前 AI 功能的标准发布模式仍将定价视为功能发布后财务部门才需要考虑的问题。PM 撰写功能描述时充斥着对能力的形容词修饰，工程团队则使用顶级模型和慷慨的默认配置进行开发，发布时采用固定的人头计费定价，因为产品的其他部分也是这么做的，而单位经济效益（unit-economics）的数学计算则留到下一次季度业务复盘时才去审查。

到那个时候，两件事已经发生了。重度用户已经上手并围绕这些慷慨的默认配置构建了工作流，因此任何收紧行为都会被视为功能削减。而且，架构已经预设了无限的上下文，导致成本控制的补丁最终散落在无人维护的条件分支废墟中，没有任何分支能对产品在极限状态下应有的表现达成共识。

及早发现这一问题的团队都有一个共同习惯：规格书中包含一个与用户故事（user-story）同等权重的单位经济效益章节。PM 编写用户故事，工程团队同步编写成本模型，财务部门批准假设的毛利，产品根据反映实际交付成本的定价梯度进行发布。当重度用户出现时，产品已经为他们准备好了阶梯定价，架构中也已经有了降级阶梯，与用户的沟通内容是“你的使用量已经足以让你升级到更高阶的方案”，而不是“我们单方面更改了限制”。

那些没有及早发现问题的团队，则是那些在半夜进行重构的团队。截断补丁发布了，用户投诉接踵而至，PM 撰写澄清文档，财务部门质问为什么毛利不对，而有人则在一旁默默观察到：PRD 从未说明过一次对话到底允许有多长。到那时，这就变成了一个补救项目，而不是一个产品决策，补救的代价不仅是工程师的工时，还有客户的信任。

定价是第一公民级的架构输入

这个教训是结构性的，而非战术性的。AI 功能是 SaaS 时代首个单位经济约束会一直渗透到 Prompt 设计、内存策略和模型选择中的产品类别。将定价视为发布后财务问题的团队，最终会因迫于压力而做出看起来像是偶然形成的产品决策的工程决策。而将定价视为规格书中第一公民级输入的团队——在用户故事中可见，在架构图中可见，在降级阶梯中可见——可以主动选择其约束条件，而不是被动地发现它们。

行业定价模型从固定的席位计费转向按对话、按解决次数以及阶梯式使用模型的转变，并非财务层面的流行时尚。这是市场在将生成成本重新核算进产品与用户达成的契约中。抗拒这种转变的团队并非在保留简洁性，他们是在推迟一个注定只能被糟糕处理的架构决策。拥抱这种转变的团队所撰写的规格书中，单次对话成本预算是一个与产品愿景并列的数字，而架构紧随其后。

下次当 PM 交给工程团队一份没有这个数字的简报时，正确的反应不是稍后再估算。正确的反应是把简报退回去，因为没有它，团队实际上并没有得到一个要构建的产品——有的只是一个其极限将由用户痛苦地去发现的功能。