systematic-debugging · 系统化调试
通用调试方法论 skill：铁律是"先找到根因，再谈修复"——症状式修复视为失败。
四阶段流程必须按序完成：根因调查（读报错、稳定复现、查近期变更、边界打点取证、数据流追溯）→ 模式分析（找可工作的参照、逐条列差异）→ 单假设小步验证 → 写出失败测试再修根因。适用于测试失败、线上 bug、构建失败、性能问题等一切技术问题。
调用示例：在聊天框中说"这个测试挂了，帮我按流程排查，别直接改代码"。
产品详解
定位
systematic-debugging 是处理任何 bug、测试失败与异常行为的调试纪律 skill：用固定四阶段流程替代"凭感觉试修"，避免反复试错带来的返工。
核心能力
- 根因调查：完整读报错与堆栈；稳定复现；检查近期变更（git diff、依赖、环境差异）；多组件系统在组件边界打日志取证；深层调用栈向上追溯坏值来源。
- 模式分析：在同代码库找可工作的相似例子；完整读参考实现；逐条列出差异；理清依赖与隐含假设。
- 假设与验证：一次只提一个假设、最小改动验证、单变量测试；不知道就直说、去查、求助，不硬猜。
- 根因修复：先写出最简失败测试（可用 test-driven-development skill）；一次只改一处；验证通过且无回归；同一问题尝试 3 次失败则停下来质疑架构。
工作流程
四阶段必须按序完成，不可跳过：
- 根因调查：未完成前不许提任何修复方案
- 模式分析：先找规律再动手
- 假设与验证：科学方法，单假设单变量
- 实现修复：修根因而非症状，验证后收尾
输入与输出
| 输入 | 说明 |
|---|---|
| 报错信息/堆栈 | 必填 |
| 复现步骤 | 尽量提供 |
| 相关代码位置 | 选填 |
输出：根因结论、失败测试用例、根因修复方案。
与相邻 skill 的区别
- verification-before-completion：宣称完成前的验证门（证据先于断言）。
- systematic-debugging（本）：出问题时的排查流程（先根因后修复）。两者常配合：本 skill 的修复阶段明确要求用 verification-before-completion 确认修复有效。
适用场景
- 测试失败、线上 bug、构建失败、性能问题、集成异常
- "赶时间想直接改"的高压场景（越急越不许跳过）
- 已经试了好几次修不好、想换思路的情况
使用前准备
- 无特殊配置；准备好完整报错信息与复现步骤。
- 纪律要求：紧急情况下更不许跳过流程，跳过等于返工。
systematic-debugging 隶属于 Aiglade Skill 库。在 Aiglade 聊天框中用自然语言描述需求即可调用。