核心用法
Deep Debugging Skill 是一套强制结构化的问题排查方法论，专为复杂全栈应用设计。用户输入触发词（如 debug、bug、error、500 等）后，系统立即加载该技能并执行严格的四阶段流程：
1. Pre-Phase（快速分诊）：30 秒内检查 5 个最常见低级错误（服务器重启、环境变量、依赖安装、数据库迁移、浏览器缓存）
2. Phase 1（数据收集）：强制回答 4 个关键问题——发生什么、何时发生、应发生什么、最近改了什么，且必须提供日志/代码证据
3. Phase 2（假设建立）：必须提出单一、可测试的具体假设，格式为 "错误因 X 发生，我将通过 Y 验证"，禁止模糊表述
4. Phase 3（二分搜索定位）：通过链式排查法（Auth/Session、API、前端、数据库、性能）逐步缩小范围，每步报告 ✅/❌
5. Phase 4（修复实施）：仅在被证明后才允许最小化修复
显著优点
- 根治随机修复：通过"先证明，后解决"原则，彻底杜绝"试试看"式调试
- 全栈覆盖：针对 NestJS/Next.js 技术栈提供精确的排查清单，包括 JWT Secret 不匹配、Cookie 跨域、Controller 前缀重复等高频陷阱
- 结构化输出：强制使用 DEBUG REPORT 格式，确保每次调试可追溯、可复盘
- 实战案例库：内置 6 个真实踩坑记录（JWT Secret 不一致、跨域 Cookie、Hooks 顺序等），极具参考价值
潜在局限
- 流程刚性：简单问题（如拼写错误）可能被过度流程化，降低效率
- 技术栈偏向：虽然通用原则适用，但详细检查清单主要针对 Node.js/NestJS/Next.js/Prisma 生态
- 依赖用户配合：若用户无法提供日志访问权限或代码片段，Phase 1 的证据收集将受阻
适合人群
- 全栈开发者处理间歇性、难以复现的复杂 Bug
- 团队技术负责人建立标准化故障排查 SOP
- 初级开发者学习系统化调试思维，避免养成猜测式习惯
常规风险
- 时间成本：严格遵循四阶段可能延长简单问题的处理时间
- 假设偏见：Phase 2 的假设若方向错误，可能导致 Phase 3 反复回退（技能本身建议 3 次尝试后重回 Phase 1）
- 环境依赖：部分调试命令（如
git bisect、prisma migrate）需要特定工具链支持