真正适配 AI 的笔记系统
TL;DR
十年的笔记锁在 OneNote 里,然后切换到 Markdown 文件,我以为这是为了可移植性。结果发现这关乎更重要的事情:Markdown 的纯文本、嵌入式元数据和显式关系的组合,使其成为 AI 智能体处理你知识的理想基础。那些界面精美的云端工具押错了宝。这个看起来无聊的"文件存磁盘"方案赢了。
我当了很长时间的 Microsoft OneNote 用户。超过十年。我甚至无法想象在那段时间里积累了多少笔记——会议记录、项目研究、代码片段、随机想法。十年的思考,存储在微软服务器上的专有格式中。
作为一名开发者,我知道良好数据管理的原则:将内容和配置保存在同一个文件中。保持可移植性。不要让工具绑架你的数据。我知道这个原则。我在代码中践行它。然后我在自己的笔记上完全忽视了它——超过十年。
我最终还是做了切换——切换到 Markdown 文件,具体来说是 Obsidian。让我惊讶的是时机。我在当前 AI 浪潮到来之前就切换了。我不是在追赶趋势。我只是终于在践行我已经相信的东西。
我没有预料到的是这个决定会有多正确,而且原因与个人生产力毫无关系,完全与 AI 智能体实际上如何工作有关。
云端生产力时代押错了宝
Notion、Confluence、Evernote、Roam——过去十年知识管理的故事是关于抽象掉文件系统的。你的笔记存在数据库里。你得到了精美的界面、协作功能和有条理的感觉。你放弃的是所有权。
试着导出一个 Notion workspace。你会得到一个充满内嵌元数据的 HTML 的 ZIP 文件。试着用 grep 搜索它。试着在不经过 Notion API 的情况下让 AI 智能体访问它。当 Notion 改变定价时,试着以任何有意义的方式拥有它。
Obsidian 走了相反的方向。你的笔记是文件,在一个文件夹里,在你的机器上。这个应用程序是一个镜头,不是容器。用 vim、VS Code 或任何曾经存在过的文本编辑器打开任何笔记。在毫秒内搜索你的整个 vault。通过脚本处理笔记。随心所欲地同步——iCloud、Syncthing、git、U盘。数据是你的。
当你想让 AI 智能体处理你的知识时,这一点极为重要。
为什么 Markdown 是 AI 原生的
Markdown 不仅仅是人类可读的。它处于一个特定的最优点:对机器来说足够结构化,对人类来说足够灵活。这里我要稍微技术一点,但跟着我走。如果你不理解所有术语,底层逻辑是直接的。这些原则是不变的。每个使 Markdown 对人类有益的属性,也使它对 AI 有益:
纯文本意味着任何工具都能读取它。无需解析库,无需 API 调用,无需格式协商。语言模型读取 Markdown 文件的方式和你一样。
YAML frontmatter 意味着机器可读的元数据与内容存储在同一个文件中。标签、关系、日期、自定义属性——它们跟着笔记一起移动。没有单独的数据库,没有同步问题,没有"元数据在这里但内容在别处"的问题。这就是黄金法则:数据和元数据在同一个文件中。带有 frontmatter 的 Markdown 正是如此。
Wikilinks 是文档之间显式的、命名的关系。不只是超链接——是语义连接。[[Parent Note]]、[[Related Concept]]。知识图谱可以遍历它们。AI 智能体可以跟随它们。它们不仅仅是导航;它们是声明式结构。
标题作为结构给 AI 系统提供了自然的分块边界。当你在笔记上构建 RAG 管道时,## 节成为连贯的检索单元。你为自己写的文档结构成为 AI 用来找到相关内容的文档结构。
将此与 Notion 导出(HTML 汤)、Confluence 页面(专有 JSON)或 Word 文档(XML zip 文件)进行比较。当你想让 AI 智能体推理你积累的知识时,Markdown 在每个维度上都胜出。
生态系统异常深厚
Obsidian 拥有约 1,500 个社区插件。数量不如这些插件所暴露的内容有趣。
值得注意的是插件能深入 Obsidian 的程度。插件不仅限于改变应用程序的外观或向工具栏添加按钮。它可以读取和遍历你的所有笔记及其之间的连接,访问和修改附加到任何笔记的元数据,创建其他应用程序可以响应的自定义链接,以及直接在你的计算机上读写文件。大多数应用程序给开发者一个狭窄的工作窗口。Obsidian 把整栋楼的钥匙都给了他们。结果是插件生态系统将 Obsidian 视为一个可以在其上构建的平台,而不是一个使用的应用程序。
由于一切都是文件,这些插件可以组合使用。一个写入 frontmatter 的插件与一个读取 frontmatter 的插件配合工作。一个添加链接的插件与一个遍历链接的插件配合工作。没有什么被隔离在自己的数据库中。文件是组件之间的契约。
本地优先是 AI 隐私的关键
当你把笔记提供给 AI 时,你是在提供你真实的思考过程。不是你精心打磨的输出——是你真实的思考。不确定性、半成形的想法、个人项目、你了解的关于雇主的事情、你还没有发布的观点。
本地优先意味着你控制什么去哪里。你的笔记默认不会训练 OpenAI 的下一个模型。你可以在本地运行模型,对抗你的整个 vault,而不会有任何数据离开你的机器。在本地运行的 AI 智能体可以访问文件系统,无需经过云端的往返。你可以选择,对于每个模型和每个任务,提供什么上下文。
这不是偏执。这是适用于任何敏感数据的相同操作安全原则。你有意识地决定什么离开你的控制,而不是由服务条款更新替你做出这个决定。
智能体接口模式
AI 智能体如何构建与人类上下文的关系正在发生一些微妙的变化,值得关注。
Claude Code 将其持久指令存储在 CLAUDE.md 中。它将关于用户的记忆存储在 memory/*.md 文件中。可重用的智能体行为在 .claude/skills/*.md 中定义。这些都不是数据库、API 或专有格式。全都是 Markdown 文件。
这不是任意的。Markdown 是这个接口的正确媒介,因为它对人类和 AI 都是可读的,可以在散文旁边包含结构化数据,可以进行版本控制,并且读写不需要任何基础设施。
你的 Obsidian vault 已经是这样结构化的——或者可以是。带有 frontmatter 属性的笔记,声明关系的 wikilinks,编码类别的标签。如果你在上面叠加正确的工具(MCP 服务器、向量搜索、RAG),你的整个知识库就可以被你使用的任何 AI 智能体查询。vault 成为上下文窗口。
但存在一个缺口
Obsidian 本地无法解决的:到 vault 外部获取内容。
vault 了解你的笔记。它不了解你的项目目录、代码仓库、下载文件夹、PDF 库。每一个不是 vault 内 Markdown 文件的工具对它来说都是不可见的。每次你想将笔记与项目目录连接时,你都在手动解决这个协调问题。
这就是促使我构建 FolderTether 的限制——但那是下一篇文章的主题。
补充:如何整理你的笔记
本节适合 Obsidian 新手或想了解上述系统所基于的组织方式的读者。这是一个实用的起点,不是主文章的要求。只是一个福利!
有效使用 Obsidian 最重要的转变是放弃将文件夹作为主要组织工具。
文件夹是我们大多数人学习组织文件的方式。它们感觉直观。但在知识系统中,它们会造成问题:一个笔记只能存在于一个文件夹中,文件夹不会出现在图形视图中,文件夹层次结构变成了你必须提前做出然后一直承受的决定。
Obsidian 给你更好的工具:标签(tags)、链接(links) 和 属性(properties)。
黄金法则
将你的数据和元数据存储在同一个文件中。在每个笔记的顶部使用 YAML frontmatter 来捕获结构化信息——标签、日期、关系、来源引用。这就是使你的笔记对你和你使用的任何 AI 工具都可查询的原因。
---
tags:
- knowledge/ai/rag
- goal/project/my-project
created: 2026-03-13
up: "[[Parent Note]]"
source: "[[Reference Material]]"
---
标签优于文件夹
标签比文件夹更灵活,因为一个笔记可以有多个标签。使用层级标签来组织结构——knowledge/ai/rag 比 knowledge 更精确,比嵌套文件夹结构更灵活。
将标签放在 frontmatter 中,而不是内联在文本中。这使你的笔记正文保持清洁,并使标签更易于查询。
链接作为声明式关系
Wikilinks([[Note Name]])是 Obsidian 最强大的功能。有意识地使用它们:
- 属性中的命名链接用于强而明确的关系:
up: "[[Parent Note]]"、source: "[[Reference]]" - 内联 wikilinks 用于笔记正文中的上下文连接
- Obsidian 跟踪所有链接,并在笔记重命名时自动更新——没有断开的引用
当你有真实链接连接真实笔记时,图形视图才变得有用。它是你思维的地图,而不仅仅是你文件夹结构的可视化。
属性用于结构
属性(frontmatter 字段)让你将 vault 视为轻量级数据库。除了标签之外,考虑:
up——主要的上游关系(这个笔记属于什么)sibling——同一层级的横向关系source——信息来自哪里archive: true——将笔记标记为非活跃,而不删除它们
关于 PARA 的说明
PARA(Projects、Areas、Resources、Archives)是你可能在 Obsidian 内容中遇到的流行组织框架。它很好地映射到标签:goal/project/...、area/...、knowledge/...。如果它符合你的思维方式,就使用它。关键是 PARA 作为标签系统比作为文件夹层次结构效果更好。