推理账单：没人愿意背的损益表科目

这是正确答案，但很少落地。原因是它每次被推销到任何一个团队那里，都会被理解成工程在把账单甩给别人。反弹意见高度一致："我们没选模型。我们没写 prompt。我们没办法控制 token，所以不该背这笔账。"这种反弹在当时很难反驳，但其实是错的。产品负责人确实能控制支出——他们决定这个功能要不要上、要不要严格做使用门槛、廉价模型的降级路径是否可接受、Agent 循环三次还是三十次。

分摊的技术基础已经摆在那里。AWS 在 Bedrock 里暴露了"按应用"的推理 profile，会给每次调用打上成本分摊元数据。主流 FinOps 平台也能按功能、按客户、按业务单元给 LLM 支出做分组，前提是遥测在调用点做了标签。这些事一旦组织决定做，技术上并不难。难的是那个决定，而那个决定需要一个论坛——一个能让工程、产品、财务把分摊规则谈出来、不会有一方拍桌走人的论坛。

关停阈值必须事先约定​

一旦分摊到位，问题就从"怎么把账单压下去"变成"哪些功能值得它的账单"。后一个问题更难，因为等一个功能开始上线被度量的时候，它就有了自己的支持者。工程师建了它。PM 拿了它的功劳。用户开始依赖它。要杀掉它，就得正面对抗那个把它发出去的团队，而"单位经济学不行"在没有事先约定的对话里，永远输给"可是用户喜欢它"。

修复办法是在功能发布前就事先约定一个关停阈值。单次产出成本超过某个数字，或者毛利率低于某个数字，就会触发一场团队事先同意过的关停讨论。讨论本身依然不好开，但它是对着一个团队在没有情感投入时挑出的数字进行的，而不是对着最大嗓门的利益相关方可以临时翻案的"感觉"。

事先约定的阈值还会改变工程的优化方向。当关停阈值白纸黑字写下来，团队就会把降本当成一项有截止日期、有负责人、有指标的功能开发。没有这个阈值时，降本永远是"下个季度再说"，每个季度都是，直到账单逼出一场 panic。

单次产出成本的目标会进到产品需求文档里，和延迟目标、满意度目标并列。如果一个功能在约定的优化窗口结束后还达不到目标，它就 sunset 掉。这个阈值不是对团队的惩罚——它是允许团队停止投入一件挣不到自己位置的东西。

推理是你第一次面对的、谈不下价格的计算成本​

云支出有一个你财务团队习惯了的杠杆：重新谈价。三年承诺协议、定制定价、超大规模厂商赠金、多供应商分散。你 CFO 跟 AWS 客户经理是有关系的。他们知道怎么开口要折扣。

推理不一样。单位价格由一家你财务团队从没见过的厂商定，折扣面很窄，杠杆不对称。你可以换模型，但换模型的调试成本，大多数产品团队都低估了。你可以自托管，但自托管推理的盈亏平衡点，大多数公司很多年都到不了。你可以谈量大折扣，但折扣幅度小于厂商单方面调整的年度价格变动。

当下的定价里包含的更多是风险投资和超大规模厂商的补贴，而不是稳态的销货成本。等这层补贴收紧，那条在"工程工具"里悄悄长大的线，会在没有预警的情况下被重置往上。那些没有提前练出跨职能肌肉、做不出"哪些 AI 功能留下、哪些走廉价模型降级、哪些 sunset"这种有据可依判断的组织，会在那第一个寒冬里内耗——争论削减究竟从谁的预算里扣。这些争论会非常熟悉——它们就是十年前云支出制造出来的同一批争论，只是当时 FinOps 还没给它们提供一个论坛和一套词汇。

工具能帮你之前，组织得先做哪些决定​

仪表盘、分摊平台、按功能打标签，这些今天都已经具备。它们不是缺的那一环。缺的是一系列领导团队还没坐下来做的决定：

• 谁是每个 AI 功能的有名有姓的预算负责人，并且明确拥有杀掉它的权力？
• 推理支出在损益表里住在哪——工程间接成本，还是产品销货成本？
• 季度复盘上，推理支出和营收、采用率并排汇报，还是埋在云账单的行项里？
• 每个功能的事先约定关停阈值是多少，触发时由谁签字？
• 哪个高管负责那个跨职能论坛——让工程、产品、财务把分摊规则吵明白？

这些问题不是技术问题。它们不会被一个工具解决。它们最终会被回答，往往是被一个失去耐心的 CFO，或者一个不再接受借口的董事会。早一点回答这些问题的组织，会显得他们 AI 的经济学运气好。其实不是。他们有一个论坛、一个负责人、一个数字——这三样东西，是在推理还没成为 AI 账单 85% 的年代画好的组织架构图里默认没有的。补上它们，才是真正的领导力动作。其余的，都是优化。