上一篇讲了为什么需要知识库、为什么选 Obsidian。这篇来说更实际的问题：文件夹怎么分层才不乱。
## 两种极端，都不好用
做知识库最容易踩两个坑。
第一个：一个文件夹装所有。
只建一个「笔记」目录，所有文件往里扔。攒到第 100 篇的时候，找一个文件跟大海捞针差不多。文件名记得还好，不记得就只能全文搜索碰运气。
第二个：分类上瘾。
建了 8 层嵌套，每层十几个分类。一篇笔记放哪里要纠结 5 分钟——「这篇属于”技术/后端/数据库/MySQL/优化”还是”技术/后端/数据库/MySQL/运维”？」
纠结着纠结着就不想记了。
这两个问题的根源是一样的——把知识库当成了硬盘的文件系统。文件夹的核心作用是快速定位，不是完美分类。
文件夹只解决一件事：一个笔记放在唯一的位置。多分类的问题，交给标签和链接。
## 怎么搭
用 PARA 法的变体做骨架。Tiago Forte 的原始框架分四类。
Projects（项目）：进行中的事，有明确的结束时间。比如「Q3 技术调研」「618 活动方案」。做完就归档。
Areas（领域）：长期负责的范畴，没有截止日期。比如「后端开发」「产品设计」。
Resources（资源）：素材和参考。行业报告、技术方案、设计案例。
Archives（归档）：已完成的项目、不再活跃的领域。搬进来不用再维护，也不删。
我自己的知识库做了点调整——把 Resources 和 Areas 合并了。个人知识库里，领域知识和参考素材没有明确界限，硬分反而费劲。
“`
知识库/
├── 资料库/ ← Resources + Areas 合并
├── 笔记/ ← 读书/文章/课程笔记
├── 项目/ ← Projects
├── 公众号文章/ ← 输出端
└── 归档/ ← Archives
“`
## 每层放什么
### 资料库
知识库的核心。放技术文档、工具使用心得、配置备忘。子目录按领域分，每个领域控制在 5 个以下。
“`
资料库/
├── 编程/
├── 运维/
├── AI 与数据/
├── 设计与视觉/
└── 管理与方法论/
“`
### 笔记
放外部来的信息——读书笔记、文章摘录、课程记录。按来源分子目录。
“`
笔记/
├── 读书笔记/
├── 文章摘录/
└── 课程记录/
“`
笔记区不追求结构化。读了一篇文章，马上写几条要点——哪怕只有 3 行。过几天回看，觉得有价值就整理到资料库去。
### 项目
一个项目一个文件夹。做完就整体移到归档。
### 公众号文章
输出端的结构有点不同。按写作流程分成几个阶段。
“`
公众号文章/
├── 00_素材库/
├── 01_定位/
├── 02_初稿/
├── 03_已发布/
└── 总指挥自动归档/
“`
数字前缀用来控制 Obsidian 文件列表里的排列顺序。
## 命名规则
定好规矩就不用再想了。
用中文命名。个人知识库不需要考虑跨语言兼容，中文最直观。Docker、GitHub 这种专有名词除外。
数字前缀控制显示顺序。有流动性的目录用 00_01_02_。资料库里不需要，按字母序排就行。
嵌套不超过 3 层。一个笔记藏到第 4 层目录下，基本就不会再打开了。超过 3 层的，要么子目录提上来，要么改用标签和链接——后面会聊到。
## 几个常见问题
一篇笔记可以属于多个分类怎么办？
不用硬塞到单个文件夹。用标签和双向链接处理多分类。文件夹只解决「放在唯一位置」这个问题。
某个笔记现在没用，以后可能用，放哪里？
放到归档。归档就是保险箱。觉得以后可能用到的、暂时分不了类的、过时的，都往里扔。真用上了再拿出来。
要不要按时间建子目录？
不建议。找笔记的时候记得的是「什么内容」，不是「哪年哪月」。要看时间线，Obsidian 的文件修改时间排序就够了。
## 几点提醒
文件夹结构是长出来的，不是设计出来的。刚开始建 3-4 个顶层目录就够了。用一段时间觉得哪里不对劲再调整。Obsidian 移动文件很方便，不用担心改结构会丢东西。
半年左右看一下——有没有空的文件夹、有没有某个分类文件太多需要拆分的。平时不用管，定期清一次就行。
很多人不敢归档，觉得归档了就跟丢了一样。但归档的本质是降低认知负担，同时保留数据。东西还在，搜一下就能找到。
—
上一篇说了为什么要搭知识库、怎么开始。这篇说了文件夹怎么分层、怎么命名。系列还剩几个有意思的话题：双向链接、标签系统、模板、接入 AI。下一篇来聊双向链接——它不是 Obsidian 的噱头，是真的能改变记笔记方式的功能。