三层看板
花费层看日花费、单位任务成本与预算消耗进度；用量层看调用次数、token 与缓存命中；质量层看成功率与接管率。为什么三层要放一起：只看花费会误判，花费降了可能是质量掉了，业务已经受影响。
四个异常模式
单请求 token 突增、重试风暴、缓存命中骤降、某场景调用量异动。怎么用：把这四类做成固定查询并配阈值，触发时先看最近的变更记录；多数异常都能在变更清单里找到对应条目，定位比盲查快得多。
预算告警要联动动作
告警只是通知，动作才止血。常见联动是超额后限流、切轻量模型或关闭非关键功能。为什么必须预先定义：事发时再讨论用哪种手段，往往已过了几个小时；动作要与业务方提前约定并写进手册。
变更审批与月度复盘
提示词、模型与检索配置的变更都要走审批并记录版本。做法是把成本影响写进变更单，上线后观察一天；边界是紧急修复可先处理后补记录，但要在二十四小时内补齐，否则复盘时说不清原因。
适用与不适用
适合谁
- 已建立基础监控与值班制度的运维团队
- 月度 AI 支出已进入预算科目的企业
- 多场景共用模型接口的平台方与部门
不适合谁
- 调用量小、尚无预算约束的项目或试点
- 没有权限查看账单明细的岗位与人员
典型场景
一家在线旅游平台的运维在节前把预算告警调到七成，并预设降级动作：超额后把推荐文案切到轻量模型，保留客服主链路。假期第一天推荐场景调用量翻倍，告警触发后自动降级，主链路未受影响，节后再调回。
可执行步骤
- 搭三层看板，把花费、用量与质量指标放在同一块屏上，指标口径统一
- 固化四个异常查询，设定阈值、通知渠道与值守人，异常时先查变更
- 与业务方约定超额后的降级动作、顺序与恢复条件，并写进操作手册
- 把成本影响写进变更单，上线后连续观察一天再关闭，观察后再关闭
- 每月复盘异常与改进项，更新阈值、动作与操作手册，形成月度结论
常见坑
- 看板只有花费没有质量，降本降出了问题，一周后才被投诉发现，回滚也来不及，损失已造成。
- 告警只发消息不联动，值班人员不敢动生产，只能等到天亮再处理，成本已经翻倍，损失无法追回。
- 变更不记录版本，异常时无法对照时间线，排查只能靠猜，平均恢复时间被拉长，复盘也无据。
- 阈值一年不更新，业务量翻倍后告警天天响，最后被整体静音，等于没有监控，风险敞口很大。
自检与验收清单
- 花费、用量与质量是否在同一看板，口径是否一致
- 四类异常查询是否固化并设定阈值，阈值多久复看
- 降级动作与顺序是否与业务方书面约定
- 变更单是否记录成本影响与版本号，能否回滚版本
- 告警阈值是否按月复核并及时调整，谁负责调整
常见问题
小团队需要三层看板吗
可以先做花费与质量两层，用量层用账单替代。关键不是层数，而是能回答两个问题：钱花在哪，效果有没有变差。等场景增多再补用量层，避免一开始就搭一套没人维护的看板。
自动降级会不会影响体验
会，所以降级要分级：先降非关键场景，再降模型档位，最后才限流。降级前应与业务方约定可接受范围与恢复条件，并在页面上做提示。没有约定的自动降级，容易在关键时刻引发客诉。
成本异常一般多久能定位
有完整变更记录与标签时，通常当天能定位到具体接口或版本；没有记录时只能按场景逐层缩小范围，往往要几天。定位速度主要取决于埋点与变更管理，而不是分析工具本身。