systematic-debugging

name	systematic-debugging
description	遇到任何 bug、测试失败或异常行为时使用，在提出修复方案之前执行

系统化调试

概述

随意修复既浪费时间又会引入新 bug。草率的补丁只会掩盖深层问题。

核心原则： 在尝试修复之前，务必先找到根本原因。只修症状就是失败。

敷衍走流程等于违背调试的精神。

铁律

不做根因调查，不许提修复方案

如果你还没完成第一阶段，就不能提出修复方案。

何时使用

用于任何技术问题：测试失败、生产环境 bug、异常行为、性能问题、构建失败、集成问题。

尤其在以下情况必须使用：

• 时间紧迫（紧急情况最容易让人猜测式修复）
• 觉得"一个小修改"就能搞定
• 已经尝试了多种修复
• 上一次修复没有生效
• 你没有完全理解问题

以下情况也不要跳过： 问题看起来很简单、你很赶时间、领导要求立刻修好。

四个阶段

你必须完成每个阶段后才能进入下一个。

第一阶段：根因调查

在尝试任何修复之前：

1. 仔细阅读错误信息

   • 使用 read_file(path="<错误日志或堆栈跟踪文件路径>") 阅读完整错误信息
   • 不要跳过错误或警告
   • 完整阅读堆栈跟踪，记下行号、文件路径、错误码

2. 稳定复现

   • 你能可靠地触发它吗？
   • 每次都能复现吗？
   • 如果无法复现 → 收集更多数据，不要猜测

3. 检查近期变更

   • run_command(command="git diff") 查看工作区变更，run_command(command="git log --oneline -10") 查看近期提交
   • search_content(pattern="...") 或 read_file(path="...") 检查相关代码
   • 新依赖、配置变更、环境差异

4. 在多组件系统中收集证据

   对每个组件边界：记录进入和离开的数据，验证环境/配置传递，检查每一层的状态。执行一次以收集证据，确定断裂点，然后针对该组件深入调查。

5. 跟踪数据流

   • 错误值从哪里产生的？
   • 谁用错误值调用了这里？
   • 持续向上追踪直到找到源头
   • 在源头修复，而不是在症状处修复

   参见 root-cause-tracing.md 了解完整的反向追踪技术。

第二阶段：模式分析

先找到模式，再修复：

1. 找到可正常工作的示例 - 使用 search_content(pattern="...") 在同一代码库中找到类似的正常代码，并用 read_file(path="...") 完整阅读参考实现
2. 与参考实现对比 - 完整阅读参考实现，逐行阅读，在应用之前彻底理解
3. 识别差异 - 列出正常代码和出问题的代码之间的每一个差异，不要假设"那不可能有影响"
4. 理解依赖关系 - 这个功能需要哪些其他组件、配置、环境？有哪些隐含假设？

第三阶段：假设与验证

科学方法：

1. 提出单一假设 - 清晰地陈述："我认为 X 是根本原因，因为 Y"
2. 最小化测试 - 做出最小的改动来验证假设，每次只改一个变量
3. 继续之前先验证 - 生效了 → 进入第四阶段；没生效 → 提出新假设；不要叠加更多修复
4. 当你不确定时 - 说"我不理解 X"，不要假装自己知道，寻求帮助

第四阶段：实施

修复根本原因，而非症状：

1. 创建失败的测试用例 - 最简化的复现，尽可能用自动化测试。使用 test-driven-development 技能编写规范的失败测试

2. 实施单一修复 - 修复已定位的根本原因，每次只改一处，不做"顺便改改"的优化，不捆绑重构

3. 验证修复 - 测试通过了吗？其他测试没有被破坏吧？问题真的解决了吗？

4. 如果修复不起作用

   • 少于 3 次：回到第一阶段，用新信息重新分析
   • 3 次或以上：停下来质疑架构

5. 如果 3 次以上修复都失败了：质疑架构

   架构问题的信号： 每次修复都暴露新的共享状态/耦合/其他位置的问题；修复需要"大规模重构"；每次修复都在其他地方产生新的症状。

   停下来质疑： 这个模式从根本上合理吗？我们是不是在"惯性驱动"下坚持了错误方案？应该重构架构还是继续修补症状？

   在尝试更多修复之前，和你的搭档讨论。 这不是假设失败——这是架构有误。

红线——停下来，按流程走

如果你发现自己在想：

• "先临时修一下，以后再排查"
• "试着改改 X 看看行不行"
• "一次性改多个地方，跑测试看看"
• "跳过测试，我手动验证"
• "大概是 X 的问题，让我修一下"
• "我不完全理解，但这应该能行"
• 没有追踪数据流就提出解决方案
• "再试一次修复"（已经尝试了 2 次以上）
• 每次修复都暴露出不同地方的新问题

以上这些都意味着：停下来。回到第一阶段。

如果 3 次以上修复都失败了： 质疑架构（见第四阶段第 5 步）

搭档发出的信号——说明你的方法不对

• "难道不是这样吗？" → 你在没有验证的情况下做了假设
• "它能告诉我们……吗？" → 你应该先收集证据
• "别猜了" → 你在没有理解的情况下提出修复
• "深入想想" → 要质疑根本性问题，而不只是症状
• "我们卡住了？"（沮丧的语气） → 你的方法没有奏效

当你看到这些信号时： 停下来。回到第一阶段。

常见借口

借口	现实
"问题很简单，不需要走流程"	简单问题也有根本原因。对于简单 bug，流程很快就能走完。
"紧急情况，没时间走流程"	系统化调试比反复猜测式修复更快。
"先试一下，再排查"	第一次修复就定下了基调。从一开始就做对。
"确认修复有效后再写测试"	没有测试的修复留不住。先写测试才能证明修复有效。
"一次修多个问题省时间"	无法隔离哪个生效了。还会引入新 bug。
"参考实现太长了，我自己改改"	一知半解必然出 bug。完整阅读。
"我看出问题了，让我修一下"	看到症状 ≠ 理解根因。
"再试一次"（在 2 次以上失败后）	3 次以上失败 = 架构问题。质疑模式，不要继续修。

速查表

阶段	关键活动	通过标准
1. 根因	阅读错误、复现、检查变更、收集证据	理解了什么出了问题以及为什么
2. 模式	找到正常示例、对比	识别出差异
3. 假设	提出理论、最小化验证	假设被验证或产生新假设
4. 实施	创建测试、修复、验证	bug 已修复，测试通过

当流程显示"找不到根因"

如果系统化排查后发现问题确实是环境相关、时序相关或外部因素导致的：

1. 你已经完成了流程
2. 记录你排查了什么
3. 实施适当的处理措施（重试、超时、错误提示）
4. 添加监控/日志以便后续排查

但是： 95% 的"找不到根因"其实是排查不充分。

辅助技术

以下技术是系统化调试的组成部分，可在本目录中找到：

• root-cause-tracing.md - 沿调用栈反向追踪 bug，找到最初的触发点
• defense-in-depth.md - 找到根因后，在多个层级添加校验
• condition-based-waiting.md - 用条件轮询替代硬编码等待时间

相关技能：

• test-driven-development - 用于创建失败测试用例
• verification-before-completion - 在宣称成功之前验证修复确实有效