4 月 3 日，Andrej Karpathy 在 X 上发了一条长帖，标题就三个词：LLM Knowledge Bases。
这条帖子的数据有点夸张——1500 万浏览，4.8 万转发，8.8 万收藏。两天后他又追加了一篇完整的方法论文档，放在 GitHub Gist 上，评论区也炸了。
我花了一天时间把原帖、Gist 文档、社区讨论全部读了一遍。这不是一个新工具推荐，是一套"用 LLM 管理知识"的方法论。读完之后我有点被刷新——原来 LLM 最该干的事，可能不是帮你写代码，而是帮你"编知识"。
下面把这套东西拆开看看。
一句话说清楚：LLM Wiki 是什么
说白了就是：你把各种原始资料（文章、论文、笔记、图片）丢给 LLM，LLM 帮你把这些资料"编译"成一个结构化的 Markdown wiki——带分类、带摘要、带交叉链接、带索引。
跟 RAG 的区别在哪？RAG 是每次提问都从原始文档里临时检索拼凑答案，知识不会积累。LLM Wiki 是提前把知识"编译"好，存成持久化的 wiki 文件，每次新增资料都会更新已有的页面。知识是会"长"的。
用 Karpathy 自己的类比：Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。你几乎不直接编辑 wiki，那是 LLM 的领地。
三层架构：Raw → Wiki → Schema
graph TB
subgraph 架构["三层架构"]
direction TB
RAW["Raw Sources<br/>原始资料<br/>文章 / 论文 / 图片 / 数据"]
WIKI["Wiki<br/>知识库<br/>摘要页 / 实体页 / 概念页 / 索引"]
SCHEMA["Schema<br/>规则文件<br/>结构规范 / 命名约定 / 工作流程"]
end
subgraph 操作["三大操作"]
direction TB
INGEST["Ingest 摄入<br/>新资料 → 摘要 → 更新关联页面"]
QUERY["Query 查询<br/>读索引 → 定位页面 → 综合回答"]
LINT["Lint 健康检查<br/>找矛盾 / 孤立页 / 数据缺口"]
end
RAW -->|LLM 只读| WIKI
SCHEMA -->|约束| WIKI
INGEST --> WIKI
QUERY --> WIKI
LINT --> WIKI
QUERY -.->|好回答存回| WIKI
classDef default fill:#EBF2F8,stroke:#0F4C81,stroke-width:1.5px,color:#1a1a1a,font-size:13px
classDef primary fill:#0F4C81,stroke:#0A3660,stroke-width:2px,color:#fff,font-size:13px
classDef secondary fill:#D4E4F1,stroke:#0F4C81,stroke-width:1.5px,color:#1a1a1a,font-size:13px
class RAW,SCHEMA default
class WIKI primary
class INGEST,QUERY,LINT secondary
style 架构 fill:#FAFCFE,stroke:#0F4C81,stroke-width:1px,color:#0F4C81
style 操作 fill:#FAFCFE,stroke:#0F4C81,stroke-width:1px,color:#0F4C81
Karpathy 在 Gist 文档里把整个系统拆成了三层，每层职责分明：
第一层：Raw Sources（原始资料）
你的资料库。文章、论文、图片、数据文件，什么都往里丢。这一层是不可变的——LLM 只读不写，这是你的信息源头。
实操上，Karpathy 用 Obsidian Web Clipper 浏览器插件把网页文章一键转成 Markdown，再用快捷键把文章里的图片全部下载到本地。这样 LLM 就能直接读图，不用依赖可能失效的外链。
第二层：Wiki（知识库）
LLM 生成和维护的 Markdown 文件集合。包括：摘要页、实体页、概念页、对比分析、综述文章、索引文件。所有页面之间有交叉链接。
关键点：这一层完全由 LLM 拥有。你读，它写。每次新增一个原始资料，LLM 不只是写一篇摘要，它会更新所有相关的实体页、概念页，标注新旧数据的矛盾，维护交叉引用。一个新资料可能触发 10-15 个页面的更新。
第三层：Schema（规则文件）
一个配置文档（比如 Claude Code 的 CLAUDE.md），告诉 LLM wiki 的结构规范、命名约定、工作流程。这是让 LLM 从"通用聊天机器人"变成"专业 wiki 维护员"的关键。你和 LLM 一起迭代这个文件，越用越精确。
三大核心操作：Ingest、Query、Lint
架构搭好之后，日常使用就围绕三个动作展开。
Ingest（摄入）
往 raw 目录丢一个新资料，让 LLM 处理它。LLM 会读原文，写摘要页，更新索引，然后扫一遍 wiki 里所有相关页面做增量更新。
Karpathy 说他更喜欢一次处理一个资料，全程参与——读 LLM 写的摘要，检查更新，引导 LLM 该强调什么。当然你也可以批量丢一堆资料让 LLM 自己处理，看你的风格。
Query（查询）
对着 wiki 提问。LLM 先读索引文件找到相关页面，再深入阅读，最后综合回答。答案可以是 Markdown 文档、对比表格、Marp 幻灯片、matplotlib 图表——取决于你问什么。
这里有个我觉得很聪明的地方：好的回答可以反哺 wiki。你做了一个对比分析，觉得有价值？存回 wiki 变成新页面。你的每次提问都在给知识库"加料"，不会消失在聊天记录里。
Lint（健康检查）
定期让 LLM 给 wiki 做体检：找矛盾的数据、过时的结论、没有入链的孤立页面、被提到但还没有独立页面的概念、可以用网络搜索补充的数据缺口。
Karpathy 说 LLM 很擅长"建议你接下来该研究什么"。想想看，这就是自动化的知识图谱扩展。
索引的秘密：为什么不需要 RAG
很多人第一反应是：wiki 大了之后，LLM 怎么找到相关内容？不需要向量数据库和 RAG 吗？
Karpathy 的回答出乎意料：不需要。至少在他的规模下（约 100 篇文章，40 万字）不需要。
秘密在两个文件：
- index.md：内容索引。每个 wiki 页面一行，包含链接、一句话摘要、分类标签。LLM 回答问题时先读这个文件，就知道该去看哪些页面。
- log.md：操作日志。按时间记录每次摄入、查询、检查的操作。格式统一（比如
## [2026-04-02] ingest | 文章标题），用 grep 就能快速回溯。
这个方案妙在哪？LLM 自己维护索引，索引质量随着 wiki 成长自动提升。不需要额外基础设施，一个目录的 Markdown 文件就够了。
当然，wiki 再大一些可能就需要搜索工具了。Karpathy 推荐了 qmd——一个本地 Markdown 搜索引擎，支持 BM25 和向量混合搜索，有 CLI 和 MCP server 两种接入方式。
真实案例：Farzapedia——2500 条日记变成 400 篇文章
光看方法论可能还是抽象。说个真实的例子。
4 月 4 日，一个叫 Farza（@FarzaTV）的开发者发了一条推文，标题是"This is Farzapedia"。他把 2500 条日记、Apple Notes 笔记和部分 iMessage 对话喂给 LLM，生成了一个关于自己的个人 Wikipedia——400 篇详细文章，覆盖朋友、创业项目、研究方向，甚至他喜欢的动漫对他的影响。所有文章之间都有反向链接。
有意思的是，Farza 说这个 wiki 不是给自己看的——是给他的 AI agent 用的。
他举了一个例子：设计新产品的落地页时，他问 agent："去看看最近启发我的图片和电影，给我一些文案和视觉方向的建议。"Agent 从 wiki 里翻出了他关于吉卜力纪录片的笔记、他截图过的 YC 公司落地页、还有他几年前保存的 1970 年代 Beatles 周边设计。然后给出了一个融合这些灵感的方案。
Farza 之前用 RAG 做过类似的系统，他的原话是"it was ass"（烂透了）。文件系统结构的 wiki 让 agent 能真正理解和导航知识，比向量检索靠谱得多。
这条推文也火了：123 万浏览，3825 点赞，4710 收藏。
社区实战经验：6 条生产环境教训
Karpathy 的 Gist 评论区也很精彩。一个叫 bluewater8008 的用户分享了他们团队在生产环境跑了几周 LLM Wiki 后的经验，我觉得比原文还实用：
1. 先分类再提取。 不要把所有文档一视同仁。50 页的报告和 2 页的信件需要不同的处理策略。先按类型分类，再用类型专属的提取流程。这能省大量 token，结果也更好。
2. 给索引设 token 预算。 他们用了四级渐进式披露：L0（约 200 token，项目上下文，每次会话都加载）、L1（1-2K，索引文件，会话开始时加载）、L2（2-5K，搜索结果）、L3（5-20K，完整文章）。关键纪律：不读完索引就不读全文。
3. 每种实体类型一个模板。 人物页、事件页、文档摘要页需要不同的字段结构。他们定义了 7 种实体类型，每种有专属的必填字段。LLM 会严格遵守，wiki 的结构一致性就有了保障。
4. 每个任务产出两个输出。 这条最关键。用户问了一个分析问题，LLM 给出答案——这是输出一。输出二是把相关发现更新回 wiki 对应的文章。如果不在 schema 里明确要求这一点，LLM 做完分析就把知识丢在聊天记录里了。
5. 从第一天就设计跨域标签。 如果你的知识可能跨多个项目、客户或研究领域，在 frontmatter 里加 domain 标签。出现在多个领域的共享实体（人物、组织、概念）会成为知识图谱里最有价值的节点。后期补这个很痛苦。
6. 人类负责验证。 LLM 可以在不引用来源的情况下做综合，你不仔细看根本发现不了。在 schema 里强制要求来源引用，定期抽查 wiki 内容——不只是查最终交付物。LLM 是作者，你是主编。
一个有意思的彩蛋：idea file
Karpathy 在追加推文里提到了一个概念，值得单独说一下。
他说这条推文火了之后，他没有选择开源一个具体的代码仓库，而是写了一个"idea file"——就是那个 Gist 文档。他的理由是：在 LLM agent 时代，分享想法比分享代码更有意义。你把 idea file 丢给你的 agent，agent 会根据你的具体需求定制和构建整个系统。
这条追加推文本身也获得了 2709 转发和 4 万收藏。
想想看，这是一种新的知识传播方式：不是给你一个成品让你 fork，而是给你一个想法让你的 AI 帮你从零构建。每个人得到的实现都不一样，核心模式是一致的。
历史回响：80 年前就有人想到了
Karpathy 在 Gist 文档的最后提到了 Vannevar Bush 1945 年发表的文章"As We May Think"和他提出的 Memex 概念。
Bush 当年设想了一种个人知识设备：用户可以存储所有书籍和记录，在任意两个条目之间建立永久链接，形成"思维路径"（trails）。这些路径可以分享给别人，别人可以在自己的 Memex 里继续扩展。
听起来是不是很像 LLM Wiki？关联索引、个人知识库、可分享的知识路径。Bush 在 80 年前就想清楚了。他没解决的问题是：谁来做维护？
LLM 补上了这最后一环。
想试试？快速上手路径
如果你想自己搭一个 LLM Wiki，这是最小可用路径：
-
准备工具：安装 Obsidian + Obsidian Web Clipper 浏览器插件。在 Obsidian 设置里把附件目录指定到
raw/assets/，绑一个快捷键用来下载文章图片。 -
创建目录结构：
raw/— 放原始资料（用 Web Clipper 剪藏的文章、手动放入的 PDF 和图片）wiki/— LLM 生成和维护的知识页面wiki/index.md— 内容索引wiki/log.md— 操作日志CLAUDE.md（或对应的 agent 配置文件）— schema 规则
-
写 Schema：把 Karpathy 的 Gist 文档（链接见文末）直接丢给你的 LLM agent，让它帮你生成一份适合你领域的 schema。告诉它你的研究方向、你想要的页面类型、你偏好的工作流程。
-
开始摄入：丢第一篇资料进
raw/，让 LLM 处理。检查生成的 wiki 页面，调整 schema，再丢第二篇。前 5-10 篇资料是调校期，之后就顺了。 -
日常使用：在 Obsidian 里浏览 wiki，在 LLM agent 里提问和摄入新资料。定期跑一次 Lint。
不需要向量数据库，不需要 RAG 框架，不需要部署服务。一个目录的 Markdown 文件加一个 LLM agent，就这样。
反思
读完 Karpathy 的方法论，我一直在想一个问题：这套模式放到企业里会怎样？
现在大多数公司的知识库都是"写了没人维护"的状态。Confluence 里躺着三年前的文档，Notion 里的项目记录半年没更新，新人入职翻半天找不到想要的东西。问题不是没人想维护，是维护成本太高——谁愿意每次开完会还要花半小时更新五个相关文档的交叉引用？
LLM Wiki 模式可能真的能解决这个问题。想象一下：会议纪要、Slack 讨论、客户反馈、项目文档全部作为 raw source 喂进去，LLM 自动维护一个结构化的内部 wiki。新人入职直接对着 wiki 提问，LLM 从索引里找到相关页面综合回答。每次有新的会议纪要进来，相关的项目页、人物页、决策记录都自动更新。
当然，企业场景比个人场景复杂得多。数据安全、权限控制、多人协作的冲突处理，这些 Karpathy 的方案都没涉及。但方向是对的：让 LLM 承担知识库的"记账"工作，人只负责输入和决策。
说几个具体的问题：
- 规模上限不明确。 Karpathy 自己的 wiki 大概 100 篇文章、40 万字。再大一个量级会怎样？索引文件还够用吗？LLM 的上下文窗口能不能覆盖？他没说。
- 对 LLM 能力有要求。 这套方法论默认你用的是顶级模型（Claude、GPT-4 级别）。小模型跑 Ingest 和 Lint 效果可能打折扣。
- 冷启动需要耐心。 前 5-10 篇资料的摄入过程需要你深度参与，调校 schema 和 wiki 结构。不是"丢进去就能用"的东西。
- 验证成本容易被低估。 bluewater8008 的第 6 条经验说得对：LLM 会在不引用来源的情况下做综合。如果你用这个系统做严肃研究或商业决策，抽查验证的时间要算进去。
一句话总结
如果你经常需要在某个领域持续积累和检索知识，Karpathy 的 LLM Wiki 模式值得一试。它不是一个工具，是一种思路——把 LLM 从"问答机器"变成"知识编译器"。
Obsidian + 任意 LLM agent + 一个目录的 Markdown 文件，门槛不高，上限很高。
参考资料：
