PARA 方法如何在Obsidian工作流中高效实践运用？

疑问解答
1

想了解下各位大佬对于 PARA 笔记法的实践运用，或者处于什么样的痛点对 PARA 进行了怎样的自定义的改造。

遇到的问题

实践运用 PARA 过程时主要有以下的问题出现，让人觉得很难受。

  • 没有收纳（inbox）文件夹，剪藏的文件入库需要先分类，分类时损耗精力。
  • 各文件夹之间允许流动，但是流动性太强，不好掌握。
  • 流动后若是拆分原有体系结构，就需要分类。若不拆分，就要冗余新建一个同名文件夹。
    • 比如构建数字花园这一项目，拆分或者总结领域知识就需要在 Area 中建立相关知识点。
    • 一边创作一边流动的时候，文件夹不拆分就需要在其他目录下冗余新建一个同名文件夹。
  • 创作时需要跨多个文件夹选取参考笔记，徒增认知负担。
  • 着眼入口太多，PAR 都需要关注，挤占工作记忆。
  • 分享的文章会分散在 PARA 多个文件夹下，没有专门留出笔记文件夹，分享比较麻烦。

预期的效果

  • 快速收集，轻分类
  • 项目驱动，重产出，方便分享
  • 创作比较容易进入心流状态，不会被文件夹切换打断
1 个赞
2
  • 哪里不舒服就改哪里。
  • 没有想要的文件夹就直接自己创建想要文件夹。
    • 没有inbox就创建个inbox呗
  • 不完全的直接使用rara，具体的分类还是要自己做的。
    • 比如仅仅把rara作为根目录的大文件夹使用，让根目录更加干净。
    • 具体的领域的内容自己分类好就好。把同领域的文件汇总整理好，而不是东一个西一个。
    • 不要分太细，追求简单，允许适当的模糊。
    • 建立归档/文档文件夹
  • 可以把当前需要的文件夹暂时全部直接放到项目文件夹里去，用完了就放回去。
3
  • 已经在爆改了，改着改着就剩个项目驱动的核心思想了 :joy:
  • 所有的内容临时放在Project中，之前就这么干过，然后越堆越多
  • 更好奇的是佬们PARA结合工作流的实践落地，想着借鉴一下
4

个人对于PARA方法进行了一定的改造：

已完成的方案

  • 在笔记库中设置了inbox文件夹和卡片文件夹
  • 对于PARA层级过多，以及自己对于事情分类需求并不强烈，将project和area两个文件夹合一来减少过多层级
  • 为了解决对于project关注不够密切，易于忘记的特点。使用了增量工作的方式解决一些不注重ddl的project。
  • 引入了spaced-repetition-recall插件，并自定义了一些卡片排期来保证不会忘记project

暂未解决的问题

  • 考虑为每个project建立目录，然后通过将特定的canvas设为主页解决问题，但不确定在主页中应呈现多少内容与层级
5

首先，感谢你的回复分享。

Inbox文件夹我也想的是单独设立，然后尝试砍掉了AR两个文件夹。

至于项目优先级的关注，你对于spaced-repetition-recall插件的用法对我有所启发，我只关注了复习回顾，没想到提醒的作用。

基于IPRA(inbox project resources archives)的结构，我尝试模拟思考了理想情况下你的笔记流转流程。

项目立项->其他文件夹开始针对性准备->项目完成->项目归档

项目是有短期明确截止日期的还好，应该可以完成。时间稍长，若没有充足动力就很难完成了。个人建议引入反馈机制。

不清楚你的行文习惯是怎样的，我如果这么改造的话。项目下会有一个单独的文件，比如：1.xx-Moc。这样项目moc文件就置顶显示了。

moc文件中可以进行头脑风暴与大纲梳理。项目文件的层级与顺序关系就可以直接在无序列表中体现出来。

多个项目的 moc 不方便查看。就贴标签或者引入Atlas文件夹，专门用于导览。

6

可以了解一下ACCESS方法，每个人的习惯和喜好是不同的，比如我看到inbox就很痛苦 :joy:

结合各种方法论，琢磨出适合自己的一套逻辑才是王道

我的结构：底层ACCESS + Tasks管零碎任务 + 建立专题+MOC管“项目”

7

我在每个项目文件夹下目前主要使用obsidian提供的白板(canvas)来进行管理，也考虑使用一些插件让打开文件夹时能自动跳转至导航用白板。
而对于较为长期的项目或是没有明确截止日期的项目，则依靠间隔重复进行提醒，同时可能会在每次间隔重复时考虑取消或暂缓一些难以或没有动力完成的项目，但有时依然会遗漏少量项目

8

有人提到ACCESS组织法了 :joy:

实际上我第一个尝试的方法就是ACCESS，为此写了一篇自己的实践与反思，详见： Obsidian文件夹体系构建-ACCESS笔记组织法。算是对于我卡片笔记以及系统性知识管理的萌芽。

实践下来除了没有inbox也有几点缺陷：

  1. calendar 太琐碎了，精细到每天个人感觉没什么价值，维护还很费时间精力
  2. extra source 使用场景太低（没有外部文献资源阅读批注的使用场景），但是这两个文件又隔断了文件的周期流转，感觉不流畅。
  3. Space 就变成了各种文件的堆积空间，好似没有一条主线串联

但是 Atlas 的思想我是学到了。这个文件夹下放置Dataview脚本以及Moc文件是不错的，相当于一个纵向切片。

9

你提及的使用白板进行管理，具体指的是将项目相关的文件作为卡片全部放进去嘛？那么很多个项目文件之间的顺序以及层级关系是怎么表示呢？

我个人之前使用白板尝试了两种方法

  1. 用线条连接，但是卡片一多，感觉这个行为就很费时间
  2. 不用线条，用卡片在白板中的位置，比如按照从左到右的顺序表示层级关系。但是阅读体验达不到想要的效果，白板卡片跳转到文件本身就不够流畅

另外白板的源文件并不是md，还有一个兼容性的问题需考虑。

10

我的做法：

不做dailynote的话calendar看似没什么用，但也可以简化作为定期复盘/总结/计划的区域，我的dailynote也不是每天都记，但是基本上每几周都会整理一下自己当前待办和一些计划，就可以放在calendar里，只要和时间强相关都都可以放进来。

extra我作为附属目录，模板、代码块、附件等等和obsidian的依赖文件都放进来，包括我前几天让AI写的插件的表情包目录也放在这里 新插件：快速插入表情包图片到Obsidian笔记中

source 我也没有外部文献阅读批注的场景，但偶尔也会有剪藏的需求，其实source就是我的剪藏目录

space内我是按照一个个专题组织，比如 财务管理（在其他app记账后的复盘）、个人资料（一些不敏感的账号密码、token等）、家庭设备（家庭nas路由网络宽带）、专项学习资料等。 当然我也看到有人在space里进行PARA

这里有一个细节，如果在space里管理工作项目，因为频繁使用也会导致入口较深，我的做法是把当前特别活跃的项目移动到根目录，加上@表示置顶，如果不那么频繁了就再放回去。 这样我的根目录常年保持 ACCESS6个再加上2-3个非常活跃的space。
然后在space里如有必要也可以做二级分类，比如我的 个人资料目录下设 家庭网络、云端服务等二级目录。

供参考。

11

我个人在使用白板时：

  • 使用canvas mindmap插件来加快制作canvas速度，以一种类思维导图的形式管理
  • 遇到不适合使用白板的场景时使用md文件作为目录
  • 使用一个单独的md文件辅助管理工作进度，用间隔重复来让自己看到文件
    但是在使用中如果项目文件过多依然会觉得难以管理，目前还没有找到更好的解决方案
12

异曲同工，你的很多想法实践我也这么干过。

Space 空间尝试 PARA，会导致文件层级太深，这问题我也遇到过。来回移动文件夹我属实没这个习惯，所以就没有尝试 Space+PARA了。

还有一点疑问，按照个人理解，ACCESS这种方法核心就是 Card文件的增多从而实现知识复利。不不知Card 文件夹你是如何使用的？card笔记来源是Space 和 Source嘛？

13

白板文件的维护需求真的很难受，比如你新增了一个项目文件，需要先移入白板，然后构建层级。为了一致性的需求，这是额外的投入。

另外编辑体验其实也不够丝滑，之前在canvas中操作感觉就是哪哪差一点的感受。

然后我就折腾Xmind，因为单就思维导图Xmind强于Ob canvas 太多了，折腾着最后还是返回了最简单的moc.md文件。

最理想的方案还是Ob的知识图谱能在项目文件增加双链的时候，自动生成类似目录一样的图谱图。然而目前Ob的知识图谱其实还是个鸡肋，要可用还有很长的优化路径。

14

space 我移动文件夹也不会很频繁，基本上几个月一次

card我主要用于“常见问题搜索”，比如写代码遇到不懂的，搜一下整理一下记录下来，然后记录上来源，然后内部按自己关注点二级分类，这个分类也不用很严格，主要还是依照标签索引，然后定期整理成长文发布

其实和source有一定的作用重复。只不过我的区别是：

source 一般是值得长期细细品读的内容，更偏向稍后阅读
card 更实用一些，一般是自己遇到问题解决掉，或者所思所想记录下来，主要来源 搜索引擎、AI和自己的脑袋瓜子

我的card来源不依赖其余目录，包括其他目录用的也都比较随性，主打一个和自己日常习惯相匹配

15

写代码、后端嘛？哈哈

Obsidian确实很适合程序员群体使用

16

不算程序员，只是会一点点python，全靠AI，写着玩

17

我是从ZK接入PARA的，PARA尽可能轻量并且只管理项目用。

然后PARA中的渐进归纳的流程我给舍弃掉了，只在ZK知识沉淀那边进行渐进归纳。所以就成了：P-管理项目，A-输出内容（相当于传统笔记文件夹+一些checklist之类的），R-原文存档（包含剪藏内容、文献原文等）A-存档项目

所以这个流程相当于限制了PAR之间的流转，尽可能轻量化，应该是很少会有你提到的这些问题，项目驱动+轻分类+重产出，例如A-输出内容里面的编程领域，输出完就可以一键同步到公众号或者其他博客平台。我这个倒是没有inbox，被ZK中的闪念笔记替代了

更详细的可以参考下我这篇： 结合 PARA 和 Zettelkasten 的工作流分享 - 经验分享 - Obsidian 中文论坛

不过… 这种结合我也是进行没多久目前感觉一切还ok，对你来说还得额外引入ZK… 所以还是仅供参考 :laughing:

1 个赞
18

没必要用别人的知识分类方法，自己设计一套自己迭代更新才更适合自己

19

主要是想借鉴参考下各种方法与实现，为迭代更新积累想法与灵感

20

我的方式：剪藏内容一个文件夹，自己创建的笔记一个文件夹。
比如最近在学车考驾驶证，则创建笔记[[P+学车考证]]，期间陆续剪藏了一些相关视频、网页，则在对应的剪藏页面中添加[[P+学车考证]]建立链接。
项目最后，无论考试通过或者失败放弃考证，文件名改成[[P-学车考证]]，代表运行中的project中减去学车考证这一项，这一过程就是archive的过程。
领域area操作方式一样。