thinking-scientific-method

科学方法（假设差异分析）

当某个症状可能源自多个地方时，列出相互竞争且可证伪的假设，并用成本最低的观察来检验最能区分这些假设的那一项。每次观察后，只保留仍然成立的假设，然后优先选择缺乏依据的假设最少者作为当前解释。

适用场景

• 某个 Bug、事件或异常可能有多个合理原因。
• 现在可以检查代码、日志、差异、跟踪记录、测试、配置或数据。
• 修复之前必须定位出错的文件、函数、分支、配置或不变量。
• 相互竞争的解释都符合表面事实，需要进行区分性检查。

不适用场景

• 单个堆栈信息、失败的测试或近期差异已经清楚地表明原因——直接修复。
• 只有一个合理的假设——检验它；不要为了走流程而凭空制造其他假设。
• 目前无法进行任何观察——先获取访问权限；不要推测故障位置。
• 为期数周的实验、产品 A/B 测试或政策试验——此技能用于 Agent 现在就能进行的检查。
• 故障已经定位，而你需要深入分析系统性根因或预防措施——使用 five-whys-plus。
• 更适合用 IS/IS-NOT 对比来分析的选择性缺陷（“只有这些对象／时间”）。
• 表示形式（文档／仪表板）可能已过时、与现实不符——先用 map-territory 核实实际情况，再继续分析假设。

流程

1. 准确描述症状。 记录失败行为、范围、时间、环境和限制。将观察与解释分开。
2. 列出 2–5 个相互竞争的假设。 指明具体文件、函数、配置、输入条件或不变量。避免含糊的类别（“后端问题”）。如果经过审慎检查后没有剩下严肃的备选假设，就退出这项差异分析，直接检验或修复唯一有证据支持的原因；绝不要为了继续流程而捏造一个竞争假设。
3. 在检查前说明证伪条件和低成本观察。 对于每个假设：什么结果会排除它？现在可以运行什么读取／grep／差异／日志／测试检查？优先选择能立即进行的观察，而不是部署、金丝雀发布或漫长等待。
4. 根据区分能力 × 成本对观察排序。 运行成本最低且最能区分主要候选项的检查。如果有一项低成本交叉检查可以排除其他可能性，就不要先深入调查最偏好的假设。
5. 每次观察后更新。 排除已证伪的假设。在仍与所有证据相符的假设中，优先选择缺乏独立依据的假设最少者（涉及额外组件、罕见时序或外部依赖较少）。简约性只用于对仍成立的假设排序；如果证据已经反驳某个假设，再简约也不能挽救它。只有排除较简单的假设后，才升级到更复杂的解释。
6. 定位并停止。 当某个假设有直接支持证据，且关键备选假设已被排除时，指出需要修改的文件／函数／配置，以及用于定位的证据。一旦直接定位，就停止分析。

输出

Symptom: <specific failing behavior, scope, timing>
Hypotheses:
  H1: <specific cause> | Why plausible | Observation | Falsified if
  H2: ...
  H3: ...
Test order: <cheapest discriminating checks>
Results: <what each observation showed>
Survivors: <remaining Hs; least-assumptive working pick among fit>
Localized fault: <file/function/config + supporting evidence>
Ruled out: <Hs dropped and why>

验证

• 如果在严肃假设少于两个时仍继续、没有预先说明证伪条件、跳过了成本更低的区分性检查，或在证据与某个“更简单”的解释相矛盾后仍保留该解释，则应证伪差异分析的结论。
• 当故障已直接定位，且相关备选假设已被排除时停止；不要继续推测。
• 避免过度使用：不要在没有相互竞争的原因时叙述“观察→提问”；不要把假设最少当作证明；如果已有证据明确表明单一明显原因，不要使用此技能。