Karpathy 最近的 token 消耗结构发生了变化：大量用在了知识操作上，而不是代码操作。

完整工作流

数据摄入 源文档（文章、论文、代码库、数据集、图片）索引到 raw/ 目录。然后用 LLM 把这些内容"编译"成一个 wiki——就是一个目录里的 .md 文件集合，包含：raw/ 所有数据的摘要、双向链接、把数据分类成概念、写文章、并链接起来。

转换网页文章为 .md：Karpathy 用 Obsidian Web Clipper 扩展，然后用一个热键下载所有相关图片到本地，方便 LLM 引用。

IDE：Obsidian 作为前端 Obsidian 是查看原始数据、编译后的 wiki、以及衍生可视化的前端"IDE"。重要的是：LLM 写和维护 wiki 的所有数据，Karpathy 很少直接手动编辑。

问答：不需要 fancy RAG 当 wiki 足够大（比如某个研究主题约 100 篇文章、40 万词），就可以对 LLM agent 问各种复杂问题，它会去研究答案。

Karpathy 原本以为要上 RAG，但结果发现 LLM 自动维护索引文件和所有文档的摘要，在这个规模下已经足够好，读取所有重要相关数据毫不费力。

输出：不止文本 不只在终端里得到文本答案——Karpathy 喜欢让 LLM 渲染 markdown 文件、或者幻灯片（Marp 格式）、或者 matplotlib 图片，然后在 Obsidian 里查看。可以根据问题想象很多其他视觉输出格式。很多时候，输出会"归档"回 wiki，丰富 wiki 内容供后续查询。所以自己的探索和查询总是在知识库里累积。

Lint：健康检查 Karpathy 用 LLM 对 wiki 做"健康检查"——比如：找出不一致的数据、用网络搜索补全缺失数据、发现有趣的联系作为新文章候选——逐步清理 wiki、提升整体数据完整性。LLM 还很擅长建议下一步可以问什么问题。

额外工具 会开发额外的工具来处理数据，比如用 vibe coding 写了一个简单（naive）的 wiki 搜索引擎，同时有 Web UI，但更常通过 CLI 交给 LLM 作为大型查询的工具。

进一步探索 随着知识库增长，自然会想到合成数据生成 + 微调——让 LLM"知道"数据在权重里，而不只是靠上下文窗口。

核心架构

raw/ 源数据 → LLM 编译成 .md wiki → 各种 CLI 操作（Q&A、增强） ↓ Obsidian（查看端）

整个 wiki 的读写维护都是 LLM 的领域，人很少直接动。

Karpathy 的判断：这中间有机会做一个真正的好产品，而不是一个 hack 的脚本集合。