把Obsidian接进OpenClaw:不用WorkBuddy也能让Markdown变成自己生长的AI知识库

> NextClaw LLM Wiki 系列第 3 篇

上一篇我们聊到，Karpathy 的 LLM Wiki 范式真正解决的，不是“让 AI 多写几篇笔记”，而是把知识管理里最重、最碎、最持续的簿记工作，重新分配给 AI。

比如：

• • 索引
• • 归档
• • 补链接
• • 合并重复概念
• • 记录来源
• • 更新旧页面
• • 检查孤立笔记

这些事情都很重要。

但它们不是最需要人类创造力的地方。

真正的问题是：

普通用户怎么把这套 LLM Wiki 方法落到自己的日常知识工作流里？

如果每次都要自己写脚本、调命令、搬文件，那它就很难成为一个长期可用的系统。

所以第 3 篇，我想讲 NextClaw 的一个核心判断：

Obsidian 是知识工作现场，OpenClaw 是执行系统，obsidian-wiki 是 Wiki 维护组件，Nextcloud 负责同步同一份 Markdown 资产。

NextClaw 要做的，不是重新发明一个笔记软件。

而是把 Karpathy 的 LLM Wiki 范式，接进很多人已经在用的 Obsidian。

一、Obsidian 用户真正缺的不是笔记软件

很多 Obsidian 用户其实已经有了一套很好的知识工作环境。

本地 Markdown 文件。

双向链接。

标签。

文件夹。

图谱视图。

社区插件。

甚至还有一套自己熟悉的命名规则和整理习惯。

这些都很珍贵。

因为知识管理最怕的不是工具不够多，而是每换一个工具，就要重新适应一套工作方式。

所以 NextClaw 的第一条产品判断是：

不要替换用户已经习惯的知识工作现场。

如果用户已经在 Obsidian 里阅读、写作、整理资料，那 AI 能力就应该进入 Obsidian，而不是逼用户迁移到另一个知识库产品里。

但 Obsidian 本身也有一个很现实的问题。

当资料越来越多，维护成本会越来越重。

新资料进来后，没人帮你整理。

旧页面过时后，没人提醒你更新。

相关概念之间本来应该建立链接，但链接经常忘记补。

一次高质量 AI 问答很有价值，但它通常留在聊天记录里，没有沉淀成 wiki 页面。

最后，知识库还是会慢慢变成一个“我知道里面有东西，但不知道从哪里进入”的文件夹。

这不是 Obsidian 的失败。

恰恰相反，Obsidian 已经把知识资产保存在了最适合长期维护的形态里：

本地 Markdown。

问题在于：

Obsidian 很适合做人类的知识工作现场，但它还需要一个能长期执行维护任务的后端。

NextClaw 想补上的就是这个后端。

二、为什么 Obsidian 是 LLM Wiki 的天然载体？

LLM Wiki 不是一个花哨的聊天窗口。

它的核心，是一组可以长期维护的 Markdown 页面。

这些页面之间有链接，有来源，有日志，有结构检查，也有人类可以随时打开、修改和审核的文本。

从这个角度看，Obsidian 几乎是 LLM Wiki 的天然载体。

1. Markdown 是主资产

LLM Wiki 最重要的一点，是知识不能被锁在一个黑盒系统里。

如果你的知识只能在某个云端产品里查看，不能直接导出，不能被普通编辑器打开，也不能用 Git 或文件系统管理，那它就很难成为真正长期可控的资产。

Obsidian 的核心资产就是本地 Markdown 文件。

这意味着：

• • 你可以用 Obsidian 打开
• • 也可以用 VSCode、Cursor、Typora 打开
• • 可以放进 Nextcloud 同步
• • 可以用 Git 做版本管理
• • 可以迁移到别的工具
• • 可以让 OpenClaw 在本地文件系统中直接操作

这非常适合 LLM Wiki。

因为 LLM Wiki 的结果不应该只是一次聊天回答，而应该是一组可以留下来的 .md 文件。

2. 双向链接适合表达知识关系

传统文件夹更适合分类。

但知识本身经常不是树状结构，而是网状结构。

比如“函数的单调性”不只属于“函数”这一章。

它还会连接到：

• • [[导数判断单调性]]
• • [[函数最值问题]]
• • [[恒成立问题]]
• • [[数形结合]]
• • [[参数分类讨论]]

这正是 Obsidian 双向链接擅长表达的东西。

LLM Wiki 想维护的，也正是这种关系网络。

3. 图谱视图可以观察知识结构

当 wiki 页面之间的链接越来越多，Obsidian 图谱视图就不只是一个好看的功能。

它可以帮助我们观察：

• • 哪些概念是中心节点
• • 哪些页面长期孤立
• • 哪些章节之间联系密集
• • 哪些方法贯穿多个主题
• • 哪些知识点还没有进入网络

比如在高中数学知识库里，如果 [[函数思想]]、[[数形结合]]、[[分类讨论]] 这些节点周围逐渐长出大量链接，就说明这套 wiki 不再只是章节笔记，而开始形成方法网络。

4. Obsidian 适合人机协作

LLM Wiki 不是让 AI 完全接管你的知识库。

更合理的分工是：

• • AI 负责摘要、索引、链接、日志、lint
• • 人负责判断、审核、修改、取舍、规则调整

Obsidian 正好适合做人类审核 AI 产物的工作台。

AI 可以先生成一个知识点页。

人可以打开看，删掉不准确的部分，补充自己的理解，调整页面标题和链接。

这比把知识封在一个不可编辑的问答系统里，要健康得多。

三、NextClaw 的落地架构：不是插件，而是一套工作流

这里要先澄清一个容易误解的点。

NextClaw 不是只做一个 Obsidian 插件。

Obsidian 插件只是入口之一。

真正的系统，是让 Obsidian、Nextcloud、OpenClaw Gateway、obsidian-wiki、RAGFlow 围绕同一份 Markdown 知识资产协同工作。

在 NextClaw 里，组件分工大概是这样：

最关键的是中间这句话：

用户 PC 上的 Obsidian vault，和 OpenClaw 主机上的 vault，通过 Nextcloud 同步的是同一份知识资产。

这带来三个结果。

第一，用户在 Obsidian 里改的内容，OpenClaw 可以看到。

第二，OpenClaw 修改的 Markdown 页面，用户可以在 Obsidian 里看到。

第三，obsidian-wiki 生成的知识点页、方法页、题型页、综合页，可以自动回流到本地 vault。

所以 NextClaw 的关键不是把 Obsidian 搬到云端。

而是让 OpenClaw 和 Obsidian 操作同一份通过 Nextcloud 同步的 Markdown vault。