用Karpathy的LLM Wiki模式，我搭了一个会自己生长的研究大脑
- 先说痛点—你可能也有的那个”research”文件夹
- 为什么RAG不够
- Karpathy的洞见：让AI当图书管理员
- 三层架构：什么放哪，为什么
- 三个核心操作
- Obsidian的角色：窗口，不是大脑
- 实战：作者两周的真实经验
- 会断的地方和怎么修
- 两周后的改变
- 更大的图景
先说痛点—你可能也有的那个”research”文件夹
你有一个叫”research”或”阅读资料”或”ai-stuff”的文件夹。里面有四十七个Markdown文件、六篇早就想总结但一直没动的PDF、三个导出过一次就再也没打开的Notion页面，还有一个叫”重要”的浏览器书签文件夹——里面的链接来自2023年。
你知道里面有一篇关于注意力机制的文章，和一篇关于MCP服务器的东西。你几乎确定这两者之间有联系——但你不知道当时记在哪了，也不知道到底有没有记过。
你不是不整理。你是被信息淹没了。这两者有本质区别。
为什么RAG不够
大多数人跟LLM和文档的互动方式是RAG：你把一堆文件上传，LLM在查询时检索相关段落，生成答案。
这能工作，但每次查询LLM都是从零重新发现知识。没有积累。没有成长。问一个需要综合五篇文档的微妙问题，LLM每次都要重新找到相关内容、拼凑在一起。什么都没有被构建起来。
我用了这个模式好几个月。NotebookLM处理论文。ChatGPT文件上传处理会议笔记。一堆永远不会再看第二眼的Claude对话。每一次都是一次性交易——我问一个问题，得到一个答案，关掉标签页，两周后我把同一批论文重新上传，问几乎同样的问题，因为之前综合出的东西没有在任何地方持久保存。
Karpathy的洞见：让AI当图书管理员
2026年4月，Andrej Karpathy在GitHub上丢了一个Gist，就叫”LLM Wiki”。不是新产品、不是新框架、不是SaaS——就是一个”思路文件”，一种设计模式，贴进Claude Code或者Codex里就能用。
核心思路的转变：
过去：你维护知识库，偶尔问AI问题。 现在：AI构建和维护整个知识库，你只管丢原始资料。
Karpathy用的类比来自软件工程：编译。你写源代码，编译器把它变成优化过的二进制产物。你不会每次运行源代码——你编译一次，分发产物，在需要时高效执行。编译步骤很贵，但在后续每一次使用中都值回票价。
在这里，编译后的产物不是二进制。是Wiki——一个文件夹的可读Markdown文件，每个概念一个页面，相互交叉引用，由模型维护，在Obsidian中查看。
RAG检索然后遗忘。Wiki积累然后复利。
三层架构：什么放哪，为什么
my-wiki/
├── raw/ # 原始资料（你维护，不可变）
│ ├── papers/
│ ├── articles/
│ └── notes/
├── wiki/ # 知识层（AI写，你读）
│ ├── entities/
│ ├── concepts/
│ ├── sources/
│ ├── index.md
│ └── log.md
└── CLAUDE.md # 规则层（操作手册）
第一层：raw/ — 原始资料
论文PDF、文章、笔记、播客文字稿全部放在这里。这层不可变——不编辑，不修改，只追加。
不可变不是审美选择，是设计决策。它意味着你随时可以从原始资料重新派生出整个Wiki。如果需要重建、发现AI出了错，你永远不会丢失原始内容。
第二层：wiki/ — 知识层
这是AI生成的Markdown文件，按类型分目录：
- entities/: 人物、组织、项目
- concepts/: 核心概念、方法、理论
- sources/: 每篇资料的总结页
每个页面内部有[[wikilinks]]交叉引用。一页可能关联到10~15个其他页面。
第三层：CLAUDE.md — 规则层
这是整个系统的灵魂。它把通用的LLM变成一个有纪律的知识工作者。
CLAUDE.md定义了：
- 页面类型（实体、概念、来源、综合）
[[wikilinks]]的命名规范- 何时新建页面 vs 更新现有页面
- lint检查清单
第一版写得比较粗糙。但经过几十次导入和几次lint之后，它会变成反映你领域实际运作方式的schema。
三个核心操作
1. 导入（Ingest）— 一份资料触达10~15页
你丢一个新资料进raw/，告诉Claude处理它。然后Claude：
- 读完整篇资料
- 跟你讨论核心观点和重点
- 在wiki里写一个摘要页
- 更新index页面
- 更新所有相关的实体和概念页面
- 在log中追加一条记录
一份资料可能触达10~15个Wiki页面。
Karpathy偏好一份一份导入，并在过程中保持参与——读摘要，检查更新，指导AI哪些该强调。第一次导入是一场对话，不是一次批处理。Claude总结完论文后，会建议创建五个概念页，并询问是否需要为某个特定数据集单独建页。这是编辑决策。模型主动询问是对的。
2. 查询（Query）— 质量碾压RAG
LLM不是从某个PDF第14页随机切一段出来。它读的是已经综合好了、交叉引用的百科条目，这些条目已经整合了系统所有所学。
作者问了一个典型问题：“关于上下文窗口长度和AI Agent可靠性的关系，我读过的所有资料都说了什么？”
Claude做了三件事：
- 读了index，定位到6个相关Wiki页面
- 引用4篇不同论文，按名字引用
- 标出了一个矛盾——两篇论文在这个问题上立场相反
还有一个关键设计：--save标记。当开启时，一次有价值的综合查询结果会被自动归档为新的Wiki页面。未来会话立即受益。Karpathy把这称为”复利原则”——你问了一个问题，系统回答了，现在Wiki也知道答案了。
3. 健康检查（Lint）— 每周8分钟的保养
没人爱做维护，这就是为什么人在做的时候Wiki最终会腐烂。但LLM做这个只需8分钟。
定期让AI健康检查Wiki，它会找：
- 页面之间的矛盾
- 被新资料推翻的过时断言
- 没有入链的孤立页面
- 被频繁提及但没有独立页面的概念
- 丢失的交叉引用
- 需要补充搜索填补的知识空白
作者在12天后做了第一次lint。AI发现了：
- 3个矛盾——其中一个第一周和第二周导入的论文之间的真实分歧，作者完全没有注意到
- 2个孤立页面
- 4个被跨页引用但没有独立页面的概念
全程约8分钟。
在lint中标记矛盾，LLM花3分钟。而那个导致每份人维护的Wiki最终腐烂的知识管理开销，彻底消失了。剩下的是真正属于人的部分：筛选资料、决定哪些重要、问正确的问题、思考这一切意味着什么。LLM处理其他一切。
Obsidian的角色：窗口，不是大脑
这里有一个关键区别：Claude Code是大脑，Obsidian是窗口。
Obsidian作为Wiki的IDE存在。它渲染带反向链接的Markdown，显示页面之间的图视图，支持全文搜索，文件变更时实时刷新。
你始终处于阅读模式，从不处于编辑模式。你浏览、跟链接、看图、阅读。你从不直接编辑Wiki文件。
图视图是那个能转变怀疑者的功能。两周后，87个页面——图视图显示出了自然的聚类：围绕Transformer架构的、围绕Agent记忆的、围绕评估文献的。特定页面作为聚类之间的桥梁。作者没有设计这些聚类——模型通过跟踪文献中实际一起讨论的内容，自主发现了这些结构。
实战：作者两周的真实经验
| 指标 | 数值 |
|---|---|
| 时间投入 | 首次搭建~2小时，后续每次导入15分钟 |
| 导入资料 | 34份（论文、文章、YouTube字幕、播客笔记） |
| 生成页面 | 87个（作者一个都没自己写） |
| 首次lint | 12天后，8分钟，发现3个矛盾+2个孤立页+4个缺失概念 |
| token消耗 | 导入阶段约5~8倍原始token量，查询阶段极低 |
会断的地方和怎么修
Schema在第三天跟你打架
第一个版本的CLAUDE.md太抽象了。几次导入后，模型创建页面的结构不一致——有些有”Key Claims”章节，有些有”Main Arguments”，意思一样但命名不同。修复方法：标准化章节名。模型会严格遵循schema说什么，所以schema必须说清楚。
认知漂移
如果AI在导入时误解了一份资料——误解、幻觉出的连接——这个错误会进入Wiki，影响后续导入。Lint操作能减轻但不能消除。通过git diff进行人工审核是真正的安全网。作者在每次导入后跑git diff，花90秒，两周内抓住了两次错误。
规模上限：约100~200份资料
Karpathy建议Wiki包含大约100篇文章以确保系统保持高效。超过这个规模，可能需要LLM Wiki v2的扩展（混合搜索、多Agent治理）或专门的RAG管线。
好消息是：200份精选资料，经过正确的编译和交叉引用，比2000份在RAG系统中每次都从零检索的原始文档有用得多。
导入成本前置
导入步骤是token消耗最集中的地方。一份10页的PDF可能触发12个Wiki文件的更新。预算大约是原始token量的5~8倍。但后续查询极为便宜——通常只需要index.md加2~3个概念页。
两周后的改变
我停止了丢失东西。
听起来很平凡？其实不然。在这个系统之前，每篇读过的有趣论文都处于逐渐衰减的状态——刚读那天最有用，此后每周都在退化。
两周后，相反的事正在发生。每份新资料都让现有资料更容易被发现，因为导入过程会明确更新所有相关页面。第一天读的论文现在在11个后来添加的Wiki页面上被交叉引用。它比刚读的时候更有连接了。
Karpathy本人几乎从不直接编辑Wiki文件。他把Wiki视为”AI的领地”。AI写、更新、维护。Karpathy只读。
那个让系统有效的纪律：你一旦开始手动编辑Wiki页面，你就在AI自己的领土上和它竞争，并且失去了让整个系统可行的维护自动化。
更大的图景
Karpathy还提到了一个未来方向：用Wiki生成合成训练数据，微调一个LLM，让它”在权重中知道”这些数据，而不仅仅通过上下文窗口理解。这意味着把个人知识库变成个性化模型。
那个未来比Gist听起来要远一些。但当前的版本——一个自愈、交叉引用、AI维护的Wiki，跑在你本机的一个文件夹里——已经是作者用过的最好的知识管理系统。
Memex终于可以建造了。不是因为我们有了更好的文档或更好的搜索，而是因为我们有了真正干活的图书管理员。
Vannevar Bush在1945年描述了Memex。Karpathy在2026年4月发布了操作说明。
文件夹就在那里。Gist是公开的。Claude Code有免费层。剩下的只是第一次导入。
原文：I Used Karpathy’s LLM Wiki to Build a Research Brain That Updates Itself，作者 Adi Insights and Innovations。