用 AI Agent + Obsidian 搭建自生长个人知识库：LLM Wiki 模式完整实操（存、编、查、检四步法）

本文由 辛梓煜@词元2号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

这篇文章讲什么： 2025 年 OpenAI 创始成员 Andrej Karpathy 提出了一套叫 LLM Wiki 的个人知识库玩法——不靠"每次提问时临时翻资料"的检索增强生成（RAG），而是让 AI 在存入资料的那一刻就把内容读透、整理成互相链接的知识页，从此你的每一次提问都站在之前所有整理成果之上。本文以腾讯 WorkBuddy（或 Claude Code、Codex 等任意 AI Agent）+ Obsidian 为工具，手把手走完存资料 → 编译 → 查询 → 检查四步，搭出一个会自己更新、自己体检、越用越聪明的本地知识库，全程约 15 分钟，数据 100% 留在你硬盘上。

核心结论先放在这： ① 整个系统只有三个部分——raw/ 原始资料夹、wiki/ AI 整理出的知识页、AGENTS.md 给 AI 立的规矩；② 全流程只需四句话指令：建目录一句、编译一句、建体检定时任务一句、建每日自动编译一句；③ 两个软件之间没有任何绑定，靠"共用一个文件夹"接上头，随时可以换 Agent；④ 这套玩法最大的价值不是"自动整理"，而是逼你重新理解——存下来的不等于你的，能随时调出来、连得成网、用得上的，才是你的。想看完整拆解，往下翻。

第一章 你的收藏夹正在悄悄贬值：从收藏到拥有的鸿沟

先问个扎心的问题：你手机里收藏夹存了多少篇文章？电脑里"资料"文件夹堆了多少个 G 的 PDF、录屏、截图？去年收藏的"干货"，今年你还翻得出来吗？

我自己的情况很典型。过去几年，我往各种收藏工具、网盘、本地文件夹里塞了上千份资料——行业报告、教程文章、会议录音转写、书摘。塞的时候每一份都觉得"早晚用得上"，可真到用的时候，我基本想不起来自己存过什么。偶尔想起来某篇东西存在，还得翻半天，翻到了发现当初根本没看完，等于存了个寂寞。

这不是懒，是工具的结构性问题。传统收藏夹干的事只有一件：把内容从一个地方搬到另一个地方。它不负责理解，不负责关联，不负责在你需要的时候把对的东西递到你手上。收藏这个动作本身给你一种"我掌握了"的错觉，实际上知识只是换了个地方吃灰。

更麻烦的是，就算你认真做了笔记，AI 时代的"问答式知识库"也没好到哪去。市面上常见的做法是把你上传的文件切碎、做向量化，然后你问一句，它现场去资料堆里扒拉几段沾边的文字拼一个答案。听起来很聪明对吧？我一开始也这么想，直到我注意到两个毛病：

第一，它每次都是"从零开始"。 你今天问它"A 和 B 有什么区别"，它翻一遍资料答你；明天再问一次，它又从头翻一遍。它不记得昨天整理出的结论，也不会因为你上周读过某篇长文而变得更懂你。理解这件事，它每次都重新做，一分钱都没攒下来。

第二，它的"理解"是临时的。 检索出来的片段是拼在一起的，段落之间什么关系、谁支持谁、谁反驳谁，它并不真的清楚。你问得越深，它答得越虚，最后往往变成"感觉说了很多，又好像什么都没说"。

我后来想明白一件事：知识管理的核心矛盾不是"存不存得下"，而是"理解发生在什么时候"。 传统收藏夹把理解这件事完全扔给未来的自己——"等我有空再看"；RAG 式问答把理解扔给每次提问的瞬间——"现读现答"；而真正靠谱的做法应该是：在资料进库的那一刻，就把理解做完、做扎实，之后每一次调用都是站在已有理解之上。

这正是 Karpathy 那套 LLM Wiki 玩法要解决的事。它把"收藏夹"升级成了"会生长的知识库"——资料进去之后，AI 负责读、负责整理、负责建立关联、负责定期体检，你要做的只有一件事：把值得存的东西丢进去。

在动手之前，先把这套玩法的全貌讲清楚，这样后面每一步你都知道自己在干什么、为什么这么干。下面这张表先给你一个整体印象，把传统收藏夹、RAG 问答、LLM Wiki 三条路放在一起对比：

看完这张表，你应该能感受到差别在哪儿了——不是工具换了个牌子，而是**"理解"这个动作被前置了、被固化了**。接下来两章，我们把 LLM Wiki 的原理和三层架构彻底拆开讲透，然后从第四章开始正式动手搭。

（正文继续）

第二章 LLM Wiki 到底是什么：把理解从"查询时"搬到"存入时"

这套玩法最初是 Andrej Karpathy 在 2025 年 4 月提出来的。Karpathy 是谁？OpenAI 创始成员、前特斯拉 AI 负责人，业内公认的顶尖工程师。他提出的不是某个 App，而是一套模式——一套"AI 帮你维护个人知识库"的组织方式。因为太实用，过去一年里被大量开发者复刻，Obsidian 官方社区甚至出现了专门的插件来实现这套流程。

2.1 一句话说清楚它在干嘛

传统问答式 AI 的姿势是：你提问 → AI 现场去资料堆里检索 → 拼凑回答 → 扔掉。Karpathy 把这件事倒了过来：

别等提问了再理解。提前让 AI 把每份资料读透，整理成一页一页互相链接的知识页面；新资料进来，就往这套体系上补。

这样一来，你每次提问，AI 不是从零开始翻，而是站在"之前全部整理成果"的肩膀上回答。理解被做成了一次性的投入，而不是每次提问都重新交一遍学费。

他自己给这套体系写过一句很形象的话，我特别喜欢：

"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
（Obsidian 是开发环境，AI 是程序员，wiki 是他写出来的代码库。）

把知识库当成一个软件项目来理解，一切都通了：raw/ 是"源代码"——你收集的原始资料；wiki/ 是"编译产物"——AI 整理出来的知识页面；而 AGENTS.md 是"项目规范"——告诉 AI 这个项目该怎么写代码。程序员写代码要遵循规范，AI 整理知识也要遵循规范，规范写得清不清楚，直接决定 AI 干活靠不靠谱。

2.2 三个核心操作：摄取、查询、巡检

Karpathy 把整套系统抽象成三个操作，英文分别是 Ingest、Query、Lint。后面正文里的"存资料、编译、查询、检查"四步，其实就是这三个操作拆开落地：

注意这三个操作的节奏完全不同：Ingest 是"存的时候做"，Query 是"问的时候做"，Lint 是"定期做"。前两个是你主动触发的，最后一个靠定时任务自动跑。三件事合在一起，这套系统才从"工具"变成"活物"。

2.3 为什么比 RAG 更适合个人知识库

市面上主流的"AI 问答你的文档"基本都是 RAG（检索增强生成）路线，前面提过它的问题。这里用一张图把两条路线的区别画出来，你一眼就能看懂差别：

graph TD
    A[资料进库] --> B{RAG 路线}
    A --> C{LLM Wiki 路线}
    B --> D[切块 → 向量化 → 存向量库]
    D --> E[你提问时<br>现场检索相似片段]
    E --> F[拼凑回答 → 答完即弃]
    C --> G[AI 通读全文 → 提炼概念/实体/摘要]
    G --> H[写成互相链接的知识页<br>更新目录与日志]
    H --> I[你提问时<br>先查目录再精读相关页]
    I --> J[基于既有理解回答<br>且带页面级依据]
    style E fill:#f5d0d0
    style F fill:#f5d0d0
    style G fill:#d0e8d0
    style H fill:#d0e8d0
    style I fill:#d0e8d0
    style J fill:#d0e8d0

图上红色分支是 RAG：工作全堆在提问那一刻，每次提问都要重新检索、重新理解，之前花的力气全白费。绿色分支是 LLM Wiki：工作前置到存入那一刻，之后每次提问都是"站在整理好的知识上回答"，越用越省力。

用编程的话说：RAG 是每次运行时动态解析，LLM Wiki 是提前编译、运行时直接调用。对一个资料量在几百篇级别、长期积累的个人知识库来说，后者明显更合适——毕竟你收藏资料是为了以后反复用，不是为了问一次就扔。

2.4 一个流传很广的误解

很多人一听"AI 自动整理知识库"，第一反应是"那我还要不要读资料了？AI 都替我读完了"。这个担心可以理解，但方向反了。这套系统里，AI 干的是图书管理员的活——编目、上架、写摘要、做索引，它不替你做消化这一步。

资料进了 raw/，AI 把它整理进 wiki/，然后呢？你还是要去读那些知识页的。区别在于，以前你面对的是"一堆没整理过的原文"，现在你面对的是"一份已经理清脉络、标好来源、连好关联的阅读清单"。省掉的是"找资料、理脉络"的苦功夫，省不掉的是"把知识变成自己的"那一步——这一步永远只能你自己来。想清楚这一点，你就不会把系统搭完就当甩手掌柜了。

顺便算一笔账，你就知道"一次编译、永久受益"不是口号。假设你每月往库里进 20 份资料，每份 5000 字，一年下来就是 240 份、120 万字。用 RAG 方案，这 120 万字每次提问都要被检索一遍，模型成本随库体量线性上涨；用 LLM Wiki 方案，编译只发生一次，之后所有查询都只在几十页知识页里打转，成本几乎恒定。按我自己的实测，资料量翻三倍之后，查询速度基本没变，回答质量还因为关联更密而更好——这就是前置理解的复利效应。

（正文继续）

第三章 三层架构拆解：raw、wiki 与规则文件的分工

动手之前，先把知识库的"骨架"看清楚。整套系统说到底就是硬盘上一个普通文件夹，里面几个子目录、几个文本文件。它的全部架构可以压缩成下面这张目录树：

书房/                          ← Obsidian 仓库（vault），也就是知识库根目录
├── AGENTS.md                  ← 给 AI 立的规矩（整个库怎么运转全看它）
├── index.md                   ← 全库目录（AI 自己维护）
├── log.md                     ← 干活日志（AI 自己记录）
├── raw/                       ← 原始资料（你只管往里放，AI 只许读不许改）
│   ├── 某篇文章的剪藏.md
│   ├── 某份报告.pdf
│   └── ...
└── wiki/                      ← AI 写的知识页都归这儿
    ├── concepts/              ← 概念页（讲"是什么、为什么"的方法论）
    ├── entities/              ← 实体页（工具、人物、产品）
    └── sources/               ← 来源页（每份原始资料的摘要与出处）

3.1 三个区域，职责分明

这套结构借鉴了软件开发里"源代码 → 构建产物 → 工程规范"的划分，每一块都有不可越界的职责：

为什么 raw/ 要"只许读不许改"？这是整套系统最容易被忽略、却最关键的设计。原始资料是事实的源头，一旦 AI 可以随意修改原文，错误就会被"写回源头"，然后越滚越大，最后整个知识库失去可信度。所以规矩必须写死：raw/ 里放的是证据，wiki/ 里放的是理解，证据不能动，理解可以改。

3.2 三类知识页：概念、实体、来源

wiki/ 下面分三个子文件夹，这个分类逻辑值得展开讲讲，因为它是 AI 整理时的"分诊台"：

• concepts/（概念页）：存"方法论"级别的东西。比如"什么是 RAG""双链笔记是什么""提示词工程的常见套路"。概念页回答的是"这类事物是怎么回事"，它往往会被多个来源反复提及，是知识网的枢纽节点。
• entities/（实体页）：存具体的"对象"——某个工具、某个人、某个产品。比如"WorkBuddy""Obsidian""Karpathy"。实体页记录的是"这个对象是什么、有什么特点、谁提过它"。
• sources/（来源页）：每份原始资料对应一页摘要，记录"这篇讲了什么、核心观点是什么、来自哪个链接"。来源页是知识网和原始资料的连接点。

这三类页面互相之间用 Obsidian 的 [[双链]] 连起来：一篇讲 AI Agent 的文章（sources 页），会链到"AI Agent"这个概念页（concepts 页），再链到 WorkBuddy、Claude Code 这些实体页（entities 页）。一个概念被五篇资料提到，五篇资料就都链到同一个概念页上——这就是知识网形成的方式，也是后面关系图谱里那一根根线的来源。

3.3 关于双链，给新手的白话说

正文里反复出现 [[双链]] 这个词，这里一次说清：双链（双向链接）是 Obsidian 的核心特性，写 [[某个页面名]] 就会生成一个可点击的跳转链接，而且反向也会记录——A 页链了 B 页，打开 B 页时能看到"谁链到了我"。它的意义在于：知识不是一条直线，而是一张网。AI 编译的时候会自动打双链，你只需要认得它是链接就行，不需要手动维护。

3.4 这套结构能随意改吗

能，而且应该按需改。上面是 Karpathy 原始构想加上社区实践后的"标准版"，我自己在用的版本还多加了两个文件夹：syntheses/（放我用 AI 深度探讨后沉淀下来的个人理解）和 assets/（放图片附件）。加文件夹不影响运转，只要你在 AGENTS.md 里把新规矩写清楚，AI 就会照做。结构是死的，规矩是活的——这正是 AGENTS.md 存在的意义。

骨架讲完，第四章开始动手。整个搭建过程只需要三个工具、一个关键操作，我们先把它备齐。

（正文继续）

第四章 开工前的准备：工具清单与打通工作空间

正式动手前，先把工具备齐。整套系统只需要三样东西，全部免费或近乎免费：