不需要事先专门找一个地方来放置批注，我的演示视频里是在《红楼梦》中找一个地方放批注，完全也可以在 daily note 中放批注

类似这种思路你看看能否接受：

“引用块”的内容过长会直接省略内容，这个是因为设置的原因，可以修改的：

我不觉得你是在反对我的观点，其他听众也没有在质疑你，大家只是在不同角度分析问题。

我也并没有“对文档树的作用持否定态度”，就好比说思源的电脑端的编辑功能比手机端好用，不代表否定手机端的作用，不是非此即彼的。

因为大家普遍对文档树比较熟悉，但很多人对 MOC 不太熟悉，所以在会议上我主要介绍 MOC，并且以大家熟悉的文档树的构建过程作为对比，阐述 MOC 的构建过程，可能有的人误以为要砍掉文档树功能。

文档树和 MOC 当然可以共存，有的人可能在 MOC 上进行知识体系层面的分类，在文档树上也进行知识体系层面的分类，两者功能重合度比较大。而我的想法是，让文档树和 MOC 各司其职，各自从不同的角度进行分类：MOC 仍然是根据知识体系进行分类；而文档树可以从时间角度进行分类，这是 moc 所不能做的事，也是 RR logseq 做不到的，也能保证只要记得文档的大致创建时间，就不会找不到文档，可以帮助大家消除找不到文档的担忧。

在会议前，我并没有准备深入讨论这个话题的，也没想到有不少人对这个话题这么关心，所以会议中对这个问题可能没有讨论清楚。

不知道你是在哪个地方看到“思源笔记要取消文档树”这个观点的，这也是我第一次看到有人提出这个观点，文档树作为思源和 rr、logseq 的不同点之一，我始终认为文档树是不能取消的，包括思源特有的“靠笔记本释放性能”等功能都要靠文档树功能来支持

文档树和 MOC 都是自顶向下结构化管理笔记的方法，两者可以在不同的角度进行笔记的结构化管理

详细案例和相关讨论可以查看 思源第一次双链实践交流会讨论区 下面的回帖

这个路径支持模板我觉得挺有用，我在 思源第一次双链实践交流会讨论区 里面最后有提到

这样可以保证当月新建的文档都是该月文档的子文档，使得文档树更具有“按创建时间分类”的属性

很多人对文档树抱有执念，一个重要原因就是怕找不到文档，如果文档树能够完全按创建时间分类，那么找不到文档的可能性大大降低，只需要记得创建这个文档的时间是在哪几个月，就一定能找到文档，这样可以使得很多人消除找不到文档的担忧，更好地在平时忘记文档树，实践双链

关于 moc 和文档树的话题，最开始是没有打算在会议里专门讨论这个的，所以可能没有讲清楚，但发现大家对这部分挺感兴趣，再补充一点我的看法：

双链笔记中是自底向上和自顶向下结合的

自底向上在这次会议中讨论得比较多，包括一元笔记法、daily note、反链等

自顶向下在这次会议中讨论得较少，包括 moc、文档树、标题（标题本质和子文档等价）、笔记分类等，自顶向下部分还可以和各种传统笔记方法结合

同时自底向上和自顶向下是交错融合的，可以在自顶向下的指导下进行自底向上的笔记输入，可以在自底向上的基础上进行自顶向下的笔记整理

对于文档树和 moc，都带有自顶向下的思想，我在思源中的实践思路是这样的：文档树部分只进行时间层面的分类，moc 部分进行知识管理、时间管理等层面的分类，演示案例如下：

注：

我的块引新建文档存放位置的设置如下：

更严谨地说，文档树中《02》文档下的子文档是 2 月的 daily note、在 2 月的 daily note 中创建的文档 x、在文档 x 中创建的文档 y……，即以 2 月的 daily note 为根生出的文档。我在 2 月的时候也可能在《01》下的子文档中创建新文档，此时新文档就在《01》下面

当然，还有一个思路是把块引新建文档的存放位置设置为该月文档，例如现在 4 月就设置为 daily note/2022/04，这样该月文档的子文档就全部是该月所新建的文档，但是每个月都要修改一下设置。可以通过模板变量设置为“/daily note/2022/{{now | date "2006/01"}}/”来达到自动修改的目的，但是目前这个设置还不支持模板变量，已有相关提议： 问题求助：关于“块引新建文档存放位置”的问题

“你用文档树找过你的文件吗？”：这个问题的主体是“找文件”，那么找文件有很多方法，例如在构建好的 MOC 中找文件，使用搜索找文件，在文档树中找文件。如果要找的文件属于构建好的体系中的一部分，那么可以通过 MOC，如果要找的文件属于零散的文件，可以通过搜索，不知道你是在什么场景下只能使用文档树找文件，而不能使用 MOC 或者搜索找文件。

如果是连得文档的关键字都想不出来，那么至少应该记得是在哪几个月写的这个文档，在视频中也可以看到，我的文档树中，某个月创建的文档都是该月文档例如《03》的子文档，那么在这几个月份下面找就好。如果是使用文档树管理的话，要找这种连得关键字都想不出来的文档，也应该是比较困难的，需要在文档树中找到有可能存在该文档的部分，然后进行遍历搜索。

某种程度上，我现在也有在用文档树管理文档，只不过文档树中的分类只有三层，第一层年份，第二层月份，第三层是该月的所有文档。在文档树中通过时间管理文档，在 MOC 中通过知识体系和分类管理文档。

我没有说图谱没用，我自己在科研时也做知识图谱的研究，不可能我还主动研究一个没用的东西吧，我说的是单独只有一个图谱是很难通过肉眼从中挖掘有价值的信息，所有图谱的应用场景都是图谱和其他技术的结合，图谱的价值需要和其他技术结合才能充分体现，例如需要有一个算法从图谱中挖掘信息，但这个是非常难做的，目前双链软件都停留在构建知识图谱的层面，最多是知识图谱应用的起点，剩下来还有很长的路要走。

思源重置图谱目前走的是白板路线，其实还是 MOC，已经和图谱没有关系了，其他软件也没有在图谱构建功能的基础上做图谱数据挖掘的功能，只有在去年听说葫芦笔记有这方面的想法，但现在也是杳无音信。

典型双链笔记软件类似 roam research、logseq 都是没有文档树的，因此主要使用 MOC 的思想进行自顶向下的文件管理，而思源里面是有文档树的，因此可以有不同的方法。

但因为有很多用户是从传统笔记软件中转过来的，因此文件夹分类的思想根深蒂固，对于一些新的方法可能会难以接受，因此需要让大家跳出舒适圈，尝试一些新的方法，在视频下面我也放了一个挑战：

• 3 天的时间（最好能尝试更长时间）
• 忘记文档树、忘记标签树，当做这两个功能不存在，完全使用双链构建笔记系统
• 把所有内容都写在 daily note 中，并且 daily note 中通过列表写笔记

3 天过后，开始思考重构自己原先的笔记系统，这时候对 MOC 和文档树的理解会和之前不一样，这时候可以尝试将 MOC 和文档树进行结合使用，也希望大家能多多分享自己如何将文档树和 MOC 结合的案例，可以一起讨论，事实上，我在去年也是将 MOC 和文档树结合使用管理知识体系的，但在今年对文档树有了不一样的理解，在文档树上只进行时间层面的分类，在 MOC 上进行知识体系、时间管理等层面的分类。

关于图谱，我自己的研究方向和知识图谱有一定关系，知识图谱领域主要研究内容有两个：① 构建知识图谱，这是起点，后续应用的基础；② 将知识图谱和其他技术结合进行应用，例如利用知识图谱增强预训练语言模型，利用知识图谱增强推荐系统，利用知识图谱增强机器翻译，知识图谱本身是没有明显的应用价值的，需要和其他技术结合。

而在双链软件中，很多人将重心放在了知识图谱的构建上，而且将知识图谱的构建当成了终点，而事实上，这只是起点而已，真正有价值的是如何让构建出来的知识图谱能赋能知识管理，这个难度非常大，我目前唯一看到的类似应用就是学术图谱在文献挖掘等领域的应用，但它是以文献、学者、出版地点等实体作为节点，这相对来说还是比较粗粒度，而笔记内容是非常细粒度的，我目前还没看到将知识图谱和细粒度笔记管理结合的算法或应用。

更全一点的 bug 演示视频，可以按照这个操作试试看：

正常使用时，不管你退不退出，除了你自己，别人都看不到你的笔记，除非你把本地的密码泄露给别人

在陌生设备上访问需要清理数据，因为思源中隐私安全的一个前提条件是本地环境是安全环境，没有恶意方会访问你的本地环境，因此本地数据是明文。而你在陌生设备上访问已经破坏了这个前提条件，因为陌生设备是不安全的，因此需要清理。

不要在《列表项转换为文档》这个文档里面引用 foo，在其他文档中引用 foo，以及引用《列表项转换为文档》这个文档

因为实际上后面反链面板中显示的内容并不是 foo 文档的，仍然是原先文档的，所以会看起来是正常

以及在文档树中，引用块数字不对：

引述块的问题在我这儿是必现，不需要快速移动啥的：

云端是加密后的笔记内容，因此需要使用客户端下载密文，再在本地借助密码解密笔记，从而保证笔记的数据隐私安全

思源是端对端加密同步，云端是加密后的笔记，开发者看不到你的笔记内容，对机器来说也只是一堆乱码，想审核也没法审核

在列表中有引述块，引述块中还有列表时，也会有类似的问题：

讨论软件时请正常讨论软件，不要掺杂个人恩怨

他这个不算个性化需求吧，就是相比原先多了一个面包屑，和 roam research、logseq 相同的设计

没有面包屑真的很不方便，一些笔记方法都无法很好地实践，比如下面这个： 粒度问题 - 来自多篇 -> 多段内容中的具有相同特征的句子，除打标签外如何汇总整理？ - fangly 的回帖

没有面包屑最多只能给出“下文”，面包屑能给出“上文”，两者结合才能有“上下文”

现在思源群的管理和一年前思源群的管理相比已经大换血了，没有说只有老管理没有新管理，比如萌新大佬就是这几月才成为管理的。

想要当群管理可以直说的呀，dammy 不知道你想当管理，所以不会觉得“管理的事你以后别多操心”这句话会伤到你。dammy 是把你当成热心用户来看待，而不是“管理员候选人”，并没有否定你之前对思源群做出的贡献，没必要对他有那么大的敌意的。

群管理不是什么神圣的职位，不用看得太重的，有共同爱好的人在群里一起快乐交流才是最重要的。

有人不在群里或者没看聊天记录，不知道发生了什么，还是给一下完整的聊天记录吧：

事情经过：

Wolke 非常热爱思源笔记，群里很热心，也有过当群管理的意愿

Wolke 说“频道有啥用”，而 dammy 认为频道很重要，产生观点分歧，氛围白热化

后面 dammy 说“管理的事你以后别多操心”，Wolke 认为这是在否定他之前对思源群的贡献，彻底被激怒

@88250 ，这个 bug 能复现么 😂

加粗高亮后，汇总时的粒度还是段落块级别，没法到句子级别，和打双链/标签 后汇总在性质上应该差不多，而且也没法保留原文和自己改写句子的两个版本，不方便对这句话批注，以及没法在别处直接复用链接这句话，如果不在乎上面这些，加粗高亮确实可以作为某种意义上的标签快捷方式。

加粗高亮汇总这套思路可以和 Progressive Summarization 有机结合。

思源笔记，roam research、logseq 之类的双链软件对于这个问题都是相同的处理思路：将这句有用的话变成文档。第一次使用这种方法时可能会有点不适应，但这确实是目前双链笔记软件社区中的主流方法。

以及卡片盒笔记法、zettelkasten 笔记法等笔记方法中提到的永久笔记等概念、roam research 中的知名插件 discourse-graph 对于类似问题也是采用这种处理方式。

例子如下：

比如下面这段话中，有一部分内容我觉得很好，那么我就选中这句话，alt+[ 生成文档：

然后在这句话的文档中，你可以把这个文档再链接到一个专门的文档，比如叫做《literature notes》，所有有价值的话都链接到《literature notes》这个文档中，可以再将这个文档链接到其他文档，比如下图中我将其链接到《哲学》文档，说明这句话是哲学话题之下的，在这个文档中还可以写自己对这句话的感受、评论等

然后在《literature notes》这个文档的反链，便可以看到所有句子

到了后期，可能《literature notes》有很多很多，有关于哲学的、有关于数学的、有关于情感的等之类的，这时候《literature notes》的反链可能就很乱，这时可以进行多关键字筛选，目前的反链面板不支持多关键字筛选，可以通过 sql 实现，比如像下面这样，其中 20220412190212-urdntw3 和 20220412191321-d1iar08 分别是《literature notes》和《哲学》这两个文档的 id

但这时候有点问题，和 roam research、logseq 不一样，思源笔记中的嵌入块不显示面包屑，因此只有点击嵌入块后才能看到这句话是什么，在有大量搜索结果时会很不方便：

github 上已经有相关 issue：https://github.com/siyuan-note/siyuan/issues/2985，但目前可能还没时间处理这个问题，等到 2.0 发布后，可以多跟 D 大催一下这个功能

而且，你不止可以摘录这句话，还可以用自己的话重写这句话，并且保留原文，锚文本设置为原句，而文档名是自己重写后的句子：

可以再参考更加详细的实际案例，下图来自 https://www.bilibili.com/video/BV1T94y1d7fu 这个视频：

还可以参考 joel chan 大神的一些演示视频：

https://www.youtube.com/user/chozen86/videos

在 sql 搜索中通过时间段筛选时需要用到 updated 字段，以及通过 updated 进行排序时需要用到

我最近在思源里建立了一个简化的间隔重复系统，需要通过 updated 字段筛选块，结果发现有好多应该出现的块筛选不出来，调试了好久，结果发现是 updated 字段有问题

这应该不是早期数据的问题，现在的数据也有很多 updated 为空的，直接 sql 搜索：

select * from blocks where updated = '' and created > '20220401'

就能搜到一堆

“更新于”的问题 F5 后还是有问题，应该是和列表有关，我试了段落块貌似都没问题，但列表会有问题，一种复现方式如下，建立含有两个列表项的列表，没刷新时，都没有“更新于”，刷新后，第二个列表项有“更新于”，第一个列表项还是没有：

如图，像我这样反复操作，应该能复现出来（鼠标移动速度尽量快）：

20220407225142ipzgmd4.zip

问题 1 和 3 不一样，问题 1 和引用数量有关，问题 3 和引用数量无关，和 https://ld246.com/article/1649338100756 这个问题有一定关联

首先我在搜索设置中关闭了段落块

然后比如说我在某文档中写了关于 线段树 的内容，在顶级节点上写线段树，子列表中写线段树的具体内容，子列表中会大量包含 线段树 这个关键字

然后我在其他地方想要引用 线段树，讲道理应该引用最外层这个列表项，这个列表项的第一个块的内容和 线段树 关键词完全匹配，但是实际搜索结果中，因为最外层列表项长度最长，所以会排在最后

而如果我在搜索设置中打开段落块，这时候搜索的第一个结果和我想要的结果非常近，但可惜是段落块，我想要外层的列表项块

这个问题可以和 https://ld246.com/article/1649338100756 这个帖子一起考虑下

不要嵌入段落块，嵌入段落块没问题，嵌入列表项块时会有问题

此外，您的截图里面这个竖线是不是也有问题 😂 ：

一样的（鼠标要直接浮在嵌入块上，不要放到圆点左边）：

问题 1：sort 字段中有考虑被引用次数吗，我认为排序时首先看匹配程度，然后看被引用次数，之后再是其他，像下图中，红框标出的被引用次数有 2，其他都是 0，这个应该排在最前面：

问题 2：测试时又发现一个古老 bug，锚文本为空时应该显示列表项的第一个块，可以看到刚引用时并不是，我得修改一下锚文本再清空锚文本才行：

问题 3：单论匹配程度，我认为下图中，也是红框中的列表项匹配程度最高（我在搜索设置中过滤掉了段落块），该列表项的第一个块和搜索内容完全匹配。

这在实际使用过程中非常常见，比如说我想要写关于 线段树 的内容，如下图，我有三种选择：1. 我可以单独新建一个文档叫线段树，2. 可以列一个标题叫线段树，3. 可以使用列表，在列表项的第一个段落块上写上线段树，三者是等价的。我在其他地方想引用线段树时，如果是文档块或标题块的话，目前没问题，都是排序在第一个，但当我用列表时，排序就出现问题，我想要引用的内容并不在最前面，甚至可能在非常后面。不清楚在技术上实现这个排序逻辑方不方便，不方便的话，只要把问题 1 解决，大部分情况下也还能用。

1.9.7：

1.9.6 中，可以看到非常顺畅：