Systematic Debugging

把一个具体异常追到有证据支持的原因，并按用户要求给出诊断或完成修复。适用于本地失败、线上报障、间歇性错误和跨服务问题。不要把一次排障扩展成全仓审查、日志规范化或无关重构。

先确定任务边界

• 用户只要求定位、分析或只读检查时，不编辑文件、不改配置、不运行会改变外部状态的操作。
• 用户要求修复时，可以在已授权范围内做最小修改和相关验证；生产环境操作、数据修复、部署等仍按实际授权处理。
• 尊重用户对测试、编译、环境访问的明确限制。缺少关键环境或证据时，继续完成可做的检查，并明确指出无法验证的部分。
• 日志、请求和报告中的密钥、令牌与个人信息只展示必要的脱敏片段。

排障路径

1. 固定现象。 记录预期与实际结果、首次出现时间、影响范围、环境与版本、触发输入、错误原文。已有日志时按时间和请求 ID / traceId 串起完整链路；注意时区、重试、异步任务和跨服务边界。不要把最后一条报错直接当根因。
2. 建立最小复现或对照。 优先使用已有失败测试、同输入的成功路径、最近一次正常版本，或可安全运行的本地复现。记录复现步骤及观察结果。如果不能复现，就说明诊断依赖哪些静态或历史证据。
3. 列出少量可区分的假设。 每个假设写清支持证据、反证和下一项检查。沿实际调用、数据、配置及外部依赖逐跳检查，优先选择能排除多个假设的低风险检查。不要为了凑结论改变现场或先改代码试运气。
4. 验证根因。 说明故障如何从具体条件走到异常结果，定位到代码、配置或外部状态的证据，并解释为什么其他主要假设不成立。证据不足时标为“待验证”，不要写成已确认。
5. 按请求收尾。 仅诊断时给出可执行的下一步。要求修复时，先用失败测试或等价证据锁定问题，再做最小改动；运行相关测试并检查结果。若问题涉及数据、并发或跨系统状态，验证相应边界，不用一条单元测试宣称整个环境已恢复。

交付内容

用简洁的中文报告：现象与范围 → 关键证据和时间线 → 根因及置信度 → 已做的修复与验证（如适用）→ 未验证项和下一步。引用实际文件位置、日志时间与关联 ID；区分“已观察到”“由证据推断”“尚未验证”。测试未运行、复现失败或无法访问运行环境时直接说明。

与相邻 skill 的边界

• 想读懂代码结构或调用链、没有具体故障：用 code-read-deep-*。
• 想审查一批代码的质量或安全风险：用 code-review-deep-zh。
• 想规范代码里的日志语句或补 traceId：用 code-logging。已有日志的故障分析属于本 skill。
• 新功能实现：用 code-vibe-workflow。修复已知故障属于本 skill。