用途
Systematic Debugging 提供一种结构化的调试方法，用来避免“随机猜测式”修改，确保在动手解决前先真正理解问题。资料指出，该技能适用于调试复杂问题时使用，其目标是系统化地定位并消除缺陷，而不仅是让症状暂时消失。
来源信息显示，该技能源自 obra/superpowers，当前收录于 vudovn/ag-kit。
四阶段调试流程
第一阶段：复现（Reproduce）
在修复之前，先可靠地复现问题。资料给出的复现步骤模板为：记录精确的复现步骤、下一步操作，以及预期结果与实际结果。并要求评估复现率，可选档位包括：始终（100%）、经常（50-90%）、有时（10-50%）、罕见（低于 10%）。
第二阶段：隔离（Isolate）
缩小问题来源。资料列出的隔离提问包括：这个问题是什么时候开始出现的？最近有什么改动？是否在所有环境中都会发生？能否用最小代码复现？触发它的最小改动是什么？
第三阶段：理解（Understand）
找到根因，而不只是症状。资料给出的根因分析方法是“5 个为什么”（The 5 Whys），通过连续追问，从第一个观察逐层深入到根因：第一个为什么对应首次观察，随后逐层追问更深层原因，直到定位根因。
第四阶段：修复与验证（Fix & Verify）
修复并验证问题确实已被解决。资料给出的验证清单包括：缺陷不再复现、相关功能仍然正常、没有引入新问题、添加测试以防止回归。
调试清单
资料将清单分为三个阶段：
- 开始前：能否稳定复现、是否已有最小复现用例、是否理解预期行为。
- 调查中：检查近期改动（git log）、检查日志中的错误、必要时添加日志、使用调试器/断点。
- 修复后：记录根因、验证修复、添加回归测试、检查相似代码。
常用调试命令
资料提供的命令示例包括：
# 近期改动
git log --oneline -20
git diff HEAD~5
# 按模式搜索
grep -r "errorPattern" --include="*.ts"
# 查看日志
pm2 logs app-name --err --lines 100
应避免的反模式
资料明确列出以下反模式：
- 随机修改——“也许我改这里就行……”。
- 忽视证据——“那不可能是原因”。
- 假设——没有证据就断言“一定是 X”。
- 未先复现——盲目修复。
- 停留在症状——不找根因。
适用场景与限制
资料表明该技能适用于调试复杂问题，尤其是需要根因分析和基于证据验证的场合。关于该技能支持的具体平台、安装方式、收费情况或价格，资料中暂未提供，因此无法确认。