上一章说，这六件工具都是画在纸上的因果图。可你随手在白板上画的思维导图也是箭头连箭头，凭什么那不算数，这个就算数？
区别只有一个：思维导图的箭头没人能反驳，逻辑树的每一根箭头，都欢迎别人来拆。这一章讲的就是这套「拆」的规矩——它才是让六棵树成为逻辑、而不是漂亮涂鸦的东西。
两种箭头，别混用
先分清楚两种完全不同的因果关系，它们对应两种读法。
第一种是充分因果——「如果 A，那么 B」。意思是：A 一旦成立，B 就自动会发生，不需要别的帮忙。比如「如果代码没测试就上线，那么线上会出 bug」。A 足够把 B 顶出来。
第二种是必要条件——「要想 A，就必须先有 B」。意思是：没有 B，A 绝无可能；但光有 B，A 也未必成。比如「要想按时上线，就必须先有一套能跑起来的测试环境」。没环境肯定上不了线，可有了环境，代码没写完照样上不了。
一句话记住区别：充分因果是「有它就够了」，必要条件是「没它就不行」。前者读成「如果…那么…」，后者读成「要想…就必须…」。混用这两种箭头，是新手画树最常翻的车。
为什么要分这么清？因为六棵树里，有四棵讲的是「有它就够了」——现状图、未来图、负面分支、转变图，全是「如果…那么…」的充分因果链；另外两棵讲的是「没它就不行」——冲突图和前提条件树，全是「要想…就必须…」的必要条件。你后面每翻到一棵树，先认它说的是哪种箭头，读起来就不会拧。
一棵树是怎么读的
逻辑树永远从下往上读：底下是原因，顺着箭头往上是结果，一层顶一层。以充分因果为例：
如果「需求老变」，并且「没有测试环境」，那么「上线出 bug」。
注意那个「并且」。有时候一个原因顶不动一个结果，得两三个原因一起使劲才行——这在树上画成两根箭头汇进同一个结果，中间用一条横线（叫逻辑「与」，意思是这几个条件缺一不可，得同时成立）拴住。这个细节很关键，一会儿就用得上。
凭什么说你这根箭头错了
现在到了这一章的核心。你画好一棵树，拿给别人看，对方不能只说「我觉得不对」——那没法讨论。约束理论给了一套固定的反驳理由清单，叫合理保留类别（英文 Categories of Legitimate Reservation，缩写 CLR，字面就是「有资格提出的质疑，一共分几类」）。一共八条。你要挑一根箭头的刺，只能从这八条里选，而且得说清是哪一条。这就把「抬杠」变成了「校验」。
八条不用死记，理解它们各自在防什么就行。挨着最常用的几条讲，还是拿那句「如果代码没测试就上线，那么出 bug」当靶子：
- 说清楚点（清晰性）：「出 bug」是什么意思？崩溃？算错数？还是界面难看？含义不清，后面全白搭。
- 这事真存在吗（实体存在）：「代码没测试就上线」在你们组真发生过吗，还是你脑补的？每个方框都得是一句独立成立、确实为真的陈述。
- 因果真成立吗（因果存在）：把箭头读出声——「如果没测试就上线，那么出 bug」——听着顺，成立。要是读出来觉得别扭，箭头就有问题。
- 原因够不够（原因不足）：光「没测试」就一定出 bug 吗？也许还得「代码本身有缺陷」这个条件一起，才顶得出「出 bug」。缺了的那半个原因，就得用上面说的「并且」补进来。
- 是不是还有别的原因（额外原因）：就算测试做足了，需求理解错了照样出 bug。这说明「没测试」不是唯一的因——你哪天真把测试补齐了，bug 也不会归零。这一条专治「以为找到一个原因就万事大吉」。
- 是不是反了（因果倒置）：到底是「没测试导致出 bug」，还是「老出 bug 导致大家索性不测了」？箭头方向搞反，药就开反。
剩下两条——「预期效应」（如果这个原因是真的，那它应该还留下别的看得见的痕迹，找找看有没有，用来反过来确认原因）和「同义反复」（别拿结果来当原因的证据，那是绕圈自证）——理解到位即可。
合理保留类别的真正妙处在这儿：它让「你的判断」变成「一根根可以被单独攻击的箭头」。哪根箭头扛不住某一条质疑，就地补强或拆掉，其余的照样立着。整个系统的看法，从此不再是一句护不住的「我觉得」，而是一堆经得起挑刺的因果关系。
这一章值多少
你可能觉得这一章太较真——不就画个因果图吗，至于抠八条规矩？至于。后面六棵树全长在这套语法上：现状图能不能追到真病根，靠的是「原因不足」和「额外原因」逼你别漏掉半个因；冲突图能不能破，靠的是分清必要条件；未来图靠不靠谱，靠「因果存在」一根根验。语法立不住，画多少棵树都是自我安慰。
规矩讲完了。下一章开始动真格——先种第一棵树，现状图，看它怎么把那个救火小组的一地鸡毛，一路追到一个病根上。