先统一口径
谁付费、按什么维度分摊、失败与重试算不算，这些要在动手前定下来。为什么：口径不定时各部门各算一套，开会只能争论数字；定下来之后哪怕不完美，也能连续观察并逐步修正。
埋点要落到请求级
至少记录场景、租户、模型、输入输出长度、是否重试与耗时。怎么落地：在网关或接口层统一采集，避免各应用各写一套；边界是日志要脱敏，提示词正文可不落库，只留长度与哈希值。
预算与告警机制
按月设预算，按阈值设告警，超额要有审批与降级预案。为什么不能只做事后分析：成本事故往往在几小时内发生，等月报出来已经花掉了；告警要能触发限流或切换轻量模型，而不只是发消息。
责任人与评审节奏
指定一个对成本负责的人，月度评审一次异常与改进项。做法是把评审挂到已有的经营会，不另开新会；边界是成本目标由业务与财务共同设定，技术团队负责实现与解释偏差，不单方承诺降幅。
适用与不适用
适合谁
- 准备建立成本治理机制的企业与集团
- 已有平台团队、能改采集链路的组织
- 多部门共用模型接口、需要分账的集团
不适合谁
- 单一场景、花费占比很小的团队或部门
- 无法获取调用明细的纯采购方与岗位
典型场景
一家制造企业的数字化部先定了口径：按场景分摊、失败与重试计入、按月结算。随后在网关加埋点，把场景与租户写进日志，再设月度预算与七成告警。第一个月就发现两个重复调用接口，第二个季度进入常规评审。
可执行步骤
- 先定口径：谁付费、按什么维度分摊、失败与重试是否计入，写进制度
- 在网关或接口层统一埋点，采集请求级的花费与质量明细，按请求落库
- 按场景设定月度预算与分级告警阈值，明确触发后的动作，并指定触发人
- 指定成本责任人，把成本评审挂进已有的月度经营会，不与新会重复
- 准备超额审批流程与降级预案，写进运维操作手册并演练，至少跑一次
常见坑
- 口径没定就上报表，各部门数字对不上，会议开成辩论赛，问题原地不动，进度也拖了。
- 埋点只在部分应用做，账单拆不开，公共成本越滚越大，归属率始终上不去，治理停在纸面。
- 只设告警不设动作，超额消息发了一堆，没人知道该限流还是降级，最后照旧，告警被忽略。
- 责任人挂在不相关的岗位，评审流于形式，改进项长期无人关闭，同样的问题反复出现。
自检与验收清单
- 计费与分摊口径是否经财务书面确认，有效期多长
- 埋点是否覆盖全部调用入口与重试，漏掉如何补救
- 预算告警是否绑定限流或降级动作，谁有权触发
- 成本责任人是否明确到具体岗位与代理人
- 降级预案是否演练过并记录结果，结果是否复盘
常见问题
口径定不下来怎么办
先定一个能跑通的临时口径，明确有效期与复核时间，用它连续统计两个月再调整。追求一次定完美通常会导致项目停摆；只要口径稳定且写下来，后续修正的成本远低于没有数据。
埋点会不会涉及个人信息
会，取决于记录内容。建议只采长度、场景、耗时与哈希，不落提示词正文与用户身份；确需留存的按数据分级管理并限制访问。具体合规判断由客户方法务与数据负责人确认。
成本目标定多少合适
先看基线。没有基线时定降幅没有意义，建议先承诺建立可视与告警，再按季度设定改进项。目标由业务与财务共同确认，技术团队对实现路径负责，不对降幅单方承诺。