LLM 知识库：Karpathy 的第一手方法论全解析

参考对象：Vannevar Bush《As We May Think》(1945) + Tiago Forte《Building a Second Brain》+ 编译器设计思想

引子：来自源头的声音

2026年4月，Andrej Karpathy 在 GitHub Gist 上发布了一份名为《LLM Knowledge Bases》的文档。这不是推文，不是演讲，是一份设计文档——专门用来复制粘贴给你的 LLM Agent（Claude Code、Codex、OpenCode 等），让它帮你构建个人知识库。

这份文档的精髓可以用一句话概括：

"传统的 RAG 每次查询都在重新发现知识，而 LLM Wiki 让知识自己生长。"

本文基于 Karpathy 的原始 Gist，完整拆解这套方法论的核心思想、三层架构、三大操作，以及为什么它可能是 Vannevar Bush 1945 年 Memex 愿景的真正实现。

第一部分：为什么传统 RAG 不够聪明？

RAG 的问题

大多数人的 LLM 文档体验是这样的：

上传文件 → 查询时检索相关片段 → LLM 生成答案

问题在哪？

NotebookLM、ChatGPT 文件上传、大多数 RAG 系统都是这样工作的。

Karpathy 的洞察

Karpathy 提出的方法完全不同：

原始素材 → LLM 编译 → 持久化 Wiki → 查询时直接读取已编译知识

关键区别：

• 不是索引后等待检索
• 而是读取、提取、整合到已有知识网络

当你添加新素材时，LLM 会：

• 读取它
• 提取关键信息
• 更新实体页面
• 修订主题摘要
• 标记新旧数据的矛盾
• 强化或挑战 evolving synthesis

知识被编译一次，然后保持最新——不是每次查询都重新推导。

第二部分：三层架构——优雅的分离

┌─────────────────────────────────────────────────────────────────────┐
│                      Karpathy 三层架构                                │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   Layer 3: Schema (配置层)                                           │
│   ┌─────────────────────────────────────────────────────────────┐  │
│   │ • CLAUDE.md / AGENTS.md                                      │  │
│   │ • 定义 wiki 结构、命名规范、工作流程                          │  │
│   │ • 让 LLM 成为"有纪律的 wiki 维护者"而非"通用聊天机器人"        │  │
│   │ • 你和 LLM 共同演化                                           │  │
│   └─────────────────────────────────────────────────────────────┘  │
│                              ↑ 指导                                  │
│   Layer 2: The Wiki (知识层)                                         │
│   ┌─────────────────────────────────────────────────────────────┐  │
│   │ • LLM 生成的 markdown 文件目录                                │  │
│   │ • 摘要、实体页面、概念页面、比较、综述                         │  │
│   │ • LLM 全权维护：创建、更新、维护交叉引用、保持一致性           │  │
│   │ • 你读它，LLM 写它                                            │  │
│   └─────────────────────────────────────────────────────────────┘  │
│                              ↑ 编译                                  │
│   Layer 1: Raw Sources (原始层)                                      │
│   ┌─────────────────────────────────────────────────────────────┐  │
│   │ • 你策划的源文档集合                                          │  │
│   │ • 文章、论文、图片、数据文件                                   │  │
│   │ • 只读——LLM 读取但永不修改                                     │  │
│   │ • 真相的来源                                                  │  │
│   └─────────────────────────────────────────────────────────────┘  │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

三层详解

Layer 1: Raw Sources（原始素材）

是什么：你策划的源文档集合 内容：文章、论文、图片、数据文件 关键原则：immutable（不可变）

• LLM 读取它们
• 但永不修改它们
• 这是你的真相来源

Layer 2: The Wiki（知识层）

是什么：LLM 生成的 markdown 文件目录 内容：

• 摘要（Summaries）
• 实体页面（Entity pages）
• 概念页面（Concept pages）
• 比较（Comparisons）
• 综述（Synthesis）

所有权：

• LLM 全权维护
• 创建页面
• 新素材到达时更新
• 维护交叉引用
• 保持一致性

你的角色：

• 你读它
• LLM 写它

Layer 3: The Schema（配置层）

是什么：告诉 LLM 如何维护 wiki 的文档 文件名：

• CLAUDE.md（Claude Code）
• AGENTS.md（Codex）

内容：

• wiki 的结构
• 命名规范
• 工作流程：如何摄入源、如何回答问题、如何维护 wiki

关键作用：

• 让 LLM 成为**"有纪律的 wiki 维护者"**
• 而非**"通用聊天机器人"**

演化方式：

• 你和 LLM 共同演化
• 随着你弄清楚什么对你的领域有效

第三部分：三大操作——完整的知识工作流

Operation 1: Ingest（摄入）

流程：

丢入新素材到 raw/
    ↓
告诉 LLM 处理它
    ↓
LLM:
  - 读取源
  - 与你讨论关键要点
  - 在 wiki 中写摘要页面
  - 更新索引
  - 更新相关实体和概念页面（可能涉及 10-15 个页面）
  - 追加条目到 log

Karpathy 的个人偏好：

"我更喜欢一次摄入一个源并保持参与——我读摘要、检查更新、指导 LLM 强调什么。"

替代方案：

• 你也可以批量摄入多个源，减少监督
• 开发适合你风格的 workflow
• 记录在 schema 中供未来会话使用

Operation 2: Query（查询）

流程：

向 wiki 提问
    ↓
LLM:
  - 搜索相关页面
  - 读取它们
  - 综合答案（带引用）
    ↓
答案形式取决于问题：
  - markdown 页面
  - 比较表
  - 幻灯片（Marp）
  - 图表（matplotlib）
  - canvas

关键洞察：

"好的答案可以作为新页面归档回 wiki。"

你要求的比较、分析、发现的联系——这些有价值，不应该消失在聊天历史中。

知识复利：

• 摄入的源会 compound
• 探索也会 compound

Operation 3: Lint（健康检查）

做什么：定期让 LLM 健康检查 wiki

检查项：

价值：

• LLM 擅长建议新问题调查
• 建议寻找的新源
• 保持 wiki 健康增长

第四部分：两个特殊文件——导航工具

index.md：内容导向

作用：wiki 内容的目录

内容：

• 每个页面列出：链接 + 一句话摘要
• 可选元数据：日期、源数量
• 按类别组织：实体、概念、源等

更新时机：每次摄入后自动更新

查询时使用：

LLM 先读 index → 找到相关页面 → 深入阅读

规模表现：

• ~100 源、~数百页面 的中等规模下工作得很好
• 避免了 embedding-based RAG 基础设施的需求

log.md：时间线导向

作用：append-only 的记录，记录发生了什么、何时发生

内容：

• 摄入
• 查询
• lint 通过

格式技巧：

## [2026-04-02] ingest | Article Title
## [2026-04-02] query | Question asked
## [2026-04-03] lint | Health check

Unix 工具友好：

# 最后5条记录
grep "^## \[" log.md | tail -5

价值：

• wiki 演化的时间线
• 帮助 LLM 理解最近做了什么

第五部分：可选工具链

搜索：qmd

问题：小规模时 index 文件足够，但 wiki 增长后需要 proper search

解决方案：qmd

• 本地 markdown 文件搜索引擎
• 混合 BM25/vector search
• LLM re-ranking
• 全设备端运行
• CLI（LLM 可以 shell 调用）
• MCP server（LLM 可以作为原生工具使用）

替代方案：

• 让 LLM 帮你 vibe-code 一个简单的搜索脚本

网页剪藏：Obsidian Web Clipper

• 浏览器扩展
• 将网页文章转换为 markdown
• 快速将源放入 raw 集合

图片处理

设置：

1. Obsidian Settings → Files and links
2. "Attachment folder path" 设为固定目录（如 raw/assets/）
3. Settings → Hotkeys，搜索 "Download"
4. 找到 "Download attachments for current file"，绑定热键（如 Ctrl+Shift+D）

使用：

• 剪藏文章后，按热键
• 所有图片下载到本地磁盘

好处：

• LLM 可以直接查看和引用图片
• 不依赖可能失效的 URL

注意：

• LLM 不能原生读取带内联图片的 markdown
• 变通：先读文本，再单独查看引用的图片

可视化：Obsidian Graph View

• 看 wiki 的形状
• 什么连接到什么
• 哪些是 hub 页面
• 哪些是孤立页面

幻灯片：Marp

• markdown-based slide deck 格式
• Obsidian 有插件
• 直接从 wiki 内容生成演示文稿

查询：Dataview

• Obsidian 插件
• 在页面 frontmatter 上运行查询
• 如果 LLM 添加 YAML frontmatter（标签、日期、源数量）
• Dataview 可以生成动态表格和列表

第六部分：为什么这套方法有效？

核心洞察

维护知识库的繁琐部分不是阅读或思考——而是记账工作：

结果：wiki 保持维护，因为维护成本接近零。

人类的新角色

历史回声：Vannevar Bush 的 Memex

1945 年，Vannevar Bush 在《As We May Think》中描述了 Memex：

• 个人的、策划的知识存储
• 文档间的 associative trails（联想路径）

Bush 的愿景 vs 互联网：

• Bush 的愿景更接近 私有、主动策划
• 文档间的连接和文档本身一样有价值
• 互联网变成了 公共、被动消费

Bush 没能解决的问题：谁来做维护？

LLM 解决了这个问题。

第七部分：应用场景

Karpathy 列举了多种应用场景：

个人

• 跟踪自己的目标、健康、心理学、自我提升
• 归档日记条目、文章、播客笔记
• 随时间构建自己的结构化图景

研究

• 数周或数月深入一个主题
• 阅读论文、文章、报告
• 逐步构建带有演化论点的综合 wiki

读书

• 边读边归档每章
• 构建人物、主题、情节线索页面
• 以及它们如何连接

类比：

• 像 Tolkien Gateway 这样的粉丝 wiki
• 数千页互链页面，覆盖人物、地点、事件、语言
• 由志愿者社区数年建成
• 你可以在阅读时个人构建类似的东西
• LLM 做所有交叉引用和维护

商业/团队

• LLM 维护的内部 wiki
• 源：Slack 线程、会议记录、项目文档、客户电话
• 可能有人类在循环中审核更新
• wiki 保持最新，因为 LLM 做团队没人想做的维护

其他

• 竞争分析
• 尽职调查
• 旅行规划
• 课程笔记
• 爱好深入

共同点：随时间积累知识，希望它有条理而不是分散

第八部分：实施建议

文档的意图

Karpathy 强调：

"这份文档故意是抽象的。它描述的是想法，不是具体实现。"

可变部分：

• 确切的目录结构
• schema 规范
• 页面格式
• 工具链

取决于：

• 你的领域
• 你的偏好
• 你选择的 LLM

模块化哲学

"上面提到的所有内容都是可选和模块化的——挑选有用的，忽略无用的。"

示例：

• 你的源可能只有文本 → 不需要图片处理
• wiki 可能足够小 → 只需要 index 文件，不需要搜索引擎
• 你可能不关心幻灯片 → 只需要 markdown 页面
• 你可能想要完全不同的输出格式集合

正确的使用方式

"正确的方式是把它分享给你的 LLM Agent，一起 instantiate 一个适合你需求的版本。"

文档的工作：传达模式 你的 LLM 的工作：弄清楚其余部分

附录：Karpathy 的原始 Gist

链接：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

标题：LLM Knowledge Bases

副标题：A pattern for building personal knowledge bases using LLMs

用途：设计为复制粘贴给你自己的 LLM Agent

目标受众：OpenAI Codex、Claude Code、OpenCode / Pi 等

从 RAG 到编译型知识库，这可能是个人知识管理的范式转移。

而这一次，维护的负担终于有人承担了。

#Karpathy #LLM #知识管理 #RAG #Wiki #智柴外脑