LLM Wiki 技术深度解析：告别 RAG，用“编译式知识库“打造你的第二大脑

核心来源：Andrej Karpathy 原始 Gist（2026-04-04）
后续实践：Farzapedia（Farza，2500 条日记 → 400 篇 Wiki）
整理时间：2026 年 6 月
关键词：LLM Wiki、Karpathy、知识库、RAG 替代、Obsidian、Agent 记忆

引言：为什么这件事值得你花时间

2026 年 4 月 4 日，Andrej Karpathy（OpenAI 联合创始人、特斯拉前 AI 总监）在 X 上发了一条推文，介绍了他正在实践的LLM Wiki工作流——让 LLM 把绝大多数 token 消耗用于构建一个"可演化的个人知识库"。

这条推文在 X 上获得了1700 万+ 浏览量。12 小时内，他整理出的"idea file"（概念文件）在 GitHub Gist 上获得了2100+ stars。一周之内，GitHub 上出现了7 个以上的开源实现。

为什么这么火？

因为它解决了一个真实痛点：过去两年，我们一直在用 RAG（检索增强生成）来做知识库，但 RAG 有一个根本性问题——每次查询都在重新发现知识，没有积累（There’s no accumulation）。

LLM Wiki 提出了一个截然不同的思路：让 LLM 持续编译和维护一个结构化的维基百科，而不是在每次查询时从原始文档中实时检索。

这篇文章将完整拆解 LLM Wiki 的技术架构、实现细节、与 RAG 的本质区别，以及真实世界的落地案例。

一、什么是 LLM Wiki

1.1 核心思想（一句话版）

LLM Wiki = 让 LLM 充当全职"知识库管理员"，持续编译、检查和链接 Markdown 维基式文档。

1.2 与 RAG 的本质区别

大多数人与 LLM + 文档交互的方式是RAG 模式：

用户提问 → 上传文档 → LLM 检索相关片段 → 生成回答

这个流程每次都在从零开始重新发现知识。如果你问一个需要综合 5 篇文档的微妙问题，LLM 每次都要重新找到并拼凑相关片段。没有任何积累。

LLM Wiki 的模式完全不同：

原始文档 → LLM 编译 → 结构化 Wiki（Markdown 文件集合） ↓ 用户提问 → LLM 读取 Wiki → 生成回答（Wiki 已预编译好）

关键区别：

Karpathy 的原话：

“这个方法在约 100 篇文章、40 万字规模下的效率显著优于传统 RAG，且完全人类可读、可审计，基本摆脱了供应商锁定。”

1.3 谁在维护 Wiki

LLM 负责写和维护，人类负责思考和引导。

• 你几乎不直接手写 Wiki 内容
• LLM 负责：总结、创建反向链接、归纳概念、创建页面、彼此链接
• 你负责：提供原始资料、引导分析方向、提出好问题

Karpathy 把这套系统的角色分配比喻为：

Obsidian = IDE（前端查看器） LLM = 程序员（全职维护 Wiki） Wiki = 代码库（持续演进的工件）

二、架构设计：三层结构

LLM Wiki 的架构极其朴素，但每个设计决策都有深意。

┌─────────────────────────────────────────────┐ │ Schema（模式层） │ │ 告诉 LLM Wiki 的结构约定和工作流 │ │ (CLAUDE.md / AGENTS.md) │ └─────────────────────────────────────────────┘ ↕ 指导 ┌─────────────────────────────────────────────┐ │ The Wiki（Wiki 层） │ │ LLM 生成的 Markdown 文件集合 │ │ 摘要 / 实体页面 / 概念页面 / 综述 │ └─────────────────────────────────────────────┘ ↕ 读取（不修改） ┌─────────────────────────────────────────────┐ │ Raw Sources（原始源层） │ │ 文章 / 论文 / 代码仓库 / 数据集 / 图片 │ │ 不可变，LLM 只读不写 │ └─────────────────────────────────────────────┘

2.1 第一层：Raw Sources（原始源）

• 内容：你收集的所有原始素材——论文、技术博客、代码仓库、数据集、图片等多模态内容
• 位置：raw/目录
• 关键原则：不可变（Immutable）。LLM 从这里读取，但永远不修改它们。这是你的"真相来源"（Source of Truth）
• 无结构设计：这一步没有任何结构，核心目标只有一个——最大化原始信息的完整性

2.2 第二层：The Wiki（Wiki 层）

• 内容：LLM 生成的 Markdown 文件集合，类似一个由 AI 自动撰写和维护的维基百科
• LLM 全权负责：创建页面、更新页面（新源到达时）、维护交叉引用、保持一致性
• 你负责读取：在 Obsidian 里查看原始数据、编译好的 Wiki、以及衍生的可视化内容

Wiki 中的典型页面类型：

2.3 第三层：Schema（模式层）

• 形式：一个 Markdown 文件（Karpathy 用CLAUDE.md，Codex 用AGENTS.md）
• 作用：告诉 LLMWiki 是如何组织的、约定是什么、摄入源/回答问题/维护 Wiki 的工作流分别是什么
• 这是让 LLM 成为"有纪律的 Wiki 维护者"而非"通用聊天机器人"的关键配置文件
• 协同演进：你和 LLM 一起演进这个文件——随着你弄清楚什么对你的领域有效，不断更新它

三、核心操作流程

LLM Wiki 有三个核心操作：Ingest（摄入）、Query（查询）、Lint（检查）。

3.1 Ingest（摄入）：从原始源到 Wiki

这是 LLM Wiki 最关键的操作——把新源"编译"进 Wiki。

典型流程（以单篇文档为例）：

1. 你把新源拖入 raw/ 目录 2. 告诉 LLM 处理它 3. LLM 读取源文档 4. LLM 与你讨论关键要点（可选，Karpathy 建议参与） 5. LLM 在 Wiki 中写入摘要页面 6. LLM 更新 index.md（索引） 7. LLM 更新相关的实体页面和概念页面 （一篇源文档可能触及 10-15 个 Wiki 页面） 8. LLM 向 log.md 追加一条记录

Karpathy 的实践建议：

• 逐篇摄入 + 保持参与：他倾向于一次摄入一篇源，保持参与——阅读摘要、检查更新、引导 LLM 强调什么
• 也可以批量摄入：如果你信任 LLM，也可以一次批量摄入多篇文章，减少监督
• 工作流程由你开发：把适合你风格的工作流程记录在 Schema 文件中，供未来会话使用

3.2 Query（查询）：问 Wiki 问题

1. 你向 LLM 提问 2. LLM 先读 index.md 找到相关页面 3. LLM 钻取（drill into）相关页面 4. LLM 综合答案并附引用

答案可以有不同的形式（取决于问题）：

重要洞察：好的答案可以存回 Wiki 作为新页面。你要求的比较、分析、发现的联系——这些都有价值，不应该消失在聊天历史中。这样你的探索就和摄入的源一样，在知识库中持续积累。

3.3 Lint（检查）：保持健康

随着 Wiki 增长，需要定期"体检"：

你：请给 Wiki 做一次健康检查 LLM 会查找： ✗ 页面之间的矛盾（A 页说 X，B 页说非 X） ✗ 过时的结论（新源已推翻旧说法） ✗ 孤立页面（没有入链，没人能找到） ✗ 被提到但没有独立页面的概念（知识缺口） ✗ 缺失的交叉引用（相关页面没有互链） ✗ 可以通过网络搜索填补的数据缺口 LLM 还擅长： ✓ 建议接下来应该研究什么问题 ✓ 建议应该寻找什么新源

这保证了 Wiki 在增长过程中保持健康、一致、无孤立知识。

四、两个特殊文件：index.md 和 log.md

这两个文件帮助 LLM（和你）在 Wiki 增长时导航。它们服务于不同目的。

4.1 index.md（内容索引）

• 定位：内容导向的目录
• 内容：Wiki 中每个页面的链接 + 一句话摘要 + 可选元数据（日期、源计数）
• 组织方式：按类别组织（实体、概念、源等）
• 更新时机：LLM 在每次摄入时更新它
• 查询时使用：回答问题时，LLM先读 index.md找到相关页面，然后钻取它们

为什么在中等规模下不需要 RAG？

Karpathy 的报告：

“在他的规模下（约 100 篇文章、40 万词），更复杂的 RAG 基础设施并不是严格必要的。LLM 会持续更新索引文件，维护文档的简短摘要，它能相当不错地读取并关联重要的相关材料。”

换句话说：index.md 就是一个手工维护的、比向量检索更可靠的"索引"。在 ~100 篇文档的规模下，这已经足够好。

4.2 log.md（操作日志）

• 定位：时间顺序的记录
• 内容：发生了什么、什么时候——摄入、查询、检查操作的追加式记录
• 格式技巧：如果每个条目以一致的前缀开头（例如## [2026-04-02] ingest | Article Title），日志可以用简单的 Unix 工具解析——grep "^## [" log.md | tail -5给出最近 5 个条目
• 作用：给你 Wiki 演进的时间线，帮助 LLM 理解最近完成了什么

五、工具生态

LLM Wiki 的工具栈极其朴素，但每个工具都有明确分工。

5.1 核心工具

5.2 Obsidian 插件生态

5.3 可选：搜索工具

当 Wiki 增长到 index.md 不够用时，可以加搜索工具。

qmd（推荐）：

• 本地 Markdown 文件搜索引擎
• 混合 BM25 / 向量搜索 + LLM 重排序
• 全部在设备上运行（隐私友好）
• 既有 CLI（LLM 可以 shell 调用它）又有 MCP Server（LLM 可以把它当作原生工具）

也可以自己写：LLM 可以帮你 vibe-code 一个朴素的搜索脚本，按需构建。

5.4 图片处理技巧

Obsidian 设置技巧（Karpathy 推荐）：

设置 → Files and links → "Attachment folder path" 设为固定目录（例如 raw/assets/） 设置 → Hotkeys → 搜索 "Download" → 找到 "Download attachments for current file" → 绑定快捷键（例如 Ctrl+Shift+D）

剪辑文章后，按快捷键，所有图片下载到本地磁盘。这让 LLM 可以直接查看和引用图片，而不是依赖可能失效的 URL。

注意：LLM 不能一次性原生读取带内联图片的 Markdown——解决方法是让 LLM 先读文本，然后单独查看部分或所有引用的图片以获得额外上下文。有点笨拙，但足够好用。

六、真实案例：Farzapedia

理论听起来好，但真实世界有人用起来了吗？

有。而且效果很惊艳。

6.1 Farza 的实践

Karpathy 发推两天后，开发者Farza就用这套思路做了一个东西——Farzapedia。

他把以下内容交给 LLM “编译”：

2500 条日记 + Apple Notes 笔记 + 部分 iMessage 对话 ↓ LLM 编译 400 篇结构化 Markdown 文章 （涵盖：朋友、创业项目、研究方向、 甚至最喜欢的动漫及其个人影响） + 全部带反向链接

6.2 Farzapedia 的关键设计

Farza 说了一句非常关键的话：

“这个 Wiki不是给我看的，是给我的 Agent 看的。”

Wiki 的文件结构和反向链接对任何 Agent 来说都非常容易爬取。他可以在 Wiki 上启动 Claude Code，Agent 从index.md出发，就能精准定位到需要的页面。

而基于文件系统的知识库，Agent 天然就能理解，反而好用得多。

6.3 实际使用案例

Farza 举了一个例子：

设计新产品的落地页时，他问 Agent：
“去看看最近启发我的图片和电影，给我一些文案和视觉方向的建议。”

Agent 从 Wiki 里翻出了：

• 他关于吉卜力纪录片的笔记
• 他截图过的 YC 公司落地页
• 他几年前保存的 1970 年代 Beatles 周边设计

然后给出了一个融合这些灵感的方案。

这件事情的妙处在于：Agent 主动跨多个"概念页面"综合出了人类可能忽略的联系。

七、Karpathy 四原则

Karpathy 看到 Farzapedia 之后专门发了一条推文，列出了这种方式做 AI 个性化的四个原则。这四个原则其实才是整件事最值得拆开讲的部分。

原则一：Explicit（显性化）

你的 AI "记住"了什么？

在 ChatGPT、Claude 的记忆功能里，这件事是黑箱——你不知道它记了什么，不知道它漏掉了什么，不知道哪天它会把两段记忆搞混。

LLM Wiki 不一样。知识全在 Markdown 文件里，打开就能看。哪条信息准确、哪条需要修正、哪条根本没被收录，一目了然。

原则二：Yours（属于你）

数据在你自己的电脑上。

不在 OpenAI 的服务器里，不在 Anthropic 的数据库里。你换 AI 供应商，知识库跟着你走。你删掉某段记忆，它就真的消失了，不会留在某个你够不到的地方。

原则三：File over App（文件优先于应用）

这个概念来自 Obsidian 创始人 Steph Ango 的一篇文章。

知识存成Markdown 和图片——两种最通用的格式。这意味着：

你可以用 Obsidian 看 你可以用 VS Code 编辑 你可以用 grep 搜索 你可以写脚本批量处理 你可以让任何 agent 直接读取 不被任何一个 App 锁死。

原则四：BYOAI（自带 AI）

你可以用 Claude、用 GPT、用 Codex、用开源模型都行。

因为知识库是标准 Markdown 文件，任何能读 Markdown 的 AI 都能用。没有供应商锁定。

八、为什么 LLM Wiki 现在才火

你可能会问：这个思路听起来不复杂，为什么是现在？

8.1 关键使能条件

8.2 "Agent 时代"的范式转变

Karpathy 在推文中提到一个观点：

“在 LLM Agent 时代，分享具体代码或应用的意义正在变弱。现在只需要分享想法，然后把它交给 Claude、Grok 等 Agent，它就可以根据你的需求，自动搭建一个属于你自己的个人知识库。”

这意味着 LLM Wiki 不只是一个 AI 工具，而更像是一种元框架（meta-framework）。它不依赖某个具体模型或技术栈，而是在尝试定义一种人类与 AI 协作管理知识的方式。随着模型不断迭代、框架持续演进，"让 LLM 帮助编译并维护一个持续生长的 Wiki"这一模式，反而具备更长期的稳定性和适用性。

九、适用场景

LLM Wiki 可以应用于很多不同的上下文。Karpathy 列了一些例子：

9.1 个人场景

• 个人成长追踪：追踪自己的目标、健康、心理、自我提升——归档日记条目、文章、播客笔记，随着时间推移建立关于自己的结构化画像
• 读书笔记：每读一章归档一章，为人物、主题、情节线索建立页面并连接。读完时你拥有一个丰富的伴侣 Wiki（类似《魔戒》粉丝维基 Tolkien Gateway——数千个互链页面，由志愿者社区多年构建。你可以在阅读时个人构建类似的东西，LLM 做所有的交叉引用和维护）

9.2 专业场景

• 研究：在几周或几个月内深入研究一个主题——阅读论文、文章、报告，逐步建立一个有演进论点的综合 Wiki
• 商业/团队：由 LLM 维护的内部 Wiki，由 Slack 线程、会议记录、项目文档、客户电话提供信息。可能有人类在回路中审查更新。Wiki 保持最新，因为 LLM 做了团队中没人想做的维护工作
• 竞争分析、尽职调查、旅行规划、课程笔记、爱好深挖——任何你随着时间推移积累知识并希望它有组织而不是分散的地方

十、LLM Wiki 的局限性

诚实评估，LLM Wiki 并不是万能的。

10.1 规模限制

关键点：LLM Wiki 和 RAG 不是互斥的。大规模下，可以用LLM Wiki（结构化知识）+ RAG（大规模检索）的混合方案。

10.2 维护质量依赖 LLM 能力

Wiki 的质量上限取决于 LLM 的能力上限。如果 LLM 犯总结错误、遗漏关键联系、错误链接，Wiki 的质量会退化。

缓解方法：

• 人类在回路（Human-in-the-loop）：Karpathy 建议逐篇摄入时保持参与
• 定期 Lint：主动检查 Wiki 健康
• 用更好的模型：Claude Opus / GPT-5 的总结质量显著优于小模型

10.3 冷启动成本

建立一个有用的 Wiki 需要摄入相当数量的源文档（Karpathy 的例子是 ~100 篇）。在开始阶段，Wiki 的查询质量可能不如直接用量化索引的 RAG。

但一旦跨过冷启动门槛，Wiki 的积累效应会显著优于 RAG。

十一、快速上手：从零开始建你的 LLM Wiki

如果你被说服了，想试试，这是一个最小可行路径：

步骤 1：建立目录结构

mkdir-p~/llm-wiki/raw# 原始源文档mkdir-p~/llm-wiki/raw/assets# 原始源中的图片mkdir-p~/llm-wiki/wiki# Wiki 主目录touch~/llm-wiki/wiki/index.md# 内容索引touch~/llm-wiki/wiki/log.md# 操作日志touch~/llm-wiki/CLAUDE.md# Schema（给 Claude Code 的指令）

步骤 2：写 Schema 文件

在CLAUDE.md中告诉 LLM Wiki 的结构约定。以下是一个最小模板：

# LLM Wiki Schema ## 目录结构 - raw/ : 原始源文档（不可变） - wiki/ : Wiki 页面（LLM 维护） - wiki/index.md : 内容索引 - wiki/log.md : 操作日志 ## 摄入工作流 1. 读取 raw/ 中的新源 2. 生成 Wiki 页面（摘要、实体、概念） 3. 更新 index.md 4. 追加 log.md ## Wiki 页面格式 每个页面应包含： - YAML frontmatter（title、tags、date、source_count） - 正文（Markdown 格式） - 反向链接部分（## Backlinks）

步骤 3：摄入第一批文档

1. 把 3-5 篇你想读的论文/文章放进 raw/ 2. 启动 Claude Code / Codex 3. 把 CLAUDE.md 的内容告诉它 4. 说："请处理 raw/ 中的第一篇文档" 5. 参与讨论，检查输出 6. 重复直到所有文档处理完毕

步骤 4：用 Obsidian 查看

1. 安装 Obsidian 2. 打开 ~/llm-wiki/ 作为 Vault 3. 查看 wiki/ 目录中的页面 4. 打开 Graph View 看图谱形状

步骤 5：提问并观察

问 Wiki 一个问题，观察 LLM 是否： ✓ 正确找到了相关页面 ✓ 综合了多个页面的信息 ✓ 给出了带引用的答案

十二、与 RAG 的混合方案

LLM Wiki 并不是要完全取代 RAG。在生产环境中，两者可以互补：

用户提问 │ ├─→ 先查 Wiki（精确、综合好、人类可读） │ ├─→ 再查向量数据库（大规模、语义检索） │ └─→ 合并结果 → 生成回答

建议策略：

十三、2026 年的趋势判断

基于 Karpathy 的原创工作和后续社区反应，以下是几个值得关注的趋势：

13.1 “编译式知识库"将挑战"检索式知识库”

过去两年，RAG 是 LLM + 知识库的标准答案。2026 年，我们预计会看到更多编译式（LLM Wiki 风格）方案出现，尤其是在中等规模（100-1000 篇文档）场景下。

13.2 开源实现将涌现

Karpathy 的 Gist 发布仅一周，GitHub 上就出现了 7 个以上的开源实现。我们预计：

• 专门的 LLM Wiki 管理工具（类似 Hugo/Hexo 但专为 LLM 维护设计）
• Obsidian 插件的专门化（LLM Wiki 专用插件）
• MCP Server 的标准化（让任何 Agent 都能读写 Wiki）

13.3 "文件优先"哲学将获得更多认可

"File over App"不是一个新概念，但 LLM Wiki 给了它一个新的、强有力的论据。我们预计会看到更多基于标准文件格式（Markdown、JSON、CSV）的 AI 工具，而不是封闭的数据库。

13.4 Agent 个性化将不再依赖黑箱记忆

Farzapedia 展示了一条路：Agent 的"记忆"可以是一个显式的、人类可读的、可审计的Wiki。这意味着：

• 你可以检查和修正 Agent 的记忆
• 你可以把记忆迁移到不同的 Agent
• 你可以让多个 Agent 共享同一个 Wiki

十四、结语：这件事的更大意义

LLM Wiki 在技术上的创新其实不大——它没有引入新的算法、新的模型架构、新的训练方法。

它的创新在于工作流的重新设计：把 LLM 从"查询时实时检索者"变成"持续编译和维护者"。

这听起来像一个微小的改变，但它从根本上改变了知识库的积累性——从"每次重新发现"变成"持续生长和演进"。

Karpathy 在他的 Gist 最后引用了 Vannevar Bush 1945 年的 Memex 概念——一个个人的、精心管理的知识存储，文档之间有联想路径。Bush 的愿景更接近 LLM Wiki 而不是今天的 Web——私人、主动管理、文档之间的连接和文档本身一样有价值。

Bush 无法解决的"谁来做维护"问题，LLM 处理了。

这就是 LLM Wiki 的更大意义：它可能是实现 Memex 愿景的最接近的方案——70 多年前设想的"思维扩展器"，在今天由 LLM 担任全职图书管理员而成为可能。

参考资源