专栏：AI 编程提效实战 30 讲
标签：AI编程 / Bug排查 / 日志分析 / 线上问题 / 工程效率
先说结论
线上 Bug 排查最怕的不是问题复杂，而是你一上来就让 AI “猜原因”。
很多人把报错日志丢给 AI，问一句：
这个问题是什么原因？
AI 往往会给你一串看似合理的可能性：网络抖动、缓存不一致、空指针、并发问题、配置错误。每个都像那么回事，但你还是不知道下一步该查哪里。
更有效的方式是：先让 AI 帮你整理事实，再构建假设，最后把假设拆成可验证的排查动作。
这篇给你一套可以直接复制的线上 Bug 排查模板，适合用在日志、告警、接口异常、用户反馈和最近发布变更的综合分析里。
为什么不能直接让 AI 猜原因
线上问题的上下文通常是不完整的。
你手里可能只有一段错误日志、几条用户反馈、一个告警指标，最多再加上最近发布记录。这个时候如果直接让 AI 判断根因，它很容易把“可能性”写成“结论”。
真正可靠的排查应该分三层：
事实层：已经确认发生了什么
假设层：可能由哪些原因导致
验证层：每个假设如何用日志、指标、代码或数据验证
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 条更容易落地的建议：
贴日志前先补上下文。 单独一段异常栈很难定位线上问题。
让 AI 整理事实，而不是直接问根因。 事实越清楚，假设越靠谱。
每个猜测都要变成验证动作。 不能验证的猜测先降级。
按时间线排查最近变更。 但要记住同时发生不等于因果关系。
定位后顺手生成复盘草稿。 复盘能暴露排查链路里的空洞。
写在最后
AI 用在 Bug 排查里，最有价值的不是“替你猜一个原因”，而是帮你更快搭出一条从事实到假设、再到验证的路径。
下一讲会继续讲需求开发前的关键动作：新需求拆解：让 AI 先给方案再写代码。
如果你也在用 AI 提升开发效率，欢迎关注专栏《AI 编程提效实战 30 讲》。
