一组规则，不是一条流水线
Agans 的方法不是"先做 A 再做 B 最后做 C"。九条规则各自独立，每条针对调试过程中一种具体的失误模式。你可以在调试的任何阶段拿出其中任何一条来用。
这和性能分析类的方法论有本质区别。USE 方法或 drill-down 分析是有严格顺序的流程——跳了一步后面就接不上。九条规则更像一套核对清单：卡住的时候拿出来逐条对照，看自己漏了哪条。
这种结构的好处是入门门槛极低。你不需要理解全部九条才能开始用——理解一条，下次调试时就多一个检查点。
四层结构
虽然规则之间没有严格顺序，但它们覆盖的是调试过程中不同层次的需求。
前提层：Understand the System。决定后面所有判断的质量。不理解系统，分而治之的切面就会选错，观察数据时也分不清正常和异常。
证据层：Make It Fail、Quit Thinking and Look、Keep an Audit Trail。三条规则共同保证你在基于事实工作——能复现、在看数据、有记录。
操作层：Divide and Conquer、Change One Thing at a Time、Check the Plug。三条规则约束你的动手方式——怎么缩小范围、怎么隔离变量、怎么不遗漏简单原因。
元规则层：Get a Fresh View、If You Didn't Fix It, It Ain't Fixed。两条规则在调试操作之外起作用——跳出当前视角的能力，以及确认修复的标准。
四层不是严格串行的。你可能在操作层卡住之后回到前提层重新理解系统，也可能在证据层发现复现条件变了而重新执行操作层。
核心假设：调试失败是人的问题
九条规则建立在一个统一假设上：大部分调试失败不是因为 bug 太复杂，而是因为调试者违反了基本纪律。
Agans 认为工程师在调试中最常犯三类错。
跳过准备。 没理解系统就开始改、没复现就开始猜、没记录就开始试。
违反隔离。 一次改多个变量、忽略简单原因、不看数据凭直觉判断。
过早收工。 问题消失就认为修好了，不验证根因、不检查修复是否覆盖了触发条件。
九条规则逐条堵住这些口子。规则的价值不在于告诉你 bug 在哪——而在于阻止你把自己绕进去。
方法的边界在"规则"这个层级
Agans 的方法有一个设计上的取舍：它只给规则，不给具体技术。
"让它出错"是规则。具体怎么让它出错——写测试用例、搭测试环境、录制重放流量——取决于你面对的系统。"分而治之"是规则。具体怎么分——在代码层分、在网络层分、在时间线上分——也取决于系统。
这是九条规则能跨硬件和软件通用的原因：它们在抽象层级上足够高。但这也意味着，在具体场景中执行某条规则时，你需要自己填入领域知识。规则告诉你"该做什么"，不告诉你"用什么工具做"。
对经验丰富的工程师，这是优势——规则不会因为技术栈过时而失效。对新手，这意味着九条规则需要和特定领域的调试工具配合使用，单独依赖规则不够。