Tip

核心观点Karpathy 提出用 Wiki 替代 RAG 的知识管理新范式，核心是让知识积累而非每次重来。

---

一个问题：为什么我们用 AI 读了那么多文档，什么都没留下？

上周刷到 Karpathy 的一条推文，凌晨一点多。他发了一个 gist，讲自己怎么用 LLM 管理知识。

不是 RAG，不是向量数据库，不是那些花里胡哨的知识库产品。

就是一堆 markdown 文件，一个 LLM agent，一个文本编辑器。

我看完第一反应是：这能好使？

然后我去读了他的 gist。读完又去读了一遍。凌晨两点多的时候，我意识到——他说的可能不是错的。

---

先说说 Karpathy 是谁

Note

人物背景Andrej Karpathy — 斯坦福博士、OpenAI 联合创始团队成员、前 Tesla AI 总监

不是所有人知道他。但在 AI 这个圈子里，他的名字几乎等于"靠谱"。

Andrej Karpathy，斯坦福博士，李飞飞的学生。2015 年，他是最早加入 OpenAI 的那批人之一。2017 年被马斯克挖去 Tesla，当 AI 总监，负责 Autopilot 和全自动驾驶。

你如果开过 Tesla，他写的代码可能帮你避过几次险。

2022 年他回 OpenAI 待了一段时间，然后 2024 年初离开，创立了自己的 AI 教育公司 Eureka Labs。

但他最出名的不是这些 title。而是他做事情的方式——极度公开、极度坦诚、极度工程化。

他在 YouTube 上开的 CS231n 课程，讲计算机视觉，全球几十万人看过。他写的代码、做的项目、分享的思考，几乎都是开源的。

这个圈子里技术大牛很多，但愿意把每个细节都摊开讲的，没几个。

所以当他说"我最近在这样做"的时候，很多人会认真听。

---

他到底在说什么

先把核心论点讲清楚。

现在绝大多数人用 LLM 处理文档的方式是 RAG：

用户提问

LLM

文档库

向量检索

生成回答

你丢一堆文件进去，LLM 每次被问到问题的时候，去里面检索相关的片段，然后生成回答。

• • NotebookLM 是这样

• • ChatGPT 的文件上传是这样

• • 市面上大部分"知识库"产品都是这样

❌ Karpathy 说这个模式有一个根本问题

Warning

核心痛点没有积累。每次提问，LLM 都在从零开始。

它得重新找到相关的碎片，重新拼接，重新理解。

你上周问过的一个需要综合五篇论文才能回答的问题，下周再问，它又得重来一遍。

什么都没有沉淀下来。

✅ 他提出的替代方案

让 LLM 不只是检索，而是主动去构建和维护一个持久的 wiki。

新资料

LLM 处理

提取关键信息

更新 Wiki

实体页面

主题摘要

交叉引用

用户提问

读取 Wiki

生成回答

存回 Wiki

这个 wiki 是一组结构化的 markdown 文件，互相链接，由 LLM 全权维护。

每当你添加一个新的资料来源，LLM 不是简单地把它索引了事，而是：

1. 1. ✅ 真的去读

2. 2. ✅ 提取关键信息

3. 3. ✅ 整合进现有的 wiki 里

• • 更新实体页面

• • 修订主题摘要

• • 标记新数据和旧结论之间的矛盾

• • 补充交叉引用

知识被编译一次，然后持续维护，而不是每次查询都重新推导。

用他的原话说：wiki 是一个 “persistent, compounding artifact”（持久、复利的产物）。

---

三层架构：数据归数据，逻辑归逻辑

Gist 里最有意思的部分之一是他提出的三层架构。

第一层：Raw Sources（原始资料）

第二层：Wiki（知识层）

第三层：Schema（规则层）

配置文件CLAUDE.md / AGENTS.md

摘要

实体页面

概念页面

交叉引用

论文

文章

数据文件

图片

📂 第一层：Raw Sources（原始资料）

你收集的所有原始材料：

• • 📄 论文

• • 📰 文章

• • 🖼️ 图片

• • 📊 数据文件

Important

关键原则这一层是不可变的，LLM 只读不写。 这是你的信息源头，你的 ground truth。

这一点很重要。他没有让 LLM 去改原始资料，而是让原始资料和 LLM 的产出彻底分开。

这意味着你随时可以回溯、核查，知道某个 wiki 页面的内容到底是从哪来的。

📝 第二层：The Wiki（知识层）

由 LLM 完全拥有和维护的一组 markdown 文件：

• • 📋 摘要

• • 👤 实体页面

• • 💡 概念页面

• • 🔍 对比分析

• • 📖 总览、综述

你读它，LLM 写它。

这一层是整个系统的核心。它不是原始资料的简单搬运，而是 LLM 在原始资料基础上做了理解、提炼、关联之后的产物。

⚙️ 第三层：The Schema（规则层）

一个配置文件（比如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md），告诉 LLM：

|
配置内容
|
说明
|
| :-- | :-- |
|
Wiki 结构
|
页面如何组织
|
|
约定规范
|
命名、格式等约定
|
|
操作流程
|
摄入、回答、维护时遵循的流程
|

Tip

核心价值这一层是让 LLM 从一个"通用聊天机器人"变成一个"有纪律的 wiki 维护者"的关键。

没有这个，LLM 每次都会按自己的理解随意组织信息，结果就是混乱。

---

Note

架构洞察这三层分离的思路其实很像软件工程里的关注点分离。

• • 数据归数据

• • 逻辑归逻辑

• • 配置归配置

---

四种操作：不只是问答

Gist 定义了四种核心操作：

1️⃣ Ingest（摄入）

你往 raw 目录里丢一个新资料，然后让 LLM 去处理。

WikiLLM用户WikiLLM用户丢入新资料读取资料讨论要点写摘要页面更新索引更新相关页面

LLM 读完之后，跟你讨论要点，写一个摘要页面，更新索引，更新相关的实体和概念页面。

一个资料来源可能触及 10-15 个 wiki 页面。

Tip

Karpathy 的偏好他更喜欢一次只摄入一个资料，全程参与。

他会读 LLM 写的摘要，检查更新，引导 LLM 在哪些方面着重展开。但你也可以一次性批量导入，少参与一些。

这里有个细节很值得注意：

他没有追求全自动化。他选择了"人在回路"的方式，不是因为 LLM 做不好，而是因为摄入的过程本身就是学习的过程。

你在引导 LLM 的同时，自己也在思考：

• • 这个资料到底重不重要？

• • 跟已有知识有什么关系？

2️⃣ Query（查询）

向 wiki 提问。LLM 搜索相关页面，读取，综合回答。

回答可以是：

• • 📄 markdown 页面

• • 📊 对比表格

• • 🎞️ 幻灯片（Marp 格式）

• • 📈 图表（matplotlib）

Important

关键洞察好的回答应该被存回 wiki。

你做的一个对比分析、一个关联发现，这些不应该消失在聊天记录里。它们应该成为 wiki 的一部分。

这一点太重要了。

大部分人用 ChatGPT 的痛点就是：聊了半天，关了窗口，什么都没留下。

3️⃣ Lint（健康检查）

定期让 LLM 给 wiki 做体检：

|
检查项
|
说明
|
| :-- | :-- |
|
🔍 找矛盾
|
新旧数据不一致
|
|
⏰ 找过时信息
|
需要更新的内容
|
|
🏝️ 找孤立页面
|
没有被引用的页面
|
|
💡 找缺失概念
|
被提及但没有独立页面
|
|
🔗 找缺失引用
|
应该关联但未关联的页面
|
|
📊 找数据空缺
|
可以通过搜索补上的信息
|

这个操作模式非常聪明。

它把 wiki 的维护变成了一个持续的、可执行的流程，而不是靠人想起来才去做。

LLM 不会忘记更新一个交叉引用，不会觉得"这个太烦了下次再说"。

4️⃣ Indexing & Logging（索引和日志）

两个特殊文件：

index.md — 内容索引

• • 列出 wiki 里每个页面的链接

• • 一句话摘要

log.md — 时间线

• • 什么时候摄入了什么

• • 做了什么查询

• • 跑了什么 lint

Tip

Karpathy 的经验在 wiki 规模不太大的时候（大概 100 个资料来源、几百个页面），LLM 直接读 index.md 来定位相关页面就够用了。

不需要搭 embedding + 向量检索那一套。

这跟很多人的直觉相反。

大家一说到"知识库"就想到 RAG pipeline、向量数据库、embedding 模型。

但如果你的 wiki 组织得好，一个结构化的索引文件可能比花哨的检索系统更有效。

---

为什么这条推文能爆

回过头来看，这条推文的传播力来自哪里？

🎯 1. 切中痛点

每个重度 LLM 用户都经历过这种挫败感：

跟 AI 聊了很多，但什么都没有留下来。知识散落在无数个对话窗口里，没有积累，没有结构。

Karpathy 把这个问题说出来了，还给了一个可操作的解法。

🏆 2. 身份背书

Karpathy 不是一个普通的技术博主：

• • ✅ 前 Tesla AI 总监

• • ✅ OpenAI 联合创始人

• • ✅ CS231n 主讲人

当他说"我最近在这样做"，大家会认真听。

而且他的表述方式非常关键：他不是在教你，他是在分享自己的实践。

🚀 3. 开放性

他在原帖最后说：

Quote

Karpathy"I think there is room here for an incredible new product instead of a hacky collection of scripts."

这句话直接把讨论空间打开了。

• • 每个创业者看到都会想"这是不是我该做的产品"

• • 每个开发者看到都会想"我能不能自己搞一个"

🔥 4. 二次引爆策略

隔两天 quote 自己，引入 “idea file” 这个新概念，附上一个精心写的 Gist。

这不是简单的重复，而是给同一个话题增加了新的维度：

• • 第一条是"我在做什么"

• • 第二条是"这应该怎么分享"

两条帖子加起来接近 2000 万浏览。

---

一个有趣的新概念：Idea File

最后值得单独说的，是 Karpathy 在 quote tweet 里提出的 “idea file” 这个概念。

Tip

核心概念在 LLM agent 时代，分享代码和分享想法的边界变了。

以前 vs 现在

|
以前
|
现在
|
| :-- | :-- |
|
要分享一个工具，你得写代码
|
只需要把想法描述清楚
|
|
建 repo、写文档
|
别人的 agent 会根据想法定制实现
|
|
门槛高
|
门槛低
|

这个 Gist 本身就是这个理念的实践：

• • ❌ 不是一个 repo

• • ❌ 没有代码

• • ✅ 只有一个清楚的思路描述

你把它丢给 Claude Code 或者 Codex，agent 就会帮你把整套系统搭出来。

这个转变意味着什么？

传播单位

传播单位

以前

Repository代码仓库

现在

Idea File想法文件

知识的传播单位正在从代码变成想法。

开源社区的基本单位从 repository 变成 idea file。

这对内容创作者来说是一个很大的机会：你不需要会写代码也能分享有价值的技术方案，你只需要把想法描述得足够清楚。

Note

早期阶段当然，这个概念现在还很早期，能不能真的成为一种新范式还不好说。

但至少 Karpathy 用将近 5000 个 Star 证明了，大家对这种分享方式是有需求的。

---

回到最开始的问题

为什么我们用 AI 读了那么多文档，什么都没留下？

Karpathy 的回答是：

Important

核心答案因为你每次都在重新推导。

你没有一个地方把知识编译好、存起来、持续维护。

你的 AI 没有记忆，它只有计算。

他给出的方案不是产品，是一套思路。

你可以用 Obsidian 实现，可以用 Notion 实现，可以用任何文本编辑器实现。

核心是那个三层架构，那四种操作，那个"知识应该积累而不是每次重来"的信念。

这个方案有天花板吗？

肯定有。

|
问题
|
说明
|
| :-- | :-- |
|
📏 上下文窗口限制
|
规模大到一定程度，需要检索机制
|
|
🔄 一致性问题
|
不同时间点的更新可能不一致
|
|
👥 多人协作
|
目前是单人方案
|

他自己在 Gist 里也提到了。

但在一定规模内——比如几十到几百个资料来源——这套东西是能跑起来的。

---

Tip

更重要的不是方案本身，而是它指向的方向

AI 产品的下一个竞争维度，可能不是谁生成的东西更好，而是谁能帮你积累得更多。

谁能让你的 AI 从一个"每次都失忆的助手"变成一个"越来越懂你的伙伴"。

Karpathy 说的那句话我觉得是对的：

“I think there is room here for an incredible new product.”

这个 product 长什么样，我还不确定。

但至少现在，我们知道它不该长什么样了：

• • ❌ 不该是每次问完就忘的聊天窗口

• • ❌ 不该是散落在无数对话里的知识碎片

• • ❌ 不该是只有检索没有积累的 RAG pipeline

它应该是一个能跟你一起成长的东西。

至于具体怎么实现——

也许你可以试试 Karpathy 的方法。或者等一等，看谁先把这个东西做出来。

我也不确定。但我觉得这个方向值得认真想想。

---

参考资料：

• • Karpathy’s Gist: LLM as OS, Agents as Apps, and the Future of AI

• • GitHub - doocs/md: 微信 Markdown 编辑器

---