thinking-occams-razor

奥卡姆剃刀

概述

奥卡姆剃刀指出：对于能同样充分解释证据的相互竞争假设，应优先选择假设最少的那个。本技能将这一原则用于调试：先测试最简单的假设，只有在证据迫使我们这么做时，才升级到复杂的解释。

本技能设有触发收缩关卡：如果只需一步就能测试最简单的假设，那就直接测试——不要运行完整的枚举和评分流程。只有在多个假设确实相互竞争，且无法明显地直接测试最简单的假设时，才使用完整流程。

核心原则：“凡事都应尽可能简单，但不能过于简单。”——爱因斯坦

适用场景

• 多个假设都可能解释某个 Bug，且无法明显地通过一步测试最简单的假设
• 你正准备调查一个复杂假设，却还没有先测试更简单的假设
• 架构或设计决策中，有几种可行方案，且复杂度各不相同
• 根因分析中，有几种原因看起来都说得通

决策流程：

Multiple explanations exist?
  → No → Use the available explanation
  → Yes → Can the simplest be tested in one step?
      → Yes → JUST TEST IT (trigger-shrink — skip full procedure)
      → No → Do they explain the evidence equally well?
          → No → Prefer the better explanation
          → Yes → RUN FULL OCCAM'S RAZOR PROCEDURE

不适用场景

• **证据已经指向某个特定原因。**遵循证据；不要降级为与之矛盾的“更简单”假设。
• 领域本质上就很复杂（分布式共识、并发、安全威胁模型）。最简单的模型是错误的；不要过度简化（“但不能过于简单”）。
• **只有一种合理的解释。**无从比较——直接测试即可。
• **所谓“简单”意味着忽略已知的交互作用，或跳过关键的安全保障。**局部简单却带来系统性风险，并非简约原则。
• **触发检查已经解决问题。**如果只需一步就能测试最简单的假设，并且测试结果证实了它，那么就可以结束——不要为了面面俱到而枚举假设。

触发卡

在运行完整的枚举和评分流程之前，先问一个问题：“我能否通过一步测试最简单的假设？”

1. 找出最简单的假设——在仍能解释证据的前提下，所需假设最少的那个。
2. 能否一步测试？→ 能 → **直接测试。**如果得到证实，就报告并停止。如果被证伪，就转向下一个最简单的假设。
3. 如果无法一步测试→运行完整的奥卡姆剃刀流程（枚举、计算假设数量、验证解释力、按顺序测试）。

如果证据已经指向某个特定原因，就遵循证据——不要降级为与之矛盾的“更简单”假设。对于本质上很复杂的领域（分布式共识、并发），最简单的模型是错误的。

流程

触发检查（快速路径）

运行完整流程之前，先问：“我能否通过一步测试最简单的假设？”

• 能 → 测试它。如果得到证实，就报告并停止。如果被证伪，就转向下一个最简单的假设。
• 不能 → 最简单的假设需要进行并非简单的调查 → 运行下面的完整流程。

完整流程：触发检查无法解决时

步骤 1：枚举相互竞争的假设

列出所有能解释所观察行为的合理原因：

Bug: Users intermittently can't log in

Hypotheses:
A. Session token expiration edge case
B. Race condition in auth service
C. Database connection pool exhaustion
D. Complex interaction between CDN cache, load balancer, and session service

步骤 2：计算每个假设所需的假设数量

假设	所需假设
A. 令牌过期	1. 令牌验证存在边界情况
B. 竞态条件	1. 可能存在并发请求，2. 存在共享的可变状态
C. 数据库连接池耗尽	1. 连接池规模不足，2. 连接泄漏
D. 复杂交互作用	1. CDN 缓存了身份验证信息，2. 负载均衡器（LB）的粘性会话失效，3. 会话同步延迟

对每个独立假设计数：每项假设 +1，每个涉及的组件 +1，每项外部依赖 +2，依赖时序的行为 +2，罕见条件 +3，“完美风暴”场景 +5。

步骤 3：验证解释力

确保较简单的假设确实能够解释证据：

Evidence: Failures correlate with high traffic periods
Hypothesis A (token edge case): Doesn't explain traffic correlation ✗
Hypothesis C (DB pool exhaustion): Explains traffic correlation ✓ — fewer assumptions than D
→ PREFERRED by Occam's Razor

步骤 4：按假设数量从少到多进行测试

按假设数量从少到多逐一调查。在简单假设被排除之前，不要跳到复杂假设。

步骤 5：只有证据迫使时才升级复杂度

有证据排除简单解释后，再转向更复杂的解释。绝不要仅凭直觉升级复杂度。

输出规范

一份完整的奥卡姆剃刀分析应包含：

1. 触发条件检查结果 — 最简单的假设是否能通过一步测试
2. 假设排序 — 按假设数量排序，并列出每个假设所需的假设
3. 解释力检查 — 哪些假设符合证据
4. 测试顺序和结果 — 测试了哪些假设、按什么顺序测试，以及结果如何
5. 结论 — 已确认的假设（若尚未解决，则给出下一个要测试的假设）

对于触发条件收缩的情况，输出可以只有一行：“已测试最简单的假设 X——确认／排除。”

反模式

反模式	症状	修正方法
过度简化不可约化领域	将“最简单”原则应用于分布式共识或安全模型	“但不能再简单了”——尊重领域复杂性
复杂性偏见	认为复杂就代表高明，优先测试复杂假设	始终优先测试所需假设最少的假设
触发条件膨胀	对一步测试就能验证的情况进行完整枚举	如果最简单的假设可以通过一步测试验证，就直接测试
忽略解释力	选择了最简单但不符合证据的假设	假设更少，不能弥补与数据不符
局部简单，系统性风险	选择简单的局部修复，却导致其他地方变得脆弱	优先考虑系统层面的简单性，而非局部简单性
仪式化地计算假设数量	花在计算假设数量上的时间超过测试所花的时间	重点是确定优先级，而非精确计算；粗略计数即可