大多数人与 LLM + 文档的交互方式是 RAG（检索增强生成）：上传一批文件，提问时 LLM 检索相关片段，生成答案。NotebookLM、ChatGPT 文件上传、大多数企业 AI 工具都是这个模式。

Karpathy 指出问题所在："LLM 每次回答问题时都从头重新发现知识。没有积累。"

问一个需要综合五篇文档的问题，RAG 系统每次都要找出相关片段并拼凑起来。明天再问同一个问题，它重做一遍。什么都不积累，什么都不复利。

Karpathy 的替代方案："不要在查询时从原始文档检索，而是让 LLM 增量构建和维护一个持久的 wiki，即在你和原始资料之间构建一组结构化的、相互链接的 markdown 文件。"

当你添加新资料时，LLM 不是简单索引它以备后续检索，而是阅读它、提取关键信息、整合到已有的 wiki 中：更新实体页面、修订主题摘要、标注新数据与旧结论的矛盾、根据新证据修正或强化已有的综述。

核心一句话："知识只编译一次，然后保持更新，而不是每次查询都重新推导。"

Karpathy 反复强调这一点："wiki 是一个持久的、复利增长的产物。"交叉引用已经建好了，矛盾已经标注了，综述已经反映了你读过的所有内容。每添加一份资料、每问一个问题，wiki 都变得更丰富。

你积累的原始文档集合,包括文章、论文、图片、数据文件等。这些是 不可变的 ：LLM 可以读，但永远不能改。这是你的知识源头。LLM 在 wiki 中犯了错，你可以追溯到原始资料来纠正。

LLM 生成的 markdown 文件目录，包含摘要、实体页面、概念页面、对比分析、概述、综述。LLM 完全拥有这一层：创建页面、新资料到来时更新、维护交叉引用、保持一致性。你读它，LLM 写它。

一份文档（Claude Code 用 CLAUDE.md ，Codex 用 AGENTS.md ），告诉 LLM wiki 的结构、约定、以及摄入资料、回答问题、维护 wiki 时的工作流程。这是关键配置文件，让 LLM 成为有纪律的 wiki 维护者，而不是普通的聊天机器人。

没有 schema，每次与 LLM 的会话都从零开始。LLM 不知道你的约定、页面格式或工作流程。你每次都要重新解释一切。Schema 就是跨会话的持久记忆，确保一致性，把通用 LLM 变成你的专属 wiki 维护者。

你把新资料放入 raw 目录，告诉 LLM 处理它。一个典型的处理流程为：LLM 阅读资料，与你讨论关键要点，在 wiki 中写摘要页，更新索引，更新相关的实体和概念页面，在活动日志中追加记录。一次摄入可能触及 10-15 个 wiki 页面。

一次摄入不只是创建一个新页面，它会波及整个 wiki。如果你摄入了一篇关于新 transformer 变体的论文，LLM 可能会做如下动作：为论文创建新的摘要页、更新"注意力机制"概念页、更新"缩放定律"页面（如果有新基准数据）、更新作者或机构的实体页、更新对比页面（如果论文与已知模型做了基准对比）、从现有页面添加指向新内容的链接、更新索引、在日志中记录。

Karpathy 有个偏好："我喜欢一次摄入一份资料，过程中持续跟进，阅读摘要、检查更新、引导 LLM 侧重什么。但你也可以批量摄入多份资料，减少监督次数。"

你向 wiki 提问。LLM 搜索相关页面，阅读后综合出带引用的答案。答案可以采取多种形式：markdown 页面、对比表、幻灯片（Marp）、图表。

但最重要的洞察是："好的答案可以回写到 wiki 中作为新页面。"一次对比分析、一个发现都是是有价值的，不应该消失在聊天历史中。这样你的探索和摄入的资料一样在知识库中复利增长。

定期让 LLM 检查 wiki 的健康状况。检查内容包括：页面间的矛盾、已经被新资料取代的过时结论、孤儿页面、被多次提及但缺少独立页面的概念、缺失的交叉引用、可以通过网络搜索填补的数据空白。

Org-mode 的方案和原文完全一致，只是文件后缀不同：

my-research/
├── raw/                    # 原始资料（不可变）
│   ├── articles/
│   ├── papers/
│   └── assets/
├── wiki/                   # LLM 维护的知识库
│   ├── index.org           # 总目录
│   ├── log.org             # 活动日志
│   ├── overview.org        # 综述
│   ├── concepts/           # 概念页面
│   ├── entities/           # 实体页面
│   ├── sources/            # 资料摘要
│   └── comparisons/        # 对比分析
└── CLAUDE.md               # Schema 配置

Org-roam 提供与 Obsidian 一模一样的双向链接功能。在 wiki 页面中用 [[roam:概念名]] 创建链接，Org-roam 会自动维护反向链接。这意味着你在"注意力机制"页面链接了"Transformer"，在"Transformer"页面就能看到反向链接。在 Emacs 中用 M-x org-roam-node-find 搜索和跳转页面，效果等同于 Obsidian 的快速跳转。

Karpathy 提到 qmd（Tobi Lutke 开发的本地 markdown 搜索引擎，支持 BM25 + 向量搜索 + LLM 重排序）。在 wiki 规模不大（100 个资料、几百个页面）时，Karpathy 自己也说 index.org 文件本身就能当索引用。LLM 读一下索引（几千 token），找到相关页面，直接去读。

在这个规模下，ripgrep（ rg ）完全可以替代 qmd：

# 在 wiki 中搜索关键词
rg "注意力机制" wiki/

# 搜索特定 frontmatter 属性
rg "#+type: concept" wiki/

当 wiki 增长到几百个页面、索引文件本身大到一次读不完时，再考虑引入专门的搜索工具。

在 CLAUDE.md 中定义 Org-mode 的 wiki 规则，比如：

## Page Conventions

Every wiki page MUST have org-mode property drawer:
:PROPERTIES:
:TITLE:    Page Title
:TYPE:     concept | entity | source-summary | comparison
:SOURCES:  [list of raw/ files referenced]
:RELATED:  [list of wiki pages linked]
:CREATED:  [YYYY-MM-DD Day]
:UPDATED:  [YYYY-MM-DD Day]
:CONFIDENCE: high | medium | low
:END:

## Ingest Workflow
When I say "ingest [filename]":
1. Read the source file in raw/
2. Discuss key takeaways with me
3. Create/update a summary page in wiki/sources/
4. Update wiki/index.org
5. Update all relevant concept and entity pages
6. Append an entry to wiki/log.org

Obsidian 的图谱视图是它的一大卖点。Org-roam 生态有 org-roam-ui 插件，提供类似的交互式图谱：所有 wiki 页面作为节点，所有 [[roam:...]] 链接作为边。在 Emacs 中用 M-x org-roam-ui-open 启动，浏览器中查看。