Andrej Karpathy 在 2026 年 4 月发布了一个 Gist，名为 LLM Wiki，描述了一种用 LLM 构建和维护个人知识库的模式。不到 48 小时，这个 Gist 收获了 5000+ Star 和 1600+ Fork，显然戳中了很多人的痛点。
这篇文章的核心问题很具体：你平时用 NotebookLM、ChatGPT 上传文件或者各类 RAG 系统时，有没有感觉像是在跟一个失忆的助手打交道——每次都要从头解释一遍，什么也没留下来？
RAG 的局限
RAG 的基本逻辑是：用户提问 → 系统从原始文档里检索相关片段 → LLM 生成答案。这个架构有一个根本性的缺陷：每次都在从原材料里重新发现知识，没有任何积累。
如果你的问题需要综合五篇文档、对比三个互相矛盾的观点，RAG 会在每次查询时重新拼凑这些碎片。没有人把它们整合过，没有人标记过矛盾，没有人维护过跨文档的引用关系。
Karpathy 的观察是：这个问题的本质不是检索质量，而是架构选择——系统处于无状态，但真正的知识积累是有状态的。
LLM Wiki 模式
核心思路的转变只有一步：不要让 LLM 在查询时检索，而是让 LLM 在摄入时整合。
具体来说，每当你把新材料添加进来，LLM 不只是把它存档等待查询。它会：
- 读取新材料，提炼关键信息
- 在 Wiki 里写一个摘要页
- 找到所有相关的已有页面，更新它们
- 标记新旧信息之间的矛盾
- 维护交叉引用
这棵知识树是持久存在的，是 LLM 写的，你来读。交叉引用已经在里面了，矛盾已经被标记了，综合已经做过了。每加入一份新材料，这棵树就更完整一些。
Karpathy 的比喻很直接：Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。
三层架构
整个系统分三层：
原始材料层（Raw Sources）
你收集的一切原始文档：文章、论文、数据文件、图片。这一层是不可变的，LLM 只读不写。这是你的事实来源。
Wiki 层
一个 LLM 生成的 Markdown 文件目录。摘要页、实体页、概念页、对比页、全局概述。这一层完全由 LLM 维护：它创建页面、更新页面、维护交叉引用。你来读，LLM 来写。
Schema 层
一个配置文档（比如 CLAUDE.md 或 AGENTS.md），告诉 LLM 这个 Wiki 的结构约定、命名规则、操作流程。这是让 LLM 成为”有章法的 Wiki 维护者”而不是”随便聊天的对话机器人”的关键。它随着你使用 Wiki 的经验一起演进。
三种操作
摄入（Ingest）
你把一份新材料扔进原始材料层，告诉 LLM 处理它。典型流程：LLM 读取材料，和你讨论重点，在 Wiki 里写摘要页，更新索引，更新所有相关实体和概念页，在日志里追加一条记录。一份材料可能触及 10-15 个 Wiki 页。Karpathy 偏好一次处理一份材料并保持参与，但也可以批量摄入。
查询（Query）
你问问题，LLM 搜索相关页面，读取，综合出带引用的答案。答案可以以多种形式呈现——Markdown 页、对比表、Marp 幻灯片、matplotlib 图表。关键洞察：好的答案本身可以被存回 Wiki 作为新页面。 你的探索也在持续积累到知识库里。
维护（Lint）
定期让 LLM 做健康检查：找矛盾、找过时信息、找孤立页面（没有入链）、找有概念但没有专属页面的词、找数据空缺。LLM 同时会建议值得追问的新问题和值得寻找的新材料。
索引与日志
两个特殊文件帮助 LLM 和你导航不断增长的 Wiki：
index.md 面向内容——Wiki 的目录，每个页面附一行摘要和链接，按分类组织（实体、概念、来源等）。LLM 每次摄入都会更新它。查询时 LLM 先读索引找相关页，再钻入。这在中等规模（约 100 份来源、数百个页面）下效果出乎意料地好，不需要嵌入式 RAG 基础设施。
log.md 面向时间线——只追加不修改，记录发生了什么：摄入、查询、维护过程。如果每条记录用统一前缀开头，比如 ## [2026-04-02] ingest | Article Title，日志就可以用简单的命令行工具解析——grep "^## \[" log.md | tail -5 就能拿到最近 5 条。
工具提示
Obsidian Web Clipper 是一个浏览器扩展，把网页文章转成 Markdown。快速把材料放进原始集合的利器。
本地图片下载：在 Obsidian 设置里把附件目录固定到 raw/assets/，再绑定一个快捷键触发”下载当前文件的附件”。剪藏文章后一键下载图片到本地，LLM 就能直接查看图片而不依赖可能失效的 URL。
图谱视图是看清 Wiki 形状的最好方式——什么连着什么，哪些页面是枢纽，哪些是孤岛。
qmd 是一个本地 Markdown 搜索引擎，HBM25 + 向量混合搜索 + LLM 重排，带 CLI 和 MCP server 两种接口。Wiki 规模增大后可以替代索引文件。
Wiki 本质上就是一个纯 Markdown 的 Git 仓库，版本历史、分支、协作全部免费。
为什么有效
知识库维护最枯燥的不是阅读或思考，而是书记工作：更新交叉引用、保持摘要最新、标记矛盾、维护数十个页面的一致性。人们放弃维护 Wiki 是因为维护成本比收益增长得更快。
LLM 不会厌倦，不会忘记更新某个交叉引用，可以在一次操作里同时修改 15 个文件。Wiki 保持维护是因为维护成本接近零。
人的工作是：筛选材料、指导分析方向、提出好问题、思考这一切意味着什么。LLM 做其余的一切。
Karpathy 提到这个想法在精神上接近 Vannevar Bush 1945 年的 Memex 构想——一种私人的、主动维护的知识存储，文档之间的关联链接和文档本身同样重要。Bush 当时无法解决的问题是：谁来做维护工作？现在 LLM 解决了这个问题。