颠覆 PARA 的传统文件夹方案

经验分享
1

起因

最近我想配一副新的眼镜。
为了汇总需要的资料（比如配智锐所需的参数），外加给自己大致定一个计划和DDL，我创建了一个新的项目笔记：[[260127_购买新的眼镜]]

如果按照 PARA 的方法论，现在应该把它放进 Project 文件夹，对吧？
但是我转念一想——何必非要创建在 Project 文件夹内呢？

反思

别忘了：
Tiago 至今还在用着他那（过时的）Evernote，他用文件夹来做 PARA 区分，是因为他只有文件夹能用，孱弱的印象笔记不支持更现代的方式。
就像 Zettelkasten 用复杂的编码来构建链接，是因为物理的纸片只能用这种方式。
我相信卢曼如果拥有现在的双链笔记，他会毫不犹豫地选择用属性和双链来构建卡片盒。

启发

所以，笔记随便放在哪里，只要添加对应的 #project 标签，或者 PARA: Project 属性，那么它就是可以视作一个项目。
同样，要归档也不用挪到 Archived 文件夹里，只需要设置成 PARA: Archived 即可。

PARA 需要挪文件夹，是因为这是它免受干扰的方式。
虽然在 OB 里移动一个笔记或者文件夹并不算什么大事儿，但终究会造成一些麻烦。

而且很多时候，这样的移动也会破坏笔记本身的聚集性，你需要把几个本来高度关联的项目拆得零零散散——仅仅因为其中一些已经完成了，而剩下的还在进行中。

在 Obsidian 里，我们有 Bases，只需要一个 Filter 条件就可以把所有归档的笔记都隐藏掉，既然如此，何必费心移动？

记住：面向目标去做笔记结构，不要囿于形式。

你不是为了“移动笔记到归档文件夹”而去移动，而是为了“在不想看到它们的时候可以不看到”。
那只要能达到这个过滤视野的结果，方法随你选。

而且，当你确实理解了PARA 的架构之后，甚至也不用局限在 PARA 这样的唯一属性。

你完全可以用单独的一个 archived 选框属性来代表归档，与此同时保持它之前的 type: project 属性，以此来表明它是个「归档的项目」。同时，也可以有「归档的资源」、「归档的领域」……等等。

type: [[project]]
archived: true

我们的属性是可以多重同时存在的，这就是属性要比文件夹优越的地方！

总结

总而言之，PARA 方法论本身有它的可取之处，也有它的局限。
对于那些认可 PARA 方法论的人而言，完全可以尝试突破它本身基于的陈旧软件带来的限制，用新技术来实现更好的效果 & 更无摩擦的工作流。

3 个赞
2

我最近正好也在重构我的 ob 库，也在迭代 para，正好简单聊几点：

  1. 我一直觉得文件夹也属于标签之一，是一种排他性标签。一个文件可以有 100 个#tag，但他只能存在于一个文件夹。

  2. 为什么我们需要文件夹？
    对于一部分人来说，身份是多重的，要做的事情很多很杂，注意力是很稀缺的，这种排他性对于保持专注是很重要的。

另外，文件夹不仅仅是分类，更是一种状态。

属性/标签是无限的：它代表内容（关于自媒体，关于 AI，关于知识管理……）。

文件夹是有限的：它代表生命周期（正在做，做完了，存起来）

如果我们的 ob 库里有很多笔记混在一起，全靠筛选，那太混乱了；而使用文件夹就会非常整洁，至少可以进行物理层面的降噪。

  1. 归档与聚集

归档并不会打断关联。

Obsidian 的强项恰恰在于：链接（双链）是永固的，与文件位置无关。

关于聚集，可以分为两类：

  • 一类是靠文件夹/标签/属性把文件放在一起，这是物理（位置）聚集。

  • 另一类是靠 MOC 或者双链把文件连接在一起，这是逻辑聚集。

归档移动的是文件的尸体（物理位置），留下来的是文件的灵魂（逻辑连接）。真正的关联是靠链接维持的，而不是靠离得近。

  1. 关于费心移动

一个项目做完了，把它移动到 archive 文件夹，这是一件很有仪式感的事情。它意味着这件事我搞定了，滚出我的视线。

特别是拖动到归档文件夹的那一刻，大脑获得了一次清理内存的快感。如果只是改个属性，文件还在原地，这种心理上的完结感会弱很多。

1 个赞
3

两个层面的东西。

分类应该和主题词去比较：分类，按对象某一维度属性的不重复划分，一个对象只能属于一个类；主题词，对对象不同方面属性的概括，一个对象可以有多个主题词。

一般来说文件夹天然地是分类的实现方式，标签是主题词的实现方式。不过也有的软件允许一个对象放到多个“文件夹”里，比如zotero。这种时候文件夹和标签就没什么区别了。

不过总的来说使用元信息中的属性都可以实现分类和主题词。所以在obsidian里有个属性就足够了。我自己搞文件夹划分更多是担心一个文件夹下几万个文件太卡（）。

4

嗷，来了！

关于文件夹

另外，文件夹不仅仅是分类，更是一种状态。
属性/标签是无限的：它代表内容（关于自媒体，关于 AI，关于知识管理……）。
文件夹是有限的：它代表生命周期（正在做，做完了，存起来）

「为什么我们需要文件夹」其实是一个很好的问题——

我们可以不要文件夹吗？可以。Kepano 就是全扔在几个大文件夹，不靠传统物理位置去做组织，只用链接和属性。

但我们大部分人还是需要文件夹，那基于文件夹的「唯一性」，问题就变成了——
「用文件夹来做什么？」

如果完全采用 PARA 的方法，相当于文件夹本身就只有“描述4种状态中的一种”这个功能了，在我的实践中，对于那种不是强“项目导向”的人来说，这种方法并不太实际，本来可以用文件夹做其他组织结构的，现在相当于就被占用了。

比如本来我把 AI 相关的内容都汇总在一个文件夹里，这是我对文件夹的“组织”用法：
Snipaste_2026-01-27_12-58-44

一旦接受了 PARA 作为文件夹的“用途”，那相当于要么要让位于它，要么得两层结构混用。

一个“AI视频生成”的资料放在 Resources/AI/AI视频生成，基于它做的实践项目放到 Projects/AI/AI视频生成、完成的项目放到 Archived/AI/AI视频生成……
这种方式会让我非常迷惑。

还是说，PARA 里移动到 Archived 里面之后就完全摊平了？ :thinking:

文件夹和属性

然后就涉及到另一个老生常谈的问题了，怎么去做「结构化的组织」。

比如上面这个 AI 文件夹，都用 parent: [[AI]] 来组织，其实也没问题的。

但那样还是要面临一个问题：笔记创建在哪里呢？
（因为这个物理属性终究逃不开）

反正都要选一个位置，我还是更喜欢把同类资料放在一起（物理聚集）。
Snipaste_2026-01-27_13-12-18

也因而更不喜欢这种物理聚集被破坏。

混乱和整洁

如果我们的 ob 库里有很多笔记混在一起，全靠筛选，那太混乱了；而使用文件夹就会非常整洁，至少可以进行物理层面的降噪。

这两种方法的效果其实也对应两种组织习惯。

比如我因为不爱用文件夹做状态管理，我的 Project 文件夹下就非常混乱，堆满了各种陈年旧项目——这当然是因为组织不善，但也是因为我确实不喜欢频繁移动文件夹 : (

Snipaste_2026-01-27_13-14-03
Snipaste_2026-01-27_13-14-03884×373 19.6 KB

而反过来说，我习惯用属性维护这些，我的 Bases 就可以获得比文件夹要更清晰、也具备更多信息量的视图：

Snipaste_2026-01-27_13-16-38
Snipaste_2026-01-27_13-16-38762×316 29.2 KB

把 Bases 放在Daily Note 里面，每天都能看到并做调整

而且因为 Bases 里可以按类别分组、按优先级或者截止日期排序，在大的项目管理层面来说，我觉得是要优于「在一个文件夹中查看进行中的项目」的。

外加我其实是个注意力很容易分散的人，会同时在多个不同领域来回切换项目，未归档项目可能有数十个：

Snipaste_2026-01-27_13-08-05
Snipaste_2026-01-27_13-08-05838×424 46.4 KB

这时候，快速通过筛选和数量限制，来批量对多个项目进行调整，就很方便了。

未归档指尚未完成或放弃，其中可能包括暂停的、进行中的、尚未开始的等不同情况。

基于我「不那么喜欢频繁做整理」的前提，对我来说成本越低的组织方式，就是越好的组织方式。

也因为我查看的方式是通过 Bases 这个透镜，所以实际笔记在文件夹里长啥样、分布于哪些不同的位置……也就不是问题了。
俗话说得好，眼不见为净 :sunglasses:

关于完成的仪式感

基于属性也可以很有仪式感 √

在“完成”一个项目的时候，会有弹窗提示——想要的话还可以加上音效（？）
并且在今天的 DailyNote 里回顾时，也能看到今天完成的项目：

Snipaste_2026-01-27_13-33-59
Snipaste_2026-01-27_13-33-59754×217 23.3 KB

成就感满满！

与此同时，它也和自己其他的好厚米们一起继续待在 Obsidain 文件夹里头。

Snipaste_2026-01-27_13-31-33
Snipaste_2026-01-27_13-31-33359×526 56.3 KB

至于「不把它移动到单独的文件夹，还是会在原地造成干扰」：
因为我现在90%的时候都是在 OB 里用搜索来定位笔记，所以只要在库内，它实际在哪个文件夹其实没有影响，挪开也无法降低干扰，留着亦不会增加效率。

2 个赞
5

写这个是因为 PARA 在《打造第二大脑》整本书里，几乎都是在用「4个基础文件夹」的方式去做划分和组织的。

所以很多人（包括我）在读完之后，都会先起手创建4个文件夹：
Snipaste_2026-01-27_13-36-44

但是我其实很少真的把这个给用起来，比如我的 YearlyGlance 插件和 EasyCopy 插件，它们的位置在 “OB 开发”文件夹里：
Snipaste_2026-01-27_13-37-24

我只是给这两个笔记加上了 #project 标签来表示“这是个项目”。

同时，它们可以和其他 OB 开发相关的笔记放在一起：
Snipaste_2026-01-27_13-38-27

如果按照原教旨的 PARA 方法——我得把这两个笔记给放进我的 Projects 文件夹里，这太不适用了。

相当于说，同样是“PARA”这种分类，用哪种手段去实现分类。
我因为想给文件夹一个我自己更舒服的结构（比如这个插件相关的资料、开发任务……都还是放在它自己的文件夹中），所以不喜欢以文件夹作为 PARA 分类的载体。

（然后因为文件夹里文件太多会卡，所以也会按自己的偏好去做多层文件结构，这就是题外话了）

1 个赞
6

在实际使用PARA的时候是容易出现很多问题，哪些属于AREA，哪些属于Project，然后Project里的task怎么说，要不要单独为Task建立一个笔记，如果task自己就是一个小的笔记是不是又会变成project。。。

7

说说我的观点，我也在用类PARA的方式搭建信息管理系统，但是现阶段还是同时在做打标或属性，及移动文件到对应文件夹分类的操作。因为我感觉按文件夹分类还是有意义的，文件夹的分类结构可以看做一种额外的检索渠道，要是在某次检索的时候，通过文件夹去检索能更快（跟base或者软件内搜索比），那么移动文件，按文件夹分类就是有意义的。个人认为检索的渠道不要怕多，只要能更快地帮助定位特定信息，都是有存在的必要的。
不过看了你的文章，我也受到一点启发了，想来可以写个通过属性及tags，按照特定规律自动化移动及分类文件的脚本，把要人工移动文件的操作自动化，那么就能更聚焦于内容创作了。

8

我用了几个月PARA后也弃用了，单纯是在我的工作流里没必要，大家确实应该结合自身的工作流考虑，很多模板和示例库并不是通解

在我的工作流里，文件夹基本只有「检索」和「功能性」两个用途，前者用于精细检索和不定期的维护，后者配合bases、模板这类用途；
然而这两个用途完全可以被上位替代掉，例如「检索」可结合链接、标签、搜索、快速切换、bases和一众卡片视图插件，「模板」有quickadd、templater、日记。

我库内的根目录只有Project和Collection两项，前者是自建的笔记，后者是外部的资料
虽然我偶尔会将排他性的笔记归到一类，例如某个时间段的项目，但其实这个Archive步骤并没什么作用

其实和Ryoo在简单谈谈标签的用法里说的类似，不要因为某个功能点局限了自己的工作流：

9

其实，从这里就能看出来，我们共同认可的一个观点：知识管理方法是因人而异的，重点是要适合自己，如果现有的方法不适合，那就借鉴一步迭代出适合的，这也是我正在做的事情。

另外，文件夹、标签和属性，他们是相互补充和协作的，并非割裂的。

对于你说的案例，有一个很大的问题，AI视频生成并不是一个项目，它是一个话题。projects必须是具体的，有截止日期的，有动词的。

如果是我，我会将AI视频生成放入我的PRKA体系中的AI Lab里，也就是Knowledge/AI Lab里，在这里存放通用的AI视频生成技术、工具、提示词。

暂时先写这么多吧

10

我们共同认可的一个观点：知识管理方法是因人而异的，重点是要适合自己，如果现有的方法不适合，那就借鉴一步迭代出适合的，这也是我正在做的事情。

是的，最开始我这篇文章其实也是源于一个临时的想法——我突然意识到， PARA 那种用文件夹分类的方式好像并不适合我，所以发出来希望能给其他人一些启发，如果也觉得不习惯文件夹，那就可以大胆抛弃，尝试新方法。

对于你说的案例，有一个很大的问题，AI视频生成 并不是一个项目，它是一个话题。projects必须是具体的，有截止日期的，有动词的。

是的，我指的是这个话题中的项目，比如「用 AI 生成一段动画视频」。
然后这个项目的项目笔记放在哪里，就成了一个新问题。

我去拜读一下 PRKA！
（果然大家都会基于 PARA 去做一些自己的改造hhh）