让每个团队在一夜之间重写 Prompt 的内部结算模型

财务部门在周一发了一份备忘录。到周五，每个产品团队都上线了 Prompt 的变更，而接下来的周二，支持队列增加了三分之一。没有人动过模型。没有人动过产品。唯一改变的是，LLM 账单现在流回了发起调用的团队——而团队的反应就像任何理性的成本中心对损益表（P&L）上的新条目所做的那样：削减它。

事后公司内部流传的是关于 Prompt 工程、或模型退化、或是由于用户流量波动导致的一周的故事。而更真实的真相是，财务部门通过一项费用分摊（Chargeback）政策，悄无声息地成为了产品经理。成本归因仪表盘成为了一个没人审查、没人为其准备监控工具、也没人负责的产品质量杠杆。当它发生波动时，公司里的每一个 Prompt 都随之波动，而导致质量退化的权衡取舍，从未被那些职责本应是监控这些变化的人察觉。

备忘录是伪装下的产品决策

Showback（费用展示）和 Chargeback（费用分摊）看起来像是穿了不同衣服的同一种治理模式，但它们的表现却像完全不同的产品。Showback 告诉团队他们花了多少钱，但不做任何要求。Chargeback 则将这个数字计入预算，团队必须在下一次规划审查中为其辩护。“你的团队上个月消耗了 42,000 美元的 Token” 作为一个幻灯片上的数字与作为你运营预算中的一个条目，其区别在于信息与激励之间的区别。前者产生的是点头，后者产生的是冲刺。

这项政策的意图几乎总是合理的。在没人能解释的情况下，单一共享预算中的 AI 账单每季度增长 30% 到 40%，而支付发票的平台团队无法说明哪项功能产生了哪部分费用。Chargeback 干净利落地解决了可见性问题。每个团队都获得一个虚拟密钥，每次调用都带有标签，账单会寄到发起请求的地址。在启用这种模式的两周内，公司通常会发现总支出的一个荒谬比例——60% 并不罕见——来自少数员工使用的单个内部工具。仅凭这个数字，就足以证明整个计划的合理性。

意想不到的后果是，你刚刚将一个此前未受监控的变量变成了目标。你这样做是有正当理由的。但一旦一个指标变成目标，工程组织就会对其进行优化，而这种优化必然会从某些地方换取空间。直到为时已晚，才有人问出的问题是：哪个变量将吸收这种变化。

团队在冲刺中对 Prompt 做了什么

这种模式在不同组织之间非常一致，你几乎可以精确到天来预测操作顺序。团队做的第一件事显而易见——缩短系统 Prompt。一个典型的生产系统 Prompt 在数月的事件响应中累积了防御性指令：“如果输入为空，返回 X”；“不要包含两次免责声明”；“将日期格式化为 ISO 8601”。其中许多行确实起到了作用，有些则是多余的。由于没有时间进行妥善的消融实验，团队删除了那些看起来最像装饰的指令并寄予希望。

第二步是削减 Few-shot 示例。原本带有四个示例的 Prompt 被修减为两个，然后是一个，最后是零个，因为每个示例都是数百个 Token 的成本，且会永远影响每一次请求。关于 Prompt 经济性的研究证明，一个精心设计的 Zero-shot Prompt 有时可以达到 Few-shot 的质量，但关键词是“有时”，而当财务部门在监督时，“仔细迭代”绝不是团队在冲刺结束时会做的事。

第三步是减少检索范围。从向量数据库检索前 8 个块（Chunks）的团队降到了 4 个。进行两阶段检索的团队降到了单阶段。系统回答得更便宜了，而且大部分时间回答是正确的，但在缺失的两个块包含实际答案的情况下，就会出现面向客户的准确度缓慢漂移，而成本仪表盘测量不到这一点。

第四步，也是领导团队最终会注意到的一步，是模型降级。昂贵的尖端模型被替换成了更便宜的同系模型，用于处理团队认为“简单”的请求。降级后的路径悄悄处理了 5% 到 10% 实际上并不简单的边缘案例，这些案例的退化看起来像噪音，直到有人把它们画成图表。

这些单独的变化本身都没有错。每一项都可以根据其自身的优点进行辩护。问题在于，它们都是由单一仪表盘上的单一数字驱动的，在一次冲刺中完成，而权衡的另一端没有补偿性指标。

仪表盘上缺少的指标

成本仪表盘回答了一个问题：我们在 LLM 推理上花了多少钱，按团队、功能和客户分类。它没有回答对业务真正重要的问题：我们为每个成功的结果支付了多少费用。如果任务完成率下降了 10%，而 Token 账单减少了一半，这并不是节省——而是在稍微降低成本项的同时提供了一个更差的产品。根据下游经济模型，一旦计入重试率、升级率和人工介入成本，它甚至可能是一个成本更高且更差的产品。

每个成功输出的成本（Cost per successful output）是将费用分摊信号与产品现实对齐的指标。这也是几乎所有组织在推出费用分摊时都没有建立好的指标，因为“成功输出”的成功标准因功能而异，需要一套可运行的评估套件（Eval suite），并且依赖于产品端而非平台端负责的质量门禁。构建它需要一个季度的工作；而推出费用分摊只是 AI 网关中的一个配置更改。难度上的不对称决定了最终交付内容的倾斜。

在第二个指标就位之前，每个费用分摊仪表盘都在含蓄地传达：Token 是价值单位。但它们不是。Token 是成本单位。价值单位是模型成功采取的行动、正确生成的答案、以及无需升级就完成的工作流。一个只衡量成本侧而不衡量价值侧的治理系统，是在要求工程团队去优化一个他们看不见分母的分数。

财务部门参与下的古德哈特定律

经典的表述是：当一个指标变成目标时，它就不再是一个好指标了。这里适用的版本更为犀利：当一个指标变成目标，且优化它的人看不见权衡（trade-off）时，优化必然会渗透到他们看不见的任何变量中。Token 成本曾是衡量 token 成本的好指标，但它衡量产品质量时却糟糕透顶。当 chargeback 将其转变为一个目标的那一刻，团队对其进行了优化，而损耗则流向了输出质量，因为那是未被衡量的部分。

这并不是一个关于坏工程师钻系统漏洞的故事，恰恰相反。团队的行为完全符合激励系统的要求。他们对一个明确的信号做出了理性的反应，且反应的时间线与信号的紧迫性相匹配。缺陷在于信号是不完整的，而且组织建立了一个在成本上以冲刺（sprint）速度运行、在质量上却以季度速度运行的反馈循环。快速循环获胜了。

领导力问题——这确实是一个领导力问题，而非工程问题——在于谁的职责是去察觉财务部门刚刚获得了一个塑造产品的杠杆。CFO 并不打算发布一个重写的 prompt。平台团队没打算这么做，产品团队也不想；他们只是想保住自己的预算，而这正是他们被要求做的事情。这个杠杆存在于三个组织之间的接缝处，而没有人负责这个接缝。

如何让 Chargeback 变得安全

行之有效的模式是将 chargeback 仪表盘与质量仪表盘挂钩，两者由管理预算的同一人负责，并确保在每次评审中两者同步变动。一个将 token 成本降低了 30% 的团队，在你看清其质量 SLO 发生了什么变化之前，其实什么也没达成。如果质量保持不变，那么这次胜利是真实的，值得庆祝。如果质量下降，那么这种变化就是一种恰好看起来像节省的退化，预算评审应将其视作退化处理。

具体而言，这意味着三件事。首先，每个参与 chargeback 的功能都需要一个有负责人、有日期、可运行的 eval 套件，它能以与成本数据相同的频率产生质量指标。这两个数字出现在同一张幻灯片上。团队不能只出示其中一个来为自己的预算辩护。第二，chargeback 政策需要允许“质量锁定预算”——即只有在质量保持不变时才能削减预算，而当某个功能成功提升质量时，预算会自动增加。这将激励从“花得更少”重新对齐为“花得更好”。第三，必须有高层人员——通常是 AI 工程负责人或平台负责人——担任财务、平台和产品交汇接缝处的指定负责人，并有权在质量检测手段就绪之前放缓 chargeback 的推广。

这些举措都不能取代对 chargeback 的需求。Chargeback 是解决原始可见性问题的正确答案，一个在没有它的情况下运作的团队，最终月度账单会达到一个无法向任何人解释的数字。重点在于，chargeback 并非带有工程副作用的财务计划。它是一套披着财务外衣的产品治理方案，那些在发布它时未意识到这一点的组织将会发现（正如该类别中的每个组织所发现的那样）：成本仪表盘始终是一个产品质量杠杆，而在没有检测手段的情况下拉动它，会产生电子表格无法显示的下游成本。

在进入下一个规划周期时，你需要内化的一点是：你放在工程师面前并与预算挂钩的任何数字，都是一项产品决策。Token 成本与延迟、错误率以及任何其他从观察跨越到目标的运营变量没有区别。对待 chargeback 的推广，应当像对待引入任何新的核心 KPI 一样：询问团队会如何做来满足它，必须有哪些抵消指标来防止显而易见的失败模式，以及谁负责在失败模式出现时捕获它的仪表盘。团队会对你给出的任何信号做出反应。领导层的职责是确保该信号正是你真正希望他们去优化的。