很多团队不是没设告警，而是设了之后该响的时候不响、不该响的时候天天响，最后被全员静音。这篇不讲概念，只给管理员一套能照着做的流程：先想清楚按什么口径报警，再决定分几档阈值、通知发给谁、误报怎么收，最后用一次小额实测确认整条链路是通的。
很多团队不是没设告警，而是设了之后该响的时候不响、不该响的时候天天响，最后被全员静音。告警一旦被静音，等于没设。这篇只给管理员一套能照着做的流程：先想清楚按什么口径报警，再决定分几档阈值、通知发给谁、误报怎么收，最后用一次小额实测确认整条链路是通的。过程中涉及的金额、调用量这类数字，都到对应站内页面看当时的数值，不要在文档里写死。
下面按「口径 → 阈值 → 时间窗与作用域 → 通知对象 → 验证与调优」五步走，每一步都配了可执行的判断标准和检查项。不承诺任何告警能百分百防住超支，它解决的是「及时发现」，不解决「结算延迟」这类系统性问题。
先定口径：你的告警按什么算
口径决定了告警能提前多久报警。按已消耗金额最直观，但结算往往有延迟，等数字落到面板上往往已经花完；按预估月末总额适合防累计超支，但对突发调用不敏感；按调用量或 token 数通常指标更快，适合做第一道闸。选哪个，取决于你更怕哪种翻车，而不是哪个听起来高级。
| 口径 | 适合防什么 | 什么情况下不适用 |
|---|---|---|
| 已消耗金额 | 总盘子超支 | 结算有延迟时，报警时钱已经花掉 |
| 预估月末总额 | 月度累计失控 | 业务量波动大时，预估本身不准 |
| 调用量 / token 数 | 突发批量任务打爆额度 | 单价差异大的多模型混用时，量不等于钱 |
- 提醒自己看结算周期：预付费扣额度、后付费出账，两种模式下告警能提前多久是不一样的
- 混合模型场景建议同时挂金额和调用量两条线，一条慢一条快
- 具体差异到 /usage 和 /ai-cost-bill-comparison 核对当时的数字，别照抄别人的结论
分几档阈值：不要只设一条线
只设一条线，结果就是要么天天响没人理，要么响的时候已经来不及。建议至少三档，每档对应不同动作，也只有最高档才值得通知所有人。阈值不要拍脑袋，拿历史用量做基线；没有历史数据时，先按团队日均水平的某个倍数起步，等有数据再收紧。
- 日常预警线用量偏离平时节奏时提醒管理员，动作是「看一眼」，不需要全员知晓。
- 行动线触发后要去查是谁在跑什么，动作是「联系对应 key 的负责人」。
- 硬上限线到达后执行限速或停用，动作要事先和业务方对齐，避免误伤线上服务。
- 基线校准拿近几周用量做参考，基线怎么算可参考 /cost-estimation-from-usage 的思路。
时间窗与作用域：按天、按月还是按项目
按天抓突发，按月防累计超支，两者不冲突，建议都开。作用域一定要分到 key 或项目，不然你只知道「总超了」，不知道是谁超的。同一套 key 多人共用时，先拆 key 再谈告警；不拆 key，告警只能定位到「某个共享凭证」，等于没有责任人。
- 按天阈值要结合业务节律，工作日和周末不是一条线
- 某个 key 一次批量任务就可能顶掉整天额度，这类 key 要单独放宽或单独盯
- 作用域分级建议：总账 → 项目 → 单个 key，三层都能下钻
- 拆 key 前先盘点谁在用哪套凭证，避免拆完没人认领
作用域拆得越细，告警越准，但配置量也越大。小团队可以先做到项目级，等有人因为超支被追责了再往 key 级拆。判断标准很简单：如果你看到告警后第一句话是「谁干的」，说明作用域还不够细。
通知发给谁、发到哪、怎么写
一条告警至少写清四件事：谁超的（key 或项目）、超了多少、触发的哪一档、现在要做什么。缺任何一项，收到的人都要额外问你一遍。通知渠道别只留一个邮箱，管理员常看的群或工单系统更实际；有值班轮换的团队，要留兜底接收人，避免值班的人正好离线。
- 责任人
- 该 key 或项目的实际使用方，不是管理员自己
- 管理员
- 负责处理告警、决定是否限速或停用的人
- 兜底接收人
- 值班离线或休假时接手的人，避免告警断链
- 明细直链
- 告警里带上能点开看当时的数字和用量的入口
告警里放直链能省掉大量来回问。站内可用的入口有 /tools/model-cost-calculator 和 /price-watch，点进去就能看到对应的估算和价格变动情况。不要把纯文本数字贴在告警里，数字会变。
上线前跑一遍验证，上线后按节奏调
配好不等于生效。上线前必须用一次小额真实调用或专门的测试 key 触发最低档阈值，确认通知真的收到、延迟在可接受范围内。没跑过这一步的告警，都只能算「理论上存在」。
- 触发最低档用测试 key 打一次小额调用，看管理员是否收到提醒。
- 检查延迟记录从调用发生到通知到达的间隔，超出团队可接受范围就换更快的口径。
- 确认可读性看通知里四要素是否齐全，直链点开是否能看到明细。
- 上线后每周复盘头一个月每周看一次误报记录，长期不触发和天天误触的阈值都改掉。
- 对账兜底结算延迟、缓存命中、重试重发都会让账单和告警不一致，这类偏差靠 /monthly-billing-reconcile 对账解决。
告警解决的是「及时发现」，不是「保证不超支」；把它当成提醒机制，而不是保险。下一步把团队历史用量和当前账单拉出来对一遍，再决定三档阈值画在哪，顺便去价格变动追踪页确认常用模型有没有调价，避免阈值还按旧价算。→
常见问题
预算告警设多少合适？
没有通用数字，得看你自己的用量基线。稳妥做法是先拉一段历史用量，取团队日均或日均消耗，把最低档设成略高于正常波动、行动线设在明显异常的倍数上。首次接入没有历史数据时，先用一个偏保守的值，跑两周再根据实际触发情况调整。各类服务的价格档位可以到站内官方 API 价格页对照当时的数字。
告警设了但没收到通知，先查什么？
按这个顺序排查：一是告警条件本身有没有被触发（阈值填错、时间窗写反是最常见的）；二是通知渠道是否被限流或进了垃圾箱；三是数据本身有延迟，结算类指标往往落后于实际调用，别拿实时心态等它。先用测试方式主动触发一次最低档，能收到再谈其他原因。
告警响个不停，怎么减少误报？
先分清是阈值太低还是业务本身波动大。阈值太低就往上调，或者改成连续两个周期超标才报；波动大就按作用域拆开，把批量任务和日常调用分到不同 key、用不同阈值。另外把低档告警只发给管理员，别一开始就全群推送。长期误报的代价是所有人开始无视告警，比不设还危险。
