我在 Obsidian 里建了 200 多条笔记后，终于摸清了 PARA 的正确打开方式
一只阿木木约 11 分钟上篇文章我用架构图讲清了 CODE 和 PARA 的关系。评论区最集中的问题是：
"图我看懂了，但真正上手的时候还是分不清：这条笔记到底该放 Projects 还是 Areas？"
"PARA 四个文件夹建好了，但二级目录怎么建？建多细？"
"我按 PARA 建了目录，结果一周后又乱了，跟没建一样。"
这些问题我全都踩过。
说实话，PARA 的概念五分钟就能理解，但真正的难点在于"落地的前两周"——你会不断遇到分不清、放不对、改来改去的挫败感。
今天这篇文章，我把自己从"建好 PARA 目录"到"真正用起来"之间踩过的所有坑、摸索出的所有规则，全部摊开来讲。
不讲理论了。全是实操、截图、模板、决策树。看完你可以直接打开 Obsidian 动手。
一、先看"案发现场"：我最初的 PARA 长什么样
在讲"正确姿势"之前，我想先展示我最初的错误版本，因为你大概率会犯同样的问题。
我第一版的 PARA（反面教材）
Vault/
├── 1-Projects/
│ ├── 工作/
│ │ ├── 后端开发/
│ │ │ ├── Java/
│ │ │ │ ├── Spring/
│ │ │ │ │ ├── SpringBoot/
│ │ │ │ │ └── SpringCloud/
│ │ │ │ └── JVM/
│ │ │ └── Go/
│ │ ├── 数据库/
│ │ │ ├── MySQL/
│ │ │ └── Redis/
│ │ └── 产品/
│ │ └── 竞品分析/
│ └── 个人/
│ ├── 写作/
│ └── 健身/
│
├── 2-Areas/
│ └── （空的，不知道放什么）
│
├── 3-Resources/
│ └── 收藏/
│ └── （把微信收藏全倒进来了，200多条未整理）
│
└── 4-Archives/
└── （空的，什么都舍不得归档）
问题清单：
用了一周我就崩了——找东西要点五六层目录，跟没整理一样。
后来我推翻重来，反复调整了三次，才摸到了 PARA 的"正确颗粒度"。
二、PARA 最关键的一个判断：四层之间的边界
PARA 之所以难落地，核心难点就一个：Projects 和 Areas 分不清。
我设计了一棵"决策树"，现在每条笔记进来我都跑一遍这棵树，三个问题就能定位：
一条新笔记/新资料进来了
│
▼
┌──────────────────┐
│ 问题1： │
│ 它跟我"正在做的 │
│ 某个具体任务" │
│ 有关吗？ │
└────────┬──────────┘
│
┌──────┴──────┐
▼ ▼
YES NO
│ │
▼ ▼
Projects ┌──────────────────┐
（放到对应 │ 问题2： │
项目文件夹） │ 它属于我"长期负责 │
│ 或长期关注的领域" │
│ 吗？ │
└────────┬──────────┘
│
┌──────┴──────┐
▼ ▼
YES NO
│ │
▼ ▼
Areas ┌──────────────────┐
（放到对应 │ 问题3： │
领域文件夹） │ 它有参考价值吗？ │
│ 未来可能用到吗？ │
└────────┬──────────┘
│
┌──────┴──────┐
▼ ▼
YES NO
│ │
▼ ▼
Resources 🗑️ 删掉
（放到对应 （对，删掉。
资源文件夹） 不是所有信息
都值得留。）
我举四个真实例子，帮你跑一遍这棵树：
例1：一篇"Redis 分布式锁最佳实践"的文章
问题1：跟我正在做的具体任务有关吗？ → 我这周正好在修一个跟分布式锁相关的线上 Bug。有关。 ✅ 放到 Projects/订单超卖修复/
如果我不是在修这个 Bug，而只是刷技术社区看到的呢？
问题1：无关（我现在没有分布式锁的任务）。 问题2：属于我长期负责的领域吗？→ 我是后端开发，分布式是我的能力范围。属于。 ✅ 放到 Areas/后端架构/
同一篇文章，在不同时间节点，可以放在不同的层。这就是 PARA 的灵活之处。
例2：团队里同事分享了一份"B端产品设计规范"
问题1：跟我正在做的任务有关吗？→ 我现在没有做 B端产品设计。无关。 问题2：属于我长��关注的领域吗？→ 我偶尔要写 PRD、做产品分析，但不是核心职责。不太属于。 问题3：有参考价值吗？→ 以后可能用到。有。 ✅ 放到 Resources/产品设计参考/
例3：刷到一篇"2019年小程序增长案例"
问题1：无关。 问题2：不属于。 问题3：有参考价值吗？→ 2019年的案例，数据已经过时了。价值不大。 ✅ 🗑️ 直接删掉。
这是 PARA 最容易被忽视的功能：它自带一个"过滤器"，帮你拒绝低质量信息。
例4：去年做的竞品分析项目
这个项目已经结束了，交付物已经提交了。 ✅ 整个文件夹移到 Archives/[2024Q1]竞品分析V1/
Archives 不是垃圾桶，是冷库。数据还在，只是不出现在你的日常视野里。
什么时候会再用到？ 下次做竞品分析的时候，去 Archives 里搜一下，把有价值的部分"激活"到新的 Projects 文件夹里。
三、我现在的 Obsidian 目录结构（第三版，终于稳定）
经过三次推翻重建，我现在用的目录结构是这样的：
Vault/
│
├── 0-Inbox/
│ └── 快速捕获.md ← 唯一入口，所有碎片先到这里
│
├── 1-Projects/
│ ├── P-第二大脑系列文章/ ← 当前正在写的系列
│ │ ├── 01-开篇.md
│ │ ├── 02-架构图.md
│ │ ├── 03-PARA实操.md ← 就是这篇文章
│ │ ├── 素材收集.md
│ │ └── 选题规划.md
│ │
│ ├── P-订单系统重构/
│ │ ├── 技术方案v2.md
│ │ ├── 踩坑日志.md
│ │ └── 上线CheckList.md
│ │
│ └── P-Q2个人OKR/
│ ├── O1-技术深度.md
│ └── O2-影响力建设.md
│
├── 2-Areas/
│ ├── A-后端技术/
│ │ ├── 分布式系统原则.md
│ │ ├── MySQL调优清单.md
│ │ ├── Redis使用规范.md
│ │ └── 代码Review要点.md
│ │
│ ├── A-产品思维/
│ │ ├── 需求分析框架.md
│ │ ├── 用户故事写法.md
│ │ └── 竞品分析模板.md
│ │
│ ├── A-数据与增长/
│ │ ├── RFM模型笔记.md
│ │ ├── 漏斗分析框架.md
│ │ └── AB测试规范.md
│ │
│ ├── A-写作与表达/
│ │ ├── 公众号写作SOP.md
│ │ └── 技术博客模板.md
│ │
│ └── A-职业发展/
│ ├── 述职素材库.md
│ ├── 晋升标准笔记.md
│ └── 1v1沟通记录.md
│
├── 3-Resources/
│ ├── R-读书笔记/
│ │ ├── 打造第二大脑.md
│ │ ├── 卡片笔记写作法.md
│ │ └── 深度工作.md
│ │
│ ├── R-AI工具库/
│ │ ├── GPT提示词收集.md
│ │ ├── Cursor使用技巧.md
│ │ └── AI编程工作流.md
│ │
│ ├── R-优秀案例/
│ │ ├── 增长案例合集.md
│ │ └── 技术架构案例.md
│ │
│ └── R-工具与效率/
│ ├── Obsidian插件清单.md
│ ├── Git工作流.md
│ └── Mac效率工具.md
│
├── 4-Archives/
│ ├── [2024Q1]竞品分析V1/
│ ├── [2023]年终述职/
│ ├── [2023]用户中心重构/
│ └── [暂停]播客计划/
│
└── Templates/
├── tpl-项目主页.md
├── tpl-读书笔记.md
├── tpl-会议纪要.md
├── tpl-踩坑记录.md
└── tpl-每周回顾.md
四、六条命名规则（别小看，这决定了你三个月后能不能找到东西）
一个知识库能不能长期运转，30% 取决于目录结构，70% 取决于命名规范。
以下是我反复调整后沉淀下来的六条规则：
规则1：一级文件夹用数字前缀排序
0-Inbox
1-Projects
2-Areas
3-Resources
4-Archives
为什么？ Obsidian 默认按字母排序。加数字前缀后，目录始终保持"从热到冷"的固定顺序，打开 Vault 第一眼看到的永远是 Inbox 和 Projects。
规则2：二级文件夹加"类型前缀"
Projects 下用 P- 前缀： P-订单系统重构
Areas 下用 A- 前缀： A-后端技术
Resources 下用 R- 前缀： R-读书笔记
Archives 下用时间标记： [2024Q1]竞品分析V1
为什么？ 当你用 Obsidian 的全局搜索或快速切换（Ctrl+O）时，输入 P- 就能只看到所有项目，输入 A- 就能只看到所有领域。这是一个微小但极其实用的效率细节。
规则3：Projects 文件夹名 = 动宾短语
✅ P-订单系统重构
✅ P-第二大脑系列文章
✅ P-Q2用户分层营销
❌ P-工作
❌ P-学习
❌ P-杂项
为什么？ 项目必须有明确的"交付物"。如果你的文件夹名字是"工作"或"学习"这种模糊词汇，说明它不是一个项目，很可能是一个领域（应该放 Areas）。
判断标准：这个事情能不能被"完成"？
"订单系统重构"——能完成 ✅ → Projects "后端技术"——永远不会"完成" ❌ → Areas
规则4：Areas 文件夹名 = 名词短语（你的"能力/责任标签"）
✅ A-后端技术
✅ A-产品思维
✅ A-写作与表达
✅ A-职业发展
❌ A-学习Spring
❌ A-写博客
为什么？ Areas 代表你长期关注和维护的"领域"。它应该像你简历上的"技能标签"，而不是一个具体任务。
检验方法：把你的 Areas 列出来，是不是像一张"个人能力雷达图"的维度？ 如果是，说明你分对了。
规则5：笔记文件名 = 能被搜索到的"自然语言"
✅ 分布式系统原则.md
✅ Redis分布式锁踩坑记录.md
✅ RFM模型在电商场景的适配方案.md
❌ 笔记01.md
❌ 2024-03-15.md（除非是日记）
❌ 未命名.md
为什么？ 三个月后你找这条笔记时，不会记得它叫"笔记01"，但你会搜"分布式锁"或"RFM"。文件名本身就是最好的搜索索引。
规则6：Archives 文件夹名 = 时间标记 + 项目名
✅ [2024Q1]竞品分析V1
✅ [2023]年终述职
✅ [暂停]播客计划
为什么？ 当你的 Archives 越积越多时，时间标记能让你快速定位"那是什么时候做的"，比搜索效率高很多。[暂停] 前缀则标记"不是完成了，只是暂时搁置"，以后可能重启。
五、三个高频纠结场景及处理方案
规则讲完了，但我知道你真正上手的时候，最折磨人的是那些**"怎么都分不清"**的边界情况。
以下三个是我遇到频率最高的，以及我最终的处理方案：
纠结1：同一条笔记，既跟当前项目有关，又属于长期领域
场景：
我在做"订单系统重构"项目时，写了一条"分布式事务的最佳实践"笔记。这条笔记既服务于当前项目，也是我"后端技术"领域的长期积累。放 Projects 还是 Areas？
我的方案：项目期间放 Projects，项目结束后"复制精华"到 Areas。
具体操作：
项目进行中 → 放在 P-订单系统重构/分布式事务实践.md项目结束后 → 做一次"项目收尾操作"： 整个项目文件夹移到 Archives 从中提炼出有长期复用价值的内容，复制（不是移动）一条精华版到 A-后端技术/分布式事务原则.md
程序员类比：项目代码在 feature branch 里跑，验证通过的通用逻辑 merge 回 main branch。
纠结2："健身"是 Projects 还是 Areas？
场景：
我想开始健身，建了个"健身"文件夹。但健身这件事没有明确的截止日期，它不是一个"项目"吧？可是我现在确实在"做"这件事啊……
我的方案：看你给它定义的粒度。
如果你只是"长期保持运动习惯" → Areas： A-健康/如果你有一个具体目标，比如"3个月减脂10斤"或"跑完一次半马" → Projects： P-3个月减脂计划/
判断公式：有没有明确的完成标准？
有 → Projects 没有 → Areas
纠结3：一篇收藏的文章，现在分不清有没有用
场景：
看到一篇文章，觉得"好像有点意思"，但说不清楚将来什么时候会用到。
我的方案：执行"两步存储法"。
第一步：先放 Inbox，不要纠结分类。
在 0-Inbox/快速捕获.md 里写一条：
- [ ] [文章标题](链接)
- 一句话说明为什么存：__________
- 可能跟哪个项目/领域相关：__________
第二步：每周清 Inbox 时做决定。
一周后再看这条记录：
如果你已经在某个项目中用到了 → 移到对应 Projects 如果它跟某个长期领域相关 → 移到 Areas 或 Resources 如果一周后你看到它完全想不起来为什么存 → 删掉
核心原则：不要在"收集的那一刻"做分类决策。收集和整理是两个独立的动作，在不同的时间完成。
程序员类比：写代码的时候先写 TODO，重构的时候再处理。不要边写功能边重构，会精神分裂。
六、我的四个 Obsidian 笔记模板（可以直接复制）
为了减少每次新建笔记时的决策成本，我为最高频的四个场景做了模板。
在 Obsidian 里，把这些文件放在 Templates/ 文件夹，然后用 Obsidian 自带的"模板"核心插件一键插入即可。
模板1：项目主页（tpl-项目主页.md）
# {{title}}
## 项目信息
- **目标**：一句话描述这个项目要交付什么
- **截止日期**：YYYY-MM-DD
- **状态**：🟢进行中 / 🟡暂停 / 🔴已完成
- **关联领域**：[[A-xxx]]
## 核心产出物
- [ ] 产出物1
- [ ] 产出物2
## 下一步行动（动词开头）
- [ ]
## 参考资料
-
## 踩坑与经验
-
## 项目收尾清单（完成后勾选）
- [ ] 交付物已提交
- [ ] 关键经验已提炼到 Areas
- [ ] 整个文件夹已移到 Archives
模板2：读书笔记（tpl-读书笔记.md）
# 《{{title}}》读书笔记
## 基本信息
- **作者**：
- **阅读日期**：{{date}}
- **推荐指数**：⭐⭐⭐⭐⭐
- **一句话总结**：
## 核心概念（用自己的话写）
### 概念1：
- 原文要点：
- 我的理解：
- 我能怎么用：
### 概念2：
- 原文要点：
- 我的理解：
- 我能怎么用：
## 金句摘录
>
## 行动清单（读完这本书我要做什么）
- [ ]
## 关联笔记
- [[]]
模板3：会议纪要 / 沟通记录（tpl-会议纪要.md）
# {{title}} - 会议纪要
## 会议信息
- **日期**：{{date}}
- **参会人**：
- **关联项目**：[[P-xxx]]
## 讨论要点
1.
2.
3.
## 决策记录（重要！）
| 决策内容 | 决策人 | 决策原因 |
|---------|-------|---------|
| | | |
## 下一步行动
| 行动项 | 负责人 | 截止日期 |
|-------|-------|---------|
| | | |
## 我的思考（私人备注）
-
为什么"决策记录"要单独列？
因为三个月后你复盘的时候，需要的不是"讨论了什么"，而是"当时为什么做了这个决定"。这在述职和项目复盘中价值巨大。
模板4：踩坑记录 / 经验卡（tpl-踩坑记录.md）
# {{title}}
## 场景描述
- **什么时候**：
- **在做什么**：
- **遇到了什么问题**：
## 原因分析
- **表面原因**：
- **根本原因**：
## 解决方案
-
## 可复用的规则（一句话）
> 下次遇到___的时候，应该___。
## 关联笔记
- [[]]
## 标签
#踩坑 #{{领域标签}}
这个模板是整个知识库里复利最高的笔记类型。
每一条踩坑记录，都是你用时间和错误换来的"原则"。积累50条，你就拥有了一本自己写的"避坑手册"。
七、我的真实进度（第三周的诚实汇报）
按照这个系列"全程公开"的原则，汇报一下我的 Obsidian 库现在的真实状态：
关键感受：
笔记从200多条（乱的）变成80条（有序的），数量少了，但可用性反而提高了。
这就像重构代码一样——代码行数减少了，但可读性、可维护性、可复用性全部提升。
八、给你的"本周行动清单"（最小启动版）
如果你看到这里，我强烈建议你现在就打开 Obsidian，花30分钟完成以下动作：
第一步（5分钟）：建目录
创建 5 个一级文件夹：
0-Inbox / 1-Projects / 2-Areas / 3-Resources / 4-Archives
再建一个 Templates 文件夹
第二步（10分钟）：定义你的 Projects 和 Areas
问自己：
- 我现在手头正在做的"有截止日期的事"有哪些？→ 各建一个 P- 文件夹
- 我长期关注和负责的"领域"有哪些？→ 各建一个 A- 文件夹
（总共不要超过 3个 Projects + 5个 Areas，贪多必乱）
第三步（10分钟）：把模板抄进去
把上面4个模板复制到 Templates 文件夹
在 Obsidian 设置 → 核心插件 → 开启"模板"插件 → 设置模板文件夹为 Templates
第四步（5分钟）：写第一条 Inbox
打开 0-Inbox/快速捕获.md
把你现在脑子里的一个想法、一个待办、一条最近看到的有用信息写进去
格式随意，一句话就行
完成这四步，你的第二大脑就有了第一个心跳。
写在最后
今天这篇是整个系列中"最工程化"的一篇。没有故事，没有感悟，全是结构、规则和模板。
但我认为这恰恰是知识管理最核心的部分——不是灵感，是工程。不是天赋，是规范。
程序员都知道一句话：
"代码是给人读的，顺便能被机器执行。"
知识库也一样：
笔记是给未来的自己读的，顺便记录了当下的思考。
如果你现在花30分钟建好这套结构，三个月后的你会感谢今天的自己。