当多个共享同一前提的修复都失败时，先质疑前提而非再写一个修复

两个及以上共享同一前提的修复在同一道关卡上失败时，先写下前提、统计各参与方的不平衡分布，再决定是否移除不对称本身。

适用场景

解决思路

1. 写下前提：用一句话写出所有失败修复共同假设的那个前提。
2. 在下一次修复前先做一次普查：按参与方统计不平衡的数量。普查展示的是哪些参与方持有不平衡，而不是不平衡有多大。按 Build the Lever 的要求，把普查写成一个可重复运行的脚本。
3. 读取偏斜：如果每次运行都是同样少数几个参与方持有大部分不平衡，说明有某种东西把该角色分配给了它们。找出是什么在分配这个角色，这个分配就是下一个要追问的“为什么”，参见 Fix Root Causes。
4. 移除不对称，而不是补偿它（参见 Laziness Protocol）：在参与方之间轮换该角色、随机化分配，或把该角色移走，使任何参与方都不会在每次运行中都持有它。返回路径、共享池、批量交接或周期性再平衡都会保留原有分配，并在每次运行时增加工作量。
5. 在前提被写下且普查存在之前，不要开始下一次修复。
6. 如果普查显示各参与方之间是均匀的，那么前提不是原因。到别处寻找原因，并把普查保留为证据。

适用边界 · 注意事项

• 尚未有两个及以上共享同一前提的修复在同一道关卡上失败时。
• 普查显示各参与方之间分布均匀时——此时前提不是原因，应到别处找原因。
• 需要围绕新需求重建设计时——那属于 Redesign from First Principles，而非质疑当前设计所假设的事实。