.. Kenneth Lee 版权所有 2021
:Authors: Kenneth Lee :Version: 1.0
专家意见和编辑意见
本文定义两个我在作为标准编辑评审标准提案时用到的定义。本质上，这也是解释《道德 经》中这段逻辑：
| 知不知上，不知知病，夫为病病，所以不病。
我们写各种技术文档，通常都是为了证明某个结论成立。要证明某个结论成立，就需要理 由。如果我们对这个世界无所不知，那么对某个证明目标给一组充分的，令人信服的理由 是很容易的。但现实并非如此，我们只掌握这个世界的部分现实，更严格来说，我们只信 任部分理由。这个说法包含了两个外延：
在我们技术论文的证明中，我们通常没有真正“严格的证明”，你把实验重复10000000 遍，也不能证明第10000001就一定是一样的结果。所以，证明首先是个信任问题，没 有基于文字的所谓“严格证明”。
技术论文的证明，不是一个人的问题，是这个论文所有我们讨论上下文中关注的读者 的信任的问题。你同意的证据，不表示别人也同意。当然，这也包括别人因为你同意 所以他也同意，这同样是“信任”的一部分。但无论多少人“信任”，这个证明的最终证 明都是它被实际应用的时候。
所以，对一个证据链（逻辑链的另一个说法，只是突出逻辑本身是一些证据而已）中的证 据，我们有三种评价：
我们知道这个证据成立
我们知道这个证据不成立
我们不知道这个证据是否成立
这三种评价都是对证据的有效信息添加。前面那个《道德经》的引文，就是对这个问题的 解释：
我们知道“我们不知道一个证据是否成立”，这也是一个有效的信息（“上”）。我们不知道 某个证据成立还是不成立，这是一件坏事（“病”），如果我们知道我们不知道它是否成立 ，从而不以它为证据（病病，以病为病），我们最终的结论就没有毛病（“不病”）。
如果我们的证明中混进了一个不成立的证据，我们的结论就（可能）不成立了。如果我们
提供额外的信息去证明这个证据的非法，这个“意见”，就称为专家意见。它给我们的证据
链这个\ :doc:逻辑闭包\ 提供了原来逻辑之外的信息。我们叫它“专家意见”，表示它
在逻辑闭包中加入了额外的逻辑信息。
如果我们的证明中混进了一个信任度不足的证据，我们的结论同样（可能）不成立。如果 我们指出这一点，这个“意见”，就称为编辑意见。它不包含逻辑闭包之外的信息，仅仅认 为这个逻辑链不可靠，需要调整证据链结构。如果我们建立的逻辑链不基于这个证据，我 们的结论仍可以成立。
不少作者收到编辑意见的时候，很容易当做专家意见，不断争辩整个证据是否成立，或者 用这样的解释去为自己辩解：“你怎么就知道这个不成立？”，这是不理解编辑意见的本质 。因为编辑意见不是认为自己知道那个证据是否成立，编辑意见是认为那个证据不能当做 证据来用，要求作者避开使用那个证据。
我们举一个例子帮助理解。比如我们做一个操作系统，是否需要支持64K页？有人使用这 样一个证据：“4K页只是历史遗留的问题，64K页在方方面面表现出来性能都比4K页高”， 这个证据是否成立呢？
我认为没有这么简单，我们这样质疑一下，如果4K也只是历史遗留问题，那么我们做一个 新的应用，64K的效果一定比4K更好吗？比如一个文件系统，大量的小碎片数据访问，但 为了访问这么小的数据，我每次都要加载64K为单位的数据到内存中，这个系统的性能还 高吗？
所以，这是一个“不知”的证据，我给出了一个“编辑意见”，认为这个证据不能使用。但你 不能反驳我“难道4K就一定比64K的性能高吗？”，我说这是一个“不知”，我没有说这是一 个知。就好像你说明天一定下雨，我说明天不一定下雨，你不能认为我认为明天一定是晴 天。实际情况是明天是否下雨是一个随机事件，你不能为了证据链组织的方便，认为这个 地方一定要有一个结论。一个好的证据链，是避开了所有的“不知”（随机事件），把每个 证据都建立在更可靠的证据上，比如建立在，“明天太阳还会从东方升起”这个事实上，我 们并不能完全保证明天太阳会不会突然变成从西边升起，但它的可靠性和可信任度还是比 明天太阳从西边升级这个证据的可靠性（可信任性）更高。
具体到前面这个问题，其实我们是可以避开使用“4K也具体是否是历史遗留问题”这个问题 的，我们可以换用这个证据：“在我们当前应用的几个场景中，我们已经测试过64K页的性 能更高”。假设我们做过了这样的策略，我们是可以信任这个结论的。我们没有必要让前 面那个“不知”的结论放进来，变成我们证据链中的一个“名”，因为如果我们承认它是一个 可靠的证据，我们后面证据调整的时候，可能会把它用到更多的地方，让我们的逻辑链建 立在不可靠的基础上，越来越多的逻辑依赖它，一旦它崩塌了，我们的整个方案就也跟着 坍塌了。
我们基于前面的讨论，延伸讨论一下怎么写技术文档的问题。这不但是个如何写技术文档 的问题，也是一个怎么做战略设计的问题。
所有的证据，只要不执行，你都无法证明它一定可行。即使一个程序这么严密的逻辑定义 ，在你没有运行前，你都不敢肯定它这次运行会不会Coredump，所以，逻辑链都是不可靠 的，越是复杂的系统越是如此，越是高层的构架设计也越是如此。而技术文档，常常就是 这样一个这样的高层逻辑链，因为你做成高层设计，或者写成论文，本质就是希望它在各 种场景中可以被复用。我们学习数学，物理，历史，地理这些知识，常常都是如此。所以 看着看了很多信息，但这些信息被我们的脑子接纳，其实我们总是在某个切面上把它们组 成逻辑链，我们才能实际把这个逻辑链应用到其他的场合中。这也是为什么读书越往后就 越不能靠“死记硬背”，因为只要你组织不出有效的逻辑链，你就没有办法把这个知识应用 到下一个场合，你背了一道数学题，你没有办法把相同的技巧应用到下一道数学题，更没 有办法应用到某个工程或者研究领域。
所以，同一个道理，要写好一个技术文档，你的目的必须集中到组织一个逻辑链（证据链 ）上。所以，理论上，你不应该上来就问人要“模板”，然后要求你填“目标”，你就填一个 “目标”的信息在里面；要求你填“读者”，你就填一个“读者”的信息在里面；要求你填“假 设和约束”，你就填一个和“假设，约束”有关的信息在里面。这样的“填空”，和前面说的 在学习的时候死记硬背一些分离的知识点，希望老师打个高分给你没有任何区别。你这些 填空没有包含任何有效的信息在里面，只能说是上班摸鱼的不二法门。
.. vim: set tw=78 fo+=mM: