核心用法
Deep Debugging Skill 是一套强制结构化的软件故障排查系统，采用"先证明后修复"的严谨方法论。用户输入 debug/bug/error 等触发词后，系统立即激活四阶段排查流程：
Pre-Phase (30秒快速分诊) — 强制检查5项基础设施问题（服务器重启、环境变量、依赖安装、数据库迁移、浏览器缓存），排除"低级错误"后再进入正式排查。
Phase 1 (数据收集) — 禁止任何修复尝试，仅通过4个维度收集证据：精确错误信息、发生条件、预期vs实际行为、最近变更记录。所有结论必须来自日志/代码实据。
Phase 2 (假设构建) — 强制要求用单一句式表述可验证假设："错误因X发生，我通过Y验证"。系统拒绝模糊假设（如"认证有问题"），必须具体到技术细节。
Phase 3 (二分搜索) — 根据假设类型选择专用排查清单（Auth/API/Frontend/DB/Performance），通过逐层断点测试缩小故障范围，每步必须报告 ✅通过 或 ❌发现故障点。
Phase 4 (最小修复) — 仅当根因100%确认后实施最小化修复，禁止边修边重构，强制验证闭环。
显著优点
- 消除认知偏差：强制Phase 2的假设构建阻断"直觉式修复"，Phase 3的二分搜索避免 confirmation bias
- 可审计的决策链：每步决策均有明确证据支撑，事后可追溯复盘
- 技术栈深度集成：针对 NestJS/Next.js/Prisma 生态提供精准故障模式库（如 JWT_SECRET不匹配、Controller前缀重复、N+1查询等）
- 防沉没成本陷阱：3次失败后强制进入Escalation Path，避免无限循环调试
- 知识沉淀机制：强制DEBUG REPORT格式标准化经验复用
潜在局限
- 刚性流程成本：简单bug（如拼写错误）仍需完整四阶段，时间开销可能高于收益
- 假设质量依赖：Phase 2假设若本身偏离，后续所有验证将无效
- 复杂分布式场景覆盖不足：微服务链路追踪、事件驱动架构的异步故障未专门覆盖
- 德语/英语混杂：原文档双语混合可能影响非德语用户理解
适合人群
- 生产环境故障排查（S1/P0级别）
- 反复出现的"幽灵bug"需要根因分析
- 团队协作调试需同步认知场景
- 初级开发者学习系统化思维
常规风险
- 过度自信于流程：可能忽视用户上下文中的隐性信息
- 工具链假设：默认NestJS/Prisma/React技术栈，其他框架需适配清单
- 修复验证盲区：仅验证当前bug消失，未覆盖回归测试