核心用法
Systematic Debugging 是一套强制五阶段流程的调试方法论，核心铁律为"无调查不修复"。
Phase 0: 上下文回溯（强制第一步）
提取错误关键词 → 搜索项目文档/MEMORY/git历史 → 输出召回摘要 → 有匹配直接应用，无匹配进入Phase 1
Phase 1: 根因调查
- 完整阅读错误信息与堆栈
- 稳定复现问题（不可复现时不猜测）
- 检查近期变更（git diff、依赖、配置、环境）
- 多组件系统：在边界处添加诊断日志，定位故障组件后再深入
- 追踪数据流至源头
Phase 2: 模式分析
寻找同类工作代码 → 完整阅读参考实现 → 对比差异清单 → 理解依赖与假设
Phase 3: 假设与验证
单一假设书面化 → 最小变更测试 → 验证通过则进入Phase 4，失败则立新假设
Phase 4: 实施修复
先写失败测试 → 单一根因修复（无顺带重构）→ 验证通过 → 若3次修复失败则质疑架构
Phase 4.5: 架构质疑（3+修复失败触发）
识别"每次修复暴露新耦合/共享状态"模式 → 讨论架构重构 vs 继续修症状
---
显著优点
| 维度 | 效果 |
|------|------|
| 效率 | 15-30分钟 vs 随机修复的2-3小时 |
| 首修成功率 | 95% vs 40% |
| 引入新bug | 趋近于零 |
| 知识沉淀 | Phase 0强制记录，形成组织记忆 |
- Iron Law机制：流程锁死跳过诱惑，尤其适用于紧急高压场景
- 多组件诊断：边界日志法避免"在哪儿修"的盲目猜测
- 架构逃生舱：3次失败强制升级，防止沉没成本陷阱
---
局限性与风险
| 局限 | 说明 |
|------|------|
| 学习成本 | 新手初期感觉"慢"，需经历2-3次对比才能内化 |
| 极端紧急场景 | 生产完全宕机时，"先止血再调查"可能必要，但需事后补流程 |
| 复杂架构问题 | Phase 4.5触发条件主观，需经验判断何为"新耦合模式" |
| 工具依赖 | Phase 0依赖项目文档/MEMBER系统的完备性 |
---
适合人群
- 所有技术角色：后端/前端/测试/运维/SRE
- 尤其适用：易冲动修复者、高压环境工作者、遗留系统维护者
- 组织层面：需建立"调试文化"而非"英雄救火"的团队
---
常规风险
1. 流程形式主义：机械执行但跳过"理解"本质，变为文书工作
2. Phase 0陷阱：找到"相关经验"后未验证上下文匹配度直接套用
3. 假设固化：Phase 3中执着于初始假设，忽视反证数据
4. 架构质疑逃避：团队政治压力导致跳过Phase 4.5，继续无效修补