名称: 系统化调试描述: 方法化调试而非随机更改版本: 2.2.0 类别: 调试作者: Jesse Vincent 许可证: MIT 来源: https://github.com/obra/superpowers-skills/tree/main/skills/debugging/systematic-debugging 渐进披露: 入口点: 摘要: “使用四阶段调查框架，用系统化问题诊断替换随机代码更改” 使用时机: “当用户报告漏洞、错误、测试失败或意外行为时。尤其是在时间压力下或’快速修复’看起来显而易见时。” 快速开始: “1. 完全阅读错误消息 2. 一致地重现 3. 形成具体假设 4. 用单个更改测试 5. 验证修复” 参考: - 工作流程.md - 示例.md - 故障排除.md - 反模式.md 上下文限制: 800 标签:

调试
问题解决
根本原因
系统化所需工具:
调试器

系统化调试

概述

随机修复浪费时间并创建新漏洞。快速补丁掩盖了潜在问题。

核心原则: 在尝试修复前，总是找到根本原因。症状修复是失败的。

这个技能强制执行一个四阶段系统化方法，确保在修复尝试前进行根本原因调查。违反这个过程的精神就是违反调试的原则。

使用这个技能的时机

激活当:

用户报告漏洞或错误
测试失败发生
代码行为意外
性能问题出现
构建或集成失败
用户说"它不工作"

特别是在以下情况下使用:

时间压力下（紧急情况使猜测变得诱人）
"只是一个快速修复"看起来显而易见
你已经尝试了多种修复
之前的修复没有奏效

铁律

没有根因调查，就没有修复

如果你没有完成第一阶段，就不能提出修复。

核心原则

先重现: 确保你能可靠地重现问题
一次更改: 测试间只更改一件事
假设驱动: 在更改前形成假设
验证修复: 确认修复有效且不破坏其他内容

快速开始

阅读错误消息: 完全阅读，包括堆栈跟踪
一致地重现: 创建可靠的复制步骤
收集证据: 在多组件系统中添加诊断工具
形成假设: 清楚地陈述"我认为X因为Y"
最小化测试: 做尽可能小的更改
验证修复: 确认解决方案且没有回归

四个阶段

第一阶段: 根因调查

在尝试任何修复前:

仔细阅读错误消息（它们通常包含解决方案）
一致地重现
检查最近的更改
在多组件系统中收集证据
追踪数据流回源头

第二阶段: 模式分析

找到工作示例，与参考比较，识别差异，理解依赖关系。

第三阶段: 假设和测试

形成单一假设，最小化测试（一次一个变量），验证前继续。

第四阶段: 实施

创建失败的测试用例，实施解决根本原因的单一修复，验证修复有效。

如果3次以上修复失败: 停止并质疑架构——这表明架构问题，而非假设失败。

关键提醒

永远不要做随机更改希望它们会奏效
在尝试修复前，总是重现问题
在更改前形成假设
一次更改一件事
验证修复实际解决了问题
修复后检查回归
如果3次以上修复失败，质疑架构

红旗 - 停止并遵循流程

如果你发现自己思考:

“先快速修复，稍后调查”
“试试更改X看是否奏效”
“可能是X，让我修复那个”
“我不完全理解，但这可能奏效”
“再尝试一次修复”（当已经尝试2次以上）
每次修复在不同地方揭示新问题

所有这些意味着: 停止。返回到第一阶段。

与其他技能的集成

根因追踪: 如何通过调用堆栈追踪
深度防御: 找到根本原因后添加验证
条件等待: 替换第二阶段识别出的超时
完成前验证: 在声称成功前验证修复奏效
测试驱动开发: 在第四阶段创建失败的测试用例

现实世界影响

从调试会话:

系统化方法: 15-30分钟修复
随机修复方法: 2-3小时折腾
首次修复率: 95% vs 40%
引入新漏洞: 几乎为零 vs 常见

系统化调试Skill systematic-debugging