2026年4月，OpenAI前AI总监Andrej Karpathy在X上发布了一条长帖，标题只有三个词：LLM Knowledge Bases。这条帖子迅速引爆——1500万浏览、4.8万转发、8.8万收藏。两天后他又追加了一篇完整的方法论文档。这不是一个新工具推荐，而是一套”用LLM管理知识”的全新方法论——LLM Wiki。
一、一句话说清楚：LLM Wiki 是什么
说白了就是：你把各种原始资料（文章、论文、笔记、图片）丢给LLM，LLM帮你把这些资料”编译”成一个结构化的Markdown Wiki——带分类、带摘要、带交叉链接、带索引。
用Karpathy自己的类比：Obsidian是IDE，LLM是程序员，Wiki是代码库。你几乎不直接编辑Wiki，那是LLM的领地。
LLM Wiki = 让大模型自动维护一个结构化、可迭代、互相关联的持久化知识库。
二、LLM Wiki vs 传统RAG：核心区别
| 维度 | 传统RAG | LLM Wiki |
|---|---|---|
| 知识存储 | 原始文档碎片化检索 | 编译成结构化Wiki页面 |
| 知识积累 | 每次从零检索，用完即忘 | 持续积累，知识会”长” |
| 实体关系 | 缺乏关联 | 自动交叉引用和链接 |
| Token消耗 | 反复读长文本 | 基于索引精准定位 |
| 幻觉控制 | 容易拼凑出错误信息 | 可人工审核、版本控制 |
| 基础设施 | 需要向量数据库+嵌入模型 | 只需Markdown文件+LLM |
简单理解：RAG是临时翻书，LLM Wiki是AI帮你整理了一本不断更新的内部百科。
三、三层架构：Raw → Wiki → Schema
Karpathy把整个系统拆成了三层，每层职责分明：
第一层：Raw Sources（原始资料）
你的资料库——文章、论文、图片、数据文件，什么都往里丢。这一层是不可变的，LLM只读不写，这是你的信息源头。
实操上，Karpathy用Obsidian Web Clipper浏览器插件把网页文章一键转成Markdown，再用快捷键把文章里的图片全部下载到本地。这样LLM就能直接读图，不用依赖可能失效的外链。
第二层：Wiki（知识库）
LLM生成和维护的Markdown文件集合，包括：
- 摘要页、实体页、概念页
- 对比分析、综述文章
- 索引文件（index.md）
- 操作日志（log.md）
所有页面之间有交叉链接。关键点：这一层完全由LLM拥有。你读，它写。每次新增一个原始资料，LLM不只是写一篇摘要，它会更新所有相关的实体页、概念页，标注新旧数据的矛盾，维护交叉引用。一个新资料可能触发10-15个页面的更新。
第三层：Schema（规则文件）
一个配置文档（比如Claude Code的CLAUDE.md），告诉LLM Wiki的结构规范、命名约定、工作流程。这是让LLM从”通用聊天机器人”变成”专业Wiki维护员”的关键。你和LLM一起迭代这个文件，越用越精确。
四、三大核心操作：Ingest、Query、Lint
1. Ingest（摄入）
往raw目录丢一个新资料，让LLM处理它。LLM会读原文，写摘要页，更新索引，然后扫一遍Wiki里所有相关页面做增量更新。Karpathy说他更喜欢一次处理一个资料，全程参与——读LLM写的摘要，检查更新，引导LLM该强调什么。
2. Query（查询）
对着Wiki提问。LLM先读索引文件找到相关页面，再深入阅读，最后综合回答。答案可以是Markdown文档、对比表格、图表——取决于你问什么。
聪明之处：好的回答可以反哺Wiki。你做了一个对比分析，觉得有价值？存回Wiki变成新页面。你的每次提问都在给知识库”加料”，不会消失在聊天记录里。
3. Lint（健康检查）
定期让LLM给Wiki做体检：
- 找矛盾的数据、过时的结论
- 发现没有入链的孤立页面
- 识别被提到但还没有独立页面的概念
- 建议可以用网络搜索补充的数据缺口
Karpathy说LLM很擅长”建议你接下来该研究什么”——这就是自动化的知识图谱扩展。
五、索引的秘密：为什么不需要RAG
很多人第一反应是：Wiki大了之后，LLM怎么找到相关内容？不需要向量数据库和RAG吗？
Karpathy的回答出乎意料：不需要。至少在他的规模下（约100篇文章，40万字）不需要。秘密在两个文件：
- index.md：内容索引。每个Wiki页面一行，包含链接、一句话摘要、分类标签。LLM回答问题时先读这个文件，就知道该去看哪些页面。
- log.md：操作日志。按时间记录每次摄入、查询、检查的操作。格式统一，用grep就能快速回溯。
这个方案妙在哪？LLM自己维护索引，索引质量随着Wiki成长自动提升。不需要额外基础设施，一个目录的Markdown文件就够了。
六、真实案例：Farzapedia——2500条日记变成400篇文章
一个叫Farza的开发者把2500条日记、Apple Notes笔记和部分iMessage对话喂给LLM，生成了一个关于自己的个人Wikipedia——400篇详细文章，覆盖朋友、创业项目、研究方向，甚至他喜欢的动漫对他的影响。所有文章之间都有反向链接。
有意思的是，Farza说这个Wiki不是给自己看的——是给他的AI Agent用的。他举了个例子：设计新产品的落地页时，他问Agent”去看看最近启发我的图片和电影，给我一些文案和视觉方向的建议”。Agent从Wiki里翻出了他关于吉卜力纪录片的笔记、他截图过的YC公司落地页、还有他几年前保存的1970年代Beatles周边设计，然后给出了一个融合这些灵感的方案。
Farza之前用RAG做过类似的系统，他的原话是”it was ass”（烂透了）。文件系统结构的Wiki让Agent能真正理解和导航知识，比向量检索靠谱得多。
七、社区实战经验：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. 每种实体类型一个模板
人物页、事件页、文档摘要页需要不同的字段结构。定义好每种实体类型的必填字段，LLM会严格遵守，Wiki的结构一致性就有了保障。
4. 每个任务产出两个输出
这条最关键。用户问了一个分析问题，LLM给出答案——这是输出一。输出二是把相关发现更新回Wiki对应的文章。如果不在Schema里明确要求这一点，LLM做完分析就把知识丢在聊天记录里了。
5. 从第一天就设计跨域标签
如果你的知识可能跨多个项目、客户或研究领域，在frontmatter里加domain标签。出现在多个领域的共享实体（人物、组织、概念）会成为知识图谱里最有价值的节点。
6. 人类负责验证
LLM可以在不引用来源的情况下做综合，你不仔细看根本发现不了。在Schema里强制要求来源引用，定期抽查Wiki内容。LLM是作者，你是主编。
八、GitHub上的落地项目推荐
| 项目 | 特点 | 适合场景 |
|---|---|---|
| karpathy/gist | 思想源头，完整方法论 | 理解底层逻辑 |
| SamurAIGPT/llm-wiki-agent | 多Agent协作，Git版本控制 | 直接搭建个人知识库 |
| abubakarsiddik31/axiom-wiki | 生产级模块化架构 | 线上稳定部署 |
| skyllwt/OmegaWiki | 多模型切换，插件化 | 追求灵活度 |
| Pratiyush/llm-wiki | 从Claude Code/Cursor会话自动构建 | 开发知识沉淀 |
| emgiezet/llmwiki | 项目目录扫描，架构图生成 | 代码库知识管理 |
九、快速上手路径
如果你想自己搭一个LLM Wiki，这是最小可用路径：
Step 1：准备工具
安装Obsidian + Obsidian Web Clipper浏览器插件。在Obsidian设置里把附件目录指定到raw/assets/，绑一个快捷键用来下载文章图片。
Step 2：创建目录结构
raw/ → 放原始资料 wiki/ → LLM生成的知识页面 wiki/index.md → 内容索引 wiki/log.md → 操作日志 CLAUDE.md → Schema规则
Step 3：写Schema
把Karpathy的Gist文档直接丢给你的LLM Agent，让它帮你生成一份适合你领域的Schema。告诉它你的研究方向、你想要的页面类型、你偏好的工作流程。
Step 4：开始摄入
丢第一篇资料进raw/，让LLM处理。检查生成的Wiki页面，调整Schema，再丢第二篇。前5-10篇资料是调校期，之后就顺了。
Step 5：日常使用
在Obsidian里浏览Wiki，在LLM Agent里提问和摄入新资料。定期跑一次Lint。
不需要向量数据库，不需要RAG框架，不需要部署服务。一个目录的Markdown文件加一个LLM Agent，就这样。
十、局限性与反思
- 规模上限不明确：Karpathy自己的Wiki大概100篇文章、40万字。再大一个量级会怎样？索引文件还够用吗？
- 对LLM能力有要求：这套方法论默认你用的是顶级模型（Claude、GPT-4级别）。小模型跑Ingest和Lint效果可能打折扣。
- 冷启动需要耐心：前5-10篇资料的摄入过程需要你深度参与，调校Schema和Wiki结构。不是”丢进去就能用”的东西。
- 验证成本容易被低估：LLM会在不引用来源的情况下做综合。如果你用这个系统做严肃研究或商业决策，抽查验证的时间要算进去。
十一、历史回响：80年前就有人想到了
Karpathy在Gist文档的最后提到了Vannevar Bush 1945年发表的文章”As We May Think”和他提出的Memex概念。
Bush当年设想了一种个人知识设备：用户可以存储所有书籍和记录，在任意两个条目之间建立永久链接，形成”思维路径”（trails）。这些路径可以分享给别人，别人可以在自己的Memex里继续扩展。
听起来是不是很像LLM Wiki？关联索引、个人知识库、可分享的知识路径。Bush在80年前就想清楚了。他没解决的问题是：谁来做维护？
LLM补上了这最后一环。
总结
LLM Wiki不是一个新的向量数据库，也不是某家大厂的封闭产品，而是一套由AI先驱提出的知识管理方法论：将原始资料作为只读输入，由LLM主动构建并持续维护一个结构化、相互链接的Markdown Wiki作为中间层，实现知识的“一次编译、持续复用、复利增长”。
如果你经常需要在某个领域持续积累和检索知识，Karpathy的LLM Wiki模式值得一试。它不是一个工具，是一种思路——把LLM从”问答机器”变成”知识编译器”。
Obsidian + 任意LLM Agent + 一个目录的Markdown文件，门槛不高，上限很高。
