核心用法
Deep Debugging 是一套证据优先的系统性调试方法论，专为难以定位、反复发作或高风险的软件缺陷设计。其核心流程分为四个强制阶段：
1. 预检阶段（30秒快速排查）
强制检查五项基础设施问题：服务重启、环境变量、依赖安装、数据库迁移、浏览器缓存。避免在基础问题上浪费深度调试时间。
2. 数据收集阶段（纯观察，零干预）
必须回答四个问题：发生了什么（精确日志/状态码）、何时发生（频率/触发条件）、应该发生什么、最近变更了什么。所有结论需附带代码或日志证据。
3. 假设与二分搜索阶段
关键创新：在触碰代码前，必须提出单一、可证伪的具体假设（格式："错误发生因为X，我通过Y验证"）。随后按问题类型选择专用检查清单（Auth/API/Frontend/DB/Performance），通过二分搜索逐层缩小范围。
4. 修复阶段
仅当根因经前三个阶段证实后才实施最小化修复，禁止同时重构，修复后必须验证。
---
显著优点
- 根治反复修复失败：通过"假设→验证→排除"的循环，避免"试试这个"式的盲目修复
- 内置防错机制：多语言触发词、强制报告格式、三次失败后升级路径，防止调试者陷入确认偏误
- 实战知识库：基于真实故障（JWT密钥不匹配、跨域Cookie问题、Prisma N+1查询等）的20+条症状-根因映射
- 框架专属优化：针对 NestJS/Next.js/Prisma 技术栈的深度集成，提供精确到文件行的诊断路径
---
局限性与风险
- 启动成本：严格的四阶段流程对简单问题（如拼写错误）显得过度，技能自身明确排除"明显拼写错误"场景
- 依赖信息完整：若用户无法提供日志访问权限或代码变更历史，数据收集阶段可能受阻
- 技术栈聚焦：虽然原理通用，但具体检查清单深度绑定 Node.js/NestJS/Prisma/React 生态，其他技术栈（如 Python/Django、Go/Gin）需自行扩展
- 认知负荷：要求调试者抑制"立刻修复"的冲动，对高压生产环境故障可能产生心理摩擦
---
适用人群
- 负责复杂全栈应用（NestJS + Next.js + Prisma）的高级开发者
- 遭遇"修复-复发"循环、需要建立系统性调试习惯的团队
- 需要调试生产环境 401/403/500 错误且无法本地复现的运维工程师
- 希望从"直觉驱动"转向"证据驱动"调试方式的开发者
---
常规风险
| 风险场景 | 缓解措施 |
|---------|---------|
| 过度调试简单问题 | 技能内置预检阶段排除基础设施问题，且文档明确排除"明显拼写错误" |
| 生产环境数据泄露 | 调试报告模板要求脱敏，JWT 解码等操作在本地执行 |
| 调试疲劳导致跳过阶段 | 三次失败后强制升级路径，引入用户协作或新子代理 |
| 假设污染（Confirmation Bias） | 升级路径包含"零上下文子代理"选项，重置推理路径 |
| 跨域/认证调试中的安全误配置 | 文档明确标注 SameSite/Secure/CORS 的安全组合要求 |