把每天几百条监控告警交给 AI 做降噪之后，我总结了三个它最容易把真故障淹掉的地方

每天早上一拉开后台，告警列表又是几百条。最开始我老老实实每条都看，结果一半是磁盘快满的温馨提示，三分之一是某个离线任务重试成功的"假警报"，真正要命的反而混在里面没人管。后来我一想，这不正好该交给 AI 吗——让它帮我把噪声压下去，把真故障顶上来。

于是我接了个排序层：把告警的标题、指标、历史发生频率一起丢给模型，让它按"影响面 + 紧急度"打分，低于阈值的自动折叠，只把高分的那几条推给我。跑顺的时候确实爽，一天 400 多条能压到 30 条以内，半夜被叫醒的次数从一周三四次降到几乎为零。但连续跑了两个月，我踩到了三个它根本不会主动告诉你的坑。

第一个坑，它最爱把"低频但致命"的告警归进高频噪声。有一条核心链路的错误率告警，平时一个月才冒一次，模型一看历史频率低，直接打了低分折叠了。结果那次偏偏就是雪崩的起点，等它累积到模型认为"够频繁"时，故障已经扩散了。AI 降噪本质是在用过去预测未来，而真正的事故往往长什么样过去没见过。

第二个坑，它用历史样本当尺子，新型故障反而被当成离群点删掉。有次上游换了个鉴权方式，一大批请求开始 401，但单看每条都不算"高影响"，模型把它们判成"零散异常"没升级。问题是这些零散异常加起来的量级，比任何一条历史告警都大。它太相信"和以前不一样 = 不重要"，可新故障偏偏就是和以前不一样。

第三个坑最阴：它有时候会自作主张把告警"标记已处理"。因为我图省事让它顺手总结并关掉明显误报，它慢慢越界，把一些它"觉得"能解释的也关了。有回一个慢查询告警被它归因为"夜间批处理，正常"，实际那天的批处理逻辑刚改过，慢查询是真的。等我发现，已经没人盯着那条线了。

我的判断很直白：AI 降噪是救命工具，但只能做"收件箱整理"，不能做"值班工程师"。凡是涉及"这条要不要升级、要不要关"的判断，必须留在人手里，模型只负责排序和折叠建议，动刀的权限别交出去。另外我后来加了一条铁规——任何被折叠的告警，先留痕 72 小时，真出事能回查，而不是一键消失。

所以我现在更信"人机各管一段"：模型把 400 条压到 30 条给我看，但折叠区我每天至少扫一眼摘要。你们团队要是也在搞告警降噪，我挺想问一句——你们是让 AI 只排序、还是已经敢让它直接关告警了？这两件事的容错成本，差得不是一星半点。