用 AI 做日志初筛：从报错堆栈到可执行排查清单的四步工作流

线上出问题时，最先到达现场的往往不是根因，而是日志。几千行报错、多个服务交错输出，把日志初筛交给 AI，是让它先整理出可核对的线索，再由人做决定。

一、为什么日志初筛值得交给 AI

人工看日志有三个瓶颈：量大，关键的第一条异常常被正常日志淹没；上下文断裂，堆栈只给出出错点；重复劳动，不同人看到同一类报错，会重复做相同的检索。

二、先做脱敏与分段再提问

发给 AI 之前先做两步准备。一是脱敏：替换真实用户标识、手机号、邮箱、Token、密钥和订单号，用 USER_001、ORDER_001 统一替换。二是分段：按一次故障、一个请求或一个时间窗口切分，保留段首段尾时间戳，并注明服务名、版本和最近变更。

三、四步工作流

第一步：定位报错锚点

先找第一条异常，而不是最醒目的一条。很多后续报错只是连锁反应，例如数据库连接失败后，业务层、网关层都会各自再报一次。锚点通常时间最早、级别最高，且后续报错都与它在时间或请求标识上相关。

第二步：还原调用链

围绕锚点向前回溯、向后延伸：向前看请求从入口到报错经过了哪些服务，向后看报错后触发了重试、降级还是直接失败。输出简化的调用链，标注耗时和返回码，排查范围就缩小到一两个环节。

第三步：区分偶发与必现

偶发问题常与并发、超时、资源抖动有关，同一操作有时成功、有时失败；必现问题常与逻辑、配置或数据异常有关，固定输入下稳定复现。对比成功与失败样本的差异：参数、版本、实例编号和耗时。差异集中在某个实例或时段，优先查部署和资源；集中在某个参数组合，优先查逻辑和数据。

第四步：输出可执行清单

最后一步不是写一段分析，而是输出清单。每一项写清：要查什么、去哪里查、预期看到什么、查到后下一步做什么。

四、一个 Nginx 与应用报错示例

下面是一段脱敏后的典型日志，Nginx 返回 502，应用日志同时出现连接超时：

10:12:03 nginx upstream timed out, request_id=REQ_001
10:12:03 app ERROR connect timeout to db-primary, REQ_001

提问可以这样写：以第一条超时为锚点，还原 REQ_001 的调用链；对比同一接口 10:00 至 10:10 的成功日志，找出差异；最后输出按优先级排序的清单。合理方向是：先查数据库在该时段的连接数和慢查询，再查连接池配置，然后查 Nginx 超时与重试设置。

五、AI 输出的复核清单

• 每个结论能否在日志或监控中找到证据，是否标明时间和请求标识。
• 调用链里的服务顺序是否与真实架构一致。
• 偶发与必现的判断是否有成功样本和失败样本对比。

六、常见坑

一是不加筛选地贴入全部日志，噪声会淹没锚点；二是不给成功样本，没有对照组就无法区分偶发与必现；三是直接执行 AI 给出的修复命令，生产写操作必须先在测试环境验证；四是忽略时间对齐。