用途：在遇到任何 bug、测试失败或异常行为时使用，强制先做根因调查再修复，避免用快速补丁掩盖底层问题。
核心原则（铁律）：没有根因调查，不得修复。
四个阶段（必须按顺序完成）：
- 根因调查（强制）：仔细阅读完整堆栈跟踪与准确行号；稳定复现问题，无法复现则先收集更多数据；检查近期变更（git diff、最近提交、新依赖）；在多组件系统中，对每个组件边界记录进入与退出的数据并验证环境/配置传递，运行一次以定位出错位置；沿数据流反向追踪坏值来源。
- 模式分析：在同一代码库中寻找可工作的相似代码；完整阅读参考实现，不要略读；列出可用与损坏之间的每一处差异；理解全部依赖与假设。
- 假设与测试：提出一个具体假设（“我认为 X 是根因，因为 Y”）；做最小改动验证；一次只改一个变量；有效则进入阶段四，无效则提出新假设。
- 实施：先写一个能复现 bug 的失败测试；实施针对根因的单一修复；验证测试通过、其他测试未被破坏、问题解决。
当 3 次以上修复失败时：应停止并质疑架构，这通常不是表层 bug，而是架构问题（每次修复暴露新的耦合或共享状态，或需要大规模重构），应先与人类讨论再继续。
危险信号（应回到阶段一）：如“先快速修复，之后再调查”“先改 X 试试看”“我不完全理解但也许可行”“再试一次修复”（在已试过 2 次以上后）、在追踪数据流前就提出解决方案。
限制：资料未提供安装命令、平台支持、收费方式或具体使用步骤；仅描述该技能的方法论与流程。