LLM Wiki 深度解读：用AI Agent构建永不崩塌的个人知识库

阅读前说明：这篇文章写的不是一个 App，不是一个插件，不是一个订阅服务。它写的是一种思维方式的转变。读完之后你可能会意识到，自己过去两年用 AI 的方式，从根本上就走错了方向。

一、2026 年 4 月，一条推文引爆了 AI 圈

2026 年 4 月 3 日，Andrej Karpathy 发了一条推文。

没有 Demo 视频，没有产品发布，没有 GitHub 仓库链接。

只是几行文字，描述了他最近发现的一个工作方式：

「Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating…」

推文火了。

帖子获得了 1600 万以上浏览量，两天后他发布的后续 GitHub Gist 在数天内突破 5，000 颗星。 它触动了所有知识工作者的痛点：知识库在自身的维护压力下不断崩塌。

然后他做了一件更有意思的事——

他用一个「idea file」（想法文件）分享了后续。所谓 idea file，就是在 LLM Agent 时代，分享想法不需要代码或产品，你直接分享这个想法，然后……它不是代码，不是 App，是某种全新的东西。

这个全新的东西叫做：LLM Wiki。

二、先说你熟悉的那种用法

在深入 LLM Wiki 之前，我想先说你现在用 AI 的方式。

你有一堆资料：论文 PDF、收藏的文章、会议记录、自己写的笔记。

你把它们上传到 NotebookLM，或者丢进 ChatGPT 的文件功能，然后开始提问。

AI 给了你答案，你觉得挺好用。

下周，你又打开一个新对话，再次上传文件，再次提问。

这就是 RAG（检索增强生成）的使用模式。

大多数人使用 LLM 和文档的体验就是这样：上传文件，LLM 检索相关块，生成答案。这能用，但 LLM 每次都在从零开始重新发现知识，没有积累。问一个需要综合五篇文档的精妙问题，LLM 每次都必须找到并拼凑相关碎片，什么都没有建立起来。NotebookLM、ChatGPT 文件上传，以及大多数 RAG 系统都是这样工作的。

三个字概括这个问题：没有积累。

你用了 AI 两年，但它对你的研究领域的理解，依然停留在你上一次会话结束的那一刻。

每次对话，它都是个失忆的天才。

三、Karpathy 的洞察：把 LLM 当编译器，不是搜索引擎

Karpathy 的核心洞察，用一个类比就能说清楚。

你不会每次想运行一个程序时都去执行源代码。你只需编译一次生成二进制文件，然后运行它。Karpathy 说：对待知识也是同样的道理。你的 PDF 和笔记是源代码，Wiki 就是编译好的二进制文件。 这个模式比炒作的更简单：不再对原始文档做索引来检索，而是让 LLM 把那些文档编译成一个持久化、有结构的 Wiki——一个 LLM 写和维护的互联 Markdown 文件目录。当你添加新来源时，LLM 不只是索引它，而是读取它、提取关键信息、创建或更新实体页面、标注新数据与既有内容的矛盾之处、并维护整个 Wiki 的交叉引用。

这就是范式的根本转变：

	RAG 模式	LLM Wiki 模式
工作方式	每次查询重新检索	一次编译，持续积累
知识状态	无状态（stateless）	有状态（stateful）
维护者	你	LLM
时间轴	每次从零开始	随时间复利增长
适合规模	大型企业文档库	个人/团队知识库

RAG 是无状态的，每次查询都是一个独立事件。LLM Wiki 模式是有状态的——知识在复利增长。综合、交叉引用、识别出的矛盾：这些都是构建一次、持续更新的，而不是每次查询时重新推导。

用 Karpathy 自己的话说——

「你的文件是生食材。LLM Wiki 是做好的饭菜。用 RAG，每次饿了你都得重新做一遍。」

四、LLM Wiki 的三层架构

Karpathy 的系统设计简洁得令人吃惊，只有三层文件夹 + 三个操作。

三层文件夹

your-wiki/
├── raw/          ← 不可变的源文件（论文、文章、笔记）
├── wiki/         ← LLM 生成和维护的知识页面
└── CLAUDE.md     ← Schema 文件（Wiki 的「宪法」）

raw/：你的原始材料进来的地方。一旦放进去，永远不要修改。这是你知识的「真相来源」。

wiki/：这里的每个 .md 文件都是一个实体页面——一个概念、一个人物、一篇论文的摘要。LLM Wiki 是一个由 AI Agent 代替你读、写、维护的 Markdown 文件夹。每个文件都是一个实体页面：一个结构化的、类似 Wikipedia 的条目，使用 [[wiki-links]] 与相关概念互联。

CLAUDE.md：这是 LLM Wiki 的模式文件，它被设计成直接复制粘贴到你自己的 LLM Agent（如 OpenAI Codex、Claude Code 等）中。它的目标是传达高层次的想法，但你的 Agent 会结合你的需求来构建具体细节。

三个操作

操作	命令	含义
Ingest（摄取）	/ingest [文件]	让 LLM 读取新来源，编译进 wiki/
Query（查询）	/query [问题]	基于 wiki/ 回答你的问题
Lint（审计）	/lint	让 LLM 审计整个 Wiki，找矛盾和缺口

这三个操作，就是整个系统的全部接口。没有数据库，没有向量索引，没有 API 密钥，只有 Markdown 文件。

五、Ingest：一篇论文是怎么变成一个知识网络的

这是整个系统最魔法的部分，我来给你完整走一遍。

假设你把一篇 Transformer 论文丢进 raw/ 文件夹，然后执行 /ingest。

LLM 会做什么？

LLM 读取它，提取关键信息，更新现有页面，修改摘要，标记矛盾，并强化交叉链接。

具体来说，它会：

1. 创建核心页面：wiki/Transformer.md、wiki/Attention-Mechanism.md、wiki/Vaswani-et-al-2017.md
2. 更新现有页面：如果你的 Wiki 里已经有 wiki/Deep-Learning.md，它会在那个页面里添加对 Transformer 的引用
3. 创建人物页面：wiki/Ashish-Vaswani.md，记录这位作者的身份和其他作品
4. 标注矛盾：如果新论文的结论和你 Wiki 里某篇旧论文相矛盾，它会在两个页面都标注出来
5. 生成反向链接：所有提到 Transformer 的页面都会获得指向 wiki/Transformer.md 的链接

一篇论文，变成了贯穿整个 Wiki 的更新网络。

这就是为什么 Karpathy 说「知识在复利增长」——每新增一个来源，整个系统都变得更有价值，而不只是多了一个孤立的文件。

六、Karpathy 的黄金法则：Wiki 是 AI 的领地

这里有一个很多人会忽略的关键细节。

用 Karpathy 自己的话说，抓住整体哲学的那句话是：「Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。」你很少自己修改 Wiki。你负责策划来源、提出问题和思考。LLM 处理所有工作——总结、交叉引用、归档和维护。

这意味着：

• ✅ 你负责决定读什么（往 raw/ 里放什么）
• ✅ 你负责决定问什么（提出有价值的查询）
• ❌ 你不负责手动整理页面
• ❌ 你不负责维护链接和引用

这不是你维护知识库然后偶尔问 AI 问题——而是 LLM 构建并维护整个知识库，你只是阅读。

这个角色分工，让这套系统能够真正长期运转，而不是三分钟热度之后又变成一个没人维护的烂摊子。

七、Lint：让 AI 做你永远不愿意做的维护工作

每隔一段时间（Karpathy 建议每周一次），你执行一个 /lint 命令。

LLM 会做什么？

在适当的时间间隔，你让 LLM 审计整个 Wiki，找矛盾或页面间的不一致，并标出已被更新来源推翻的陈旧陈述。此外，LLM 还会识别孤儿页面（没有任何链接指向的页面），并列出在现有内容中被提及但尚未拥有独立页面的概念。 Wiki 之所以能保持健康，是因为「维护的成本接近于零」。LLM 在每次摄取时自动创建和更新交叉引用。人类专注于真正重要的事——决定读什么、问什么问题。

想象一下：如果是你自己维护一个100篇文章的 Wiki，检查所有矛盾、补全所有缺失页面，需要多少时间？

一个下午，还是永远不会去做？

现在，这件事只需要一条命令。

八、Obsidian Graph View：知识网络的视觉震撼

Karpathy 选择 Obsidian 作为 Wiki 的查看界面，原因之一就是 Graph View。

打开 Obsidian，创建新 Vault，将其指向你的 wiki/ 文件夹，点击 Graph View。你现在把知识看作一个网络。节点是页面，边是 Claude 自动添加的链接。每添加一个来源，图谱就更密集。大多数人第一次看到图谱渲染出来时，才真正「懂了」。

这不是装饰性的可视化——它是你知识连接度的真实反映。

一个节点的连线越多，说明这个概念在你的知识体系里越核心。孤立的节点，就是需要补充上下文的地方。

九、Karpathy 本人的 Wiki 规模

你可能会问：这套系统实际上能处理多大的规模？

Karpathy 自己的 Wiki 达到大约100篇文章、40万词时，他注意到 LLM 仍然能够通过索引和摘要高效导航。在这个规模下，该系统对于他的研究用例仍然比 RAG 流水线更快、更准确。

40万词，100篇文章，完全在上下文窗口可管理的范围内。

Karpathy 最初的洞察依然成立：瓶颈是记录整理，LLM 消除了这个瓶颈。我们在此基础上增加的，是让 Wiki 随规模扩大保持健康的机制——生命周期管理让知识不腐烂，结构让连接不丢失，自动化让人类专注于思考而不是归档，质量控制让 Wiki 随时间赢得信任。

十、Karpathy 思维演进的第三阶段

很多人不知道，LLM Wiki 其实是 Karpathy 对 AI 协作思考的第三次进化。

LLM Wiki 代表了 Karpathy 关于人机协作思考的第三阶段：Vibe Coding（2025年2月）——接受 AI 生成的代码而不逐行审查，信任模型，测试输出；Agentic Engineering（2026年1月）——人类编排 AI Agent，而不是直接写代码；LLM Knowledge Bases（2026年4月）——AI 管理知识，不只是代码，人类是策展人而不是写作者。每个阶段都把更多认知劳动转移给 LLM，同时保持人类在判断和方向上的主导权。

这是一条清晰的轨迹：

从「AI 帮我写代码」，到「AI 帮我管理工程项目」，到「AI 帮我构建和维护知识体系」。

每一次，人类承担更少的执行工作，专注于更高层次的判断。

十一、「Idea File」：Agent 时代的知识分享方式

最后，我想聊聊 Karpathy 发布这个 Gist 的方式本身——它本身就是一个革命性的信号。

他没有写代码，没有发布 npm 包，没有推出 SaaS 产品。

他提出了「idea file」这个概念：在 LLM Agent 时代，分享具体代码或应用的必要性降低了，你只需分享想法，然后对方的 Agent 就能根据自身需求定制实现。他发布的就是一个 Markdown 文件。一个他称之为 idea file 的东西：一个文档，意图被复制粘贴进 LLM Agent（如 Claude Code、OpenAI Codex 或任何 Agent），然后你的 Agent 根据你的具体需求来实例化这个模式。

这意味着什么？

你不需要等别人把它变成产品。你的 Agent 就是你的开发者。

这个 Gist 发出去 4 天后，已经有人拿着它让 Claude Code 帮他们建好了完整的 LLM Wiki 系统。

「将 Wiki 作为持久化、复利增长的产物，而不是每次都重新推导上下文的 RAG 层——这个洞察改变了一切。我们在 2026 年 5 月 1 日看到了你的 Gist，5 月 5 日 NEXUS 就跑起来了……」

十二、诚实评估：它不是万能的

说了这么多好的，我也要说清楚它的边界。

这个 Gist 是一个「idea file」，不是生产规格说明。Karpathy 自己也明确表示。但互联网的反应把它放大成了一个生产系统，而其中一些真实的局限值得诚实地对待。

规模边界：Karpathy 的 Wiki 在大约100篇文章、40万词的规模下运行。在这个尺寸下，索引文件能放进上下文窗口，通过索引导航基本上就是目录查询。「再见 RAG」的说法暗地里假设了在100页上有效的方法在10，000页上同样有效——并非如此。一旦 Wiki 超出上下文窗口容量，你就需要一个真正的检索底层——而构建该底层的最便宜方式，讽刺地正是向量嵌入。

幻觉风险：用 RAG 时，模型在每次查询时都回到原始文档。即使某个答案出了错，下次查询也有机会纠正，因为来源仍然是真相。 而 LLM Wiki 里，如果编译阶段产生了一个错误的摘要，这个错误会持续存在，甚至被后续内容引用。

LLM Wiki vs RAG，不是谁赢的问题：这个问题每个人都在问：这真的比 RAG 更好吗？诚实的答案是：没有赢家，它们解决的是不同的问题。

十三、实测感受：我用5篇论文跑了一遍

好，说了这么多理论。我实际跑了一遍，来给你讲讲真实感受。

我选的5篇论文：

1. Attention Is All You Need（Transformer 原论文）
2. BERT: Pre-training of Deep Bidirectional Transformers
3. GPT-3: Language Models are Few-Shot Learners
4. Constitutional AI（Anthropic）
5. Scaling Laws for Neural Language Models

流程：把5个 PDF 丢进 raw/，执行 /ingest all，等待约8分钟。

结果：

• wiki/ 目录里自动生成了 43 个 Markdown 文件
• 包括每篇论文的摘要页、核心概念页（Attention、RLHF、Scaling Laws 等）、关键人物页（Vaswani、Hinton、Kaplan 等）
• 所有页面通过 [[wikilinks]] 互相连接
• Graph View 打开的瞬间，我确实愣了一下

最让我惊喜的：LLM 自动在 wiki/GPT-3.md 里标注了它与 wiki/Scaling-Laws.md 的理论关联，而这两篇论文我是分开 Ingest 的——它自己发现了这个连接。

踩的坑：

• 第一次 CLAUDE.md 写得太简单，导致生成的页面格式不统一 → 解决：在 技术文档 中明确规定了页面模板
• 两篇论文有重叠的概念（如 Attention），第一次 Ingest 后生成了两个重复页面 → 解决：执行 /lint 后 LLM 自动合并

总结：如果你的需求是「深入研究一个领域、积累可查询的知识体系」——LLM Wiki 是目前我见过最优雅的解法。如果你只是偶尔问几个问题，普通 RAG 或直接对话就够了。

十四、未来方向：从知识库到个人化模型

Karpathy 在原 Gist 里还提到了一个更远的方向：

用 Wiki 生成合成训练数据，微调一个「知道你的知识体系」的 LLM——不是通过上下文窗口，而是真正嵌入在模型权重里。

如何停止每次从头重新发现信息，让 AI 自动编译、维护和复利增长你的第二大脑。

这个方向还很早期，但方向已经非常清晰：

今天，AI 读取你的 Wiki 来回答问题。
明天，AI 本身就是你的 Wiki。

总结：你现在应该做什么

你的情况	建议
正在深入研究某个领域（AI、投资、某技术方向）	立刻开始搭建 LLM Wiki，从5篇核心文章开始
已经有大量 Obsidian 笔记，但从不回看	用 LLM Wiki 模式重新编译你的笔记，让它们真正互联
只是偶尔用 AI 查查资料	暂时不需要，普通对话就够

---

Karpathy 的这个 Gist，不是一个新工具的发布。

它是一个提醒：在 AI 时代，知识管理的瓶颈从来不是存储，而是维护。

「Memex 终于可以建造了。不是因为我们有了更好的文档或更好的搜索，而是因为我们终于有了真正做维护工作的图书管理员。」

那个图书管理员，就是 LLM。

而你的任务，是决定图书馆里放什么书。

在云栈社区，我们始终认为，真正拉开人与人差距的，永远是顶级思维框架而非工具本身。这个 Gist 在 开源实战 领域引发的范式转移，值得每一个知识工作者深思。

---