用 AI 排障的这几周，我总结出一条最值钱的判断标准
背景是智汇社区从今年开始把不少日常运维脚本迁到了 AI 辅助写的状态，我也慢慢养成先让模型给方案、再自己审代码的习惯。前阵子社区偶尔出现接口偶发超时，白天没事，晚上高峰就报 502，查了两天没头绪。
我一开始的做法是让 AI 直接"修复超时"，结果它给了一堆并发调优、加缓存、改 nginx 配置的建议，听着头头是道，但都是隔靴搔痒——因为问题根因根本没定位清楚。这其实是大部分人用 AI 写代码/排障最容易踩的坑：把 AI 当成"直接给答案"的工具，而它本质上是"在给定上下文里补全"的工具。上下文给错了，答案再好也是错的。
后来我换了个思路：第一步不碰代码，先把问题讲清楚。我把 nginx 错误日志、supervisor 日志、最近一次改动 commit 记录、以及请求流量的时间段分布，这几样东西原样贴给模型，然后只问一句"根据这些日志，你觉得最可疑的环节在哪，为什么"。这一步逼着模型基于证据推理，而不是凭经验编故事。
它圈出了两个可疑点：一个是某个 worker 进程连续几小时内存缓存在缓慢上涨没释放，另一个是数据库连接池在高峰时段的等待数异常。我顺着这两个点去查，发现是我上个月上线的一个定时任务，每半小时全量扫一次某个表并在内存里重建索引，白天数据量小没事，夜里累积到一定程度，内存占用翻倍，触发旧进程被系统 OOM 杀，新进程冷启动又赶上流量高峰，就出现间歇超时。
修复其实很简单：把全量重建改成增量更新，加上内存上限保护，再给任务加了错峰时间。改动不到三十行，问题当晚就稳定了。
这件事让我真正接受了用 AI 工作的一个原则：AI 的价值在"缩小排查范围"和"帮你看漏了什么"，而不在"直接改对"。你越早把原始证据喂给它、越早让它做"假设优先级排序"而不是"直接输出修复代码"，它的准确率会高一整个量级。反过来，你越是想省事直接要答案，越容易被它那种流畅的自信带进沟里。
可复用的方法我记成了三步：一，出问题先整理原始日志和时间线，别急着贴需求让 AI 改；二，让 AI 先给出"最可疑的三个环节和理由"，逼它做排除法；三，对修复合入前，自己把改动逐行审一遍，确认改的是根因不是表象。这三步听着像废话，但真正照着做的人不多，多数人还是习惯拿到问题就甩给 AI 要个补丁。
