用途
Systematic Debugging 用于处理任何技术问题，包括测试失败、生产环境 bug、异常行为、性能问题以及构建失败。它的定位是在提出修复方案之前使用，避免随机修补浪费时间并引入新的 bug。
核心原则
该技能的核心原则是：在尝试修复之前，始终先找到根本原因。只修复症状被视为失败。违反流程的字面要求，就等于违反调试的精神。
其“铁律”为：没有先进行根因调查，就不允许修复。如果尚未完成第一阶段，就不能提出修复方案。
四个阶段
第一阶段：根因调查
在尝试任何修复之前：
- 仔细阅读错误信息，它们往往包含确切的解决方案
- 稳定复现问题，确认能否可靠触发
- 检查最近的变更，找出可能导致问题的改动
- 收集证据，在多组件系统中添加诊断性插桩
- 追踪数据流，参见 root-cause-tracing.md
第二阶段：模式分析
- 寻找可工作的示例，定位类似的可运行代码
- 对照参考实现，完整阅读参考实现
- 识别差异，列出每一处差异，无论多小
- 理解依赖关系，包括设置、配置和环境
第三阶段：假设与测试
- 形成单一假设，例如“我认为 X 是根本原因，因为 Y”
- 进行最小化测试，一次只改变一个变量
- 在继续之前验证，确认是否有效；如果无效，则提出新的假设
- 当你不理解时，直接说“我不理解 X”
第四阶段：实施
- 创建失败的测试用例，使用 test-driven-development 技能
- 实施单一修复，一次只做一个改动
- 验证修复，确认测试通过且没有破坏其他测试
- 如果 3 次以上修复失败，则质疑架构
危险信号：停止并遵循流程
以下情况出现时，意味着必须停止并回到第一阶段：
- “先快速修复，之后再调查”
- “先试试改 X，看看行不行”
- “我不完全理解，但这可能有用”
- 在追踪数据流之前就提出解决方案
- “再试一次修复”（当已经尝试 2 次以上时）
常见借口与事实
- 借口“问题很简单”，事实是简单问题也有根本原因。
- 借口“紧急情况，没时间”，事实是系统化调试比反复折腾更快。
- 借口“先试试这个”，事实是第一次修复会设定模式，应当做对。
- 借口“我看到问题了”，事实是看到症状不等于理解根本原因。
支持技术
- root-cause-tracing.md：通过调用栈向后追踪 bug
- defense-in-depth.md：在多个层面添加验证
适用场景与限制
该技能适用于任何技术问题的调试场景，尤其强调在提出修复前使用。资料中未提供关于收费、价格、平台支持范围或具体安装步骤的信息，暂未提供。