大多数 bug 不是因为不知道怎么写代码，而是因为在排查时的假设出了问题。Claude Code 最有价值的不是帮你直接找到 bug，而是帮你建立系统性排查思维。
核心框架：假设驱动调试
1. 观察现象（Observe）
2. 建立假设（Hypothesize）
3. 设计实验（Design experiment）
4. 执行并观察（Execute）
5. 更新假设（Update）
6. 重复直到找到根因（Repeat）
用 Claude 建立假设：
claude "现象：用户的支付成功，但订单状态没有更新。
这个现象有哪些可能的根因？
按概率从高到低排列，每个假设说明：
1. 为什么这种情况会发生
2. 如何快速验证或排除这个假设
3. 需要什么额外信息"
设计最小化实验：
claude "我怀疑是这段代码（processor.go:78-95）的并发问题。
帮我设计一个能在本地复现这个问题的测试：
- 最小化的测试场景
- 如何模拟并发
- 成功复现的判断标准
- 如果这个测试通过，说明我的假设是错的，下一步怎么排查"
避免"叙述性调试"：
叙述性调试是调试最大的陷阱——你开始讲"这段代码应该这样工作"，然后开始相信自己的叙述，忽略实际发生的事情。
# 坏：叙述性
claude "这段代码应该是先检查权限，再执行操作，
所以如果权限检查通过了，操作应该成功，
但用户说操作失败了..."
# 好：现象驱动
claude "实际观察到的：
- 权限检查日志：显示通过
- 操作执行日志：不存在
- 返回给用户的错误：403
根据这些实际日志，可能发生了什么？
不要基于'代码应该怎样工作'，只基于这些日志"
二分法定位问题：
claude "问题出现在请求处理的某个环节，但不知道在哪里。
请求链路是：
Handler → Auth Middleware → Rate Limiter → Service → Repository → DB
帮我设计二分法排查：
1. 先在哪个点加日志能把问题范围缩小一半？
2. 根据结果，下一步在哪里加日志？
3. 预计几轮能定位到具体函数？"
用 Rubber Duck 方法：
claude "我要向你解释一个 bug，请你只在我说错的时候打断我：
我们的 payment service 处理退款时...
[详细解释你的理解]
在我解释完之前，不要给解决方案，只帮我发现逻辑漏洞。"
这个方法强迫你把思路说清楚，往往在说的过程中自己就发现问题了。Claude 只是一个"不会无聊"的倾听者。
复盘与预防：
claude "我们找到了这个 bug 的根因：[根因描述]。
帮我分析：
1. 为什么这个 bug 能通过代码 review？
2. 为什么测试没有覆盖到？
3. 如何修改 CLAUDE.md 或测试策略，防止类似问题？
4. 是否需要写一份 post-mortem？"
调试能力是区分工程师水平的核心能力之一。Claude Code 不能替代你的调试直觉，但它能帮你把隐性的调试方法显性化，逐渐内化成系统性思维。