用途：这是一套结构化的四阶段调试方法论，核心原则是“在尝试修复之前，始终先找到根因”。适用于任何技术问题，包括测试失败、意外行为、流水线错误、构建失败、Galaxy 工作流错误、笔记本异常和环境问题；尤其适用于看似“只需快速修一下”、已尝试多次修复、上次修复无效或尚未完全理解问题的情况。
四个阶段（需完成前一阶段再进入下一阶段）：
- 根因调查：仔细阅读错误信息与完整堆栈，记录行号、文件路径、错误码；稳定复现问题，无法复现则收集更多数据而非猜测；检查近期变更（git diff、提交、新依赖、配置与环境差异）；在多组件系统中收集证据，对流水线（Galaxy 工作流→工具→数据）记录每个组件的输入输出，先带诊断运行一次定位断点；沿调用链向上追踪数据流，找到坏值来源，在源头而非症状处修复。
- 模式分析：在同一代码库中寻找可用的相似示例，完整阅读参考实现而非略读，列出所有差异（无论多小），理解依赖、配置、环境与假设。
- 假设与验证：形成单一假设（“我认为 X 是根因，因为 Y”），做最小改动、一次只变一个变量，验证是否有效；无效则提出新假设，不要叠加修复；不知道就明说，继续研究。
- 实施：创建最简单的失败测试或复现（尽量自动化），实施单一修复，只针对根因做一处改动，不做“顺便改进”；验证测试通过、其他测试未被破坏、问题已解决。
若修复无效：统计尝试次数，少于 3 次则带着新信息回到阶段 1；达到或超过 3 次则停止，质疑架构。当 3 次以上修复失败，且每次修复都在不同位置暴露新问题、需要大规模重构或产生新症状时，应停止并与用户讨论，这通常意味着方法本身有误。
危险信号（出现即回到阶段 1）：想“先快速修一下，之后再调查”“先改 X 试试看”“大概是 X，我来修”“我不完全理解但也许可行”、在追踪数据流前就提出方案、已尝试 2 次以上还想“再试一次”。常见借口与事实：问题简单也有根因；紧急情况下系统化比反复试错更快；第一次修复会定下基调；一次改多处无法隔离有效改动并引入新 bug；看到症状不等于理解根因。
配套文件：root-cause-tracing.md 讲解沿调用链反向追踪原始触发点、插桩技术与堆栈分析；defense-in-depth.md 讲解找到根因后在入口点、业务逻辑、环境守卫和调试日志等多层添加校验。
限制：资料未提供具体安装命令、平台支持、收费方式或效果数据，暂未提供。