AI辅助调试排障

等级 L2 · 每天 20 分钟 · 场景:查bug→一、贴什么决定了答什么

一句话：排障场景下 AI 最大的风险不是答不出来，是给一个听起来很合理但完全不是真因的答案——你照着改，浪费半天。正确用法是让它给假设，你去验证，而不是让它给结论。

学习地图

你的问题	看哪一节
「贴了报错它答得很泛」	一、贴什么决定了答什么
「它给的原因改完没用」	二、让它给假设而不是给结论
「日志几万行怎么给它」	三、二分定位
「什么问题它查不了」	四、能力边界

一、贴什么决定了答什么

只贴一行报错 = 让它猜

❌ NullPointerException 怎么解决

这种问法只能得到「检查对象是否为 null」这种正确但没用的答案。

完整的排障上下文有四块

✅ 【现象】线上下单接口偶发 500，约每小时 3~5 次，其余时间正常。
   【报错】（完整堆栈，不要只贴第一行）
   java.lang.NullPointerException: Cannot invoke "Coupon.getAmount()"
     at OrderService.calculatePrice(OrderService.java:88)
     at OrderService.createOrder(OrderService.java:45)
     ...
   【相关代码】（贴 calculatePrice 全文 + 它调用的 couponService.query）
   【环境】Spring Boot 3.2，4 台实例，昨天上线了优惠券灰度功能
   给我 3 个最可能的原因，按可能性排序，每个说明怎么验证。

四块信息各自的作用：

信息块	少了会怎样
现象 —— 偶发还是必现、什么时候开始、影响面	它按必现问题的思路答，方向就错了
完整堆栈 —— 不要只贴最后一行	调用链是定位的主要线索，砍掉等于蒙眼
相关代码 —— 报错行所在方法 + 它依赖的东西	它只能按通用模式猜
环境与变更 —— 最近上了什么	「昨天上线了 X」经常直接指向真因

最后一块最容易被忽略，但价值最高。 偶发问题九成和最近的变更有关，把变更信息给它，排查范围立刻收窄。

二、让它给假设而不是给结论

这是排障场景最重要的一条。

❌ 这个报错是什么原因？
   →（它给一个原因，你照着改，没用，再问，再改，循环）

✅ 给我 3 个最可能的原因，按可能性排序。
   每个原因说明：怎么验证它是不是真因（看什么日志/加什么埋点/跑什么查询）。
   先别给修复方案。

为什么这样问更好：

AI 不知道你的运行时状态——它只能基于代码和报错推理，没法看到真实数据、真实并发、真实配置
它不会说「我不确定」——单个答案的语气和确定的答案完全一样，你无法从措辞判断可信度
要 3 个而不是 1 个，逼它展开可能性空间——真因经常排在第二第三位

验证优先级：先验证最容易验证的

拿到三个假设后，不要按它给的可能性顺序验，按验证成本排序：

假设	可能性	验证成本	先验哪个
优惠券查询超时返回 null	高	看一条日志	✅ 先验这个
并发下缓存击穿	中	要压测复现	后
分表路由错误	低	要查数据	中

一条日志能验证的假设，永远先验。 哪怕它可能性排第三。

三、二分定位

日志几万行、链路十几跳时，不要整个丢给 AI——又贵又不准（原因见大模型基础概念）。用二分：

先定位到「哪一段」

这是一次失败请求的完整链路耗时：
  网关 5ms → 订单服务 2300ms → 库存服务 45ms → 支付服务 80ms
问题在订单服务内部。这是订单服务这一段的日志（贴这一段），
帮我判断 2300ms 花在哪个环节。

再定位到「哪一行」

确认是某个方法慢之后，再贴那个方法的代码和它内部的日志。

每一轮只给一个数量级的信息。 从链路→服务→方法→行，逐层收窄。这个过程你本来就要做，AI 只是在每一层帮你缩短判断时间。

让它帮你写排查命令

这是被低估的用法：

帮我写一条命令：从这个日志文件里，找出所有 traceId 出现过 "timeout" 的完整链路，
按耗时倒序排前 20 条。日志格式是：（贴一行样例）

awk/jq/grep 组合命令，自己写要查文档，让它写几秒钟。这类活验证成本极低（跑一下就知道对不对），非常适合交给 AI。

四、能力边界

说清楚它查不了什么，比列它能查什么更有用。

查得了

代码逻辑错误：空指针、边界、类型转换、并发写法不对
报错信息解读：陌生框架的异常、看不懂的堆栈
配置问题：参数含义、常见错配组合
写排查命令、解析日志格式
提供假设方向：「这类现象通常有哪几种成因」

查不了

实时状态：当前连接数、内存占用、线程栈——它看不见你的机器
数据问题：脏数据、数据不一致——除非你把数据贴给它
环境差异：「本地能跑线上不行」通常是配置/版本/网络差异，得你去比对
依赖方的问题：下游服务抽风，它只能从你这侧的表现猜
你们特有的历史坑：「这个字段其实一直没用」这种事只有团队知道

一句话概括边界：它能做的是「基于你给的信息做推理」，不能做的是「获取你没给的信息」。排障的难点通常在后者——所以 AI 加速的是分析环节，不是取证环节。

常见追问

它给的原因看起来都不对怎么办？ 通常说明上下文给少了。补三样东西试试：最近的变更、失败请求和成功请求的差异、报错的完整堆栈（不是截断的）。如果补完还不对，那多半是环境或数据问题——AI 帮不上，回到传统排查。
能直接让它看我们的监控吗？ 有些工具支持接 MCP 之类的协议去读外部数据源，那样确实能让它看到实时指标。但要先过数据边界这一关：监控数据里可能有用户信息、内部拓扑。先确认合规再接，见 AI工程化与风险。
偶发问题它能帮上忙吗？ 能，但方式不同。偶发问题的关键是攒证据，可以让它帮你设计埋点：「这个假设成立的话，在哪里加什么日志能证明？」——它设计埋点比直接猜原因靠谱得多。
线上紧急故障时该用吗？ 分场景。熟悉的故障别用——你的直觉更快。陌生报错、陌生组件时值得用——比翻文档快。但记住：它给的是假设不是结论，紧急场景下更要坚持”先验证再动手”，慌乱中照着一个错误结论改，会把事故扩大。
怎么避免被它带偏？ 一个简单纪律：任何 AI 给的原因，在你亲眼看到证据之前，都只是候选。它说”因为缓存穿透”，你要能指出哪条日志/哪个指标证明了缓存穿透。做不到就还没定位到。

Interview Wiki

探索