主张

最近一段时间，Karpathy 发现自己很大一部分 token 消耗不再是「操作代码」，而是「操作知识」——以 Markdown 和图片的形式存储。原因是当前模型已经足够擅长做这件事。

具体做法是搭建个人知识库：原始资料进 raw/，LLM 把它增量编译成一份 wiki，人在 Obsidian 里阅读与提问。

有一个前提值得单独强调：wiki 由 LLM 写入与维护，人很少直接动它。这和「人写笔记、AI 帮忙润色」是相反的分工。

工作流的六个环节

1. 数据摄取

把文章、论文、仓库、数据集、图片等源文档索引进 raw/ 目录；然后用 LLM 增量地「编译」出一份 wiki——本质是一个目录结构里的 .md 文件集合。

wiki 的内容包括：

• raw/ 中所有数据的摘要
• 反向链接（backlinks）
• 按概念归类的文章，以及文章之间的互相链接

把网页文章转成 Markdown 用 Obsidian Web Clipper；再用一个快捷键把相关图片下载到本地，方便模型直接引用。

2. IDE

Obsidian 充当「前端」：同时查看原始数据、编译后的 wiki 和派生的可视化。作者提到试过一些插件以其他方式渲染与查看数据，例如用 Marp 做幻灯片。

3. 问答

当 wiki 足够大之后（他某个研究主题的 wiki 约有 100 篇文章、40 万字），就可以针对它提出各种复杂问题，让 agent 自己去查、去研究。

一个反直觉的结论：不需要上复杂的 RAG。在这个规模下，模型自己维护索引文件和每篇文档的简短摘要，已经能顺利读完相关材料。

4. 输出

不只给文本答案，而是渲染成 Markdown 文件、Marp 幻灯片或 matplotlib 图，再回到 Obsidian 里查看。不同问题可以有不同的可视化形式。

更关键的是：这些输出常常被「归档」回 wiki，用来增强后续查询。于是每次探索都会累积进知识库，而不是散落在聊天记录里。

5. 巡检（linting）

对 wiki 跑「健康检查」：

• 找出数据不一致的地方
• 借助网络搜索补全缺失数据
• 发现值得写成新文章的有趣关联

这一步是增量清理，目标是提升整体数据完整性。模型也很擅长提出「接下来该问什么」。

6. 额外工具

为处理数据而开发小工具，例如一个用 vibe coding 写出来的朴素搜索引擎：既能在网页界面里直接用，也常被当作 CLI 工具交给 LLM，用于更大的查询。

再往前一步

随着仓库变大，自然会想到合成数据生成与微调——让模型把数据「装进权重」，而不只是放在上下文窗口里。这是作者提到的后续探索方向，本文没有给出实现。

一句话总结

一定数量的源数据被收集起来，由 LLM 编译成 .md wiki，再由各种 CLI 在 wiki 上做问答与增量增强，全部在 Obsidian 里查看。人几乎不手写或编辑 wiki，那是 LLM 的领域。作者认为这里存在一个「了不起的新产品」的空间，而不该只是脚本的拼凑。

值得追问的地方

评论区提出了一个作者尚未回答的关键问题：增量编译的粒度和批次。

提问者说，如果一篇一篇处理，单篇上下文不足以判断该如何划分目录；他想知道是否存在最优批次大小，或者是否需要多阶段处理。作者只回应了「我也正想拍个视频讲这个」，没有给出答案。

这暴露了整套方法里最不透明的部分：wiki 的目录结构、概念文章的划分、摘要的详略，都依赖 LLM 的判断，而这些判断在不同批次规模下可能不一致。规模小时看不出来，wiki 长到几百篇后，结构漂移会变成维护成本。

另一个隐含前提是：模型要能可靠地维护索引与摘要。作者的体验是「在这个规模下够用」，但 40 万字是一个具体量级，超过之后是否仍成立，文中没有数据。

理解检验

1. 为什么作者说「不需要复杂 RAG」？这个结论依赖什么前提？

参考答案：因为在约 100 篇文章、40 万字的规模下，LLM 自己维护的索引文件与每篇文档的简短摘要，已经足以让它找到并读完相关材料，不需要额外的向量检索或分块管线。这个结论依赖两个前提：wiki 的规模仍处于「模型可以直接读相关文件」的量级；以及模型能稳定地维护索引与摘要。规模显著变大或索引质量下降时，结论不一定成立。

2. 在这套工作流里，人和模型的分工与常见做法有什么不同？

参考答案：常见做法是人写笔记、AI 辅助润色或检索；这里反过来——LLM 负责写入与维护全部 wiki 内容，人主要在 Obsidian 里阅读、提问和判断。人几乎不直接编辑 wiki。这种分工的好处是知识库能持续被增量编译与巡检，代价是人需要信任模型的分类与摘要，并且要能发现结构漂移。

3. 为什么「把输出归档回 wiki」很重要？

参考答案：因为它让每次探索都累积成知识资产。如果答案只留在对话里，下次还要重新查；归档后，后续查询可以直接复用，wiki 也会因为这些输出而变得更有用。这与「linting 发现新文章候选」形成同一个循环：使用越多，知识库越完整。

4. 评论区提出的未解问题是什么？它为什么重要？

参考答案：问题是增量编译的批次大小与阶段划分——逐篇处理时，单篇上下文不足以决定目录如何划分；是否存在最优批次或多阶段流程，作者没有回答。它重要是因为目录结构与概念划分直接决定 wiki 是否可用，而不同批次规模可能导致分类不一致，规模越大越难纠正。

与前后内容的关系

这篇给出的是一个「知识库由模型维护」的框架，和本库里把剪藏编译成站点笔记的流程是同一类工作：摄取 → 编译 → 问答 → 回写。区别在于这里的产物是给人读的 Markdown 站点，而 Karpathy 的产物是给模型自己查询的 wiki。若要把它落到工程上，Agent 如何组织上下文、如何压缩历史，可参考《AI Agent 工程》的「拆解 Codex 的 Agent 循环」一篇。

The claim

Lately a large fraction of Karpathy's token throughput has gone not into manipulating code but into manipulating knowledge, stored as Markdown and images. The reason is simple: current models are quite good at it.

The setup is a personal knowledge base: source documents land in raw/, an LLM incrementally compiles a wiki, and the human reads and asks questions in Obsidian.

One premise deserves emphasis: the wiki is written and maintained by the LLM, and the human rarely touches it. That is the opposite division of labour from "human writes notes, AI polishes them".

Six stages of the workflow

1. Data ingest

Index source documents — articles, papers, repos, datasets, images — into a raw/ directory, then use an LLM to incrementally compile a wiki, which is just a collection of .md files in a directory structure.

The wiki contains:

• summaries of everything in raw/
• backlinks
• articles organized by concept, linked to one another

Web articles are converted to Markdown with the Obsidian Web Clipper, and a hotkey downloads related images locally so the model can reference them directly.

2. IDE

Obsidian serves as the frontend: it shows the raw data, the compiled wiki, and derived visualizations side by side. The author mentions experimenting with plugins for other renderings, such as Marp for slides.

3. Q&A

Once the wiki is large enough — roughly 100 articles and 400K words for one research topic — you can ask it complex questions and let the agent go research the answers.

A counterintuitive result: no elaborate RAG is needed. At this scale the model maintains its own index files and short per-document summaries, and reads all the relevant material without much trouble.

4. Output

Answers do not have to be text. The model renders Markdown files, Marp slide decks, or matplotlib figures, which are then viewed back in Obsidian. Different questions invite different visual formats.

More importantly, outputs are often filed back into the wiki, enhancing it for later queries. Explorations accumulate instead of scattering across chat logs.

5. Linting

"Health checks" run over the wiki to:

• find inconsistent data
• impute missing data with web searches
• surface interesting connections that deserve new articles

This is incremental cleanup aimed at overall data integrity. Models are also good at suggesting what to ask next.

6. Extra tools

Small tools get built along the way. One example is a naive search engine over the wiki, vibe-coded, usable directly in a web UI and often handed to an LLM via CLI for larger queries.

The next step

As the repository grows, the natural ambition is synthetic data generation and fine-tuning, so the model "knows" the data in its weights rather than only in context. This is mentioned as a direction, not described or implemented.

The one-line summary

Raw data from a set of sources is collected, compiled by an LLM into a .md wiki, and then operated on by various CLIs for Q&A and incremental enhancement, all viewable in Obsidian. You rarely write or edit the wiki manually; it belongs to the LLM. The author believes there is room here for an incredible new product rather than a hacky collection of scripts.

Open questions

The comments raise a question the author does not answer: the granularity and batching of incremental compilation.

A commenter notes that processing one document at a time leaves too little context to decide how to divide directories, and asks whether there is an optimal batch size or a multi-stage process. The author replies only that he was thinking of making a video about it.

That exposes the least transparent part of the method. The directory structure, the split into concept articles, and the level of detail in summaries all depend on LLM judgment, and that judgment may drift with batch size. At small scale it is invisible; at several hundred articles, structural drift becomes maintenance cost.

There is also an implicit assumption: the model can reliably maintain indexes and summaries. The author's experience is that this holds at his scale, but 400K words is a specific magnitude, and the post offers no data on what happens beyond it.

Comprehension check

1. Why does the author say complex RAG is unnecessary, and what does that conclusion depend on?

Reference answer: At roughly 100 articles and 400K words, the index files and short summaries the LLM maintains are enough for it to locate and read the relevant material, without a separate vector-retrieval or chunking pipeline. The conclusion depends on two premises: the wiki stays at a scale where the model can read the relevant files directly, and the model reliably maintains indexes and summaries. At a much larger scale, or with degraded indexes, it would not necessarily hold.

2. How does the human/model division of labour here differ from the common pattern?

Reference answer: The common pattern is that a human writes notes and AI assists with polishing or retrieval. Here it is reversed: the LLM writes and maintains all wiki content, while the human mostly reads, asks questions, and judges in Obsidian, almost never editing the wiki directly. The benefit is continuous incremental compilation and linting; the cost is that the human must trust the model's categorization and summaries, and must be able to notice structural drift.

3. Why does filing outputs back into the wiki matter?

Reference answer: It turns each exploration into a knowledge asset. If an answer only lives in a chat, the next query has to rediscover it; once filed, later queries reuse it and the wiki becomes more useful. This is the same loop as linting surfacing new article candidates: the more the base is used, the more complete it becomes.

4. What unresolved question do the comments raise, and why does it matter?

Reference answer: The batching and staging of incremental compilation — processing one document at a time leaves too little context to decide directory structure, and the author does not say whether an optimal batch size or multi-stage process exists. It matters because directory structure and concept division determine whether the wiki is usable at all, and different batch sizes can produce inconsistent categorization that gets harder to correct as the wiki grows.

How this connects

This post gives a framework in which the model maintains the knowledge base. It is the same kind of work as compiling clippings into a reading site — ingest, compile, question, write back — with one difference: here the product is a Markdown site for humans, while Karpathy's product is a wiki for the model to query. For the engineering side of how an agent organizes context and compacts history, see the Codex agent loop chapter in the AI Agent Engineering notes.