用途
Debugging 是一套系统化调试技能框架，用于在修改代码之前先定位问题的根本原因。其核心理念是“没有完成根因调查前不做任何修复”，因为随机修复既浪费时间，又可能引入新的 Bug。
主要能力
- 四阶段调试流程：调查（Investigating）→ 分析（Analyzing）→ 提出假设（Hypothesizing）→ 修复（Fixing）。
- 根因追溯：当错误出现在深层调用栈时，从出错位置开始向后追踪坏数据的来源，直到找到源头，并在源头而非症状处修复。
- 验证协议：强调“没有新的验证就不能宣称完成”，要求实际运行验证命令（如 npm test、yarn test、pytest 等）并查看输出后再下结论。
- 危险信号识别：把“先临时快速修一下”“试试改 X”“大概是 X”“现在应该行了”“看起来修好了”等表述视为需要退回第一阶段的信号。
使用方式
第一阶段：调查
- 完整阅读错误信息和堆栈跟踪。
- 复现问题，确认 Bug 确实存在。
- 检查近期变更（git diff、git log）。
- 收集证据，例如日志和控制台输出。
第二阶段：分析
- 找到一个可正常工作的相似示例。
- 对比两者差异。
- 找出模式，确定分歧出现的位置。
第三阶段：提出假设
- 形成理论，例如“它出错是因为……”。
- 做最小化测试，用最小的改动来验证。
- 确认修复是否有效。
第四阶段：修复
- 先写测试，确保能复现该 Bug。
- 应用单一、聚焦的修复。
- 验证测试通过且没有引入回归。
深层堆栈错误的处理
- 从错误位置开始。
- 向后追溯：坏数据来自哪里？
- 持续追溯直到找到源头。
- 在源头修复，而不是只处理症状。
验证协议
规则：没有新的验证，就不能宣称完成。
# Run verification
npm test # or yarn test, pytest, etc.
# Check output
# THEN claim result
错误做法：“现在应该可以了”。正确做法：“测试通过：[粘贴输出]”。
适用场景
- 测试失败
- Bug 与错误
- 异常行为
- 性能问题
- 构建失败
- 在宣称“已修复”之前
限制与缺失信息
资料未说明该技能的安装方式、依赖环境、支持平台或与具体工具的集成方式，这些信息暂未提供。