systematic-debugging

系统化调试 (Systematic Debugging)

技能概述

系统化调试是一种结构化的故障排查方法论，强调在尝试任何修复之前先找到根本原因，通过四个明确阶段（根因调查、模式分析、假设验证、实施修复）来避免盲目修复和新bug的产生。

适用场景

测试失败排查 - 当自动化测试或手动测试失败时，使用系统化方法定位失败根源而不是随意修改代码

生产环境故障 - 面对线上bug或性能问题时，按流程收集证据、分析模式，避免在压力下做出随机修复

集成和构建问题 - 在多组件系统（CI/CD流水线、API集成、数据库交互）中，通过逐层诊断找出真正出问题的组件

核心功能

四阶段调试流程 - 提供清晰的根因调查、模式分析、假设测试、实施修复框架，确保每一步都有明确的成功标准

多组件诊断技术 - 在复杂系统中教导如何在每个组件边界添加诊断日志，追踪数据流和环境变量传播，精确定位故障层级

架构问题识别机制 - 当三次以上修复尝试都失败时，自动触发架构审查流程，避免在错误的设计上继续浪费时间

常见问题

什么是"铁律"（Iron Law）？

铁律是系统化调试的核心原则：在找到根本原因之前，不允许进行任何修复。这意味着如果你没有完成第一阶段（根因调查），就不能提出修复方案。这条原则看似严苛，实际上能避免大量无效工作和新bug的产生。

紧急情况下可以跳过系统化流程吗？

不可以，反而尤其需要遵循系统化流程。紧急情况最容易让人陷入"快速修复"的陷阱，导致猜测式修复。经验表明，系统化调试（15-30分钟）比随机试错（2-3小时的反复修改）更快解决问题。紧急时刻保持流程规范，才能一次修复成功。

多次修复失败后该怎么办？

如果你已经尝试了3次以上的修复都没有成功，技能会触发"架构问题识别"机制。这时应该停止继续修复，转而质疑基础架构是否合理：当前模式是否有根本性缺陷？是否因为惯性在坚持错误的设计？是否需要重构而不是修补？这是从调试转向架构设计的信号。