---
name: execution-systematic-debugging
description: 系统化调试 4 阶段根因分析：调查→模式分析→假设测试→实现修复。来自 Superpowers。
---

# 系统化调试

## 铁律

```
不要猜测。调查。
```

## 4 阶段流程

### 阶段 1: 调查

1. 复现问题
2. 收集错误信息（日志、堆栈、截图）
3. 确定影响范围
4. 检查最近的变更（`git log --oneline -20`）

### 阶段 2: 模式分析

1. 错误信息中的关键词是什么？
2. 这个错误模式在代码库中有先例吗？
3. 最近有什么变更可能引入这个问题？
4. 是回归还是新问题？

### 阶段 3: 假设测试

1. 形成假设："如果 X，那么 Y"
2. 设计验证实验
3. 运行实验
4. 如果假设被否定，形成新假设

### 阶段 4: 实现修复

1. 修复根因，不是症状
2. 写回归测试
3. 验证修复
4. 检查是否有类似问题

## 根因追踪

如果修复后问题再次出现，说明你没有找到根因。回到阶段 1。

## 合理化防御表

| 你可能的想法 | 现实 |
|-------------|------|
| "我猜是这个问题" | 猜测不是调试。验证。 |
| "先修了再说" | 修症状不是修根因。 |
| "没时间调查了" | 不调查就修 = 问题会回来。 |
| "这个错误信息不重要" | 错误信息是线索。读它。 |
| "肯定是最近改的" | 也可能是旧 bug 被新代码触发。 |
| "我应该直接问同事" | 先自己调查 15 分钟再问。 |
| "这个 bug 太复杂了" | 复杂 bug 也是简单问题的组合。分解它。 |
| "重启一下就好了" | 重启掩盖问题，不解决问题。 |
| "这个只在测试环境出现" | 测试环境暴露问题，不是制造问题。 |
| "用户操作错误" | 用户操作是反馈，不是借口。 |
| "这个优先级不高" | bug 不会因为你标记低优先级就停止影响用户。 |

## 红旗清单

以下 13 条危险信号出现时，立即 STOP：

1. **"我猜是这个问题"** → 猜测不是调试。形成假设并验证。
2. **"先修了再说"** → 修症状不是修根因。问题会回来。
3. **"没时间调查了"** → 不调查就修 = 赌博。
4. **"这个错误信息不重要"** → 错误信息是第一条线索。忽略它 = 盲人摸象。
5. **"肯定是最近改的"** → 确认偏误。检查所有可能性。
6. **"我加个日志看看"** → 日志是好的，但先读现有日志和堆栈。
7. **"这个 bug 太复杂了"** → 复杂 bug 也是简单问题的组合。分解它。
8. **"重启一下就好了"** → 重启掩盖问题。根因还在。
9. **"这个只在测试环境出现"** → 测试环境暴露问题，不是制造问题。
10. **"用户操作错误"** → 用户操作是反馈。系统应该能处理错误操作。
11. **"这个优先级不高"** → bug 不会因为低优先级就停止影响用户。
12. **"我之前遇到过类似的"** → 类似不等于相同。每次都要验证。
13. **"应该是并发/时序问题"** → 不要跳到结论。先排除确定性 bug。

## 压力测试

在声称修复完成前，问自己：

1. 如果输入是空的怎么办？
2. 如果输入是 null/undefined 怎么办？
3. 如果并发 1000 个请求怎么办？
4. 如果网络断了怎么办？
5. 如果磁盘满了怎么办？
6. 如果数据库连接超时怎么办？
7. 如果配置缺失怎么办？
8. 如果依赖服务返回错误怎么办？
9. 如果这个修复引入了新问题怎么办？回归测试覆盖了吗？
10. 如果问题在另一个环境复现不了怎么办？