核心用法
Deep Debugging 是一套系统化的软件故障排查方法论，专为复杂、复发或高风险的软件缺陷设计。其核心原则是 "先证明，后修复" ——在动手修改代码之前，必须通过结构化流程将故障根因定位到 100% 确定。
四阶段工作流
| 阶段 | 时长 | 核心任务 |
|------|------|----------|
| **Pre-Phase** | 30 秒 | 快速排查 5 个基础设施问题（服务重启、环境变量、依赖安装、数据库迁移、浏览器缓存） |
| **Phase 1** | 5–15 分钟 | 数据收集：回答 4 个关键问题（发生什么、何时发生、应发生什么、最近改了什么） |
| **Phase 2** | 强制 | 假设 formulation：用一句话表述可验证的因果假设 |
| **Phase 3** | 核心耗时 | 二分搜索：按假设类型选择专项排查清单（Auth/API/Frontend/DB/Performance），逐层缩小范围 |
| **Phase 4** | 最后一步 | 最小化修复：仅修改被证实的根因，即时验证 |
显著优点
1. 防止修复 regressions：强制假设验证避免"症状缓解但根因未除"
2. 效率提升：二分搜索将指数级排查转为对数级，尤其适合嵌套调用链（JWT 验证 5 步、API 请求 6 层、React 渲染 7 环）
3. 知识沉淀：内置 Lessons Learned 库（JWT 签名不匹配、跨域 Cookie 陷阱、Prisma N+1 等真实案例）
4. 抗认知偏差：3 次失败后强制 escalation，支持启动无偏 Subagent 避免 confirmation bias
5. 安全合规：敏感数据（JWT 值、密码、生产连接串）明确禁止进入日志/报告
潜在局限性与风险
| 局限 | 说明 |
|------|------|
| **启动成本** | 简单拼写错误或缺失安装会触发完整四阶段流程，可能过度设计 |
| **时间压力冲突** | 生产环境紧急故障时，"30 秒 pre-phase + 完整假设"流程可能与"先止血"需求矛盾 |
| **假设质量依赖** | Phase 2 的假设若本身错误，后续二分搜索可能方向偏离（虽有 escalation 兜底） |
| **工具链绑定** | 专项清单深度适配 NestJS/Next.js/Prisma 技术栈，其他框架需适配 |
| **德语/英语混用** | 技能文档以德语为主（"Kein blindes Fixen"），可能增加非德语团队认知负荷 |
适合人群
- 中级以上开发者：理解 JWT 流程、React hooks 规则、Prisma 查询优化等概念
- 全栈工程师：需要同时排查前后端交互问题
- 团队技术负责人：建立团队级调试规范，减少"试一下这个"式排查
- 复杂系统维护者：微服务、多租户、SSO 等场景下的 auth/permission 类 bug
常规风险
- 敏感信息泄露：文档虽强调不输出 JWT 值，但 copy-paste 错误仍可能发生
- 调试污染生产：curl 命令示例建议用 localhost，但实际执行时需严格隔离环境
- 无限递归假设：Phase 3 的二分若边界定义不清，可能陷入"再测一步"的无限循环
- Fix 范围蔓延：Phase 4 要求"最小修复"，但开发者常顺手重构周边代码
使用建议
> 触发词：debug / bug / broken / 401 / 403 / 500 / "funktioniert nicht"
- 不要用于：明显拼写错误、
npm install未执行、漏写逗号等 trivial 问题 - 必须用于：用户说"修复了但没好"、间歇性故障、安全相关（auth/session）问题、需要代码审查前的根因分析