用途
“攻击前提”是一条调试与问题排查原则，适用于以下情形：两个或更多修复方案共享同一个前提，并且它们在同一个关卡（gate）上以相同方式失败。此时应当怀疑的是这个前提，而不是继续修改修复方案。
核心逻辑
每一次失败的修复，都是对其所假设信念的一份反证。如果继续在同一前提上做第三次修复，就等于把精力花在证据已经表明原因并不存在的地方。
操作模式
- 写下前提：前提就是每一个失败修复都假设的那一句话。
- 在下一次修复前检验前提：找到一个观察——如果前提为假，这个观察会呈现不同的结果——并实际去做这个观察。不要只看失败有多大，还要看失败是如何分布的。让这个检查可以重复运行（参考 /principle-build-the-lever）。
- 跟随证据：如果证据与前提矛盾，说明原因在别处。寻找这些失败共同具备、而前提未能预测到的特征。如果证据确认了前提，则继续追问下一个“为什么”（参考 /principle-fix-root-causes）。此前的修复可能只是在处理后果，而不是原因。
- 移除条件，而不是补偿它（参考 /principle-laziness-protocol）：如果证据显示某个部分总是落在失败的一侧，就改变让它落到那里的东西。一个事后清理的机制会把原因留在原处，并在每次运行时增加额外工作。
停止条件
在前提被写下并检验之前，不要开始下一次修复。
与其他原则的区别
本原则不同于 /principle-redesign-from-first-principles（从第一性原理重新设计），后者是围绕一个新需求重建设计；而本原则质疑的是当前设计所假设的一个事实。
适用场景
- 多个修复方案反复在同一关卡失败，且它们隐含同一个假设。
- 需要判断问题根因是否被错误定位。
- 需要避免在错误方向上继续投入修复成本。
限制
资料未提供该原则的具体实现代码、安装命令、平台支持范围、收费方式或效果数据。