我该把笔记放在哪里？

经验分享
1

这是一个梳理我自己的心路历程的帖子。

使用 Obsidian 的一个最大障碍就是不清楚该把笔记放在哪里。如果从第一性原理的角度进行推导，之所以会纠结这个问题，是因为不想要把笔记放在根目录，这是害怕自己的笔记变成欠组织（乱）的，以至于缺乏彼此的关联性，以及难以提取。

而显然还存在另一个事实，就是笔记一旦被组织，就很难被切换为另一种组织。这就使得该问题更加使人焦虑，不清楚到底该使用那种划分文件夹的办法，该怎么去利用标签，就没法进行初始化的组织，甚至没法开始写笔记。

经常有人教育说，如果觉得 Obsidian 门槛高，就不要先折腾其他的东西，先从写笔记开始。看似是很正常的，然而仔细一想，这是难以执行的。如果 Obsidian 没使得你的思维产生变化，让你有积极组织笔记的积极性，那么你是本来就有手机备忘录，电脑记事本的，既然之前没写过笔记，现在自然也不会写下去。

方法论给人以动力，而这种动力是隔绝于其本身的效用之外的。这也是人们为什么说颜值就是生产力，仪式感就是生产力。

回到问题本身。复杂的文件夹，目录…这些东西的本质是什么？

是笔记的一个属性。这看起来有点违反直觉。因为路径好像不是一个属性…或者说，起码和其他的属性不一样。你看，离开 Obsidian 之后，属性都失效了，目录还是可以一层层翻阅，即使在 Obsidian 内部，我可以在不同目录之间拖拽，其他的属性又没有这种功能性，而且 yaml 字段里也没有显示目录啊…

这说明路径不应该是一个常规的属性。

仔细想。上面所说的路径不是一个普通的属性的论据，本质上都有一个共同点。这是在用可以进行的操作，或者说与之关联的操作来定义一个属性是普通的，还是特殊的。

假设在 Obsidian 内部不可以用拖拽把笔记在不同目录之间移动，路径也仍然是一个属性。当然，你还可以把“文件列表”这个核心插件关掉，路径还是作为一个属性存在着。我第一次发现这点时觉得很奇怪，嘿，这是我最根本的视图，我在这组织文件，查找文件…不应该是默认功能吗？为什么可以关掉它？谁需要关掉它？

由此可见，属性的本质不变，而功能性根据其所关联的操作变化而变化。

现在想想看，Obsidian 之所以特殊，是因为什么。是双向链接…它为了支持双向链接，一定在软件设计上为双向链接提供了更多关联的操作…

我们有反向链接面板，有图谱，有 bases…如果只使用复杂的目录和标签，或许根本用不上这些。或者说起码原本的应用场景会被破坏。

所以到底我该把笔记放在哪里呢？也许就放在根目录就行了。不过为了和附件区分开，也可以选择放在一个 Notes 文件夹下，下面就不再有任何其他文件夹了。如果我需要组织笔记，需要让一个笔记可以通过某一个特征来提取，我就链接到对应的笔记。

在这个意义上，对于笔记已经不再存在“放在哪里”这个问题，而是被链接到了哪里，链接到了几篇笔记。这样做很明显起码在某个角度上具有好处，你的库看似不再组织良好，但却是更加“可阅读的”。

1 个赞
2

和楼主类似，我之前用过一段时间 PARA 分类方法，后来发现，如果不高频使用文件列表检索，其实完全没必要，于是直接简化为两个根目录的文件夹Projects和Resources（也就是PARA中的PR）

如果有固定用途或领域的条目，标记上标签或用双链汇总到一个导航页面完全足够替代文件列表了

不过偶尔还是需要逐条目浏览的，我一般配合vault explorer等gallery插件，看笔记封面检索更快一些

3

这是一个很好的补充设置。因为我觉得 Obsidian 主要是为纯文本设计的，如果有更多信息，利用上也很好。

4

路径确实是一个相对比较特殊的属性，虽然它和目录等其他属性一样都是为读者 检索内容 服务的。但这和实体书的摆放位置一样，读者对位置的搜索很多时候都是靠人力完成的。所以基于不同理论设计的摆放路径，会给用户带来不同的检索体验。一般来说比较常见的路径设计，要么是把主题相近的内容放在一起（分类法），要么就纯靠时间顺序或者题名字母顺序。

不过路径的设计和双链等其他方法也不冲突。比如我的15k+篇笔记，大多时候使用双链来管理，但同时也采用了几十个文件夹来分类存放，作为候补的检索使用。

5

我是只针对了自己的使用情况来说。如果库大到这种程度，加上文件夹的维度在某种程度上可能是相当必要的。还有一个情况就是高度结构化的数据，例如我为自己设计的桌游建立了一个库，这就不可能不使用大量的文件夹来区分各类卡牌了。

6

其实有时思想是转变了，但是该如何实现呢，我现在所有的笔记都在一个文件夹，创建笔记用templater模板化流程，规范每一篇笔记，用标签进行组织（少量的高质量的标签，一般笔记的第一个标签类似之前文件夹的作用），用dataview做出索引文件进行查询。就结果而言，我做到了完全不管笔记如何创建，放在哪里，如何组织，只需要关心笔记内容，减少复杂的文件夹嵌套，维护文件夹结构的心力

问题出在这个索引文件了，当我远离了维护文件夹结构，又开始维护索引文件，每当新创建了一个标签时，惦记着要是否创建一个索引目录

但仔细想想，似乎通过标签的组合我已经可以精确的找出一篇想要找到的笔记，这比用文件夹结构去查询笔记效率高的多，但我心里总是感觉空空的，或许是少了那种文件夹排的整整齐齐，结构嵌套完整的安全感？总是时不时想要看到自己的那些笔记，像一个贪财的国王守着自己的宝库一样。。。。

7

如果有人像我一样没事就要把库里的东西扔到库外就不会有这样的感受，因为必须得用文件夹结构，不可能不用 :joy:

8

单纯就这种检视自己的笔记的冲动，我个人认为并不是一件坏事。秩序井然的结构具有一种天然的惰性，是不利于使库实时反映拥有者的思想的。重点还是如何分配精力吧。

9

还是有这个需求的，这几天开发了两个obsidian插件，在obsidian内写了说明文档，要移到git中的时候发现，图片附件还要手动的去附件文件夹中去复制，辛亏我的图片命名都是以文档名称命名的，不然得一顿好找，所以我考虑要不要做一个分离文档和其附件到单独文件夹的插件，这样工作流的最后一环就完成了

10

双向链接和标签显然都不具备互操作性（Interoperability）。这的确是缺陷之一。

11

在我说到“笔记”的时候，我首先想到的是一些更加非结构化，非工程化的笔记内容和组织方式。这的确是我的疏忽，一个用语上的混淆。

12

如果你指的是移动或复制md文档及其附件到同一个文件夹的话，试试markdown export插件

13

哭死，我项目都拉好写了半天代码了，这功能不好做，文件出来附件不出来，还要考虑ob的双链引用的文件。。。。。我还是站在巨人的肩膀上吧

14

我只测试过markdown export能导出图片之类的附件，双链引用的md文件不知道能不能正常导出。

如果要写插件的话，拿file.file下面的api查附件和出链应该可以。不过思路简单，开发起来就很麻烦就是了 :cold_face:

15

递归查出链和图片不就好了。