把线上故障排查交给 AI 之后，我总结了三个它最容易把我带沟里的坑

凌晨两点告警炸了，服务超时率飙到 40%。我半梦半醒把日志片段和监控截图丢给 AI，它三秒定位"疑似数据库连接池耗尽"，还附了三条排查命令。我顺着跑了半小时，指标没回来，人快醒了。最后发现真正的原因：上游一个新发布的服务响应变慢，把整条链路拖垮的。连接池超时是结果，不是原因——AI 的"定位"自信，但错得离谱。

那次之后我学乖了。AI 排查故障确实快，但它有三个坑，专门坑半夜不清醒的人。

第一个坑：把相关当因果，先入为主。 日志里刷得最凶的是连接池超时，AI 就咬定是连接池。实际上那是被上游慢查询拖出来的表象，病根在别处。它排优先级的方式是"哪个错误显眼排哪个"，而线上故障最阴险的偏偏是那个不显眼的根因。AI 给的第一个结论听起来总是最合理的——这恰恰是它最危险的地方，因为你不会去怀疑一个看起来最像的答案。

第二个坑：拿残缺的信息下笃定的结论。 我给的日志是截取的片段，AI 不知道一小时前刚发过版、不知道上游昨天改过配置、不知道这只是全量时间线里的一小段。它基于残缺信息输出一个"最可能"的答案，语气跟基于全量信息时一模一样笃定。半夜排查的人最容易照着这个语气跑偏——你都来不及问一句"你确定吗"。

第三个坑：给的命令直接跑，容易把自愈当治好。 它建议重启连接池、清本地缓存。我照做之后指标确实回落了，我以为修好了。早上高峰一来又炸——其实凌晨指标回落是夜间流量自己降下去的，跟我的操作半点关系没有。排障最怕把"时间自愈"误判成"处置有效"，AI 可不管这个，它只管给下一步命令。

我的判断很明确：AI 适合当排查助理，不适合当排障结论的唯一来源。 我现在的规矩是：AI 负责列可能性、给命令、查文档，省掉我翻文档的时间；但因果链必须自己验证，它的每个结论我先问一句"证据呢，哪条日志支持的"。这个我建议先收藏，下次值班出事时拿出来对一遍，能少走半小时弯路。

你们线上出问题会让 AI 先定位吗？有没有被它带沟里过——我特别想听反面案例，看还有多少坑是我没踩到的。