为什么 LLM Wiki 选择 Obsidian？

2025年10月，Andrej Karpathy在Twitter上发文说他一直在使用LLM在研究主题上构建个人知识库。两天后他发布了一个名为llm-wiki.md的GitHub Gist描述这个模式。六个月内，该模式已经变成了一个小型运动：至少有五个成熟的开源实现（claude-obsidian、obsidian-wiki、llm-wikid、Pratiyush/llm-wiki及其变体），Steph Ango——Obsidian自己的CEO——发布了一套官方技能，教Claude用Obsidian的"母语"（wikilinks、callouts、canvas）写作，"LLM Wiki"这个术语进入了任何对AI增强知识管理感兴趣的开发者的词汇表。

这里有一个没有人停下来问的问题：为什么是Obsidian？

Karpathy没有说"用Obsidian"。他说的是："有一个markdown文件夹，指向一个智能体，让智能体做工作。"理论上，任何编辑器都行——VS Code、Typora、iA Writer，甚至是vim。理论上。在实践中，上述五个实现都选择了Obsidian。Obsidian的CEO发布了官方技能。在Medium和Substack上疯传的文章都围绕Obsidian。在特定平台上出现了自发的收敛，这种收敛值得分析——因为理解它就是理解知识平台的哪些属性在智能体时代能够存活，哪些会被淘汰。

这是关于Obsidian + Claude三部分系列的第一篇文章。接下来的文章会更具体：第二篇是一个动手教程，构建Karpathy风格的LLM Wiki结合开发者的"第二大脑"（ADR、复盘、决策），第三篇是个人案例研究，展示我日常如何使用这个设置。但在"怎么做"之前先说"为什么"——因为选错了基础以后会付出代价。

留出20分钟，我们开始。

1、没有人测量的属性

大多数Obsidian、Notion、Confluence等之间的比较都写于2024年之前，测量的都是错误的东西。经典标准是：富文本可视化编辑器 vs 纯markdown、实时协作 vs 个人使用、嵌入式数据库 vs 仅笔记、移动支持、插件生态、价格。

这些标准仍然相关。但在2026年它们已经不够了。有一个改变游戏规则的新维度，几乎没有任何传统评测在测量：

外部智能体（LLM）能多好地读取、写入和操作你的知识系统？

我称之为"智能体友好性"。在这个特定轴上，三大平台的定位截然不同。让我们看看矩阵：

2026年重要的问题不再是"哪个工具更漂亮或更强大"。而是：如果我想让一个智能体读取我的知识库、写入内容、维护一致性并自动创建交叉引用，哪个工具让这件事变得容易或困难？

让我们逐维度来看。

2、数据主权（或者说：智能体能到达哪里？）

在任何功能讨论之前，有一个操作性问题：你的笔记在物理上存在于哪里？谁能访问它们？你选择的LLM智能体——Claude Code、Cursor、Codex、Gemini CLI——能打开文件吗？

在Obsidian中，答案是直接的：每个笔记都是磁盘上文件夹中的.md文件。Claude Code运行cat ~/vault/notes/kubernetes-misconfig.md就能获取内容。没有API，没有认证，没有速率限制。智能体是同一操作系统上的进程，以与你相同的方式打开文件。这是可能的最低摩擦级别。

在Notion中，答案是：看情况。Notion有一个合理的REST API，但外部智能体使用（非Notion AI）有三个实际问题。首先，API需要令牌并有激进的速率限制。其次，返回格式是Notion的"块模型"（描述UI块的嵌套JSON），而非markdown——与markdown之间的转换是机械性的但并非简单。第三，也是最重要的：Notion在2025年5月屏蔽了第三方AI访问，取消了独立的AI附加组件，将所有AI Agent和"Ask Notion"功能移到了Business计划。你仍然可以编写一个与Notion REST API通信的客户端——但"Notion AI"现在是封闭的：它在Notion内部运行，而非外部。

在Confluence中，有企业的出路：Atlassian Rovo，于2025年4月在所有付费的Jira、Confluence和Jira Service Management Cloud订阅中可用。它暴露了一个Claude Code可以消费的MCP端点。它可以工作。对于已经生活在Atlassian中的企业团队来说，这是一个好方案。对于个人使用来说，它是大材小用——你不会仅仅为了让Claude读取一个知识库就付Confluence Premium。

在Apple Notes / Bear / Drafts中，答案是：实际上不可能。格式是专有的，存储位于iCloud加密之下，没有外部智能体可以使用的API。Apple Notes不是为此构建的，也永远不会是——它是一个供人类用眼睛阅读的工具。

这里的操作差异是巨大的。在Obsidian中，智能体设置只需一行（cd ~/vault && claude）。在Notion中，这是一个项目：你需要决定是使用官方API、编写包装器、映射块模型、处理网络延迟。在Confluence中，取决于你是否是工作区的管理员以及你的计划。在Apple Notes中，别想了。

但有细微差别。"主权"不仅仅是便利——它也是风险。Claude Code直接访问文件夹意味着，如果某个会话出了问题，智能体可以删除文件、覆盖内容或向git提交错误的东西。在Notion中，Notion AI有细粒度的工作区权限；在Confluence中，Rovo尊重用户授权。本地markdown的便利伴随着你在备份、版本控制和审查方面的个人自律。我在第6部分讨论这个问题。

3、没人看到的层：个人知识库栈

值得在这里暂停一下，画出组织后续讨论的心智模型。当人们谈论"Obsidian"时，很容易将三个物理上分离的东西混淆：

在我所说的"个人知识库"中有四层，大多数工具比较将一层与另一层混淆：

存储——文件系统。你磁盘上的一个文件夹。这是当所有其他层都关闭时存在的东西。
格式——带有YAML前置元数据和[[file]] wikilink约定的纯markdown。一个开放标准，可在任何编辑器中阅读，可被任何语言解析。
UI / 查看器——Obsidian是一个选项，但VS Code配合合适的插件、iA Writer、Typora、Zed都能打开同一个文件夹。UI是可替换的，不会丢失任何一个笔记。
智能体——Claude Code、Cursor、Codex、Gemini CLI。读写UI读取的同一文件夹。可替换。

这种设计的精妙之处——以及Obsidian作为LLM Wiki模式基础"胜出"的原因——恰好在于这种分离。每一层都可以独立于其他层进行替换。我可以明天停止使用Obsidian，在Cursor中打开知识库；我的1,500条笔记仍然在那里，有相同的反向链接、相同的文件。我可以把Claude Code换成Codex；文件夹不变。我可以从Mac转到Linux；知识库只是一个文件夹。

这与Notion提供的恰恰相反。在Notion中，四层是融合的：存储是他们的数据库，格式是他们的块模型，UI是他们的应用，智能体是他们的Notion AI。你不能在不更换所有层的情况下更换一层。想要不同的UI？使用Notion的其他UI。想要带走你的笔记？导出为markdown并在途中丢失30%的结构。想要不同的AI？不行——Notion AI是唯一被允许的AI界面。

这种层融合有真正的好处。Notion的UI比Obsidian的更精致。实时协作可以工作。2025年9月Notion 3.0推出的AI Agents支持多模型（GPT-5、Claude Opus 4.1、o3）并能执行多步骤工作流，确实很好。对于优先考虑精致UX和企业团队协作的人来说，Notion在多个维度上胜出。

但对于像LLM Wiki这样的模式——它根本上依赖于智能体能够触碰文件——Notion在结构上不适用。Karpathy没有写"Notion是IDE；LLM是程序员；wiki是代码库。"他写的是"Obsidian是IDE。"那不是营销——是对一种架构属性的认可。

4、Notion 3.0：改进的封闭平台

在做出最终评判之前，我必须对Notion诚实。2024年到2026年间确实有真正的演进，改变了部分分析。

2025年9月发布的Notion 3.0引入了能够执行多步骤工作流的自主AI Agents，标志着从"建议的AI"到"执行的AI"的转变。Ask Notion让你可以查询整个工作区，包括Google Drive和Slack等集成来源，每个回答都链接回原始来源。2026年2月，Notion 3.3添加了Custom Agents，让团队能够构建专门的AI工作流。客观地说，这是一套严肃的能力。

这里是重要的细节：LLM Wiki在Obsidian中手动完成的许多工作，Notion AI原生就能做。想要跨文档摘要？Ask Notion。想要摄入一篇文章并链接到现有笔记？有专门的agents。想要系统检测页面间的矛盾？正在开发中。

那么问题不是能力——而是所有权。

当你使用Notion AI时，你在他们的基础设施上运行他们的智能体，使用他们选择的模型（即使底层是Claude/GPT/o3），遵守他们的使用限制，数据留存遵循他们的政策。你不能离线运行。你不能针对你自己的本地模型（Llama、Qwen等）运行。你不能在他们允许的提示之外自定义智能体行为。你不能在不通过API并遵守速率限制的情况下从Python脚本读取你的数据进行统计分析。

所有这些都是一个合理的交易——对于许多企业团队来说，这是正确的交易。你用主权换取便利，便利是真实的。但对于"想要实验Claude Code、自定义MCP服务器、本地RAG、与自己代码仓库集成的开发者的个人知识库"这个特定用例——你需要主权。而Notion不给你。

还有成本问题。2026年，Notion取消了独立AI附加组件，将完整AI访问移到了Business计划的每月20美元/用户（年付15美元）。对于想要AI Agents和Ask Notion的个人用户，没有更便宜的路径——即使你不需要SAML SSO或私有团队空间，也要支付Business最低费用。对于一个10人开发团队想要Notion AI，那是每月200美元固定费用。

对比Obsidian：个人使用免费，Sync是每月4美元可选，Publish每月8美元可选。如果你已经有Claude订阅，系统的"AI"来自那里——没有加价，没有额外速率限制，没有第三方中介。

2026年认真个人使用的账目明显偏向Obsidian。

5、Confluence + Rovo：企业选择

Confluence是它自己的情况。对于个人PKM使用，没有人会选择Confluence——它过度工程化、缓慢、封闭、昂贵。对于已经身处Atlassian生态系统中的企业团队使用来说，它经常是唯一政治上可行的选项。

2025-2026年的大新闻是Rovo从2025年4月9日开始以无额外前期成本包含在付费的Jira、Confluence和Jira Service Management Cloud计划中，设有使用配额并计划未来按使用量收费。在此之前，它是一个极其昂贵的独立产品。现在，任何已经支付Confluence Premium（每月11美元/用户）或Enterprise的团队都能"免费"获得Rovo（有配额）。

Rovo在其目标方面做得很好。Rovo Search搜索Atlassian和连接的SaaS应用，Rovo Chat可在Jira、Confluence、JSM中通过浏览器扩展访问，Rovo Agents可以执行创建Jira工单、发送Slack消息或安排Google日历等任务。对于需要记录在Confluence中的决策能被团队查询的企业团队来说，Rovo能交付。

与Claude Code的集成也是可行的：Atlassian Rovo MCP Server通过MCP/HTTP暴露Confluence（和Jira），使用API令牌认证。这就是我们在上一篇关于Java知识库的文章中使用的——Claude Code读取issue、更新页面、转换状态。

但对于本文的讨论——什么是个人知识库的最佳基础——Confluence因为三个原因出局了：

成本。即使是Standard对个人使用来说也很昂贵，Premium（解锁AI）起价每月11美元/用户。
延迟。Confluence很慢。页面加载、搜索、编辑——与Obsidian（即时、本地）相比，差异在每次操作1-2秒的量级。在数小时使用中累积。
哲学。Confluence为团队设计。其中的一切都假设协作、权限、空间层级。对于个人使用，这变成了摩擦。

有一个有趣的边缘案例：已经生活在企业Confluence中的团队想要在Confluence内部复制部分LLM Wiki模式。这是可能的——Rovo Studio让你构建自定义智能体——但结果是企业知识库，而非个人的。本系列的第2和第3篇文章是关于个人的。

6、Obsidian在哪里失败（因为每个选择都有权衡）

我承诺了诚实比较，所以我需要以Obsidian不是正确选择的场景来收尾。四个场景：

6.1 你需要实时协作

Obsidian本质上是一个单用户工具。有Obsidian Sync（每月4美元）在你的设备间同步知识库，但没有同时编辑，没有其他用户光标，没有结构化的段落锚定评论。对于一起写书的夫妻，或实时编辑策略文档的团队，Notion或Google Docs轻松胜出。

有变通方法——把知识库放在iCloud Drive或共享Dropbox中，使用同步插件——但所有方法都有问题：合并冲突、最终一致性、插件并行写入文件的问题。如果实时协作是关键需求，Obsidian是错误的工具。

6.2 你想要带有筛选、看板、日历的可视化数据库

Notion在这里大放异彩。将笔记列表变成看板、日历、带筛选的表格的能力是真正的差异化。Obsidian有Bases插件（从v1.9.10开始）和社区插件如Dataview和DB Folder可以做类似的事情，但体验更技术化——你写查询而不是通过拖放配置视图。对于把信息当作结构化数据库来思考的人来说，Notion更合适。

6.3 你没有版本控制和备份的自律

Obsidian本地优先意味着如果你的磁盘坏了且没有备份，你就失去了一切。Obsidian Sync作为设备间同步有帮助但不是备份（在一个设备上删除，所有设备上都会删除）。社区的标准解决方案是使用git对知识库进行版本控制——效果很好，我就是这么用的——但它需要自律。Notion和Confluence自动处理备份，因为你的数据存在于他们的云中。

如果你知道自己不会设置git、不会考虑备份，丢失数据的想法让你焦虑——Notion用已经讨论过的权衡换取了消除那一整类问题。

6.4 你想要让大型非技术团队上手

Obsidian有中等的入门门槛。Wikilinks [[Notebook]]、YAML前置元数据、插件、快捷键——所有这些对开发者来说很熟悉，对非开发者来说很陌生。对于从未打开过markdown的市场营销、销售或产品团队，Notion（可视化界面、块、拖放）要友好得多。

实用规则：如果你的主要受众是你自己（可能还有2-3个技术协作者），Obsidian很好。如果你的主要受众是一个将要消费内容而非创建内容的团队，Notion很好。

7、值得引用的争议

作为诚实的额外收获，在"LLM Wiki"这个术语周围有一个活跃的争议，在你投入该模式之前值得了解。

在Karpathy自己的gist中，有极其尖锐的批评。有人写道（大意）："这是对每一位Wikipedia编辑者、每一位MediaWiki贡献者、每一位花数小时引用来源、解决争议、构建历史上最大协作知识库的人类的侮辱。Karpathy的'wiki'没有共识构建、没有争议解决、没有引用要求、没有编辑监督、没有办法说'这个事实有争议'。"

这个批评不是在发牢骚——它在技术上是有效的。Wiki在原始意义上（Ward Cunningham，1995年）是人类协作的工具，具有可验证性、中立性和共识机制。Karpathy描述的是一个LLM维护的个人知识库，这是不同的东西。名字不好——"LLM维护的个人知识库"更精确但不适合发推特。

对于本文的讨论，重要的是：**不要将该模式与可审计的事实来源混淆。**LLM Wiki的可靠性仅取决于谁向其提供来源和审查输出。将智能体生成的页面当作事实而不经人类审查，与将聊天机器人回答当作事实是同样的错误。智能体会犯错、产生幻觉、自相矛盾，且没有问责。使用该模式来加速总结和交叉引用；不要用它替代你自己的推理。

这个警告适用于任何工具——不仅仅是Obsidian + Claude。Notion AI以完全相同的方式产生幻觉；Rovo也是。区别在于，在Obsidian中你更有能力审查智能体写了什么（因为它是纯markdown，容易通过git diff），而在更不透明的工具中，AI输出作为界面呈现，而非作为制品。但在每个平台上，最终规则是相同的：人类审查是不可妥协的。

8、结束语

按用例综合：

选择Obsidian + Claude Code，如果：

你是开发者（或习惯markdown、git、终端）。
你的主要受众是你自己，可能还有1-2个技术协作者。
你想实验自定义智能体、MCP服务器、与你自己的代码仓库集成。
数据主权很重要（因为你是开发者，处理机密材料，或仅仅倾向于不依赖第三方云）。
你愿意投入30-60分钟设置，然后受益数年。

选择Notion 3.0，如果：

你的主要受众是一个将要消费内容的非技术团队。
实时协作是关键需求。
你更偏好精致的视觉体验而非深度自定义。
你想要与笔记集成的可视化数据库（看板、日历、筛选表格）。
每月15-20美元/用户的成本对你可行。

选择Confluence + Rovo，如果：

你的团队已经生活在Atlassian中（Jira、Bitbucket、JSM）。
你需要决策和文档对企业团队可访问。
团队已有Premium或更高级别的许可证。
企业合规要求具有SOC 2、ISO 27001、审计日志的平台。

对于Apple Notes / Bear / Drafts：

用它们进行快速捕获（手机上5秒），之后导出到"真正的"系统。不要试图在上面构建LLM知识库——封闭格式扼杀了可能性。

这篇比较的诚实结论是，选择不是绝对的。它是视情境而定的。但对于"有经验的开发者想要构建一个结合工作笔记、研究、书籍和想法的个人知识库，LLM智能体在其中自主且深入地运行"这个特定情况——Obsidian以架构优势胜出，而非炒作。四个独立层、开放格式、直接文件系统，以及LLM技能社区收敛于该平台——是所有这些的总和构成了意义。

原文链接: Why Obsidian Won as the Base for the Personal LLM Harness (and When You Shouldn't Pick It)

汇智网翻译整理，转载请标明出处