个人知识怎么管理？用 Obsidian 一小时搭好基础框架

个人知识要长期可用，需要同时设计分类、标签、笔记结构和维护流程。这套方法以 Obsidian 为例，覆盖从日常归档到 AI 检索的数据准备。整理出干净的 Markdown 和字段，只是数据准备；具体用哪款 AI 工具接入、怎么摄取、怎么配置索引和权限，不在本文范围。

01 先解决一个根本问题：东西放在哪

很多人一上来就问：用 PARA 还是按学科分类？用文件夹还是标签？其实这些问题背后，是不同工具在回答不同问题。

PARA 是 Tiago Forte 提出的组织方法，把信息分成四类：Projects（项目）、Areas（领域）、Resources（资源）、Archives（归档）。项目是有明确目标、能完成的事，比如“写完这篇文章”；领域是需要长期维持的责任，比如健康、财务；资源是未来可能有用的主题，比如写作方法、人工智能；归档是前三类中已经不活跃的内容。

Forte 强调按可行动性组织，学科不是他的主要组织维度。这对需要围绕项目推进的人很实用，但它只是一种可行的方法。主题型学习、学术研究、人物关系、日记这些内容，未必适合完全按 PARA 放置。你可以保留 PARA 作为顶层结构，同时用其他方式建立主题网络。

比选分类法更重要的是理解工具分工。在 Obsidian 里，文件夹、属性、标签、链接、搜索各自解决不同问题：

• 文件夹回答“主要放在哪里”，适合少量顶层容器，比如 10 Projects、20 Areas
• 属性回答“这条笔记有什么稳定字段”，比如 status: draft、type: source、created: 2026-07-30
• 标签回答“它有什么横切状态或特征”，比如 #status/inbox、#type/meeting，适合跨文件夹聚合
• 链接回答“它与哪条具体知识有关”，比如 [[检索增强生成]]，并且要用一句话说明关系
• 搜索负责在不确定位置时找回内容，比如 tag:#status/inbox 或 [project:个人知识管理]（前提是笔记里存在 project 属性）

这套分工可以记成一句话：文件夹管去向，属性管字段，标签管横切状态，链接管具体关系，搜索负责找回。这是根据官方能力归纳出的低门槛方案，Obsidian 官方并未这样定义。

02 标签怎么用才不乱

标签是最容易用乱的工具。Obsidian 支持正文里写 #meeting，也支持在 YAML 属性里写 tags: 列表，还支持嵌套标签和标签搜索。但官方没有规定最佳数量，也不存在统一标准。

比较稳妥的做法是：基础框架阶段可先从 2—4 个稳定维度开始，每条笔记按需使用，发现真实检索需求后再增加。

常见的可用维度包括：

• 工作流状态：#status/inbox、#status/processing、#status/done
• 内容类型：#type/source、#type/meeting、#type/idea
• 来源/媒介：#source/book、#source/interview
• 主题：#topic/rag、#topic/knowledge-management

标签和属性、链接有明确区别。属性是键—值结构，status: draft 比 #draft 更明确，因为字段名表达了维度，适合筛选和排序。链接连接两个具体对象，语义来自链接周围的句子；标签只能说明“同组”，不能自动说明“支持、反驳、来自、用于”这些关系。

命名上建议统一一种语言和格式。英文可以全小写加连字符，中文直接用中文词。不要混用 AI、ai、人工智能 三套词。层级保持浅，可先从两层开始，比如 #status/draft；超过两层往往是在用标签重建文件夹树。

每周花几分钟看看标签列表，合并同义词，修正拼写变体，删除长期只出现一次且没有检索价值的标签。可以建一条“标签词表”笔记，记录首选词、弃用同义词、定义和示例。Obsidian 官方没有提供同义标签自动合并功能，需要人工治理。

03 第二大脑：从捕获到输出

Tiago Forte 把第二大脑的流程概括为 CODE：Capture（捕获）、Organize（整理）、Distill（提炼）、Express（表达）。捕获是只保存对自己有共鸣、可能有用的内容；整理是按当前项目和行动需要组织；提炼是让未来的自己能快速看出要点；表达是把知识用于交付物、决策或创作。输出是整个流程的目的。

Forte 还提出了渐进式总结：保存原文或原始资料，捕获有价值片段，之后在真实使用时加粗重点，再突出“重点中的重点”，对少量高价值笔记写自己的摘要，极少数内容进一步重组为作品。不要要求第一次保存时就写完精美摘要，每次使用时给笔记增加一点价值即可。

另一个社区方法是原子化笔记，由 Andy Matuschak 提出，主张一条笔记尽量围绕一件事，并尽可能完整地捕捉这件事，以便重用和建立连接。但原作者也承认没有清晰的判定线，过宽会模糊链接，过碎也会割裂网络。普通读者不需要把每一句都拆成卡片，更实用的判断是：标题能否完整表达一个问题或观点，笔记能否脱离原页面被理解，是否值得从两个以上上下文链接。

在 Obsidian 里，内部链接可以指向笔记、标题或块；反向链接能列出指向当前笔记的引用和未链接提及。创建链接时，用一句话说明关系，比如“这条证据支持 [[结论]]”或“应用到 [[项目]]”。只在“相关链接”下堆 20 个标题，未来很难理解。

04 一小时搭好个人知识库的基础框架

时间分配由本文设计；目标是一小时搭好个人知识库的基础框架，全部旧资料另行处理。以下时间估算面向已经安装 Obsidian、建好库并会基本新建和移动笔记的读者；完全新手需要另留安装和熟悉界面的时间。

0—10 分钟：建最小目录

00 Inbox
10 Projects
20 Areas
30 Resources
40 Archives
90 Templates

只建一层。PARA 只是起点，如果你已有稳定目录，可以保留原结构，只增加 Inbox 和 Archive。如果要处理旧笔记，先确认备份，再从 Obsidian 内小批量移动，排除 .obsidian 配置、附件、模板和正在使用的项目；移动后抽查链接和附件是否正常。不要无条件整体搬迁。

10—20 分钟：建两个模板

在 90 Templates 里建两个模板：

1. 资料笔记：标题、摘要、来源、日期、事实、摘录、我的判断、使用上下文
2. 观点笔记：一句话观点、依据、反例或适用条件、相关链接、下一步

启用官方 Templates 核心插件，设置模板文件夹为 90 Templates，用 {{title}} 和 {{date}} 填充基础字段。

20—30 分钟：定字段和少量标签

属性建议：type、status、created、updated、source。project、sensitivity 等字段可按需增加。

标签可先从这些开始：#status/inbox、#status/processing、#type/source、#type/idea，再加 2—3 个当前真正在用的主题。写一条“标签词表”笔记，规定语言和拼写。

30—45 分钟：做 3 条真实笔记

• 一条网页或书籍资料，写一句摘要、来源 URL、日期，明确区分摘录和个人判断
• 一条自己的观点，写清依据和适用条件
• 一条当前项目主页，说明目标和下一步

可先创建两个带上下文的链接，比如“这条资料用于支持 [[项目主页]] 中的某一判断”。

45—55 分钟：建立找回入口

在 Search 中运行两条查询：tag:#status/inbox、[project:项目名]。如果需要长期保存，可以启用 Bookmarks 核心插件后收藏对应搜索；不启用的话，记住或复制这两条查询即可。[project:项目名] 是属性查询，前提是笔记里存在 project 属性。

可选：创建一个 Bases 表格，显示 file.name、type、status、updated、source，筛选 status = inbox。Bases 是 Obsidian 官方核心插件，能读取笔记和 Properties 生成数据库式视图；笔记内容和 Properties 保存在本地 Markdown/YAML 中，独立视图定义可保存为 .base 文件或嵌入笔记。如果界面版本不一致或觉得复杂，跳过并用搜索替代，不影响基础框架成立。

55—60 分钟：写维护约定

每日可先从 2—5 分钟开始：只捕获真正有用的内容，补标题、来源、日期。

每周可先从 20—30 分钟开始：清空 Inbox，移到项目、领域或资源；合并标签同义词；补摘要和链接；归档完成项目；随机用 3 个真实问题测试是否找得到。

每月可选：检查敏感数据、重复资料、失效链接、过期结论。

以上所有数量和频率都是本文给初学者的启动值，可按资料量和使用场景调整。

05 为 AI 检索准备个人数据

现在很多人都在尝试把个人笔记接入 AI，让 AI 基于自己的资料回答问题。这背后常见的技术思路叫 RAG（Retrieval-Augmented Generation，检索增强生成）：先检索相关的外部资料，再把它们作为上下文交给生成模型。高质量检索上下文有可能提高答案相关性；如果系统保留并展示来源，也更便于追溯。但 RAG 不能消除错误，检索到过期资料或生成模型理解偏差，依然会导致答案出错。

个人能直接改善的是数据质量：清洗、结构、元数据、版本、切块和检索评估。

建议起步字段

---
type: source
status: inbox
created: 2026-07-30
updated: 2026-07-30
source: https://example.com/original
---

可按需加入同一组 YAML 的字段：author、project、summary、sensitivity、tags。summary 字段适合一句话摘要，长摘要放正文。这些字段是根据 RAG 工程实践归纳出的建议，Obsidian 并未强制要求。需要明确的是：仅在 YAML 中增加字段，不代表所用 AI/RAG 工具一定解析、索引、过滤或回传这些字段。如果所用工具会解析并随切块保留这些字段，它们可用于过滤、判断时效和展示来源；需要用真实查询确认字段确实进入检索结果。

正文固定分区，分离事实、摘录和观点

## 摘要
用自己的话说明内容及适用条件。

## 已核验事实
- 事实陈述。[来源 URL]

## 原文摘录
> 准确摘录，注明作者、页面或时间位置。

## 我的判断
- 个人观点、推断或待验证问题。

## 使用上下文
- 可用于哪个项目、决策或问题。

这样做能降低 AI 把个人猜测当外部事实的概率，但不能保证模型永不混淆。

粒度和切块：没有固定最佳参数

RAG 系统需要把文档切成小块进行检索。Microsoft 的 Azure AI Search 文档列出固定、结构感知、语义和组合切块，并明确最优重叠和大小取决于内容和用例。512 tokens、25% 重叠是某些产品文档中的起始建议，不能当作普适标准。

对个人笔记，更实用的原则是：优先用 Markdown 标题切分，让一个段落或小节回答一个相对完整的问题。太小会丢上下文，太大会混入多个主题。可先从 10—20 个自己真实会问的问题做检索测试，这是本文建议的启动值，可按测试结果调整。

去重和版本：同一来源保留一个主笔记

网页剪藏、摘要、摘录可以放同一笔记的不同分区，避免三份近重复内容同时进入索引。使用稳定来源 URL，必要时增加 source_id、version、updated。内容更新时替换主版本，把旧版本移入归档或标记 superseded_by。

不要仅按标题去重，同名可能不同内容，改标题也可能同源。结合来源 URL、内容指纹或人工判断。

隐私和脱敏：降低风险，但仍可能被重识别

向云端 AI 提交笔记前，删除不必要的身份信息、凭证、精确地址、健康和财务敏感信息。NIST（美国国家标准与技术研究院）的去标识报告指出：移除身份信息可以降低风险，但某些去标识数据仍可能被重新识别。脱敏范围包括正文、附件、文件名和元数据；代号只能降低直接识别，仍可能被关联识别。

具体操作建议：

• 不把密码、API Key、Cookie、身份证件、银行卡等写入知识库或提交 AI
• 删除不影响任务的姓名、电话、邮箱、精确地址、账号；必要时用稳定代号替代
• 个人笔记中包含的第三方信息，同样需要取得外发权利并做脱敏
• sensitivity 只是一种标记，不是权限控制。外部 AI 管道必须另设排除规则或默认拒绝策略，并用测试笔记验证；无法确认工具是否执行过滤时，不应接入含敏感信息的库
• 云端模型的数据保留、训练使用、地区和删除机制随服务变化，必须查当时条款

Markdown 的可移植性：更好，但不是零锁定

Obsidian 的笔记主体是本地 Markdown，Properties 以 YAML 等形式保存在 Markdown 文件中；Bases 读取这些字段生成视图，独立视图定义可保存为 .base 文件或嵌入笔记。CommonMark 将 Markdown 定义为用于结构化文档的纯文本格式，强调源文本可读性，同时指出不同实现长期存在分歧。

纯文本 Markdown 通常比封闭二进制格式更容易被多种工具和 AI 管道处理，但 Obsidian 特有的 Wikilinks、块链接（block links）等扩展语法不属于标准 Markdown，插件字段和附件路径也可能导致迁移损失。如果重视互操作，可以优先使用标准 Markdown 链接，定期抽样在其他编辑器中打开测试，保留附件并使用相对路径。

06 今天就能做的最小动作

如果你还没有任何系统，今天建一个 00 Inbox 文件夹，新建一条笔记，写下你最近收藏的一篇文章，补一句摘要、来源链接和日期。这就是开始。

已有笔记时，先根据当前痛点选一个动作：找不到就小批量归档并抽查；AI 检索不准就补字段、分区，再用真实问题测试。