双链笔记记录规则

1-双链笔记记录规则

本文分四个主要部分，一是目的，即为什么要使用双链，需要解决哪些问题；二是方法或原则，从目的出发，分析笔记记录应遵循的原则，主要是笔记的细部组织和引用的使用；三是工作流，讨论笔记的整体组织。最后，从其他角度进行补充可选规则。

本人使用的双链笔记软件为思源笔记，所列规则均是针对该笔记产生的，个人想法浓厚，观点仅供参考，有些方法可能对于其他笔记软件并不适用。

1.1-前言

1.1.1-为什么要制定双链笔记使用规则

双链笔记很灵活，以至于过于灵活，容易引起笔记系统的混乱。但是，块删除、合并后引用将失效，引用不正确不统一等问题容易发生，发生后进行批量更改又比较困难。为尽量避免这些问题，需要预先制定一些规则。

如果仅将笔记系统作为一个小百度使用的话，可忽略全部规则。

1.1.2-关于本文使用的一些词语解释等

引用：即链接，指的是在某一文本中通过双链笔记的『引用块』功能插入其他块，应与嵌入快、超链接等区别。

概念：指的是笔记的一般内容，可以理解为笔记的主题，其不是指特定的某篇笔记或某个块，而是指该笔记所记录的主题概念，多个笔记或块可以记录同一个概念，但多个概念不能或不应在同一笔记或块中记录。如『苹果』是一个概念，但记录苹果相关内容的名字叫做『苹果』的笔记不是一个概念。

1.2-关于使用双链的目的

明确使用双链的目的，对于怎样进行双链进行记录具有重要的指导意义，所有记录规则都是为了便于实现这些目的。

1.2.1-使用引用便于跳转和复用

首先双链应具有传统引用的功能，即通过本笔记跳转到其引用的笔记，通过使用引用，不必在各笔记中反复书写重复的知识，而只需加入一个指向详细信息的引用即可。

如果仅为该目的而使用引用，不必使用双链笔记，传统笔记大多均满足需求。

1.2.2-使用双链便于从不同维度汇总知识

使用双链，更重要的是目的是为了归集、汇总。通过反向引用，可以通过不同的维度汇总知识，查看引用其的文档或块。

如各种水果的颜色均在各水果介绍的文档中，并引用颜色的文档，这样在颜色的文档中就可以通过反向引用汇总出该颜色的水果有什么。

1.3-使用笔记记录的一般规定

1.3.1-（强制）引用应指向最详细的文档或块

​#key/目的#​引用应指向最详细的文档或块，从 1.2.2-使用双链便于从不同维度汇总知识¹角度来说：可以保证汇总的完全性。若对同一概念的引用，在不同的笔记中引用至不同的块，则汇总时需要分别对这些不同的块进行汇总。

​#key/目的#​引用应指向最详细的文档或块，从 1.2.1-使用引用便于跳转和复用²角度来说：可以在引用文本中最大程度的通过一次点击就查看到引用概念的全部方面，而不必层层跳转。

引用应指向最详细的文档或块，并避免链式引用，这一点看起来理所当然，但是在笔记形成过程中，容易陷入按时间引用的误区，即后形成文档引用之前形成文档，即使之前形成的文档仅仅是简要概述。

当暂时没有最详细的文档或块时，而又感觉有必要深入研究时，应为其预留位置，并暂时描述简要内容。

应尽量保持最详细块的唯一性，避免同一概念分散记录在笔记不同位置（必要的引用除外），这需要对笔记进行滚动更新。

正确的引用应该如下所示：

总论文档：

• 一、方面1文档的引用​

  • 方面 1 的简要阐述

• 二、方面 2

  • 方面 2 的简要阐述

方面 1 文档：

• 一、方面 1 的定义
• 二、方面 1 的分类

另一个文档：

这里引用了 方面1文档的引用​​，而不引用“总论文档中的方面 1”

1.3.2-（强制）引用应指向关系最为密切的块

这条指的是避免随意扩大范围，造成查看引用关系时的模糊性。如需要引用『苹果的颜色』时，应避免随意引用到其父级『苹果』上。

​#key/目的#​引用应指向关系最为密切的块的主要目的是：1.2.2-使用双链便于从不同维度汇总知识¹

引用应指向关系最为密切的块与 1.3.1-（强制）引用应指向最详细的文档或块³发生冲突时，应以指向关系最为密切的块为优先。这样可以在汇总知识时减少筛选成本。如 10 个块均引用到『苹果』上，相比于 5 个块引用到『苹果的颜色』上，5 个块引用到『苹果的形状』上，后者相当于对反向引用进行了一次预先分类，在汇总起来更为方便。而针对引用应指向最详细的文档或块的第二个目的⁴，可以通过该跳转和上下文弥补。

而至于引用所指向的块应密切到何种程度，一般意义上讲，细化至最小的标题即可，因为正文中的块可能会经常发生合并拆分，有丢失引用的风险。如果觉得最小标题仍不够小，则再将标题下正文拆分为几个部分建立标题，直至不可再分时，才使用段落块。针对此点，参见 1.3.10-（推荐）块应当具有完整的意思表示⁵。

1.3.3-（推荐）带有引用的块应有『命名』或本身就是『命名』

1.3.3.1-带有引用的块有『命名』，目的是 1.2.2-使用双链便于从不同维度汇总知识¹

为了在反向汇总时，便于分辨与查看哪些块引用了该块。所以，该原则仅针对的是为使用双链便于从不同维度汇总知识目的而进行的引用。至于为 1.2.1-使用引用便于跳转和复用²而进行的引用，在方便的情况下也应『命名』，以备潜在的汇总需要。

1.3.3.2-带有引用的块有『命名』的具体规则

1.3.3.2.1-在标题中引用或使用『：』

有些带有引用的块本身就是『命名』，这里的『命名』，是指标题等概括性质的块。对于大量文字来说，带有引用的块应尽量在其标题上，这样在查看反向引用时，就不必细读这些内容来确定该块为什么引用。

对于细小的知识，也不必非要建立一个标题，如一句话就能表述清楚的知识点，可以采用『事物 A 的概念：XXXX』形式书写笔记，这样，无论引用在『：』的前面还是后面，在查看反向引用时都可以一眼看出引用块的主要内容是什么。『：』前面的部分，就是所谓的『命名』。

1.3.3.2.2-『命名』应便于排序和汇总（使用标签、统一命名）

在可能的情况下，『命名』应当较为统一，从 1.2.2-使用双链便于从不同维度汇总知识¹的角度出发，如何将反链进行分类汇总是值得考虑的问题，如果命名统一，那么无论是排序还是通过 SQL 等进行分类都会变得容易。

有三种方法使『命名』统一，即自建规则、引用、标签。

自建规则如在开头使用『属性-』的形式表示一个规范的命名，这种方法简单，可以立即执行，但是缺少硬性规定，容易产生混乱。

使用引用，即将不统一的『命名』指向一个统一的『命名』引用，如所有与长度有关的块在开头的几个字引用『长度』文档。这种方法存在硬性规定，可以保持一致性。
另外的好处是，便于对统一的『命名』进行分类，如 A 领域的『概念』和 B 领域的『概念』可以分别建两个文档分离开。
但是这种方法的缺点是，作为『命名』的引用与一般意义上的引用耦合在一起了，将它们分开需要额外的判断，如引用内容是否在某个特定的文件夹中。而且使用起来不直观，在使用 SQL 时，一般需要不断通过 Id 来进行查询，维护比较困难。

使用标签也可以保持一致性，其特点与上文中的引用正好相反，标签不能直接使用树状结构的分类，但也不会与引用耦合，SQL 查询时可直接通过标签名进行查询。

经取舍，决定使用标签。因为使用『命名』通过 SQL 等进行分类方面的要求大于其本身的分类要求，想要只汇总某个文件夹中带有某个『命名』的笔记，直接对笔记进行文件夹限定即可，不必对『命名』进行限定。

需要注意的是，上文讨论的是『命名』作为类似数据库中 Key 字段使用时的场景，当需要对『命名』进行反链汇总时，使用引用而不使用标签。其两者的区别在于，前者『命名』不能脱离上级而存在，如 #概念#微积分是高等数学中研究函数的微分（Differentiation）、积分（Integration）以及有关概念和应用的数学分支​。在这里也可以不写『微积分』一词（在微积分标题下这是常见的情况），单纯从这一句是难以判断其是什么的概念的。但如【计算题】、【案例分析】等，是可以独立存在的，毕竟试题汇总等都是这种情况，这时候就应使用引用了。关于这一点将在 1.3.9-（强制）标签使用规则⁷中详细讨论。

另外还需要注意的是，Key 字段更多的是为后期的 SQL 查询等潜在功能服务的，如汇总本文件夹中所有带『概念』字段的块、将反向链接按照 Key 字段进行分类等。鉴于标签的全局作用域特性¹⁷：
首先，在某一父级下需要大量使用 Key 字段，应做好约定，重要的可以通过标签的树状结构进行区分；
其次，对于作用域较小的 Key 字段，如一个小型多级列表中，需要使用较多不常用的『命名』（即 Key 字段），尽量不使用标签，直接采用如 【命名】​、命名：​等相同形式即可。
#ChangeLog/2023/02/26#​

1.3.4-（可选）标题或块应便于查找

即 1.3.3-（推荐）带有引用的块应有『命名』或本身就是『命名』⁶中的『命名』，应尽量表述完整。如在『手机』文档下的『使用』标题，就不利于标题查找，应采用『手机使用』作为标题。

这是单纯从引用方便的目的出发的，而不论引用的目的是什么。如果可以确定该块不会用于引用，则可以不遵循该原则。

1.3.5-（可选）将要点放在标题中

将要点放在标题中意思是直接将结论等放在标题中，而不仅仅是『问题』。如：『监护人责任的归责原则是无过错原则』，而不用『监护人责任的归责原则』。

其原因是，这样可以仅通过标题就直接得到结论，而不必细看标题下的正文内容，节省时间，有利于整理，也与 1.3.3-（推荐）带有引用的块应有『命名』或本身就是『命名』⁶具有相同的要求。

值得注意的是，将要点放在标题中，一般只要求在最低级的标题中这样做，因为高一级的标题往往要点可分，不易直接将要点放置其中。如『XXX 的分类』，往往有下一级标题『分类 1』、『分类 2』等，将其写为『XXX 的分类有分类 1、分类 2』没有必要。

但是，是否将要点放在标题中，对笔记结构的形成和引用的方便与否上影响较小，却会一定程度上增加笔记记录负担，故这只是一个推荐的记录方法，并不强求。

1.3.6-（推荐）不采用枚举引用

链式引用，指 A 引用 B，B 又引用 C 的情形；枚举引用，指 A 分别引用 B 与 C 的情形。

在有时候，可以使用链式引用，也可以使用枚举引用，此时应优先选用链式引用。因为在此情形下，枚举引用容易使得从被引用块汇总知识变得困难，因为与其关系最密切的块和间接联系的块均包含在内了。如下例所示：

采用链式引用：

A 文档：债务加入对诉讼时效的影响：债务加入生效后，原债务人与债务承担人成为所加入全部或部分债务的连带债务人，对于[[其中一人发生诉讼时效中断效力的事由]]对另一人也发生效力。

上述文本引用到下面的文本：对于[[连带债务人]]中的一人发生诉讼时效中断的事由，其效力为……

而采用枚举引用：

A 文档：债务加入对诉讼时效的影响：债务加入生效后，原债务人与债务承担人成为所加入全部或部分债务的[[连带债务人]]，对于[[其中一人发生诉讼时效中断效力的事由]]对另一人也发生效力。

显然，采用枚举引用后，在对『连带债务人』进行反链汇总时，『债务加入对诉讼时效的影响』（A 文档）与『对于连带债务人中的一人发生诉讼时效中断的事由……』（两个例子共同引用的文本）相比较，后者与『连带债务人』（与 A 文档间接联系的块）关系更为密切，且后者本身已经包含了前者的内容，会产生重复。

1.3.7-（可选）例子采用引述块

例子采用引述块，以示区分。

1.3.8-（可选）一级标题重复文档标题

由于文档不可使用引用、标签，故应从二级标题开始正文。

1.3.9-（强制）标签使用规则

讨论标签使用方法的意义在于：标签和引用之间的相互转换十分困难，当发现某个标签需要转化为引用，或者对于同一内容既使用了标签，又使用了引用，只能一一进行处理。所以在二者的选择上应当慎重。

1.3.9.1-传统标签有以下问题

1.3.9.1.1-难以维护

首先，维护一套标签系统是费力的，需要使用人具有强烈的使用标签进行管理的意识和动力。
就我个人而言，我做引用一般是在想不起来某个概念是什么时，在引用的同时看一下引用的内容，即 1.2.1-使用引用便于跳转和复用²，或者遇到分类困难等情况，1.2.2-使用双链便于从不同维度汇总知识¹。但使用标签，这个过程并不自然，当想不起来某个概念是什么时，需要查看已有标签都有什么，做引用，再打上标签，或者只打标签，然后查找一下这个概念看一下。
而对于标签来说，我暂时不打标签完全不影响笔记的记录，在很多时候也就没有打标签的动力。

另外，很难把标签打全，在这方面即使使用引用也是很难全部引用到的，而这时候搜索的最快方法可能是尽量缩小搜索范围，然后根据关键字搜索或使用正则搜索。

最后，组合使用标签进行搜索仅在 3 个及以上不同分类的情况下有利，对于 2 个分类的情况，完全可以使用树形 + 引用找到，即使用 1.4.2-树形结构与引用（网状结构）的结合⁸中的方法。

1.3.9.1.2-灵活性差

灵活性是指可以轻易表示多对多关系，这是最难表示的一种关系。

当只有树状结构的时候，标签系统很灵活很有用，但是现在我们加入了引用系统，情况就发生了变化。因为没有引用时，标签其实就是将笔记『引用』到了这个标签上。但是这个『引用』缺乏链式引用，缺乏详细信息等要素，灵活性就差了很多。

换言之，树状结构可以表示一对多关系，标签系统可以表示多对多关系、一对多对多关系（对标签进行分类），而引用可以表示多对多对多关系。

1.3.9.1.3-与树状系统结合性差

并且，标签系统的分类是与树状系统分离的，在存在树状系统的笔记中，不可能再另外建一套与之结构一致的标签系统，所以标签通常采用另外一套系统，但是这套系统难以与树状系统进行结合。引用则不存在此问题，所引用的笔记本身就是树状系统的一部分（当然，于树状系统结合的过于紧密也并非全是好处，在 1.3.9.4-在需要与父子文件夹结合时使用标签#ChangeLog/2023/02/28#¹³中会说这个问题）。

例如，在学习科目一时，将所有计算题打上了『计算题』标签，但是后来学习科目二时发现，都使用同一标签不利于查找，此时批量的处理方法一般是将现存的『计算题』标签全部改为『计算题/科目一』标签，然后之后的计算题打『计算题/科目二』标签。如此这个分类系统就无法改变，即使有『计算题/科目二十』，也只能在标签系统中寻找，而不能直接放在科目二十文件夹下。

1.3.9.1.4-容易混乱

容易混乱是指易发生大批量的分类重复，不同分类应当合并、拆分、变更等情况，或者出现这种情况后不容易解决。

树状结构可以随时调整文档位置，是最不易混乱的（当然也是最不灵活的）。

引用系统（网状结构）是最灵活的，当然也是最容易混乱的，所以我们才要制定很多规则。

标签系统一般可以批量更改，在这方面出现混乱后可以解决，但是标签不要求『引用』到已存在的标签上，即不需要先建立标签再打标签，所以一般不会检查是否有同义词标签存在，容易产生混乱。从这个方面讲，容易混乱是标签最小的问题。

为避免标签系统的混乱，标签应仅用于通用的表示类型，如重点、待办等，且应当小型化，即不要使用过多不同的标签。

1.3.9.2-标签系统的优势

1.3.9.2.1-独立于笔记系统

这一点在 1.3.9.1.3-与树状系统结合性差¹⁴中已说明，既是其优点，又是其缺点。另外，其与引用系统也是完全隔离的。

1.3.9.2.2-标志明显，易于搜索

带有明显的搜索标志 #​，而一般引用没有明显的搜索标志，[[​的标识符在一些软件中进行搜索将不会查找到内容。但是这对传统搜索帮助不大，见标签的缺点——难以维护¹⁵。

1.3.9.2.3-不使用的标签不会存在

这个特点显而易见，而且这是引用所没有的，不管笔记是否被引用，其都会存在。

1.3.9.2.4-在查询中直观，见 1.3.3.2.2-『命名』应便于排序和汇总（使用标签、统一命名）¹⁶

1.3.9.3-使用引用代替大部分传统意义上标签

首先，传统意义上的标签是为分类而存在的，鉴于标签完全独立于树状系统¹⁸，就不要将其与树状系统再耦合起来，即不要与文件夹使用同一套分类系统或类似的一套分类系统。这并不意味着完全舍弃标签系统，标签可以作为另外一套分类系统存在，如将标签作为形式上的分类使用，如 #论文#​​、#题库#​​等，或者对属性名（Key 字段）进行分类等。总之，标签应该与文件夹彻底解耦，在内容上完全独立，这是针对标签使用的总原则。#ChangeLog/2023/02/28#​​

针对传统意义标签的问题，使用引用代替大部分标签，除非后面列举的情况，全部使用引用代替标签。

使用引用代替标签，作为标签使用的引用，用 【】​​​​包裹，如【案例】，使用该符号的原因为：
1.实心方头括号很少使用，即使需要使用，也可以用 []​​​​或 {}​​​​或 〖 〗​​​​等代替。
2.采用符号包裹便于搜索和与普通引用之间进行区分。

1.3.9.4-在需要与父子文件夹结合时使用标签#ChangeLog/2023/02/28#​

首先我们比较一下在文件夹系统下，引用和标签与文件夹系统的结合方便程度。

• 场景一，汇总某一文件夹（包括文档作为文件夹）中内容

  • 引用：可预先区分文件夹，直接查看其反向引用即可
  • 标签：内置功能可区分文档，可指定文件夹

• 场景二，汇总某一父文件夹中内容

  • 引用：需要对子文件夹中一一汇总
  • 标签：同场景一

• 场景三，汇总某一子文件夹内容

  • 引用：需要额外限定 path，内置功能无法实现
  • 标签：同场景一

可以看出，标签与各级文件夹可以进行结合，虽然与具体文件夹（具体文档）结合松散，但却对各级文件夹均有结合性；引用与单一文档（文件夹）密切结合，附着于文件夹系统，但对父、子级文件夹的结合性较差。有鉴于此，在可能需要与父子文件夹结合使用时，可以使用标签，如需要在『河南/信阳』两级标签中分别进行汇总，需要在『法律/刑法』两级文件夹中分别进行汇总等。

1.3.9.4.1-不要用标签系统代替文件夹系统

还有一个方案，因为标签 1.3.9.1.3-与树状系统结合性差¹⁴，直接用标签系统替代文件夹系统，看是否可行，下面进行文件夹系统与标签的比较。

• 场景一，引用时搜索块

  • 文件夹系统：可区分文件夹，区分方便
  • 标签：输入 [[​​​后搜索不能区分标签，可用全局搜索实现，即输入 #标签# 块内容​​​找到块，再复制为引用，区分有困难

• 场景二，定位文档

  • 使用文件夹系统：多上级不在其中一个文件夹中的话，可使用引用跳转
  • 标签：多上级一定在任何一个标签下，是通过搜索进行筛选的实现，文档和块会混在一起，是优势也是劣势

• 场景三，多级文件夹组织

  • 文件夹系统：与硬盘文件系统一致，批量导入时可按直接按树形文件夹结构导入，但有层级限制
  • 标签：与硬盘文件系统不一致，批量导入文件需要一一添加标签，但无层级限制

虽然看上去标签系统替代文件夹系统具有一定的可行性，但是有一个致命的问题，就是采用这种方式失去了与文件夹系统的结合性。因为文件夹系统不存在了，文件夹系统是基于文档的，对于查找带有 #文件夹1/子文件夹#​的文档下，带有 #标签#​的块，是没有简便方法的，除非每个块都加上 #文件夹1/子文件夹#​标签，或者定制功能。

最终，我的结论是，使用标签代替文件夹，不具有可行性。

1.3.9.5-需要检查使用情况时使用标签

需要经常检查使用该标签的内容是否还存在的，或者说在流程中使用标签，如『疑问』、『未开始』、『处理中』、『已搁置』等。若使用引用，该文档将一直存在，使用标签，则可以随时检查进度，如优先处理『处理中』文档等。

1.3.9.6-将标签作为 Key 字段使用，见 1.3.3.2.2-『命名』应便于排序和汇总（使用标签、统一命名）¹⁶

1.3.9.7-作用域为全局时使用标签#ChangeLog/2023/02/26#​

鉴于标签 1.3.9.2.1-独立于笔记系统¹⁸，当使用的标签具有很强的通用性时可以使用标签，即标签名在几乎任何一个笔记文档中均适用，比如，#修改时间#​​、#来源#​​等。否则，就容易发生编程中滥用全局变量一般的问题，加之标签具有 1.3.9.2.3-不使用的标签不会存在¹⁹的特性，很容易发生诸如 #计算#​​、#计算题#​​、#算例#​​标签同时存在的情形，而且时间一长无法判断它们是否表示的是同一个意思（引用一般不会出现此问题，因为引用是『局部变量』，在『作用域』之外的引用可以通过其不在同一『祖先』下发现）。

1.3.9.8-利用标签表示日期#ChangeLog/2023/02/26#​

思源笔记中用文档嵌套的方式表示 daily notes，但是我觉得似乎在需要使用时间的地方用标签是个不错的选择。

1.3.9.8.1-首先，日期标签的汇总方便

思源笔记的标签是支持树状结构的，使用的是 /​标志，这也可以作为日期中年月日的分隔标志。#2021/02/03#​这个标签，其实同时创建了 2021、2021/02、2021/02/03 三个日期标签。

针对搜索汇总而言，标签虽然是树状结构，实际上还是文本的形式，搜索 #2023​可以汇总所有与 2023 年有关的信息，不论其标签精确到年、月还是日。

反观引用，汇总与 2023 年相关引用，反向链接是无法汇总到精确到月和日的信息的。

对于直接全局搜索日期的情形，又会出现大量无关信息，比如本节中举的 #2021/02/03#​例子，其实跟这个日期完全没有本质上的关系，更不用说还可能出现『20215689』这样的非日期干扰项。使用『2021/』进行搜索，又不能保证所有日期均是这种形式，如果存在『2021 年』等就无法找到，正则是一种方法，但毕竟也难免存在疏漏。

1.3.9.8.2-另外，标签的新建、删除方便

标签具有 1.3.9.2.3-不使用的标签不会存在¹⁹的特性，日期性质的标签如果精确到日的话，必然就会大量存在。对于标签，新建很方便，可以随用随建，在文件中也只是一行字而已。

但反观引用，如果一个日期建立一个文档的话要建立大量文件，影响性能。如果把日、月乃至年写在文档中作为段落或标题的话，的确规避了此问题，但又带来一个新问题：增加日期非常麻烦，需要定位到文档，输入，再回来引用。

1.3.9.8.3-日期标签应具有根文件夹

这个指的是，不要直接使用 #2021/02/03#​形式，而应使用如 #time/2021/02/03#​形式。第一，没有根文件夹，标签栏将逐渐被日期标签填满；第二，如果今后想建立另外一个日期标签系统，如将于个人事项相关的日期和与历史事件相关的日期分隔开，可以直接再新建一个根文件夹，使用 #history/2021/02/03#​名称，并且根目录『time』也可以改名。除了分割不容易外（这个用什么系统都不容易实现），更名、增加、合并（直接改成同一个名即可）都很简单。

1.3.10-（推荐）块应当具有完整的意思表示

一个块应具有完整的意思表示，块不同于段落，几个段落合并为一个意思表示时，不宜拆分为多个块。否则，根据 1.3.3-（推荐）带有引用的块应有『命名』或本身就是『命名』⁶，需要命名的块就会太多。

以下示例不应拆分为多个块

第二十七条  父母是未成年子女的监护人。
未成年人的父母已经死亡或者没有监护能力的，由下列有监护能力的人按顺序担任监护人：
（一）祖父母、外祖父母；
（二）兄、姐；
（三）其他愿意担任监护人的个人或者组织，但是须经未成年人住所地的居民委员会、村民委员会或者民政部门同意。

第二，对于引用，块拆分不会丢失，但是块合并会丢失（因为有块被删除了），这就对块的合并做出了限制，为避免麻烦，在笔记入库时就应当完成合并。

1.3.11-（可选）利于迁移

1.3.2-（强制）引用应指向关系最为密切的块⁹对笔记迁移影响最大。引用指向关系最密切的块，就不可避免的将引用文档下的标题或段落块，即块引用。文档引用多数笔记均使用 [[文档标题]]​形式（也有采用 @文档标题​形式），但是块引用不同笔记之间差异较大。

这里的差异不止指引用的形式，还包括块的命名方法，常见笔记关于块引用的约定如下：

1.3.11.1-obsidian 关于块引用的约定

• 块命名使用 待引用的块 ^0e9f6c​形式

• 标题命名使用如下形式

  • ## 待引用的标题
    
    ^2fc8c7
    

• 块引用使用 [[测试#^2fc8c7|显示的文字内容]]​形式

1.3.11.2-logseq 关于块引用的约定

• 块命名使用如下形式

  • - 待引用块
      id:: 63a1080c-a495-460d-b472-71508b00e76e
    

• 块引用使用 - ((63a10817-05d9-4198-b912-4944be79f45e))​​形式

  • 注意，这将会显示原来块中的内容，至于如何使显示内容与指向的引用块内容不同，未找到相关方法

1.3.11.3-Siyuan（思源笔记）关于块引用的约定

思源笔记使用 JSON 格式存储笔记文件，以下所用形式均为 JSON 格式而非导出的 markdown 格式。

• 块命名使用如下形式

  • {
        "ID": "20221214201619-j1gs8li",
        "Type": "NodeParagraph",
        "Properties": {
            "id": "20221214201619-j1gs8li",
            "updated": "20221214204233"
        },
        "Children": [
            {
                "Type": "NodeText",
                "Data": "待引用的块"
            }
        ]
    }
    

• 块引用使用如下形式

  • {
    "Type": "NodeTextMark",
    "TextMarkType": "block-ref",
    "TextMarkBlockRefID": "20221214111010-ludwkrq",
    "TextMarkBlockRefSubtype": "d",
    "TextMarkTextContent": "显示的文字内容"
    }
    

通过以上比较可以看出，使用块引用的笔记在各笔记软件之间迁移是困难的，要利于迁移，就要尽量避免块引用，而仅使用文档引用，且最好不要自定义 显示的文字内容​，但这未免对笔记的记录限制过大，故利于迁移这一原则处于基本上不予考虑的处境。

1.4-工作流

1.4.1-笔记入库（树形结构的组织）

1.4.1.1-树形结构是否存在必要

双链笔记出现后，很多人觉得不必再使用树形结构了，但是只使用网状结构，我总觉得别扭，每每看到一堆 Daily Notes 堆在那里就觉得头皮发麻。仔细一想，可能是网状结构没有解决入口的问题，即我应当如何快速找到自己想看的那一篇笔记，再以此为起点进行扩展？可能的方法就只有搜索了，但搜索是一种低效的方式，筛选成本大，即使有双链加持，也需要层层跳转才能准确找到内容。

树形结构的入口就清晰很多，在大部分场景下，可以通过文件夹找到，在不易找到的情况下，树状结构也可以帮助缩小搜索范围。

另外，网状关系中，父子关系占了很大一部分，树状结构组织后，可以大大缩小双链网络的规模，减小其维护难度。首先通过树状结构进行组织，也是因为这是一种强制组织方式，提高维护笔记系统的动力。

1.4.1.2-将文章进行预处理

笔记应以『知识』为中心，可以把其理解为输入、概念、wiki 词条、编程中的类，其特点是：
1.系统化、结构性强，通常有父级和子级
2.有明显的『属性』，如概念、分类、特点等
3.复用性强，与一般信息或事实不同，被引用的概率大
4.主观成分少，客观性强

笔记来源于文章，而文章分为综合性和专业性的。综合性文章需要拆分为多个专业性笔记，即易于进行归类的笔记。综合性图书很多，如论文集等，但是综合性文章一般较少，这里暂时不讨论如何拆分。

此时会出现两种情况：一是原笔记中有相关内容，此时与原笔记进行整合；二是原笔记中没有相关内容此时我们直接入类，并进行排版、删除无关描述等简单处理。

此时，需不需要再将文章拆分成更小的笔记是需要讨论的问题。如『常见年宵花』需不需要拆分成『杜鹃花』、『君子兰』等。拆分的好处是再加入新内容易于找到，缺点是繁琐，有些文章结构性不强，不易拆分。不拆的好处是心智负担小，有些内容与自己关注的领域关系不大，拆分的意义不大，缺点是之后再有新笔记加入容易忽略已有内容。

这里还是需要区分情况：需要保留来源的重要文章不拆，视以下情况建立引用；不合理的父子关系拆，如『常见年宵花』就属于这种，花卉一般不分为『常见年宵花』和『不常见年宵花』，这就需要将其拆出来；与主题相关性差的拆，如在将某一历史事件时，讲到某个人物，插了很大一段讲其生平，这种内容就需要拆分出来。

需要注意的是，需要保留来源的重要文章要完善来源信息。

1.4.1.3-树状结构分类的一般情况：根据学科性质分类

拆分处理后的内容就需要进行分类了，系统性知识、专注领域（经常关注的领域）的零碎知识入数学、文化等带有学科性质的有关各类。

1.4.1.4-多上级内容的分类（多对一）

在本节中，仅讨论多上级内容的树状分类，而不讨论如何引用，如何引用见 1.4.2-树形结构与引用（网状结构）的结合⁸。

1.4.1.4.1-因分类方法不同导致的多上级内容：入其中一类

对于因分类方法不同导致的多上级内容，直接根据一种分类方法入库即可。

为了便于与标签系统进行整合使用，特别是便于搜索和汇总，在入其中一类的同时，最好使用嵌入块在另外一个分类中建立嵌入块。#ChangeLog/2023/03/01#​

1.4.1.4.2-包含多个概念导致的多上级内容：入共同上级，根据形式分

包含多个概念的内容即综合性的知识。

例 1：A 与 B 的比较，其既不属于 A 也不属于 B，或者即属于 A 又属于 B，并且，后期还可能变成 A、B、C 的比较。

例 2：某计算题分别综合应用了方法 A、方法 B。

一般入多个概念的共同上级，但因为其不属于概念型子类，应建立形式上的分类，如对比汇总、案例汇总等。

当然，这一规则也并不完全，从方便来讲，也可以直接入 A 或入 B，有必要时在进行整合。

1.4.2-树形结构与引用（网状结构）的结合

笔记通常采用树形结构组织，当树形结构不满足需求时，区分不同情形，采用如下规则处理。

1.4.2.1-重要概念要进行引用

重要概念都需要引用，即使没有已有笔记，还是要新建一个笔记，进行引用或反向引用。一般时代、地点等通用概念要引用，其他视自身了解程度，主观把握即可。

引用时新建的文档要再次进行分类。

1.4.2.2-不同分类方法导致不同分类形式（一对多对多），且可枚举

在父级下列举不同分类方法的不同子级，在一种分类形式中进行详细描述，在另一种分类形式中引用子级，如：

‍

• 分类方法 A

  • 子分类 1

    • 子项 1.1
    • 子项 1.2

  • 子分类 2

    • 子项 2.1

• 分类方法 B

  • 子分类 3：子项1.1的引用​、子项2.1的引用​
  • 子分类 4：子项1.2的引用​

这种方法适用范围较窄。一般来说，各种分类方法有共同上级，构成一对多关系，各分类方法与子分类又构成多对多关系。

1.4.2.3-不同分类方法导致不同分类形式（多对多对多），难以枚举

将分类方法作为引用，在各子项中以类似标签的形式处理：

电影 A

参演人员（电影 A）：演员A的引用​、演员B的引用​

导演（电影 A）：导演A的引用​​

类型（电影 A）：悬疑的引用​、动作的引用​、喜剧的引用​

以上例说明，此处的难以枚举是指，电影可以根据『演员 A、B……参演的电影』、『导演 A、B……执导的电影』乃至于『类型』等分类，此时我们在记录电影 A 笔记时（即向这些分类插入子项时）不必在分类的文档中一一插入子文档的引用，而直接在子文档中引用父文档即可。

还有一个问题是，在上例中，演员 A 的笔记应如何组织呢？即在演员 A 的笔记中，需不需要引用『电影 A』？为了避免相互引用的繁琐，应避免相互引用，可以采取如下方法：使用 1.3.2-（强制）引用应指向关系最为密切的块⁹，在演员 A 的笔记中加入『演员 A 参演电影』标题，但不列举，在上例中引用演员 A 时，引用到其『演员 A 参演电影』标题上。

一般来说，各分类方法都有差别较大的上级分类方法（如该例中『演员 A』、『演员 B』属于『演员』，与『悬疑』、『动作』属于电影类型），不会出现多对一的情况；如果有，（如该例中『演员 A』既属于『演员』，又属于『导演』），参考 1.4.1.4-多上级内容的分类（多对一）¹⁰）#ChangeLog/2023/03/01#​

1.4.2.4-子项作为父项的补充（一对多的特殊情形）

所谓的子项作为父项的补充，是指某一概念存在一般情形，或从一类概念中可以抽象出一般情形，但在该概念的子概念或一类概念中的部分概念中，存在特殊情形。

（不推荐）对父项和子项进行相互引用

即子项引用父项的一般情形，父项列举引用子项的特殊情形。因为需要在父项文档中枚举特殊情形，该方法容易导致遗漏，仅推荐在易于枚举时使用。

对父项和子项进行相互引用的目的仅为 1.2.1-使用引用便于跳转和复用²。

父项文档：

• XX 的通用原则

  • 原则 A：详细信息
  • 原则 B：详细信息

• XX 的特殊原则：

  • 原则 C：见 子项1 的文档引用​

子项 1 文档：

• 子项 1 的遵循原则

  • ​原则A的引用​​
  • ​原则B的引用​​
  • 原则 C：详细信息

或

• 子项 1 的遵循原则

  • 通用原则的引用​
  • 原则 C：详细信息

在子项中进行两次引用

即子项引用父项的一般情形，并在父项中设立『特殊情形』标题以用以进行引用。采用该种方法，可以在父项中方便的通过反向引用查看所有的『特殊情形』。

子项引用父项的一般情形，目的为 1.2.1-使用引用便于跳转和复用²；

子项引用父项的『特殊情形』标题，目的为 1.2.2-使用双链便于从不同维度汇总知识¹。

如：

父项文档：

• XX 的原则

  • XX 的通用原则

    • 原则 A：详细信息
    • 原则 B：详细信息

  • XX 的特殊原则

子项 1 文档：

• 子项 1 的遵循原则

  • XX 的通用原则¹¹
  • 子项 1 的原则 C（XX 的特殊原则¹²）：详细信息

1.4.3-笔记的搜索

笔记的搜索手段有以下几种：

1. 直接利用树状结构，对只有一个关键词时最快。可以在某文件夹、某文档下搜索以缩小范围，或者利用空格隔开多个关键词，或者使用正则，可解决大部分问题。
2. 在反向链接中使用搜索，先找到其中一个关键词的文档，对其进行搜索，如果没找到，在其反向链接中进行搜索。文档反向链接较多时，可使用『聚焦』功能缩小范围。对关键词较多时比较有效。
3. 利用标签⁷，但需要维护标签系统，对关键词较多时比较有效。
4. 全局搜索，最后的解决方案。

总的来说，搜索没有找到完美的解决方案，因为搜索需求总是多种多样的，很难事前完全确定需要搜索的内容是什么，而进行针对性的优化。来源、分类、时间等可能是较为常见的需求，为了快速找到需要的内容，与其完善引用等，最直接有效的方式是用文字完善其要素，如在文档中记录来源等信息，1.3.4-（可选）标题或块应便于查找²⁰等。

1.4.4-笔记的输出

整合为输出其实是『文章』形成的过程，将知识进行引用、综合，针对具体目的的不同形成不同的文章，用于发布等。

当整合为输出时，可以根据项目等基于外部目的分类归入相关文件夹。

1.5-后记

本人感觉记笔记不应该成为一种负担，即记笔记的过程应该尽量自然，以自己感觉方便的方式进行记录，所以该笔记记录规则中的方法一般都是在记笔记的过程中逐步使用的，已有笔记通过不断的更改而逐步完善。

首先 1.3-使用笔记记录的一般规定²¹中的强制规定必须遵守，否则之后改起来会很麻烦，推荐规定一般只对重要内容需要遵守，可选规则则需要的时候再修改即可。

1.4-工作流²²中的规定，对于引用网络的形成影响很大，即 1.2.2-使用双链便于从不同维度汇总知识¹，一般需要的内容都可以通过搜索²³找到，但是不遵守工作流会使得反向链接汇总不到，最终影响的是笔记的输出²⁴。

ChangeLog

2023-03-01 19:42:43

新创建 76 个块，新增 3541 字；更新 55 个块。

本次更新新增了很多关于标签的讨论，感觉标签还是有存在的必要，但是因为其与引用有太多的相似之处，选择起来很是纠结，但最终感觉似乎可能还是得出了『自圆其说』的结论。

在 1.4.1.4.1-因分类方法不同导致的多上级内容：入其中一类²⁵中加入了嵌入块的简单应用说明。

将 1.4.2-树形结构与引用（网状结构）的结合⁸中几种分类方法区别为『一对多对多』等。

为发布时容易区分，更加了层级前的序号（这个应该出个插件实现#待办#​）。

2023-02-25 22:34:14

首次完成写作。

2022-11-17 15:12:46

开始写作。