报错日志贴给 AI：五步查到根因，留一张排查记录表

一句话结论

把完整堆栈、复现步骤和最近改动一起交给 AI，先让它列全假设再逐条验证，五步能锁到根因，顺手留下一张排查记录表。

这篇解决什么问题

上周预发环境的支付回调抛了个空指针，我第一反应是去搜堆栈里的关键字，翻了二十多分钟没头绪。后来换了个做法：把报错原样交给 AI，让它按固定流程带着我走，四十来分钟定位到是连接池参数改小之后超时被吞掉。这篇就是把那套流程固定下来。

适用：有明确报错文本、能复现或至少能捞到日志的服务端问题。不适用：纯性能劣化但没有报错、以及要抓包看协议层的场景，这类问题这套流程只能帮你排掉一半。

开始前要准备什么

• 一段完整报错，含堆栈前后各十来行，别只截最后一行
• 环境信息：语言与框架版本、部署方式、报错时间点
• 最近三天内的改动清单，配置、依赖、SQL、发版都算
• 能开网页的浏览器；DeepSeek、豆包网页端都有免费额度，跑完一轮够用
• Cursor 这类编辑器内置的对话也能用，看你手头习惯哪个
• 一张空表格，或者干脆让 AI 最后直接吐 markdown
• 预计耗时：信息齐全的话，一轮走完通常 30 到 50 分钟

具体怎么做

第 1 步 · 先把现场信息补齐

很多人贴报错只贴最后一行，AI 只能回你一句“检查空指针”。把它当成刚入职的同事，它看不到你的机器，你不说它就不知道。这一步先让它告诉你还缺什么。

你是后端排障助手。下面是我遇到的一段报错，我掌握的现场信息在【已知】里。
【已知】
– 服务：order-api（Java 17 + Spring Boot 3.2）
– 环境：预发，单实例
– 报错时间：昨天下午两点二十左右，持续约三分钟后自行恢复
– 报错原文：（在此粘贴完整堆栈）
– 复现步骤：提交订单后点“确认支付”必现，重试第二次正常
– 最近改动：昨天把 Redis 连接池最大连接数从 64 调到 16
请只做三件事：
1. 要定位这条报错的根因，最少还需要哪些信息，按重要性排序，最多 8 条；
2. 每条说明为什么需要、去哪个日志或配置或监控面板能拿到；
3. 这一轮不要给根因猜测，不要给修复方案。
输出一张表格，三列：需要的信息｜为什么需要｜去哪里拿。

预期产出：一张五到八行的信息清单，每行都标了出处。多数时候你会发现自己漏了“影响范围”或者“最近改动”这类关键项。

第 2 步 · 只列假设，不许下结论

现场补齐之后，最大的诱惑是直接问“这是什么原因”。我在实操中发现，只要你先抛出自己的猜测，AI 就会顺着你的猜测往下编。这一步要在提示词里把“给方案”这条路堵死。

上一轮的现场信息我已经补齐，补充如下：
【补充】（把新拿到的信息贴进来）
现在请你列出可能导致这个报错的假设，要求：
1. 至少 6 条、最多 10 条，按可能性从高到低排序；
2. 每条写清楚三件事：假设内容、它成立的话应该观察到什么现象、什么现象能直接否掉它；
3. 假设要具体到组件和参数层面，不要写“代码 bug”“网络问题”这种笼统说法；
4. 明确区分哪些是本次改动引入的，哪些是历史遗留被这次改动触发的；
5. 这一轮仍然不要给修复方案。
输出用编号列表，一条一段，不要合并。

预期产出：六到十条带编号的假设，每条都写了成立时该看到什么。你自己先扫一遍，把明显对不上的划掉，剩下的带进下一步。

第 3 步 · 把假设翻译成验证动作

假设本身不解决问题，能动手验的才行。这一步是把“可能是连接池”变成“去监控看 active 连接数有没有打满”这种带具体动作的话。

把上一步假设清单里排前 5 条的，各设计一个验证动作。要求：
1. 每个动作必须是我 5 分钟内能做完的：查一条日志、跑一条命令、看一个监控指标、改一处配置复现一次；
2. 写清楚具体命令或具体日志关键字，不要写“检查一下 Redis”这种话；
3. 每条注明判定标准：观察到结果 A 代表假设成立，结果 B 代表假设不成立；
4. 按“最快能排除的排前面”重新排序，不要沿用原来的可能性顺序；
5. 标注哪几条可以合并成一次验证。
输出格式：假设编号｜验证动作（含命令或日志关键字）｜判定标准｜预计耗时。

预期产出：一张验证清单，每条都能直接执行。我跑的时候排第一的那条两分钟就出结果，一下砍掉一半可能性。

第 4 步 · 回填证据，让它做排除

验证结果要原样贴回去，包括那些没验出东西的。这一步 AI 的角色从出主意的人变成裁判，它要做的是排除，不是继续发散。

我把验证结果贴回来，格式是“假设编号：实际观察到的结果”。
【结果】
H1：连接池 active 连接数打满 16，等待队列长度 200 以上，符合结果 A
H2：慢查询日志无新增记录，符合结果 B
H3：线程池队列长度正常，证据不足，日志级别没开到 DEBUG 拿不到
H4：（继续按同样格式补充）
请你：
1. 逐条判定假设成立、不成立还是证据不足，并说明判断依据；
2. 对成立的假设，往下再拆一层，给出下一轮要验证的子假设，2 到 3 条即可；
3. 对证据不足的，说明还差什么证据、怎么拿到；
4. 最后给一句结论：当前最可能的根因是什么，置信度高中低，还差哪一步才能确认。
不要给修复代码，先把根因确认清楚。

预期产出：一份逐条判定的结果，末尾一句带置信度的根因判断。置信度写“低”的时候别硬上，说明证据没到位，退回第 3 步补验。

第 5 步 · 沉淀成一张排查记录表

问题修完人就松劲了，记录往往断在这一步。但下次撞上同类报错，这张表比你的记忆靠得住，交接给同事也省口舌。

把这次排查整理成一张排查记录表，用 markdown 表格输出，列固定为：
时间｜现象｜当时的假设｜验证动作｜结果｜结论（排除 / 确认）｜下一步
要求：
1. 按时间顺序还原整个过程，包括走错的弯路，不要美化；
2. “结果”一列只写客观观察，不写判断和推测；
3. 表格下面补三行：根因一句话、触发条件、防止复发的检查项，检查项最多 3 条；
4. 语言用工程师自己能看懂的白话，不要写成汇报材料。

预期产出：一张七列的 markdown 表，下面跟着根因、触发条件、防复发检查项。直接粘进 wiki，或者扔进仓库的 docs 目录。

实测记录

五步里第 2 步和第 4 步最影响结果，省掉任何一步，整个流程基本退化成闲聊。

最容易错的 3 个地方

1. 只贴最后一行报错，AI 只能给通用答案。纠正：连堆栈上下文和最近改动一起贴。
2. 先说了自己的猜测，AI 会顺着编。纠正：第一轮明说“不要给根因和方案”。
3. 验证完不回填结果，假设清单烂尾。纠正：每条结果都回贴，没结论的也写上去。

可复用的东西

五段提示词存成一个 markdown 文件放在项目 docs 下面，下次报错直接复制，只改【已知】和【结果】两段内容。顺序别调，尤其是第 2 步那句“不许给结论”，省了它后面全白搭。

• 第 1 步：现场补齐清单，标了去哪拿
• 第 2 步：假设列表，带成立与否掉的判据
• 第 3 步：验证动作，含命令和判定标准
• 第 4 步：排除结论，标置信度
• 第 5 步：七列排查记录表，可直接进 wiki

这套流程没什么玄的，本质是把“猜”换成了“列出来再一条条排除”。走得慢一点，但每一步留了痕迹，下次同类报错能省一大半时间。你最近一次排查，是卡在收集信息，还是卡在验证这一环？

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接