聊聊 systematic-debugging。
背景
这个 skill 是 Jesse Vincent 鼓捣出来的，GitHub @obra，Superpowers 的创建者。
干什么的？专门治瞎猜这个毛病。
核心理念就一句：没找到根本原因之前，别动手修。
What — 这是什么
systematic-debugging 是一套调试流程，分四步：
第一步：根本原因调查
官方描述：
"Read Error Messages Carefully. Don't skip past errors or warnings. They often contain the exact solution. Read stack traces completely. Note line numbers, file paths, error codes."
翻译：仔细读错误信息。别跳过错误和警告，它们经常包含确切答案。把堆栈跟踪读完，记下行号、文件路径、错误码。
还要复现问题：能稳定触发吗？具体步骤是什么？每次都发生吗？不能复现就收集更多数据，别猜。
还要检查最近改动：什么改动可能导致这个问题？Git diff、最近的提交、新依赖、配置变更、环境差异。
还要追踪数据流：错误发生在调用栈深处？坏值从哪来的？谁调用时传了坏值？一直追溯到源头，在源头修，别在症状处修。
第二步：模式分析
官方描述：
"Find Working Examples. Locate similar working code in same codebase. What works that's similar to what's broken?"
翻译：找类似的好代码。代码库里有没有类似的、正常工作的代码？什么做法能让它正常运转？
还要对比参考实现：
"If implementing pattern, read reference implementation COMPLETELY. Don't skim - read every line. Understand the pattern fully before applying."
翻译：如果在实现某个模式，把参考实现从头到尾读一遍。别跳着看，一行一行读，完全理解再动手。
还要找出差异：正常工作的和坏掉的有什么区别？列出每一个差异，哪怕很小，别觉得"这个不可能有影响"。
第三步：假设测试
官方描述：
"Form Single Hypothesis. State clearly: 'I think X is the root cause because Y'. Write it down. Be specific, not vague."
翻译：形成单个假设。清楚说出来："我觉得 X 是根本原因，因为 Y"。写下来，要具体，不要模糊。
还要最小化测试：做最小的改动来验证假设，一次只改一个变量，别同时修一堆东西。
第四步：实施
"Create Failing Test Case. Simplest possible reproduction. Automated test if possible. One-off test script if no framework. MUST have before fixing."
翻译：写个失败的测试用例。最简单的复现方式，能自动化就自动化，没有框架就写一次性脚本。修复之前必须先有这个。
还要做单一修复：解决已识别出的根本原因，一次只改一个地方，别"既然都来了"顺手改进，别夹带重构。
遇到 bug、测试失败、行为不符预期，先调查再动手。没有例外。
Why — 为什么要用
因为人会本能地跳步。
什么是本能的调试？官方描述说：
"Random fixes waste time and create new bugs. Quick patches mask underlying issues."
翻译：随机修复浪费时间，还会引入新 bug。快速补丁掩盖根本问题。
"Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure."
翻译：核心原则：动手修复之前，总是先找到根本原因。修症状就是失败。
这就是为什么人们总是需要这些借口：
"Issue is simple, don't need process" — 简单问题也有根本原因
"Emergency, no time for process" — 系统性调试比瞎撞更快
"Just try this first, then investigate" — 第一个修复定了基调
"I'll write test after confirming fix works" — 没测试的修复不牢固
结果呢？官方数据：
"Systematic approach: 15-30 minutes to fix. Random fixes approach: 2-3 hours of thrashing. First-time fix rate: 95% vs 40%. New bugs introduced: Near zero vs common."
翻译：系统性方法 15-30 分钟解决。瞎撞方法 2-3 小时反复折腾。一次修复成功率 95% vs 40%。引入新 bug 几乎为零 vs 常见。
瞎猜是随机搜索，系统性调试是把不确定变成确定，每一步都在缩小范围。
这个 skill 对 AI 特别有用。AI 的本能跟人一样，看到问题就想给答案。有了这套流程，AI 才能先调查再动手。
When — 什么时候用
"Use for ANY technical issue: Test failures, Bugs in production, Unexpected behavior, Performance problems, Build failures, Integration issues."
翻译：用于任何技术问题：测试失败、生产 bug、行为不符预期、性能问题、构建失败、集成问题。
尤其要用的是这几种：
"Use this ESPECIALLY when: Under time pressure (emergencies make guessing tempting), 'Just one quick fix' seems obvious, You've already tried multiple fixes, Previous fix didn't work, You don't fully understand the issue."
翻译：尤其要用：时间紧迫（紧急情况最容易冲动）、"就改一下应该就行"看起来很明显、已经试过很多次修复、上一次修复不管用、你压根没搞懂这个问题。
还有：
"Don't skip when: Issue seems simple (simple bugs have root causes too), You're in a hurry (rushing guarantees rework), Manager wants it fixed NOW (systematic is faster than thrashing)."
翻译：别跳过：问题看起来很简单（简单 bug 也有根本原因）、你赶时间（赶时间瞎修只会返工）、老板说现在就修（系统性调试比乱撞更快）。
How — 怎么用
这个 skill 设计了一套提醒机制，让你知道自己什么时候在违反规则。
红牌警告——你在瞎猜了：
"If you catch yourself thinking: 'Quick fix for now, investigate later', 'Just try changing X and see if it works', 'I don't fully understand but this might work', 'One more fix attempt' (when already tried 2+), 'Each fix reveals new problem in different place' — ALL of these mean: STOP. Return to Phase 1."
翻译：如果你开始这么想：先快速修一下之后再调查、先试试改 X 看看能不能成、我不太懂但这可能有用、再试一次修复（已经试了 2+ 次了）、每次修复都在不同地方暴露新问题——上面任何一条的意思都是：停，回到第一步。
还要注意这个：
"If 3+ Fixes Failed: Question Architecture. Pattern indicating architectural problem: Each fix reveals new shared state/coupling/problem in different place, Fixes require 'massive refactoring' to implement, Each fix creates new symptoms elsewhere. STOP and question fundamentals."
翻译：如果 3+ 修复都失败了，质疑架构。出现这些情况说明架构有问题：每次修复都在不同地方暴露新问题、修复需要大规模重构才能实现、每次修复都在别处产生新症状。停，质疑基本设计。
人类搭档觉得你在瞎猜的信号：
"Watch for these redirections: 'Is that not happening?' - You assumed without verifying, 'Stop guessing' - You're proposing fixes without understanding, 'Ultrathink this' - Question fundamentals, not just symptoms."
翻译：注意这些重新导向："没发生吗？"——你假设了但没验证、"别瞎猜"——你在没搞懂之前就提修复、"仔细想这个"——质疑基本原理，不只是症状。
这个 skill 的设计逻辑是：人不觉得自己在瞎猜，但搭档看得出来。所以 skill 借用了这个思路，设计了这些信号，让 AI 和人协作时能及时停下来。
最后
这个 skill 最有意思的地方不是那四步流程，而是它的前提假设：
"Violating the letter of this process is violating the spirit of debugging."
翻译：违反这个流程的字面规定，就是违反调试的本质。
人会本能地跳步，在没完全理解问题之前就开始修复。看到问题就想解决，是效率本能，但在调试这里，效率本能反而会拖慢速度。
Kent Beck 那句话放这儿也合适：
"I'm not a great debugger; I'm a debugger with great habits."
我不是什么调试大师，我只是个有好习惯的调试者。
Superpowers 把它变成强制流程，AI 也得遵守这个老派但管用的调试方式。
