Andrej Karpathy 今天发了一条很长的推文，分享他最近高频在用的一套工作流：让 LLM 帮他构建和管理研究领域的个人知识库。这不是在谈 RAG，也不是在谈某个产品，而是他自己拼起来的一套工具链。核心思路是：把原始文献”编译”成一个 Markdown wiki，然后用同一个 LLM 对这个 wiki 做查询、维护和扩展。
他的原话说得很直接：“我最近有大量时间不是在用 LLM 操作代码，而是在用 LLM 操作知识。“对他来说，这已经是日常研究的标准配置。
数据摄取：从 raw/ 到 wiki
整个流程从一个 raw/ 目录开始。他把所有来源的文档放进去——论文、文章、代码仓库、数据集、图片，格式不限。然后让 LLM 增量”编译”这些原始材料，生成一个 wiki：一个目录结构下的 .md 文件集合。
这个 wiki 不只是摘要堆叠。LLM 会：
- 为每份 raw 数据生成摘要和反向链接
- 识别数据里的概念，为每个概念单独写一篇文章
- 把所有概念文章互相链接
web 文章的转入用 Obsidian Web Clipper 插件来做，他还配了一个快捷键，可以把文章里的相关图片全部下载到本地，方便 LLM 后续引用。
IDE：Obsidian 做前端
他用 Obsidian 当 IDE 前端。原始数据、编译后的 wiki 和派生出来的可视化内容，都在 Obsidian 里统一查看。重要的一点是：wiki 里所有数据都由 LLM 写入和维护，他自己几乎不直接编辑。他也试过一些 Obsidian 插件来做不同形式的展示，比如用 Marp 渲染幻灯片。
不靠 RAG 也能查
当 wiki 积累到一定规模——比如他某个研究方向的 wiki 已经有约 100 篇文章、40 万词——就可以让 LLM agent 在这个 wiki 上跑复杂查询。
他原以为到这个规模必须上 RAG，结果发现没必要。原因是：LLM 本身很擅长维护索引文件和所有文档的简短摘要，到这个”小规模”阶段，它能比较顺畅地读取所有相关数据。他的描述是”~small scale”，字里行间带着一点意外。
输出不只是文本
查询结果不输出到 terminal 或对话框。他让 LLM 把答案渲染成 Markdown 文件、Marp 幻灯片或 matplotlib 图片，然后统一在 Obsidian 里查看。
更关键的是：这些输出经常会被”归档”回 wiki，作为后续查询的基础材料。他的每一次探索和查询，都在积累进知识库。
wiki 的”健康检查”
他会定期对 wiki 跑一些 LLM “health check”：找出数据不一致的地方、用网络搜索补全缺失字段、发现适合写新文章的关联点，持续清理和增强 wiki 的数据质量。他提到 LLM 在”建议下一步该研究什么”上效果也很好。
辅助工具
随着 wiki 越来越大，他开始为它开发额外的工具。他提到”vibe coded”了一个简单的搜索引擎，可以直接用 web UI 访问，也可以通过 CLI 作为工具传给 LLM，用于更大规模的查询。
自然延伸：LLM 团队 + 临时 wiki
他随后补充了一条：这个流程的自然延伸是，对一个前沿 LLM 提出问题时，它会自动召唤一组 LLM 来处理整件事：迭代构建一个临时的 wiki，lint 几轮，最终写出完整报告——远超当前 .decode() 调用的能力上限。
从脚本到产品
这套工作流目前还是”一堆凑合能跑的脚本”，但 Karpathy 认为这个方向有机会变成一个了不起的产品，而不只是散件拼凑。
整件事的起点很简单：不要把 LLM 当搜索框，也不要把它当代码补全工具，而是把它当成一个能持续维护、增强、操作知识的编辑者。这个角色转换，改变了他最近相当大比例的 token 用量方向。