第7讲｜用 AI 快速定位线上 Bug 的思路模板

专栏：AI 编程提效实战 30 讲

标签：AI编程 / Bug排查 / 日志分析 / 线上问题 / 工程效率

先说结论

线上 Bug 排查最怕的不是问题复杂，而是你一上来就让 AI "猜原因"。

很多人把报错日志丢给 AI，问一句：

这个问题是什么原因？

AI 往往会给你一串看似合理的可能性：网络抖动、缓存不一致、空指针、并发问题、配置错误。每个都像那么回事，但你还是不知道下一步该查哪里。

更有效的方式是：先让 AI 帮你整理事实，再构建假设，最后把假设拆成可验证的排查动作。

这篇给你一套可以直接复制的线上 Bug 排查模板，适合用在日志、告警、接口异常、用户反馈和最近发布变更的综合分析里。

为什么不能直接让 AI 猜原因

线上问题的上下文通常是不完整的。

你手里可能只有一段错误日志、几条用户反馈、一个告警指标，最多再加上最近发布记录。这个时候如果直接让 AI 判断根因，它很容易把"可能性"写成"结论"。

真正可靠的排查应该分三层：

1. 事实层：已经确认发生了什么

2. 假设层：可能由哪些原因导致

3. 验证层：每个假设如何用日志、指标、代码或数据验证

AI 最擅长的不是替你拍脑袋，而是帮你把混乱信息整理成可执行清单。

我固定使用的 5 步排查流程

第 1 步：先收集事实，不要先问结论

把你掌握的信息按类别喂给 AI，而不是只贴一段日志。

建议至少包含这些内容：

• 报错日志或异常栈

• 发生时间和影响范围

• 相关接口、任务、服务名

• 最近一次发布或配置变更

• 用户反馈或复现路径

• 关键监控指标变化

可以这样问：

你现在是我的线上问题排查助手。
请先整理事实，不要直接下结论。

我会提供日志、告警、用户反馈和最近变更。

请输出：
1. 已确认事实
2. 仍然缺失的信息
3. 时间线
4. 受影响范围
5. 不能从现有信息推出的结论

要求：
- 不要猜根因
- 不确定的地方标注"不确定"
- 明确区分事实和推测

这一步的价值，是把 AI 从"推理模式"先拉回"记录模式"。

如果事实没有整理清楚，后面的假设大概率会跑偏。

第 2 步：让 AI 建立时间线

很多线上 Bug 的线索都藏在时间里。

比如：

• 10:02 发布新版本

• 10:08 错误率开始上升

• 10:12 用户开始反馈登录失败

• 10:15 缓存命中率明显下降

这些信息单独看都不够，但连成时间线后，就能快速缩小范围。

提示词可以这样写：

请基于现有信息整理一条排查时间线。

按时间顺序列出：
- 变更事件
- 告警事件
- 错误日志出现时间
- 用户反馈时间
- 指标异常时间

请标注哪些事件可能相关，哪些只是同时发生但证据不足。

注意最后一句很重要：同时发生不等于因果关系。

AI 如果能帮你守住这一点，排查质量会高很多。

第 3 步：把可能原因拆成假设，而不是结论

事实和时间线整理完，再让 AI 生成假设。

这里不要问"原因是什么"，而要问"有哪些待验证假设"。

基于已确认事实和时间线，请生成线上问题的待验证假设。

每个假设请包含：
1. 假设描述
2. 支持它的证据
3. 反对它或不足的证据
4. 需要验证的数据
5. 验证优先级

请不要把证据不足的猜测写成确定结论。

我一般会要求 AI 按优先级分成三类：

• 高优先级：和时间线、错误日志、最近变更都能对上

• 中优先级：有部分证据，但还缺关键验证

• 低优先级：只是理论上可能，但目前证据弱

这样可以避免被一堆"可能原因"拖进无效排查。

第 4 步：让 AI 输出验证动作

假设只有能被验证，才对排查有用。

这一步让 AI 把每个假设拆成具体动作：

请把每个高优先级假设拆成可执行的验证动作。

每个动作请写清楚：
- 要查哪个日志、指标、表或代码位置
- 预期看到什么结果可以支持该假设
- 看到什么结果可以排除该假设
- 验证成本是低、中还是高
- 如果验证通过，下一步做什么

这段提示词的核心是"支持"和"排除"都要写。

很多排查低效，是因为只知道找证据证明自己的猜测，却没有设计排除路径。AI 可以帮你把这部分补齐。

第 5 步：让 AI 生成复盘草稿

问题定位后，不要立刻结束。

趁上下文还完整，让 AI 帮你生成复盘草稿：

基于最终确认的原因和处理过程，请生成一份线上问题复盘草稿。

结构包括：
1. 问题概述
2. 影响范围
3. 时间线
4. 根因分析
5. 临时止血动作
6. 长期修复方案
7. 监控和测试补充
8. 后续负责人和截止时间

要求：
- 只写已确认事实
- 推测内容单独标注
- 不甩锅，不写情绪化表达

这一步能反过来检查你的排查是否闭环。

如果复盘里写不清"证据链"，说明你可能只是解决了现象，还没有真正定位问题。

一个完整可复制的总提示词

你可以把下面这一版保存成自己的线上问题排查模板：

你现在是我的线上 Bug 排查助手。

目标：帮助我把线上异常从零散信息整理成可验证的排查路径。

请严格按以下流程工作：
1. 先整理已确认事实，不要直接猜根因
2. 建立时间线，区分变更、告警、日志、用户反馈和指标异常
3. 明确缺失信息，并告诉我需要补哪些日志、指标或上下文
4. 基于事实生成待验证假设，不要把猜测写成结论
5. 对每个假设写出支持证据、反对证据、验证动作和排除条件
6. 按验证成本和影响范围给出排查优先级
7. 如果根因确认，再帮我生成复盘草稿

输出格式：
- 已确认事实
- 缺失信息
- 时间线
- 待验证假设
- 排查动作清单
- 初步止血建议
- 复盘草稿提纲

限制：
- 不确定的内容必须标注"不确定"
- 不允许凭空补业务规则
- 不要建议直接改代码，除非已经说明验证依据
- 同时发生不等于因果关系

我提供的信息如下：

我的实战建议

最后给 5 条更容易落地的建议：

1. 贴日志前先补上下文。 单独一段异常栈很难定位线上问题。

2. 让 AI 整理事实，而不是直接问根因。 事实越清楚，假设越靠谱。

3. 每个猜测都要变成验证动作。 不能验证的猜测先降级。

4. 按时间线排查最近变更。 但要记住同时发生不等于因果关系。

5. 定位后顺手生成复盘草稿。 复盘能暴露排查链路里的空洞。

写在最后

AI 用在 Bug 排查里，最有价值的不是"替你猜一个原因"，而是帮你更快搭出一条从事实到假设、再到验证的路径。

下一讲会继续讲需求开发前的关键动作：新需求拆解：让 AI 先给方案再写代码。

---

如果你也在用 AI 提升开发效率，欢迎关注专栏《AI 编程提效实战 30 讲》。