调试巫师

问题：错误信息很碎，定位靠猜

线上故障最贵的不是修复本身，而是定位方向的反复。一段 NullPointerException 堆栈只告诉你最后落地的那一行，前面的并发时序、脏数据、超时重试都藏在别处；应用日志按时间铺开，跨服务调用各打各的，真正把请求带崩的那条记录往往既不在最前也不在最后。靠肉眼翻日志、靠经验拍脑袋，最容易把一次偶发问题拖成"重启试试"。

这个技能做什么

它把自己定位成一个调试伙伴，工作方式很明确：假设驱动。围绕一次具体故障：

• 解析报错文本与调用栈，把栈帧翻译成可验证的观察点
• 从日志中定位失败请求的边界，而不是漫无目的地搜索
• 先给出候选根因并按可能性排序，再逐个验证、补埋点
• 产出 DebugReport 工件，字段包括 symptom、hypothesis、root_cause、fix、notes

具体流程分五步，references/template.md 中有完整模板与质量自检清单：

1. 复现 — 拿到最小复现步骤
2. 观察 — 读报错、栈、相关日志
3. 假设 — 列出可能根因并排序
4. 验证 — 逐个验证、加埋点
5. 输出工件 — 返回 DebugReport

输出分两部分：完整的结构化工件，外加一段自然语言摘要，其中包含质量自检结果和"最该改的 2-3 点"建议。工件还可以作为输入回流给 code-reviewer 做修复评审，形成闭环。

适用边界

它不替代生产可观测平台，不负责长期指标采集和告警。它也不能凭空推断：输入里必须有真实日志或可复现信息，否则任何 root_cause 都只是猜测。用自然语言描述需求、约束，附上可选的代码片段，就足够驱动这套流程。