删除

现在这样挺好，我完全无法想象没了文档树怎么下手。

我个人是赞同保留文档树的。原因很简单：更符合大众用户的旧习惯。

我觉得即使是新型笔记软件，也要考虑到用户的思维切换过度，不然很难吸引到更多的用户，永远只是小圈子了。MOC 的想法我也觉得很好，但是目前来看，强行推广不合适

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

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

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

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

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

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

第一点：没用过 RR，但我知道 logseq 有个目录功能，re 有个主题列表，本质都是为了方便找到文档，我觉得从这个角度来看 moc 和文档树没有区别。他们没有文档树，所以他们使用 moc 构建进行管理，思源有文档树，思源也可以用 moc 构建管理。
第二点：我认同你的宣传理念，并且赞同你的宣传方法，我反对的是一刀切的想法。
第三点：我不知道你为什么抛弃文档树管理，文中我对 moc 使用中产生的几点疑问我想知道你是怎么解决的。或者换个角度问，你用文档树找过你的文件吗？
第四点：我不认同，不知道你听没听过全历史，里面的关系图谱就是图谱的一个应用，图谱真的没用吗？知识图谱视角下的双链笔记 - 知乎 (zhihu.com)这篇文章作者也说明了他认为的知识图谱的作用，只能说目前双链笔记的关系图谱做的不尽人意，但不能否定单独的图谱是有用的。
第五点我认同，双链笔记关系图谱功能是失败的。但是我觉得如果没有其余信息的干扰，单独拿双链笔记用来记录历史人物，记录人脉关系，其实是可行的。

我提出图谱这个功能只是希望大家重视他。我希望更多的人使用到图谱功能，并能发挥他的作用；我希望更多的人给图谱功能提建议完善图谱功能。

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

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

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

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

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

文档树可以不用，但不能没有，就这么简单。有啥可讨论的？就非要取消文档树？还不如想想加个什么新功能来得实在

我就是因为 logseq 没有文档树而对它弃如敝履。不要盲目崇拜一些所谓的新理念，如果你对自己的所有笔记没有一个清晰的概念，全靠所谓的链接而管理，那真是可笑。大脑存储不就是因为没有结构才诞生了思维导图，目录这些东西么？大纲，是不是你批评的文档树的一种变种呢？？？如果哪天思维导图，大纲，微软的资源管理器都消亡了，我就认可取消文档树。图，这种东西，在计算机领域和现在的神经网络模型中应用广泛，他是有自己的优势和效率的，但不一定适合人脑。

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

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

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

我原来一直使用文档树管理文档，确实有很多不便的地方，并且想要高效还要专门学习效率达人的笔记体系。

后面出了大纲双链笔记之后，去体验了 logseq，后来又接触了 moc，之后就一直用这个理念来管理我的笔记内容。我在看过会议之后，有了切换回思源当作主力的想法，觉得 @fangly 提到的这种思源笔记使用方式让我找到了大纲双链的感觉。。

会议几乎全程我都听过，对于会议里的方法对大部分双链大纲笔记都是适用的，思源笔记兼容性很强所以也适用。思源有他的好，好在其他地方。

我本意并不打算发一篇这样文章，我在 23 号会议反对了演讲人的一些观点，给出了自己的意见，遭到一些听众的质疑，于是我在会议上回复会单独开篇文章解释我的观点，于是有了这一篇文章。
下面是会议聊天记录。

演讲人是好意的，也感谢他的演讲。这篇文章也只是正常讨论，希望评论的各位正常交流友好讨论，谢谢大家。

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

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

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

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

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

我不知道怎样才算质疑怎样不算质疑？下面的图片上大家的评论都在那，这算是在不同角度分析问题？

我就是在反对你的观点，反对你在会议上说的观点，你有录屏你可以回放看看你的观点。当然我也仅仅是反对你的观点，我同样非常感谢你分享的方法。

哈哈，文档树目录结构是对“整理”有“洁癖”的人用的。。。

当你的计算机/软件 搜索功能足够强大的时候从来不需要文档树，有什么需要的搜索即可。但是标签 TAG 不可缺少，有的时候一篇笔记、文档多打几个 TAG ，让搜索更容易显示在最前排，比整理目录树更有效。

——包括现在的 Windows 目录、浏览器收藏夹，目录越多，发现越难查找，不如搜索关键词来得便利！因此好的标题、文件名、TAG 比好的目录树结构更有效。

结合个人文档、笔记整理需要，个人觉得目录文档树只需要建立几个大的目录归类即可，不需要将目录建立超过 2 层（个别笔记、知识合集可以例外），以上个人观点！

非常赞同作者。
我是不愿意放弃文档树的，文档树 + 网络结构 相得益彰、得心应手。

每个人的知识管理方式都不同。想放弃文档树的可以自行放弃（把文档树直接隐藏即可）、也可以自由反对，但不要试图从软件中抹杀这个功能，从而变相强制别人也放弃。

我是不用文档树的，但是现在没有日历插件，如果按日期查看笔记是没办法的，如果解决了这个问题，对于我而言是完全不需要文档树的

我才是不知道你是在哪个地方看到“思源笔记要取消文档树”这个观点的。我的评论表达了我对反对文档树的反对和对极端形式的软件比如 logseq 的反对，如果你说的是并存，我觉得可行，新模式的出现肯定也有它的优势，至于优势有多大，需要时间和时间检验，至少目前我是没有信心加入的。

在一个树形结构上拖来拖去，更改他的结构然后欣赏，好解压，让人心情好。😋

熊掌记，可以了解下，MAC 用户比较多，没有文档目录树的笔记工具，标签足够灵活，事实上，他的标签就是目录树。

我反正把文档树隐藏掉了。

通过引用和快捷键在笔记中跳转。

可以不用，但不能没有

太微（TiddlyWiki）同时支持文档树和自动生成目录页

比如我的博客 https://onetwo.ren/wiki/#:Index

右侧就是一个自动根据标签生成的文档树（是一个插件，插件的逻辑是标签=文件夹），此外还有 https://onetwo.ren/wiki/#所见即所得编辑器 这个条目是用 <$list 微件（可以理解为 Obsidian 的 dataview 功能）自动生成的文件目录，不过还自动把文件内容嵌入进来了。

我个人的使用经验是，两种同时都在用，自动生成 MOC 适合对一个主题做统一整理，然后对外发布的时候。我会让他自动生成索引页，然后整体复制粘贴发布到知乎等平台。然后这个页面也适合做于对外分享的页面，方便读者按需查看。

而文档树适合碎片化地去整理一个主题，或者在产生新的思考的时候，有想法就添加到笔记里并加上标签，也就是放进文件夹里。然后文件树自动就出来了，之后要整理的时候就直接看这个自动生成的文件树。