用途
该技能用于系统化调试：目标定位问题根因并验证修复，而不是仅让表面症状消失。其核心分工是“用户是报告者，AI 是调查者”：用户提供期望发生什么、实际发生了什么、看到的错误信息、问题何时开始或是否曾经正常工作；AI 不应向用户追问根因位于哪个文件、问题出在何处或应如何修复，而应自行调查原因。
主要能力
- 元调试：调试自己写的代码时，把代码当作他人所写来阅读，质疑自己的设计决策，将实现视为假设，以代码实际行为为准，并优先怀疑自己最近改动过的代码。
- 基础原则：区分可观察的确定事实与未经验证的假设，从事实重建理解。
- 认知偏差应对：确认偏差——主动寻找反证；锚定——调查前先提出至少 3 个假设；可得性——把每个 bug 视为新问题；沉没成本——每 30 分钟自问是否仍会走这条路。
- 系统化调查：一次只改一个变量，测试、观察、记录、重复；完整阅读整个函数而非只读“相关”行；接受“我不知道”，警惕“一定是 X”。
- 重启规则：超过 2 小时无进展、3 次以上修复无效、无法解释当前行为、在调试调试器本身、或修复生效但不知原因时，考虑重启：关闭所有文件与终端，写下确定事实与已排除项，列出新假设，从第一阶段重新开始。
- 假设检验：要求假设可证伪，例如“状态有问题”不合格，而“组件在路由变化时重新挂载导致用户状态被重置”合格；观察要精确，列出所有可能原因，为每个假设明确支持或反驳它的证据。
- 调试技术：橡皮鸭调试（口述系统应做 X、实际做 Y、推测因为 Z、代码路径 A→B→C→D、已验证与假设项）；最小复现（复制失败代码，逐块删除并测试，直到最小可复现）；逆向追溯（从期望输出沿调用栈逐层回查）；差分调试（对比时间、环境、数据、配置变化）；二分查找（在已知正常状态与当前异常状态之间取中点缩小范围）；注释排除（注释掉函数内容后逐块恢复，定位触发问题的部分）。
使用方式
该技能以代理工作流形式运作，维护 DEBUG.md 持久状态文件，其状态取值为 gathering、investigating、fixing、verifying、resolved，并记录触发输入、当前假设、测试方式、预期结果、下一步行动、症状（期望、实际、错误）、已排除假设及证据、证据记录和解决情况（根因、修复、验证）。输出格式包括三种：“ROOT CAUSE FOUND”（根因、证据、推荐修复）、“INVESTIGATION INCONCLUSIVE”（已排除、待查、受阻原因、建议）、“CHECKPOINT REACHED”（状态、进展、需要用户提供什么）。
验证
“已验证”指：按具体步骤可稳定复现 bug；修复不破坏其他功能；修复在相关环境中有效；重试后 bug 不再出现。验证清单包括：修复前复现、应用修复、不再复现、相关功能正常、边界情况已测、原始报告者确认（如适用）。三次修复失败后应停止当前思路，在 DEBUG.md 记录尝试内容，向 STATE.md 汇总，并建议以全新上下文会话继续。
适用场景与限制
适用于需要根因分析的复杂缺陷调查、多人协作中的状态化调试，以及需要避免反复试错的场景。该资料未提供具体安装命令、运行平台、价格或性能数据，这些信息暂未提供；使用时需自行准备可复现的 bug 报告与项目代码环境。