> ## Documentation Index > Fetch the complete documentation index at: https://adonis-til.mintlify.app/llms.txt > Use this file to discover all available pages before exploring further. # 让 LLM 持续维护你的知识库：Karpathy LLM Wiki 模式精读与落地指南 > 解读 Andrej Karpathy 的 LLM Wiki 模式，分析它和 RAG 的本质差异、三层架构（raw / wiki / schema）、ingest/query/lint 三种核心操作，并给出在个人知识库中跑通最小可用版本的落地路径 > 原文：[LLM Wiki: A Pattern for AI-Maintained Knowledge Bases](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) 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`），先放一个最小骨架。**不要追求一次写完美**，写得了就够，后面边用边改。 骨架长这样（占位符你按自己情况填）： ```markdown theme={null} # Wiki Schema ## 目录结构 - raw/ - wiki/ - concepts/ - people/ - sources/ - topics/ - index.md - log.md ## Page 模板 ## 操作: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 个高价值场景](./llm-wiki-in-code-projects.md) —— 本文讲的是"个人知识库"场景，那篇专门讲"代码项目"场景下这套模式长什么样（ADR 决策档案、Feature 总图、依赖情报、Bug 档案、Onboarding Wiki），以及哪些事该交给 TypeScript / Prisma / Storybook 而不是 LLM wiki * **原文**：[LLM Wiki (gist)](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) by Andrej Karpathy