用 AI 分析日志：怎么问才问得出线索

排障最耗时的部分，往往不是定位，而是"看"。几千行日志里真正有用的可能只有三行。把这一步交给 AI 是可行的，但前提是你要给它看得懂、且脱过敏的输入，否则得到的只是看似专业的猜测。

一、先说清楚 AI 能做什么、不能做什么

• 能做：归类错误信息、找出异常模式、整理时间线、提出可验证的假设
• 不能做：替代你对环境的判断，也不保证结论正确

把它当成一位没进过机房但读得很快的同事：它擅长归纳和提醒，不擅长替你做现场判断。这个定位清楚了，用法就顺了。

二、输入要这样处理

直接把原始日志整段贴进去，效果通常很差：噪声太多、上下文缺失、还可能泄露敏感信息。三步预处理能显著提升结果质量。

1. 裁剪：限定时间窗口、只留相关组件、按关键字过滤
2. 脱敏：内网 IP、账号、手机号、密钥、令牌一律替换
3. 附背景：系统是做什么的、最近有没有变更、现象是什么、已经排除了什么

三、提问模板：四要素

把问题写清楚的结构其实很固定，四要素缺一个，答案质量就下一档。

• 现象：什么时候开始、表现是什么、影响谁
• 范围：哪台机器、哪个服务、什么时间段
• 已排除：哪些猜测已经验证过不成立
• 想要的输出：要假设清单、要时间线，还是要修复建议

例如："这是某业务系统 10:00–10:20 的应用日志与系统日志，现象是接口偶发 500，已排除数据库连接数不足。请给出按可能性排序的原因假设，每条附上验证方法。"这类提问得到的答案，通常可以直接拿去用。

四、让结论可验证

AI 给出的原因往往"讲得通"，但讲得通不等于成立。要求它按"假设 + 验证方法 + 预期结果"的三段式输出，然后逐条去系统里验：看指标、看配置、看上下游日志。

• 能验证的要落地验证，不能验证的标记为待查
• 假设被推翻也是收获：排除项写进记录，下次不用重复排查
• 多个假设并存时，优先验证成本最低的那个

五、把结论沉下来

排障结束后的十分钟，决定了这次故障的价值：现象、原因、处理、后续动作，整理成一条记录进知识库。下次同类问题先查知识库，再问 AI，效率会明显不同。

长期看，最划算的做法是把重复出现的告警直接做成监控规则——AI 帮你发现一次，监控帮你发现每一次。