从文件夹到知识库：我如何让笔记真正为我所用

系列文章：AI 驱动的知识管理——第 1 篇，共 9 篇

文件夹陷阱

我曾经是 OneNote 的重度用户，用了很多年。在当时，它对我来说非常完美。我在笔记本里嵌套了分区，分区里又嵌套分区，还用颜色编码精心维护。当我需要什么东西时，我靠记忆在自己搭建的层级结构中导航。只要我还记得东西放在哪里，而且信息恰好能归入某一个类别，这套方法就能用。

但信息往往不只属于一个类别。这很令人沮丧，但我忍了。

一条关于 API 认证模式的笔记，应该放在"安全"下面还是"后端"下面，还是"项目 Beta"下面？在文件夹系统中，你只能选一个，然后祈祷六个月后还能记得自己选了哪个。或者你复制一份。或者你创建一个快捷方式。每一种方案都是在为一个根本问题打补丁——文件夹把单一的组织维度强加在了本身存在于多个维度上的信息上。

文件夹是我们大多数人一直以来整理东西的方式。在电脑上、在邮件里、在脑子里。这感觉就像是处理信息的天然方式。

标签、属性，以及连接之网

当我迁移到 Obsidian 时，我把旧习惯也带了过来。我的第一个知识库（vault）看起来就像我的 OneNote 笔记本：深层的文件夹树，精心分类。Obsidian 是一个更好的工具，但我用的方式和以前一样。它不过是一个界面更漂亮的文件柜。

转变始于我偶然接触到一个理念：用标签和前置属性（front matter properties）来组织笔记，而不是用文件夹。Obsidian 支持在每条笔记顶部放一个 YAML 块，用来定义结构化的元数据：标签、与其他笔记的关系、来源、状态。当然，Obsidian 把这些都做成了友好的 UI，你不需要直接处理原始配置。与其把笔记放进一个叫"安全"的文件夹，不如给它打上 knowledge/security 标签，同时也打上 knowledge/backend 标签，再链接到项目 Beta。这条笔记就能同时存在于多个上下文中，而无需重复。

更重要的是，我开始使用关系属性——up 表示上级笔记，sibling 表示横向关联，source 表示参考来源。这在笔记之间创建了一张显式连接的网络，这些连接独立于文件在磁盘上的物理位置。物理位置变得次要了。意义在元数据之中。

我至今仍然手动给每条笔记打标签。我对此近乎偏执。但这个当时看起来像是额外负担的习惯，后来被证明是后续一切的基础。

突破知识库的边界

一旦我内化了"连接比位置更重要"这个理念，一个新的摩擦点就变得显而易见：Obsidian 的知识库边界。Obsidian 的知识库（vault）是这样一个概念：用一个顶层根文件夹来存放所有的 Markdown 文件，也就是你的笔记文件。在知识库内部，一切都是互相链接、可发现的。在外部，什么都不相连。我的代码项目不在里面，办公文档不在里面，参考用的 PDF 也不在里面。知识库是一座组织得更好的孤岛，但它终归还是一座孤岛。

这一点是在和一位同事的对话中顿悟的。他试过 Obsidian 但没坚持下来，因为他真正的工作内容并不在知识库里。那次对话促使我开发了 FolderTether Obsidian 插件。它在笔记和文件系统中任何目录之间创建了一个双向链接。在 Obsidian 中，点一下就能在 Finder 中打开关联的文件夹。在 Finder 中，目录里的一个 .url 文件可以直接在 Obsidian 中打开对应的笔记。知识库不再是一个封闭的花园，而是变成了你整个数字工作空间的导航索引。

这是一个小工具，但它完成了我思考笔记方式的一次转变。关于项目 Beta 的笔记不需要放在"项目"文件夹里。它甚至不需要在项目文件附近。它只需要和它们有一条连接。把我从文件夹带向标签的那个原则，现在延伸到了知识库本身之外：物理位置是次要的，关系才是关键。

而这对 AI 智能体（Agent）也很重要。当 Claude Code 查询我的知识库时，它可以发现关于项目的笔记，然后顺着 linked_dir 属性找到实际的项目目录，而不需要我告诉它东西在哪里。知识库不仅成为了我的索引，也成为了任何能读取 Markdown 和跟踪链接的工具的索引。

当良好的组织仍然不够时

大多数人止步于此，说实话，我也在这个阶段停了好一阵子。标签和链接确实是对文件夹的实质性改进。你可以按主题查找、追踪思路之间的连接，Obsidian 的图谱视图（Graph View）还能给你一张所有内容关联的可视化地图。作为个人知识管理系统，它很不错。对于几百条笔记，它很棒。

但到了几千条笔记的规模，它会以另一种方式崩溃。

"规模化"之后的问题不再是组织，而是检索。你可以把标签打得完美无缺，但仍然找不到你需要的东西——因为你搜索的是一个概念，而你的笔记用了不同的措辞。搜索"认证"（authentication），你不会找到那条你写的关于"会话令牌管理"（session token management）或"登录安全"（login security）的笔记。大多数人会觉得它们说的是同一件事。关键词搜索找的是字符串匹配，它不理解含义。

这就是旅程再次转折的地方。这次转折发生在我开始接触 AI 并实现 RAG（Retrieval Augmented Generation，检索增强生成）之后。语义搜索基于向量（含义的数字化表示），搜索是根据相似性而非精确文本匹配来进行的。你问"我该如何处理用户认证？"，它会返回关于会话令牌、OAuth 流程和登录安全的笔记——因为它理解这些概念是相关的，即使它们没有共同的关键词。

一旦你体验过语义搜索，关键词搜索就像是按封面颜色来找书一样。

看见思路之间的连接

但即使是语义搜索也有它的天花板。虽然它能找到相关文档，但它不理解文档之间的关系。它能告诉你有五条笔记都和"AI"相关，但它无法告诉你其中两条描述的是同一个 LLM 提供商，一条引用了一个已经不再是最先进的模型，或者三条写的是同一个智能体框架（Agent Framework）。

这就是知识图谱（Knowledge Graph）的作用。知识图谱不是把笔记当作恰好匹配查询的孤立文档来处理，而是提取实体以及它们之间的关系。它构建出一种反映信息实际连接方式的结构。你不再问"哪些文档匹配？"，而是开始问"这些想法之间有什么关系？"、"哪些项目使用了这项技术？"、"我还写过关于这个工具的哪些内容？"

知识图谱不是替代搜索，而是在搜索之上叠加了一层。语义搜索找到相关笔记；知识图谱理解它们之间的连接。

向你的笔记提问，获得回答

我写这个系列的原因，是为了展示当你把上述所有这些与像 Claude Code 这样的 AI 智能体结合起来时会发生什么。

整体设置是这样的：Obsidian 存储笔记。语义索引使它们可以按含义搜索。知识图谱映射实体之间的关系。而 AI 坐在最顶层，接收你的问题，从这三个层面检索相关上下文，然后生成一个带有指向你实际笔记的引用的回答。

这就是把 RAG 应用到你自己的知识库上。你用自然语言提出一个问题。系统从你的笔记中检索相关上下文。模型基于你实际写过的内容生成回答，并附上源笔记的链接，让你可以验证并深入了解。

对于个人笔记来说，这听起来像是太多基础设施了。如果你只有五十条关于食谱和旅行计划的笔记，确实如此。但如果你有多年积累的跨越项目、研究、决策和创意的知识，它会改变你笔记的用途。而作为一个项目和想法经常横跨个人和职业界限的人，有一种方法能连接和查询所有这些内容，是一个真正的质变。

我并没有事先规划这条路线。我没有某天坐下来决定要搭建一个知识管理流水线。我只是从把笔记从 OneNote 迁出开始。然后对文件夹感到不满。然后发现了标签。然后撞上了关键词搜索的瓶颈。每一步都解决了上一步暴露出来的问题。而事后来看，每一步都在为下一步打基础。

我在时间节点上也是幸运的。如果我不是两年前而是两年后才做这些重组工作，AI 工具会存在，但我的笔记不会为它们准备好。那些标签、关系、结构化的笔记属性——我在 AI 智能体成为工作流一部分之前所做的所有手动工作——恰恰是现在让笔记能被 AI 智能体消费的原因。教训是：投资于信息组织方式，会以你当时无法预测的方式获得回报。

下一篇

这是关于构建 AI 驱动的知识管理系统的九篇系列文章中的第一篇。下一篇将专门讨论 Obsidian——不是作为一个笔记应用，而是作为一个知识平台——以及为什么磁盘上的 Markdown 文件竟然是上述一切的理想基础。

本文是"AI 驱动的知识管理"系列的一部分。下一篇：Obsidian 作为知识平台。