让 LLM 持续维护你的知识库：Karpathy LLM Wiki 模式精读与落地指南

解读 Andrej Karpathy 的 LLM Wiki 模式，分析它和 RAG 的本质差异、三层架构（raw / wiki / schema）、ingest/query/lint 三种核心操作，并给出在个人知识库中跑通最小可用版本的落地路径

原文：LLM Wiki: A Pattern for AI-Maintained Knowledge Bases by Andrej Karpathy

---

一句话总结

别让 LLM 每次查询都”重新发现”知识——让它像一个不会疲倦的图书管理员，把读到的每一篇东西，沉淀进一份持续生长的 wiki。

这就是 Karpathy 这篇 gist 的全部要点。但它背后的心智模型转变，比看上去要根本得多。

---

一、问题：为什么我们需要重新想象”AI + 知识库”

1.1 RAG 的隐藏代价：每次查询都从零开始

主流的 “AI + 知识库” 范式叫 RAG（Retrieval-Augmented Generation）：把文档切片、做 embedding、查询时按相似度召回若干片段、塞进 prompt 让 LLM 回答。

这个流程在 demo 里很漂亮，但用久了你会发现一个隐蔽的问题：

RAG 把”理解”这件事永远推到了查询时刻。

每次你问同一类问题，模型都要从一堆原始切片重新拼出答案。它不会”记住”上次的结论，不会建立跨文档的关联，更不会主动指出”你这里的说法和上次问到的那篇论文矛盾”。

切片、检索、回答——一次性的、用完就扔。

1.2 人类维护 wiki 的悖论

那为什么我们不直接维护一份人写的 wiki？

因为人维护 wiki 有一个普遍规律：维护成本增长比价值快。

• 新建一个页面要 10 分钟，更新所有相关页面要 30 分钟
• 加一个新概念要重排导航
• 链接久了会失效，引用久了会过时
• 三个月后没人记得为什么当时这么分类

绝大多数个人 wiki、团队 wiki、知识库项目都死在这里——不是没有价值，而是维护负担把人压垮了。

1.3 Karpathy 的关键观察

Humans abandon wikis because maintenance burden grows faster than value. LLMs don’t get bored.

这句话是整个模式的支点。

LLM 不会因为”又来一篇文章要 ingest”而疲倦，不会觉得”这个 cross-reference 太琐碎”，更不会因为做 lint 太枯燥就跳过。对人类维护负担最大的部分，恰恰是 LLM 最擅长、最不抵触的部分。

这就给”持续维护的知识库”这件事打开了一个新空间。

---

二、心智模型：三层架构

LLM Wiki 的整个架构只有三层，但每一层的角色都需要严格区分。

┌──────────────────────────────────────────┐
│  Layer 3: Schema  (CLAUDE.md / AGENTS.md)│  ← 约定层：定义 wiki 怎么长
├──────────────────────────────────────────┤
│  Layer 2: The Wiki                       │  ← 知识层：LLM 持续读写
│  (markdown pages, index, log)            │
├──────────────────────────────────────────┤
│  Layer 1: Raw Sources                    │  ← 素材层：只读不改
│  (articles, papers, screenshots, ...)    │
└──────────────────────────────────────────┘

2.1 Raw Sources（素材层）—— 只读不改

外部世界送进来的所有原始材料：网页文章、PDF 论文、截图、聊天记录、视频字幕……

铁律：LLM 永远不修改这一层。 它是你这份知识库的”事实底座”，需要可被反复回查、可被审计。一旦 LLM 可以改它，整套体系就失去了可信锚点。

实践上建议：

• 用 Web Clipper 一类工具把网页转成 markdown 存档
• 图片本地化，避免外链失效
• 给每份素材一个稳定的标识（文件名 + 日期）

2.2 The Wiki（知识层）—— LLM 持续读写

这一层是 LLM 的工作台。它由一堆相互链接的 markdown 页面组成，每页可能是：

• 一篇 source 的摘要
• 一个 entity（人、项目、库、概念）的画像
• 一个 topic 的综述
• 一个 question 的累积答案

关键转变在这里：在 RAG 里，模型每次查询都从 raw sources 重新拼答案；在 LLM Wiki 里，模型把”理解过程”本身写下来、存起来、下次直接用。

写比读贵。LLM Wiki 把”贵”的部分摊销到了 ingest 阶段，让查询变得便宜而高质量。

2.3 The Schema（约定层）—— 一个文件控制全部

这是整个架构的杠杆点：一份 CLAUDE.md（或 AGENTS.md）文件，定义了 wiki 的目录结构、命名规范、page 模板、cross-reference 风格，以及三种核心操作（ingest / query / lint）的步骤。

LLM 每次工作前都会读这份 schema，并按它行事。

这意味着： 你不需要给 LLM 写代码，你只需要写一份”工作手册”。修改 schema 就是修改 LLM 的行为。

2.4 三种范式对照

维度	传统人写 wiki	RAG	LLM Wiki
写入频率	低，靠人	一次性预处理（embedding）	高，每次 ingest 都触及多页
跨文档关联	靠人手工链接	几乎没有	LLM 主动维护 cross-refs
查询成本	低（直接读）	中（向量召回 + 拼接）	低（已沉淀好的 page）
维护成本	高，最终崩溃	低，但理解永远不沉淀	几乎为零（LLM 来做）
可审计性	高	低（embedding 是黑盒）	高（全是 markdown）

---

三、三个核心操作

LLM Wiki 的所有日常工作都可以归到三个动词上：ingest、query、lint。schema 文件需要为每一个都写明细。

3.1 Ingest：把新素材消化进 wiki

输入：一份新的 raw source（文章 / 论文 / 截图）。 步骤：

1. 读这份素材
2. 在 wiki 里创建或更新这份素材对应的 summary page
3. 识别其中提到的 entity / concept，更新对应 page
4. 维护 cross-reference 链接
5. 更新 index.md，追加 log.md

副作用：一次 ingest 通常会触及 10–15 个 wiki 页面。这正是 LLM 最闪光的地方——人类做这件事会想哭，LLM 不在乎。

反模式：

• 把 ingest 写成”只摘要这一篇”——失去了跨页关联的价值
• 让 ingest 修改 raw source ——污染事实底座
• 一篇 source 配一页 wiki 的一一对应——退化成普通笔记

3.2 Query：从 wiki 取答案，并回流新发现

输入：用户的一个问题。 步骤：

1. 先读 index.md，定位相关 page
2. 读这些 page，综合出答案，带 citation
3. 如果发现”这个回答里有值得沉淀的新东西” —— 比如一个新的关联、一个新的概念定义、一段值得收藏的对比 —— 把它作为新 page 写回 wiki
4. 追加 log.md

第 3 步是这个模式区别于 RAG 的核心特征：查询不只是消费 wiki，也是 wiki 的增长动力。 每次提问都让 wiki 更聪明一点。

3.3 Lint：周期性健康检查

输入：整份 wiki。 步骤：扫一遍，找出

• 自相矛盾的断言
• 已经过时的事实
• 没有任何页面链接指向的孤儿页
• 缺失的 cross-reference
• 数据空洞（“这一类话题我们一篇都没收”）

为什么需要这一步：ingest 和 query 都是局部操作，时间长了一定会积累全局的不一致。lint 是把”全局视角”显式塞进 LLM 工作流的方式。

每周、每月跑一次都行——反正它不嫌烦。

---

四、两个支撑文件

整套系统能跑起来，除了三种操作之外，还依赖两个特殊文件。它们看起来像基础设施，但作用比看上去大得多。

4.1 index.md —— 内容目录而非文件目录

这不是 ls -R 的输出，不是文件系统的镜像。它是按内容组织的目录：

## Concepts
- [RAG](concepts/rag.md) — retrieval-augmented generation 的基本流程
- [Context Window](concepts/context-window.md) — 上下文窗口与压缩策略

## People
- [Andrej Karpathy](people/karpathy.md) — OpenAI 联创，提出 LLM Wiki 模式

## Sources
- [LLM Wiki gist](sources/karpathy-llm-wiki.md) — 2024

LLM 在回答任何问题前，第一件事是读 index。所以 index 的质量直接决定查询质量。

4.2 log.md —— append-only 时间线

每次 ingest / query / lint 都向 log 追加一行，带统一前缀：

2026-04-06 INGEST karpathy-llm-wiki.md → 12 pages updated
2026-04-06 QUERY  "什么是 sprint contract?" → harness-design.md
2026-04-06 LINT   3 stale claims, 1 orphan page

为什么需要它：

• 时间线可重建：你可以倒推”上周三那次 query 是从哪页拿的答案”
• 用 Unix 工具就能查：grep INGEST log.md | wc -l 告诉你这个月吃了多少素材
• 给 LLM 自己留下”我做过什么”的痕迹，下次会话可以接得上

---

五、为什么这个模式真正有效

到这里你可能会问：很多人都做过类似的事情，为什么这一次值得当回事？我的理解是三个原因。

1. 写比读贵，但只贵一次。

传统 RAG 把 understanding 推到查询时，每次都重新付费。LLM Wiki 把它前置到 ingest，付完一次就不再付。从经济学角度看，这是一次”资本化”——把流动性消耗转成了固定资产。

2. “宽度操作”是 LLM 独有的优势。

人维护 wiki 最痛苦的不是写新内容，而是”改一处 → 找出所有相关页面 → 同步更新”。LLM 一次能加载几十个文件、修改十几处、保持一致——这不是”人加速版”，这是只有 LLM 才能做的工作模式。

3. Schema 是杠杆。

你不需要训练模型，不需要写代码，甚至不需要部署服务。你只要写一份 markdown，告诉 LLM “这里这样组织、那里那样命名、ingest 时这么做”，它就会照办。整套系统的可塑性极高，迭代成本极低。

---

六、How-to：在个人知识库里跑通最小版本

理论说够了。下面给一条最小可行路径——每一步都可以独立做，做一步就有收益。

6.1 第一步：盘点你已经有的

先别急着加东西。看看你现有的笔记 / 博客 / docs 仓库，对照 LLM Wiki 的三层架构问自己：

• 素材层有没有？通常没有——大多数人是边读边写笔记，原文丢了
• 知识层有没有？大概有一些散文章，但缺统一约定
• 约定层有没有？几乎一定没有

最缺的往往是”约定层”和”素材层”。先把这两个补上，知识层会自然受益。

6.2 第二步：起一份 schema 骨架

在仓库根目录新建 CLAUDE.md（或 AGENTS.md），先放一个最小骨架。不要追求一次写完美，写得了就够，后面边用边改。

骨架长这样（占位符你按自己情况填）：

# Wiki Schema

## 目录结构
- raw/         <!-- 原始素材，只读 -->
- wiki/        <!-- LLM 维护的页面 -->
  - concepts/  <!-- 概念 -->
  - people/    <!-- 人物 -->
  - sources/   <!-- 素材摘要 -->
  - topics/    <!-- 主题综述 -->
- index.md     <!-- 内容目录 -->
- log.md       <!-- 操作日志 -->

## Page 模板
<!-- 每页固定格式：title / aliases / related / body -->

## 操作:Ingest
<!-- 收到新素材时按这些步骤做 -->

## 操作:Query
<!-- 回答问题时按这些步骤做 -->

## 操作:Lint
<!-- 健康检查的检查项清单 -->

只有骨架，没有”标准答案”。你要做的是把里面的每个 <!-- ... --> 替换成贴合你领域的具体约定——你写学习笔记？写技术研究？写读书摘抄？schema 都不一样。

6.3 第三步：开一个 raw/ 目录承接素材

把”我以后想读的所有东西”都先存到 raw/。Web Clipper 是一个常用入口，你也可以手动 curl > raw/foo.md。

关键不是工具，是把”原始素材”和”我的理解”在物理上分开。这一步是整个模式可信的前提。

6.4 第四步：跑通一次端到端 ingest

挑一份 raw 文件，让 Claude Code 按你写好的 schema 跑一次 ingest。第一次大概率会发现：

• schema 里某些约定不清晰
• 触及的 page 比你预想的多得多
• index 该怎么组织你之前根本没想过

这些都是好事。改 schema，再试一遍。 三五次之后 schema 就会稳定下来。

6.5 第五步：让 query 反哺 wiki

下次你问 LLM 问题时，要求它：“先读 index，从 wiki 找答案，给 citation；如果发现新东西，写一页新 wiki。”

这一步是把 wiki 从”静态笔记”变成”活的”的关键开关。

6.6 第六步：每周 lint 一次

设个日历提醒，每周让 LLM 把整份 wiki 扫一遍，输出一份 lint 报告。前几次会找出一堆问题——这是健康的。

6.7 一个元示范

事实上，你正在读的这篇文章本身就是一次 ingest 的产物：raw source 是 Karpathy 的 gist，输出是 posts/ai/llm-wiki-pattern.md。如果按 LLM Wiki 模式严格执行，这次操作还应该顺手：

• 在 index.md 的 AI 类目下加一行指向本文
• 在 log.md 追加 2026-04-06 INGEST karpathy-llm-wiki → llm-wiki-pattern.md
• 检查是否有相关概念页（如 concepts/rag.md）需要更新交叉引用

而我现在的 til 仓库还没有 index 和 log——这正是下一步要补的功课。

---

七、边界与陷阱

这个模式很有力，但不是银弹。三类场景需要警惕。

7.1 不适合的场景

场景	为什么不适合
高频变动的实时数据	wiki 的”沉淀”特性会让数据永远过期
需要原文级精度的法律 / 医学	LLM 摘要会损失关键措辞，应直接读 raw
安全敏感凭证 / 私密数据	wiki 的扩散性让审计变难

7.2 和 RAG 不是对立而是互补

不要把这套和 RAG 当成二选一。它们解决不同的问题：

• LLM Wiki 适合”沉淀型”知识——概念、关联、经过时间检验的判断
• RAG 适合”查证型”知识——给我那段原文、给我那一行代码、给我那条数据

两者完全可以共存：wiki 提供理解，RAG 提供原文回查。

7.3 别在第一天追求完美的 schema

最常见的失败模式是花一周设计一份”完美的 schema”——分类详尽、模板严谨、命名统一——然后从来没真正用起来。

正确做法：写一个能跑的最小 schema，立刻开始 ingest，跑出问题再改。schema 是被使用养大的，不是被设计出来的。

---

八、行动清单

读完这篇，你可以立刻做的事情：

• 选一个你已经维护的笔记 / 博客 / docs 仓库
• 在根目录起一份最小 CLAUDE.md schema
• 新建 raw/ 目录，把”我以后想读但还没读”的东西丢进去
• 选一份 raw 文件，让 Claude Code 跑一次 ingest，观察它触及哪些文件
• 根据这次跑的结果修订 schema
• 创建 index.md，让它成为 LLM 查询时第一个读的入口
• 创建 log.md，开始累积操作时间线
• 设一个每周提醒，跑一次 lint
• 一个月后回头看：你的 wiki 长得和你预想的一样吗？哪里超出预期？哪里没用上？

---

写在最后

Karpathy 这篇 gist 的字数其实非常少，但它指向的方向比字数大得多。

主流叙事一直把 LLM 当成”更聪明的搜索引擎”——你问它答，问完就忘。LLM Wiki 在反过来想：如果 LLM 不只是回答问题，而是在你身边持续做笔记呢？如果它读你给它读的所有东西，并把理解一点点地沉淀下来呢？

那你就不再拥有一个会回答问题的助手——你拥有一个会随时间变得更懂你的领域的、持续生长的知识库。

而它最大的优势是：它不会无聊。

---

延伸阅读

• 落地姊妹篇：把 LLM Wiki 模式搬进代码仓库：NextJS 项目的 5 个高价值场景 —— 本文讲的是”个人知识库”场景，那篇专门讲”代码项目”场景下这套模式长什么样（ADR 决策档案、Feature 总图、依赖情报、Bug 档案、Onboarding Wiki），以及哪些事该交给 TypeScript / Prisma / Storybook 而不是 LLM wiki
• 原文：LLM Wiki (gist) by Andrej Karpathy