用 Obsidian + Claude Code 搭建 Karpathy 的「LLM Wiki」

制作模型：deepseek-flash（coding-agent / pi；据 ~/.pi/agent/settings.json）

说明：本书为视频字幕的中文重构，所有画面均截自原视频，按时间锚点标注，便于溯源。

本讲路线图

1. 问题：现在的 AI（RAG）用完就忘，每次提问都从零开始；
2. 方案：Karpathy 的 LLM Wiki——AI 读一遍文档，建一个持久、互链的知识库；
3. 原理：Karpathy 的类比（Obsidian = IDE，LLM = 程序员，wiki = 代码库）与系统三层结构；
4. 动手搭建：Obsidian + 文件夹结构 + CLAUDE.md schema + Web Clipper；
5. 实战：喂入资料 → 图谱视图 → 加第二份资料看它自我更新 → 跨资料提问 → Lint 体检；
6. 适用场景与局限。

一、一个你一旦看清就再也无法忽视的问题

(参考时间: 00:00)

如今大多数人使用 AI 的方式都存在一个根本问题。当你把文档上传到 ChatGPT 或 NotebookLM 并提问时，AI 会在你的文件里搜索、抓出一些相关片段，然后给出答案——这能用。但关键在于：你明天再问一个类似的问题，AI 会把这一切从头再做一遍。什么都没被保存，什么都没被积累，每个问题都从零开始**。

Andrej Karpathy（AI 领域最知名的人物之一、OpenAI 联合创始人、前特斯拉 AI 总监）最近分享了一个能解决这个问题的想法，他称之为 LLM Wiki（大语言模型维基）。一旦你理解它在做什么，旧的文档工作方式就会显得「坏掉了」。

📷 视频开场：介绍要解决的问题
回到原视频 (00:00:04)

二、RAG 是什么，为什么它不够用

(参考时间: 01:00)

大多数 AI 工具处理文档的方式叫 RAG（Retrieval-Augmented Generation，检索增强生成）：你上传文件 → 提问 → AI 在文件里检索 → 抓取看起来相关的片段 → 生成答案。

flowchart LR
  U[用户提问] --> S[在原始文档中检索]
  S --> C[抓取相关片段]
  C --> G[生成答案]
  G --> U
  S -. 每次都从零开始 .-> S

这对简单问题没问题。但如果你的问题需要串联五份不同文档里的想法呢？AI 每次都必须把这些碎片重新找出来、再缝合一遍。

• 没有记忆；
• 没有积累；
• 没有任何东西会复利（compound）。

打个比方：假设你是一名研究者，已经读了好几周的论文。在 RAG 下，你每问 AI 一个问题，它都像从未读过那些论文一样，每次从头开始——这就是瓶颈所在。

📷 RAG 的工作方式与其局限
回到原视频 (00:01:10)

三、LLM Wiki 如何解决这个问题

(参考时间: 01:51)

Karpathy 的想法把这一切反转过来：不是每次提问都去搜索原始文档，而是让 AI 把你的文档读一遍，并从中构建一个结构化的 wiki——一个真正持久的、由互链 Markdown 文件组成的知识库。

于是，当你加入一个新来源（比如一份 PDF 或一篇文章）时，AI 不只是把它「存起来待用」，而是会：

• 阅读它；
• 提取关键概念；
• 整合进 wiki——更新已有页面、为新概念创建新页面、把相关想法互相链接；
• 如果新来源与 wiki 中已有的内容矛盾，它会标记出来。

flowchart LR
  R[原始来源<br/>PDF / 文章 / 笔记] --> A[AI 阅读并提取关键概念]
  A --> W[Wiki：更新已有页 / 新建页 / 互链]
  W --> F{与已有内容矛盾?}
  F -->|是| FLAG[标记冲突]
  F -->|否| W

随着时间推移，wiki 不断长大、越来越丰富。连接已经建好，综合（synthesis）已经完成。当你提问时，AI 不是从零开始，而是从一个预先建好、有组织的知识库出发。

📷 LLM Wiki 的运作方式
回到原视频 (00:02:10)

四、Karpathy 的类比：IDE、程序员与代码库

(参考时间: 02:40)

Karpathy 这样描述这套系统：

把 Obsidian 想象成 IDE，把 LLM 想象成程序员，把 wiki 想象成代码库。

你很少自己去写这个 wiki——AI 负责写作与组织，你只需要专注于放什么进去、以及问什么问题。

📷 Karpathy 的类比
回到原视频 (00:02:42)

五、系统的三层结构

(参考时间: 02:59)

整个系统只有三层，非常简单：

flowchart TB
  L3[第三层：Schema 规则文件<br/>CLAUDE.md —— 告诉 AI 如何组织] --> L2
  L2[第二层：Wiki 本身<br/>AI 创建并维护的 Markdown 文件] --> L1
  L1[第一层：原始来源 Raw Sources<br/>PDF / 文章 / 会议笔记 —— 只读]

1. 第一层：原始来源（Raw Sources）
   你的原始文档：PDF、文章、会议笔记……关键是它们只读——AI 会读，但永不修改。这是你的真相来源（source of truth）。

2. 第二层：Wiki 本身
   一个由 AI 创建并维护的 Markdown 文件夹：索引页、概念页、实体页、摘要对比等，全部互相链接、由 AI 维护。

3. 第三层：Schema（规则文件）
   一份规则文档，告诉 AI 如何组织 wiki、如何处理新来源、如何排版。若使用 Claude Code，这就是你的 CLAUDE.md 文件。

📷 系统的三层结构
回到原视频 (00:03:02)

六、动手搭建

6.1 需要准备什么

(参考时间: 03:54)

• Obsidian：免费笔记应用，处理纯 Markdown 文件，将作为我们的查看器（viewer）。下载：https://obsidian.md。
• 一个 AI 编程代理：视频用 Claude Code（与之配合很好），但你也可以用 OpenAI Codex、Cursor 或其他能读写本机文件的工具。

编者说明：这里用 Obsidian 主要是因为它有图谱视图（graph view），能把连接可视得很直观；但这个 wiki 本质上只是一个 Markdown 文件夹——你也可以用 VS Code 或任意文本编辑器。

📷 准备 Obsidian 与 AI 编程代理
回到原视频 (00:04:00)

6.2 创建 vault 与文件夹结构

(参考时间: 04:39)

打开 Obsidian，创建一个新 vault（仓库）——这只是「文件夹」的一个花哨叫法。把它命名为 LLM wiki，保存到一个简单的位置（例如「文档」目录）。

📷 新建一个 vault
回到原视频 (00:04:46)

接着建立三个文件夹：

LLM wiki/
├── raw/        # 原始来源（只读，真相来源）
├── wiki/       # AI 创建与维护的页面
└── templates/  # 可选：手动创建笔记时的模板

• raw：AI 从这里读取，但永不改动；
• wiki：AI 构建并维护所有页面的地方；
• templates：可选。若你想手动在 Obsidian 里创建格式一致的笔记，可以把模板放这里。由于 Claude 会替我们创建所有 wiki 页面，本教程用不到它，只是顺带说明。

📷 创建 raw / wiki / templates 三个文件夹
回到原视频 (00:05:12)

📷 文件夹结构一览
回到原视频 (00:05:46)

6.3 编写 schema 文件（CLAUDE.md）

(参考时间: 05:50)

这是最关键的规则文件，告诉 AI 如何操作这个 wiki。若使用 Claude Code，就在 vault 的根目录创建一个名为 CLAUDE.md 的文件——Claude Code 打开项目时会自动读取它。

把这个文件放进根目录后打开，你会看到它包含以下几部分：

flowchart TB
  P[1. 目的 Purpose<br/>这个知识库是关于什么的] --> S[2. 文件夹结构<br/>raw 在哪、wiki 在哪]
  S --> W[3. 摄取工作流 Ingest Workflow]
  W --> F[4. 页面格式规则]
  F --> Q[5. 问答行为]

1. 目的（Purpose）：这个知识库是关于什么的。模板里默认设为「规划一次日本旅行」（因为今天的演示就是这个）——下载后你唯一需要改的就是这一行。研究可再生能源就改成那个，想追踪读书就改成那个，其余内容无需改动。

2. 文件夹结构：原始资源在哪、wiki 输出在哪、什么放在哪里。

3. 摄取工作流（Ingest Workflow）：加入新来源文档时 AI 该做什么。基本步骤是：阅读文档 → 提取关键概念 → 创建/更新 wiki 页面 → 更新索引 → 记录改动。

4. 页面格式规则：例如每页顶部要有摘要、每条论断都要标注来源、页面要链接到相关概念。

5. 问答行为：你提问时，AI 应先查阅 wiki、引用来源、并在不确定时明确告知。

不要把它想复杂：模板已经给了扎实的起点，你随时可以边用边改进——schema 会随着 wiki 成长而演化，这本身就是流程的一部分。

📷 把 CLAUDE.md 放到 vault 根目录
回到原视频 (00:06:28)

📷 CLAUDE.md 的「目的」一行需要你自定义
回到原视频 (00:06:38)

📷 schema 中的摄取工作流与页面格式规则
回到原视频 (00:07:20)

6.4 安装 Obsidian Web Clipper

(参考时间: 08:03)

再装一个 Obsidian 扩展——Web Clipper。它是免费的，作用是把任意网页文章转成 Markdown 文件，非常好用。

📷 安装 Obsidian Web Clipper
回到原视频 (00:08:06)

七、喂入第一份资料

(参考时间: 08:12)

现在进入有趣的部分——给 wiki 喂第一份文档。演示场景是规划一次日本旅行，所以先找一篇关于「东京必去」的旅行博客（讲街区、玩法之类）。

1. 用刚才装的扩展，把这篇文章保存为 Markdown；
2. 回到 Obsidian，把它拖进 raw 文件夹；
3. 这样一来，那篇文章的全部信息就进入了你的 raw。

来源不必是 Markdown：PDF 直接拖进 raw 即可，Claude Code 能原生读取 PDF；.txt、.md 同理。不管你的文档是什么格式，丢进去，Claude 会处理。

📷 把网页文章保存为 Markdown
回到原视频 (00:08:36)

📷 把文章拖入 raw 文件夹
回到原视频 (00:08:58)

让 Claude 摄取它：先确认命令行的工作目录指向你的 vault（视频里就放在「文档」下的这个文件夹），然后打开 Claude，输入：

I just added a new source to the raw folder. Please read it and update the wiki.
（我刚刚在 raw 文件夹里加了一个新来源，请阅读它并更新 wiki。）

观察发生了什么：Claude 读取文章 → 创建 wiki 页面。你会看到文章的摘要、不同街区的页面——它列出了计划创建的所有 wiki 页面。你可以调整范围（scope）；如果看起来没问题，就说「go ahead」。大约 3 分钟后全部完成。

📷 让 Claude 摄取新来源
回到原视频 (00:09:42)

📷 Claude 正在阅读文章、创建 wiki 页面
回到原视频 (00:09:58)

八、探索 wiki 与图谱视图

(参考时间: 10:23)

回到 Obsidian 打开 wiki，你会看到结构化的页面：点开任意一页，里面有指向其他页面的链接。

然后切到 图谱视图（graph view）——连接正在形成。这只是一份文档；想象一下 20 份来源之后它会是什么样子。

📷 结构化的 wiki 页面与内部链接
回到原视频 (00:10:26)

📷 图谱视图：连接开始形成
回到原视频 (00:10:38)

九、加入第二份资料：看 wiki 自我更新

(参考时间: 10:42)

再喂一份日本美食指南：保存为 Markdown → 拖进 raw → 对 Claude 说同样的话：

I just added new sources to the raw folder. Please read it and update the wiki.

注意看：Claude 不只是创建新页面，它还在更新之前已经建立的街区页面。仔细看细节，你会发现它如何针对每个页面做调整——这就是 wiki 在发挥作用。

再看图谱视图：更多节点、更多连接。每加一份来源，wiki 都变得更聪明。

📷 加入第二份来源
回到原视频 (00:10:52)

📷 Claude 更新已有的街区页面
回到原视频 (00:11:12)

📷 图谱视图更密：更多节点与连接
回到原视频 (00:11:24)

十、跨资料提问

(参考时间: 11:31)

现在问一个需要同时用到两份来源的问题：

What neighborhood should I stay at if I want to be close to the best food
and still near the major temples?
（如果我想离最好的美食近、又靠近主要寺庙，应该住在哪个街区？）

看这个回答：Claude 不是在检索原始文章，而是从 wiki 的街区页、美食页、寺庙页中取信息，把散落在完全不同来源里的点连接起来，并引用具体的 wiki 页面。

这与「基础 RAG 配置」得到的结果完全不同——这正是 LLM Wiki 的核心价值。

📷 跨资料提问，并从 wiki 页面引用答案
回到原视频 (00:11:46)

十一、Lint：给 wiki 做「体检」

(参考时间: 11:57)

Karpathy 还讲到 lint（代码检查） 这个很聪明的做法。就像代码 linter 检查代码问题一样，你可以定期让 AI 检查整个 wiki，找出：

• 页面之间的矛盾；
• 可能过时的论断；
• 孤儿页面（没有任何链接指向它）；
• 被提到、但还没有自己专属页面的概念。

只需说一句：

Please lint the wiki.

Claude 会通读一切并给出报告。这就是你随 wiki 成长保持它健康的方式。

在演示中，报告列出了孤儿页面、断链等各项检查，说明 wiki 结构上是健全的（只放了两篇文章，符合预期）；同时指出最大的缺口是还没有美食来源，甚至主动提出修复引用问题。

📷 让 AI 对整个 wiki 做 lint
回到原视频 (00:12:24)

📷 lint 报告：孤儿页面、断链等检查结果
回到原视频 (00:12:40)

十二、适用场景

(参考时间: 12:52)

• 学生 / 研究者：边读论文、文章边建 wiki，最后得到一个结构化知识库，而不是一堆高亮的 PDF；
• 教师：把课程文件、专业发展材料、文章喂进去，建一个随时间成长的教学 wiki；
• 企业：把会议笔记、客户通话记录、项目文档喂进去，让新成员浏览整理好的 wiki，而不是翻 Slack 历史；
• 爱读书的普通人：追踪你从书、播客、文章里学到的东西，就像建一本自己的百科。

这个模式适用于任何「随着时间积累知识、并希望它有序而非零散」的场景。

十三、局限与注意事项

(参考时间: 13:43)

坦率地说——这不是魔法：

1. 最适合个人规模。Karpathy 提到的是「几周、大约 100 篇文章」的量级。如果要建成千上万页的东西，你需要比「一堆 Markdown 文件」更多的基础设施。
2. 垃圾进，垃圾出（garbage in, garbage out）。wiki 的质量取决于你喂进去的来源，你仍需筛选放进去的内容。
3. 需要一个编程代理。Obsidian 自身不干这些事，AI 才是引擎——你需要能访问 Claude Code、Codex 或类似工具。
4. AI 会犯错。它可能归类错误或连接错误，这正是 lint 存在的意义。建议（尤其早期）审查它建出来的东西。

不过话说回来，这确实是我见过最实用的 AI 工作流之一：它解决真实问题、搭建免费，而且你的数据以你自己拥有的纯文本文件形式留在本地电脑上。

📷 局限与注意事项
回到原视频 (00:13:46)

十四、总结与下一步

(参考时间: 14:39)

LLM Wiki 是一个由 AI 建立并维护、而且会随时间越变越好的个人知识库——它不再是每问一个问题都从零开始。

• 架构：原始来源（只读）+ Wiki（AI 维护）+ Schema（CLAUDE.md 规则）；
• 关键动作：Ingest（摄取）→ 图谱连接 → 跨资料提问 → Lint（体检）；
• 工具：Obsidian（查看器 + 图谱）+ Claude Code / Codex / Cursor（引擎）。

模板与所有链接都在视频描述里；想系统学习 Claude Code，可以看作者的入门指南。

📷 总结与下一步
回到原视频 (00:14:42)

附：资源与延伸阅读

版权说明：本书为 Teacher's Tech 视频《Karpathy's LLM Wiki - Full Beginner Setup Guide》的学习性中文重构，截图取自原视频，版权归原作者所有，仅供学习交流。