AI 辅助 Bug 定位：从日志到根因 10 分钟

案例背景

生产环境报错，需要快速定位根因。传统流程：

收到告警 → 看日志 → 日志千万行
翻调用链 → 几十层
查代码 → 不知道哪段
复现 → 不稳定
排查 2 小时，压力巨大

目标：用 AI 把"过滤日志 + 定位代码 + 生成假设"自动化，人只做最终确认。

工具链

Claude：日志分析与根因推演
Filesystem MCP：读取日志文件
GitHub MCP：查相关代码

工作流程

Phase 1：日志读取与过滤（2 分钟）

Prompt：
用 Filesystem MCP 读 /var/log/app/error.log 的最后 500 行
过滤出含 "ERROR" "Exception" "Traceback" 的行
按时间排序，提取最关键的 3 段堆栈

AI 自动：

读日志文件
过滤噪音（INFO/DEBUG）
提取关键错误：

[2026-08-19 14:23:01] ERROR PaymentService.process: callback timeout
  at PaymentService.process (payment.js:45)
  at OrderController.checkout (order.js:78)
  at asyncHandler (middleware.js:12)
[2026-08-19 14:23:01] ERROR DB query timeout
  at Pool.query (db.js:234)
  at PaymentService.process (payment.js:42)

Phase 2：代码定位（3 分钟）

Prompt：
基于堆栈，用 GitHub MCP 读这几个文件的相关代码：
- payment.js:40-50（PaymentService.process）
- db.js:230-240（Pool.query）
- order.js:75-85（OrderController.checkout）
找出可能超时的代码段

AI 自动：

调 GitHub MCP 读代码
定位可疑代码：

// payment.js:40-50
async process(orderId) {
  const order = await Order.findById(orderId);  // 第 1 次查库
  const result = await this.callPaymentApi(order);  // ← 可能超时
  await Order.update(orderId, { paid: true });  // 第 2 次查库
  return result;
}

标注可疑点：callPaymentApi 无超时设置。

Phase 3：根因推演（3 分钟）

Prompt：
基于日志和代码，推演根因：
1. 直接原因是什么
2. 触发条件是什么
3. 为什么之前没暴露
4. 给出 3 个验证假设

AI 输出：

直接原因：
  PaymentService.callPaymentApi 调用第三方支付 API 超时
  → 该调用无超时设置 → 阻塞 30 秒
  → 上游 DB 连接池耗尽 → 连锁超时

触发条件：
  第三方支付 API 响应慢（>5 秒）
  或 第三方 API 不可达
  高并发时放大（连接池耗尽）

为什么之前没暴露：
  1. 之前第三方 API 响应快（<1 秒）
  2. 没有超时监控
  3. 高并发场景未压测

验证假设：
  H1：第三方 API 当前慢了
    → 验证：测 curl 第三方 API 响应时间
  H2：网络问题
    → 验证：traceroute 第三方域名
  H3：第三方 API 限流我们
    → 验证：查第三方 API 状态页/限流头

Phase 4：修复方案（2 分钟）

Prompt：
给出修复方案，分临时止血和长期根治

AI 输出：

临时止血（立即）：
  1. 给 callPaymentApi 加超时（5 秒）+ 重试（3 次）
  2. 重启服务释放连接池
  3. 通知第三方查 API 状态

长期根治（本周）：
  1. 所有外部调用加超时 + 熔断
  2. 加支付链路监控（成功率/延迟告警）
  3. 压测高并发支付场景
  4. 连接池改隔离（支付不与查询抢连接）

Phase 5：工单与通知（1 分钟）

配合 Linear MCP：

你：把这个 bug 建工单 + 通知团队

AI：
  1. 在 Linear 建 bug 工单
  2. 标题：[P0] 支付 API 超时致连接池耗尽
  3. 描述：根因 + 修复方案
  4. 负责人 = 支付模块 owner
  5. Slack 通知 oncall（Slack MCP）

关键 Prompt 复盘

Prompt 1：日志过滤明确

过滤含 "ERROR" "Exception" "Traceback" 的行
提取最关键的 3 段堆栈

为什么有效：明确过滤词，避免 AI 输出全部日志。限制 3 段堆栈，聚焦最关键的。

Prompt 2：代码定位精确

读 payment.js:40-50
找出可能超时的代码段

为什么有效：给行号范围，避免 AI 读整个文件。明确要找"超时"相关，聚焦问题。

Prompt 3：假设分多个

给出 3 个验证假设

为什么有效：不限定单一根因，避免 AI 过早收敛。3 个假设让人快速验证排除。这与 A/B 测试的"控制变量验证"思路一致。

Prompt 4：修复分两层

临时止血（立即）
长期根治（本周）

为什么有效：区分紧急止血和长期改进，避免只做临时 hack 不根治。

踩过的坑

坑 1：日志噪音淹没

500 行日志里有 450 行 INFO
→ AI 读了半天找不到 ERROR
→ 浪费时间

解决：先 grep 过滤，只读 ERROR 行，再给 AI。用 Filesystem MCP 读已过滤的文件。

坑 2：AI 编造代码行

AI 说 payment.js:45 有超时问题
→ 查代码第 45 行根本不是那段
→ 编造行号

解决：让 AI 用 GitHub MCP 真实读代码，不靠"记忆"。要求标注"已读代码"。

坑 3：根因太单一

AI 只说"超时" → 太表面
→ 真正根因是连接池耗尽
→ 没挖到第二层

解决：Prompt 要求"直接原因 + 触发条件 + 为什么没暴露"三层分析。

坑 4：修复方案太激进

AI 建议"重构整个支付模块"
→ 紧急时刻不该大改
→ 引入新风险

解决：要求"临时止血用最小改动，长期根治另开任务"。

坑 5：漏掉影响范围

只定位支付 bug
→ 不知道影响了多少用户
→ 不知道要不要回滚

解决：Prompt 加一步"评估影响范围（用户数/订单数/时长）"，配合 Postgres MCP 查影响数据。

效率对比

环节	传统	AI 辅助	提速
日志过滤	20 分钟	2 分钟	10x
代码定位	30 分钟	3 分钟	10x
根因推演	40 分钟	3 分钟	13x
修复方案	30 分钟	2 分钟	15x
工单通知	10 分钟	1 分钟	10x
合计	2 小时	11 分钟	11x

准确率对比

维度	传统（人工）	AI 辅助
日志噪音过滤	70%（累）	95%（机器不累）
代码定位	80%	85%
根因深度	中（压力大想不全）	高（三层分析）
修复方案	保守	平衡（止血+根治）

AI 在根因深度上优势明显——人压力大时容易只看表面，AI 冷静三层分析。

哪些环节 AI 真省时间

✅ 日志过滤：千万行日志秒级过滤
✅ 代码定位：读堆栈直接跳到代码行
✅ 假设生成：冷静推演 3 个假设

哪些环节还得靠人

⚠️ 假设验证：AI 给假设，验证要人跑命令
⚠️ 修复实施：AI 给方案，改代码要人确认
⚠️ 业务判断：要不要回滚、要不要通知用户，靠人判断
⚠️ 复杂并发 bug：多线程竞态，AI 推理弱

质量保障

发布前必查：

AI 读的是真实代码（GitHub MCP 读的，非编造）
根因有 3 层（直接原因/触发条件/为何未暴露）
至少 2 个验证假设
修复方案分临时+长期
影响范围已评估

小结

这个案例最大的启示：Bug 排查的瓶颈不是"懂技术"，而是"信息太多"。AI 把日志过滤和代码定位的繁琐工作自动化了，人只做根因判断和修复决策。

下次遇到生产 bug 别慌——用 Filesystem MCP 读日志、GitHub MCP 查代码、Claude 推演根因、Linear MCP 建工单，10 分钟出完整排查链，你会发现真正需要人脑的可能就是那个"要不要回滚"的决策。