关于设计方案中的逻辑链问题

在设计方案讨论中，我常常会遇到在“需要有逻辑链”这个问题上就对不齐的情况。这种基 本观点都对不齐，所有讨论都是浪费时间了，所以我想通过这个文档梳理一下这个逻辑， 以免每次讨论都得首先解释这个基本逻辑。

首先解释一下什么是逻辑链。逻辑链这种说法我自己都不知道我来自什么地方，仿佛是我 经过这么多年的数学和工程训练自然就形成的概念。我查了一下Google，也不是只有我这 样说，比如我们能找到这样的描述:

Chains of Logic to justify your plan When we apply for grants,

we are telling the grant sponsor that our research plan will

meeting their needs. We have already worked on creating

explanations for how your research will meet their needs,

But not every reviewer will necessarily agree with your

plan as the best plan. Therefore, you mush make it very

clear why your plan fits the solicitation needs.

我要说的概念和这类描述完全一致，这一定程度上说明，这是一种普适的概念。就如同我 们都见过“红色”，然后说这是“红色”一样。

我深入定义一下什么是逻辑链。

我们进行预判和推理，总是基于“因为-所以”，我把它简称“因果”。“因为我饿了，所以我 现在要吃饭”，这是一对因果，一对因果是一个单向矢量，包括“因”，“果”和“因果的有向 关联”三个要素。如果我们把因果串起来，把一对因果的果，作为另一对因果的因，组合成 一个链条或者一棵树，我们就称这个链条或者这棵树，构成一个逻辑链。例如：

和

因果的三个要素，我们都称为“逻辑事实”，简称“事实”，就是在逻辑链结构中，我们认为 他们是事实。其中，根节点上的事实，我们称为整个逻辑链的“证明目标”，或者简称“目标 ”。我们建立逻辑链的目的，是为了在逻辑上“证明”我们的“目标”是成立的，从而保证我们 最终在事实上可以达成那个目标。

（根这个定义其实挺不好的，因为我们常常把“因”叫做问题的“根”，而不是目标、结果作 为问题的根。但对一棵树呢，汇聚那个点才叫“根”。为了避免误会，我们尽量不用“根”这 个概念，而用“目标”和“原始因”的概念。前者表示逻辑链目标，后者表示逻辑链上的叶子 节点。而目标和原始因上的其他因果节点，我们称为“中间因果”。）

打破一个逻辑链的方法很简单，只要证明逻辑链中的任何一环的“逻辑事实”不成立，或者 直接制造逻辑链的“逻辑事实”自相矛盾即可。我们评估一个方案，本质上是想办法：

1. 打破一个逻辑链，从而导出方案的不可行
2. 无法打破一个逻辑链，从而“承认”方案可行
3. 提出另外建立一个逻辑链，证明比本逻辑链更具优势

在这个基本定义下，我们有一些很有趣的观察：

观察1：“打破逻辑链”所证明的是“方案不可行”，不是证明“目标”不成立。

观察2：逻辑链讨论的底线是“逻辑事实”，如果某个“逻辑事实”在讨论的双方没有共识，整 个逻辑链的讨论就失去价值了。我们可能需要更多的交流或者证据来实现这个共识。否则 ，这整个逻辑链讨论的基础就不存在了，我们必须另外找其他手段进行交流。一个极端的 例子是，你根本不同意我说的“逻辑链”乃至“因果”的存在。用前面的例子来举例，我认知 的逻辑事实是“因为我饿了，所以要吃饭”，而你认知的逻辑事实是“饿了就应该继续饿着， 过几个小时自然就饱了”，在这个问题上我们无法达成共识，那我们就不靠逻辑链来讨论问 题了（比如，我们可能可以靠“拳头”来讨论问题）。

观察3：逻辑链可以基于逻辑事实无限分解，一对因果可以分解为一个子逻辑链，所以，非 要细化逻辑链是没有意义的，我们细化逻辑链的某个因果或者某个“逻辑事实”，主要是为 了在这个逻辑事实上达成共识，如果我们已经有了共识，细化下去只会增加工作量，并没 有价值。

观察4：逻辑链可以被优化。如果逻辑链中除目标以外的某个逻辑事实被删除后，逻辑链仍 然成立，没有断裂，则我们称新的逻辑链为原逻辑链的“更简逻辑链”，如果某个逻辑链没 有更简逻辑链，我们称它为“最简逻辑链”。我们还要注意到，为了证明某个目标，我们可 能不止一个最简逻辑链。例如：

图中的两个不同颜色的阴影部分，独立构成同一个目标的最简逻辑链。

有了这些基础，我们就可以讨论设计方案中经常会犯的错误了。首先，我们需要有一个共 识，我们做一个设计方案，就是为了证明一个，或者一组目标。很多人写设计方案，都不 写Purpose，这个完全没法讨论。无目标的信息堆砌，构不成逻辑链，你是要我一个个为你 确认每个逻辑事实是否正确吗？就算正确，这又解决什么问题呢？

这是我在设计文档中经常碰到的问题，如果你的设计文档是这样的，我们就无法讨论了。

第二个常见问题，设计文档的描述不构成逻辑链，设计文档中有大量的“逻辑事实”，但无 法从中整理出逻辑链模型。即使这些“逻辑事实”都正确，意义是什么呢？

第三个常见问题，设计文档不是在描述最优逻辑链，这个问题稍好一点，但如果太严重， 也是个大问题。你明明3页的表述就可以证明目标的成立了，结果写了100页的逻辑事实。 这些多余的逻辑事实淹没了整个实施团队的精力，同样会导致实施的失败。

在各种评审中，当我直接给人提意见的时候，他们的第一反应是给我提供更多的“逻辑事实 ”，而不是优化他们的“逻辑链”，这就是为什么我需要在这里单独提出这个问题，希望每个 设计者，都聚焦到你们的逻辑链建立上。