用途：这是一套系统化调试框架，用于处理任何技术问题，包括测试失败、生产环境缺陷、异常行为、性能问题、构建失败和集成问题。核心原则是“未完成根因调查前不得提出修复”，认为随机修复浪费时间并引入新缺陷。
主要能力：框架分为四个阶段。第一阶段根因调查：阅读错误、复现问题、检查变更、收集证据，弄清“是什么”和“为什么”。第二阶段模式分析：寻找可工作的示例并对比，找出差异。第三阶段假设与测试：形成理论并做最小化验证，确认或产生新假设。第四阶段实现：先写测试，再修复并验证，要求缺陷解决且测试通过。
配套指南：systematic.md 提供四阶段完整流程、多组件系统诊断、连续三次以上修复失败后转向架构质疑；root-cause.md 讲沿调用栈回溯，找到原始触发点而非只修症状，并给出添加堆栈追踪、定位污染测试的示例；defense-in-depth.md 讲在数据经过的每一层做校验，包括入口校验、业务逻辑校验、环境守卫和调试埋点，使缺陷在结构上难以发生；verification.md 强调“没有新鲜验证就不得声称完成”，给出声明前的五步门控函数、回归测试红绿循环及常见失败模式。
使用方式：当出现“快速修一下”“先改 X 试试”“跳过测试手动验证”“大概是 X”等念头时，应停止并回到第一阶段。若已尝试三次以上修复仍失败，应质疑架构而非继续修症状。文中给出多组件诊断命令示例，例如用 echo 检查工作流、构建脚本和目标脚本各层的变量状态；也给出在操作前打印 stack、cwd、NODE_ENV 的调试埋点写法，以及分层校验的代码结构。
适用场景与限制：适合时间紧迫、看似有显而易见的小修复、已多次尝试修复、前次修复无效或尚未完全理解问题的情形。该技能可与 systematic-thinking、code-review、validate-plan 配合使用。资料未提供安装命令、平台支持、收费方式或具体效果数据，相关事实暂未提供。