还记得在第一次使用双链笔记的时候，我兴冲冲地进入到 Daily Notes 界面，立马按下了那个「神圣」的 [ 按键，创建了我的第一个双链。可就在准备继续为这个双链补充内容时，我却突然卡住，不知道下一步应该怎么做了——面对这个与之相关的新内容，我是应该把它放进刚才建立的独立的双链页面内呢？还是应该在这个双链的下面建立一个子内容块，然后直接输入呢？
当时的我并没有纠结太久，还是按照习惯把它放到了独立的双链页面中。后面的一段时间内，虽然每次还是会有一点困惑，我还是选择忽略，一直按照习惯使用：遇到相关的内容，搜索双链页面标题，进入页面，找到合适位置，输入内容。久而久之，这个困惑就逐渐被我遗忘了。
直到有一次，我遇到的一个知识与之前在 Notion 里记录的内容相关。于是，我打开了尘封已久的 Notion，搜索页面标题，进入页面，找到合适位置，输入内容，一气呵成。可就在输完的一瞬间，我突然意识到一件事——这不就是我平时在 roam 里的操作吗？好像这些双链笔记软件，只是多了个反向链接而已，好像也没有太大的差别，也没有网上说的那么神奇？
但转念一想，其实是我把 Notion 里的习惯沿用进了双链笔记里，那当然就越用越像 Notion 了。如果我改变记笔记的方式，会不会有不同的效果？于是，我又来到了 Daily Notes 界面，创建了一个双链。但这一次，我没有进入双链页面，而是按下了另一个「神圣」的按键——Tab 键，在双链的下面建立了一个子内容块。
这时我才反应过来，虽然我们习惯都叫它们为双链笔记软件，但实际上，它们本身并没有强调自己是「双链」软件，更多的是说自己是个人知识管理（Personal Knowledge Management）软件、生产力软件或网状思考软件。双链确实是它们和其他软件最大的区别，但它们和其他「单链」笔记软件还有一个比较大、但常常被忽略的区别——它们也是大纲笔记（或「块编辑器」）。
而我一直以来的那个困惑，其实就源于我一直没有弄清楚大纲笔记的优势和用法究竟是什么。我一直都是沿用着文档笔记的逻辑，没用好大纲的功能（就像一直背着一只手打架一样）。
所以，我开始到网上搜集大纲笔记的演变历程，以便我能够完全理解大纲笔记的底层逻辑，并搞清楚它和文档类的笔记有什么根本上的不同。
要弄懂大纲笔记（块编辑器）的底层逻辑，时间线要倒回到它们还没有如此火爆的几年前，这时候一些未来的大纲笔记潜在用户还在尝试使用 Twitter 来构建卡片笔记盒（Zettelkasting Twitter）。人们为了把 Twitter 用得更加有价值，想出了各种有趣的方法和理论，例如创建特定 list、超长线程（thread）、快捷搜索和回顾自己的推特……
虽然乍一看有点离谱，但仔细了解后发现其实也挺合理。他们主要看重的就是 Twitter 的线程功能，即把 Twitter 上的线程作为一种思考工具，来构建一个可以不断延展的思维系统。在这个系统里，每条推文都是一个离散的、相对完整的成果——可以把想法一个个地记录在这里，然后需要的时候再整合起来做更系统的表达。而且，当各个线程紧密相连时，作者自己或者浏览者都可以根据自己的兴趣沿着线程来探索这些想法，并在合适的地方进行扩展。
具体而言，就是人们可以在原有的相关线程下继续发推，来延续自己或他人的思维链路，让原本比较零散的、时效性不高的想法能够汇集起来，也便于人们日后沿着这个主题线程来回顾。同时，他们还可以在一个线程下的任意一个推文处建立一个新的分支线程，来写一些大主题下的延伸的思路。
如果用示意图来表示这个结构，就可以大概看出它和大纲笔记的相似之处了。它们都可以在任一节点上进行分支，并可以无限的延伸和扩展。
虽然理论上这样的结构是可以支撑人们来构建类似于笔记盒的系统的（而且还可以协作），但比较 Twitter 本身的定位是聚焦于「现在」而不是过去，使用上并没有为这种功能考虑。因此，Twitter 上复杂线程的阅读体验非常差，稍微复杂一点就容易迷路。同时，还有检索、视图、风气等问题干扰着人们的输入和输出。这个尝试并没有掀起波涛，毕竟这是想在错误的软件上做对的事，费力也不讨好。
但值得庆幸的是，最近几年大纲笔记渐渐走入了人们的视野，原来这部分的人大多都转而成为了大纲笔记的用户或开发者。这类软件的结构和 Twitter 类似，都是由「块（block）」和「线程（thread）」组成的。所有的内容都是在一个内容块中输入，再通过线程链接到其他块中。可以说，大纲笔记的产品形态，一定程度上是受到了 Twitter 的线程功能影响的。而这两点，就衍生出了文档笔记和大纲笔记间最本质的不同——浓缩性和延伸性。
基于文档的笔记软件更适合记录 [是什么] 的内容。因为它的系统建立在 [标题] —— [文档] 的基础上，这样的结构很类似于文章或 wiki，把详尽的内容压缩整合为一个概念或短语。而在双链笔记中，虽然它多了反向链接，但其代表性的双中括号快捷符号「[[]]」的本意也是浓缩性的，即代表了框内的概念是一些更丰富内容的浓缩，通过链接能深入了解其含义。所以，如果只是多了反向链接，它们确实没有那么大的区别。因为其符号含义和形式决定了基于文档的笔记软件都适合做浓缩、整合知识的工具。
而真正使「双链」区别于「单链」的，是基于缩进的大纲笔记功能。它们更适合记录独立的内容以及它们间的关联。
网的总绳，称之为「大纲」。特指总领全篇的重点所在。因此，大纲在语义和属性上的单位是「点」，更强调拆分；而文档的单位则是「篇」或「段」，更强调凝聚。而且，大纲更关注网中各个要点之间的逻辑和关联——绳结，而文档更关注链接整个网的主题和中心——绳头。
如果要给大纲笔记找一个象征性的标志，我认为应该是 tab 键的符号「->」。这个符号的含义是前进或延展，代表了后面的内容是之前内容的延伸。因此，它适合记录一些超乎当前内容外的标注性、分析性、扩展性的内容。例如：一个附加的标签，一句联想到的名言，一个案例的延伸分析，一篇文章中领悟的想法，一个被其激发的灵感等。
这个形式上的区别，潜意识地影响着我们使用这两类软件时的思维：浓缩是制造外化的工具，延伸是模拟内化的思维。具体而言，在使用基于文档的笔记软件时，我们主要思考的是记录和检索，即「我现在怎么记得更完善？之后我想找它的时候，我会在哪里找到它？」它在思维上比较表层，就像是一个外化的知识平台。
而人的思维是联想性的，一个想法会由另一个引出。在使用基于大纲的笔记软件时，我们主要思考的是逻辑和链接，即「这些知识之间的逻辑关系是什么？我根据这些想到了什么？」它更底层，就像是在记录我们大脑学习和联想的思维链路。
思维不同，记录的目的也就不同，最终产出的内容也就不同。那么，大纲笔记的这种形式应该如何使用，能带来什么优势呢？
正如上面提到，大纲笔记的思维模式和文档笔记有比较大的不同。我们可以从一个新知识的视角，来分析在吸收、拆分、编码和运用的四个阶段中，大纲笔记的具体用法和优势。
大纲笔记的优势在于，通过近乎无限的缩进，可以将这个知识的整个思维链路（知识背景）呈现出来，而不仅仅是单个知识。这样的方式不同于类似于文件夹的上下级「嵌套和包围」，而像是一张网，把这个知识给串联了起来。
向上能够看到它所有的父级知识，向下能看到所有的子级延伸，横向追溯还能查看类似的、并列的知识。这让我在记录的时候时刻都有一种「知识层级」的思维，思考各个知识间的关系：
就像在我整理论文理论的过程中，部分概念在不同的领域和研究之下会有不同的定义和侧重。因此，有了语境的支持，我可以轻松的理解这个概念在当前是什么意思，而不会有理解的误差。此外，还可以通过这个概念为跳板，来比较这个概念在不同领域下的不同和共同点，加深自己对它的理解。
通过块引用，我们不仅可以把这个知识引用到对应的位置，还可以快速的跳转回原来的地方，来查看他的来源。在写论文的过程中非常有帮助，可以通过单个论点检索出它原本所属的论文，然后通过原本的论文来进行发散思考和补充其他相关论点。
大纲在形式上更强调简洁性。在面对大纲笔记中的一个内容块时，我内心默认是写下一个「点」；而面对文档笔记时，我默认是写下一个「段」。这减小了我的心理压力，也让我每次添加的内容都更精简，更原子化。这样每次记录，之后便可以轻松地将它们逐渐组合成更大的知识链或网。大多数文档笔记迫使我们从一开始就思考它结构和主题，这给写作增加了很多阻力。我目前用双链软件写的东西比 Notion 多太多了。（目前我整体的 graph 里面，有 50 万字左右的内容，而内容块的数量就有 1.2 万左右，平均每个块的字数只有 40 多。）
我尽可能地将每个内容块里的知识和表述做到相对精炼和独立，以便于日后与其他的块做链接。之前没有做好笔记的原子化时，虽然能看到之前自己的提及和链接，但不清楚一段话里具体是哪个知识点使当时的我产生了如此的联想。
此外，它既能提供轻松检索的方式，也不会内容块本身的完整性和纯净性。比如，我现在有时候会在子集或者父级上打上标签或者引用另一个块，而不是在这个内容块的开头或结尾。这样当我在整理的时候，既可以快速地检索，把知识进行整合和关联，也可以保证这个内容块不会被其他标签或引用所「污染」。
自文档笔记发展而来，我们形成了一个思维定势——我们需要给每一个知识或者是文章写上一个标题。其实在我们的生活中，并不是每一个知识都能够用一个标题来概括。比如一句名言，我们应该用什么标题来给他概括呢？这个知识过于独立，我们没有特别好的概括的方式。一般情况下，我们会用作者、书籍的名字加「摘录」来作为这个文档的标题。但其实这个标题并不能概括这个知识，它只是起到一个辅助检索的作用。
但现在的笔记软件中，我们有了像标签、Daily Note、块引用、字块双向链接等功能来帮助我们从多个角度，多个路径找到我们想要找的知识，为什么我们还要局限在「给它取一个标题」这种固化的思维上呢？
如果从这个思维上解放出来，我们可以发现，无论是标签还是标题，他们本质上都是一个思维上的「钩子（hook）」。其目的就是在我们想要去找这个知识的时候，可以快速的找到这个钩子，然后通过钩子把它所勾连的所有的知识给检索出来。在文档笔记中，标题是一个最大的钩子（或者也可以叫线头）。但是在大纲笔记中，所有的内容其实都是一个钩子。他的上一级是钩子，它的下一级也是钩子，只要能够找到跟他相关联的知识的内容，都是钩子。
所以，我们只需要保证每个知识相对精简和独立，并把它与其他块做链接，就能获得尽可能多的钩子，增加想起或检索到它的可能性。但其实，「相对精炼和独立」和「与其他块做链接」不就是卡片笔记法里对每个卡片的要求吗？那么按照这个思路，其实每个内容块本身就是一个卡片！只不过它的内容即是它的标题（或主题）。
因为，之前的标题本身其实也就是一个以字句的形式出现的块，只是我们人为地给它赋予了钩子的功能。现在，由于每个内容块都可以溯源到其上级内容块，那么，它的父级、爷爷级、祖父级的内容块都可以是它的标题。所以在这样的结构中，我们不用再去纠结起什么标题，打什么标签，我们只用记下其所属的语境，就可以找到我们想要的内容。
这就形成了一个更加灵活和轻松的卡片笔记系统。在这个系统里，我们的内容不再受限于之前的「卡片」或「页面」等形式，可以用粒度更细的「一句话」或「一个观点」来直接记录。部分情况下，我们甚至不用费心给它起标题。我们的注意力可以完全集中到内容本身以及知识间的关系上。我认为，这可能是卡片笔记法的更理想的使用形态。
当然，也不是说完全抛弃标题和标签，只是起到的作用不同。用标题和标签来检索类似于提一个网的「绳头」，而用上下级来检索类似于抓一个网中的一个「绳结」。标题检索是你给了一个思维的起点，就是你可以通过这个起点，比较详尽的去从开始检索到结尾。而块检索是给你一个知识网络的中间点。它不是这个思维链路的开头，但你可以通过他的上下级关系去检索和溯源，然后再通过它来进行发散。
我们可以根据具体知识的特点来选择编码的策略，而不是一味纠结于「起什么标题」、「打什么标签」等问题上。
大纲笔记的 apply children 功能可以使一个内容块的子内容块被快速地引用出来。它能保证你下次要使用这个知识时，能够快速地用 apply children 将它引用，无需点进它们原来所属的那一页，再复制粘贴。这对于一些需要之间引用的框架性、解释性内容十分有用。例如，某个概念的解释、某个因素的几个特点等。
此外，此前添加在一些内容块下的评论和思考也可以直接引用出来。例如，我会在阅读论文时，常常会在引用的句子下面添加文献综述和评论分析。而在日后写论文的时候，一旦这句话被引用，我提前写的综述和评论也就出现了。这样，我就只用把自己之前写的内容修改融合一下，就能快速完成这部分的综述，而不用重新开始组织语言。
在了解了大纲笔记的来源和特点后，回到最初困扰我的问题：面对新知识，什么时候应该放进独立的双链页面内？什么时候应该建立一个子内容块并直接输入？
我认为应该从知识层级的角度出发，和这个知识本身是同一层级的知识，以及对这个知识的解释性描述之类的应该放进双链页面内；而由这个知识衍生出来的，或者是这个知识的上层的理论基础知识，就应该放到对应知识块的父级或子级大纲中。这样，我们就能保证知识的原子化，也能将它和语境联系起来，方便我们理解、查看和运用。
最后，如果要用一个简单的比喻来总结一下它们之间的区别的话，我觉得可以用卢曼的卡片笔记法来比喻：文档是构建一个卡盒，而大纲是构建一个卡组。
文档思考的是哪些知识是有共性的，可以整合起来形成一个详尽的集合；而大纲则是思考哪些知识是有逻辑关联的，可以产生化学反应，成为一系列相互支撑的观点。
不过遗憾的是，目前的大纲软件还没有一个较好的块链接网状视图，没办法很好地浏览。目前有的，只是一个没有什么用的标题的网状视图，而我认为真正有用的应该是块链接视图。大纲视图一定程度上能展现网状视图大部分的效果，能表现一定程度的关联关系，是我们目前能用的、较为理想的选择了。
不过要真正成为理想的卡组，那还缺少一个东西：链接的逻辑。有了逻辑关系，我们才能思考不同卡片间能产生什么化学反应。软件现有的链接仅能表示它们之间有链接，而不能清晰地表达它们之间的逻辑关系是什么。
所以，目前又有较多的基于白板的软件和插件出现，我们可以通过连线实现更细致的逻辑关系的说明，也能更加自由地排布各个知识。目前感觉这应该是个可以弥补大纲笔记不足的一个方式，但它的自由度过高，整理起来也会比较麻烦。
如果展望未来，我还是希望能有更理想的形式出现。它应该要比大纲更灵活，比白板更规范。让我们能够以更贴近我们思维结构的形式来记录和使用知识。
> 下载 少数派 2.0 客户端、关注 少数派公众号，解锁全新阅读体验 📰
> 实用、好用的 正版软件，少数派为你呈现 🚀
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。