当所有人都在聊 AI 写代码的时候，Karpathy 把 token 花在了另一个地方：把原始资料"编译"成一个不断生长的个人 Wiki。这个思路比你想象的深远得多。
起因
最近 Karpathy 发了一条长推文，标题叫 "LLM Knowledge Bases"。
核心意思是：他最近大量使用 LLM 的方式已经不是写代码了，而是操作知识——用 Markdown 和图片来存储、组织、查询、生成。
他的原话大意是，他的 token 吞吐量正在从"操作代码"转向"操作知识"。
这条推文在开发者圈子里没有像 autoresearch（21K Star）或他去年那句"我从 12 月起就没打过一行代码"那样炸裂传播，但我觉得它揭示的东西可能更本质——因为它回答了一个很多人没想清楚的问题：
除了写代码，LLM 还能拿来干什么高杠杆的事？
答案是：帮你构建和维护一个会自我生长的知识系统。
Karpathy 具体怎么做的
他的方法拆开来其实不复杂，但每一步的设计都很有讲究。
第一步：数据收集
他把所有原始资料——论文、文章、代码仓库、数据集、图片——都丢进一个叫 raw/ 的目录。
内容采集主要靠 Obsidian 的 Web Clipper 浏览器扩展，一键把网页文章转成本地的 .md 文件。他还用了一个快捷键把文章里的所有图片下载到本地，这样 LLM 在处理的时候可以直接引用图片路径，不需要联网。
关键细节：所有东西都是本地的。纯 Markdown 文件，纯文件夹结构。没有云端数据库，没有向量存储，没有复杂的后端。
第二步：LLM "编译" Wiki
这一步是整个流程最核心的环节。
他不是自己手动整理这些资料，而是让 LLM 把 raw/ 目录里的原始数据"编译"成一个结构化的 Wiki。这个 Wiki 也是一堆 .md 文件，但跟原始资料不同的是，它有：
- 每篇原始资料的摘要
- 按概念分类的条目文章
- 条目之间的反向链接
- 自动维护的索引文件
注意他用的词："编译"（compile）。不是"整理"，不是"归纳"，而是编译。这个用词很精确——就像编译器把源代码转成可执行文件一样，LLM 把散乱的原始资料转成了一个可查询、可导航、可持续增长的知识结构。
还有一个关键点：他几乎不直接编辑 Wiki 的内容。Wiki 完全由 LLM 写和维护，他只是偶尔看看、提问、下达指令。
第三步：在 Obsidian 里浏览
他用 Obsidian 作为前端 IDE，来查看原始数据、编译好的 Wiki、以及各种衍生的可视化内容。
Obsidian 的核心优势在这个场景下特别突出：双向链接让你可以从任何一个概念条目跳转到相关的原始资料、其他概念条目、或者之前的查询结果。图谱视图（Graph View）让你直观看到知识之间的关联结构——哪些概念是孤立的，哪些是高度连接的节点。
他还尝试了一些 Obsidian 插件来用不同方式渲染数据，比如 Marp（一个把 Markdown 转成幻灯片的工具）。
第四步：对 Wiki 做 Q&A
当 Wiki 积累到一定规模的时候（他提到他的某个研究 Wiki 已经有大约 100 篇文章、40 万字），事情开始变得有趣了。
你可以向 LLM agent 提出各种复杂问题，它会在 Wiki 里研究、交叉引用，然后给出答案。
这里有一个让很多人意外的发现：他说他以为需要用到复杂的 RAG（检索增强生成），但实际上 LLM 自己维护的索引文件和摘要就够用了。 在这个"小规模"下（约 40 万字），LLM 可以很轻松地读取所有相关数据。
这一点非常值得深入讨论，我们后面会展开。
第五步：输出不是文字，是文件
这一步体现了 Karpathy 对 LLM 交互范式的深刻理解。
他不满足于在终端里看到文本回复。他让 LLM 输出的是 Markdown 文件、Marp 格式的幻灯片、matplotlib 生成的图表——所有这些都可以直接在 Obsidian 里查看。
更重要的是，他会把这些查询输出"归档"回 Wiki 里，变成知识库的一部分。这意味着你每次提问和探索，都在增厚知识库，让后续的查询更丰富、更准确。
这跟大部分人用 ChatGPT 的方式完全不同。大部分人的对话都是"用完就扔"的，下次重新来过。Karpathy 的方式让每次交互都有"复利"。
第六步：LLM 做"健康检查"
他会定期让 LLM 对 Wiki 做一种类似代码 linting 的操作：
- 找出自相矛盾的数据
- 补充缺失的信息（结合网络搜索）
- 发现可以写新条目的有趣关联
- 提高整体数据的一致性
他说 LLM 非常擅长给你建议"接下来应该研究什么"。
第七步：为 LLM 开发专属工具
他还 vibe coded 了一个小型的 Wiki 搜索引擎。既可以自己在 Web UI 里直接用，更多时候是把它作为 CLI 工具交给 LLM，让 LLM 在处理更大的查询时有一个高效的检索手段。
终极展望：微调让 LLM "学进"知识
他在最后提到，随着知识库不断增长，一个自然的想法是用合成数据生成加微调的方式，让 LLM 把这些知识"内化"到模型权重里，而不只是放在上下文窗口中。
这个方向跟他之前在 OpenAI 做的工作（midtraining 和合成数据生成）直接相关。
为什么我觉得这个思路比 AI 写代码更重要
AI 写代码已经是一个被充分讨论的话题了。但 AI 操作知识？这个方向才刚刚开始。
Karpathy 的这套方法揭示了几个深层趋势：
趋势一：Markdown 正在成为 AI 的"编程语言"
这一点在 2026 年越来越明显了。
Karpathy 今年 3 月开源的 autoresearch 项目（21K Star）让这个趋势具象化了。在 autoresearch 里，人类不写 Python，人类写的是一个叫 program.md 的 Markdown 文件，然后 AI agent 根据这个文件自主运行实验——修改代码、训练模型、评估结果、保留改进、循环往复。一夜之间跑 100 个实验，零人工干预。
同样的模式在 AI 编程领域也在发生。Claude Code 用 CLAUDE.md，GitHub Copilot 用 AGENTS.md，Garry Tan 的 gstack 用 SKILL.md。所有这些的共同点：人类写 Markdown，AI 读 Markdown 然后行动。
Karpathy 自己在今年初说得很直白："Vibe coding 已经过时了。新的范式叫 agentic engineering——你 99% 的时间不是在直接写代码，而是在编排 agent 并充当监督者。"
而他的 LLM Knowledge Base 方法，本质上就是"用 Markdown 编排 AI 来操作知识"。
趋势二：RAG 可能被高估了（在小规模下）
Karpathy 明确说，他以为需要用 RAG，但发现不需要。LLM 自己维护的索引和摘要就够了。
这个观察跟 Vercel 今年做的一个实验结论惊人一致。Vercel 对比了 Agent Skills（类似 RAG 的按需加载方式）和直接把信息嵌入 AGENTS.md 的方式，结果后者拿到了 100% 的测试通过率，而前者最高只到 79%。
原因是 RAG 引入了一个"决策点"——AI 需要决定什么时候去检索、检索什么。而在小到中等规模的知识库里（比如 Karpathy 的 40 万字），直接让 AI 读索引文件、然后按需读原文，比 RAG 更可靠。
当然这个结论有适用范围。当知识库大到几百万字甚至更大的时候，你可能确实需要向量检索。但对于大部分个人知识管理场景来说，Karpathy 的方法可能比搭一套 RAG pipeline 更实用。
趋势三：AI 知识系统的"污染"问题
这是一个被大部分人忽略、但 Obsidian 官方已经在讨论的问题。
Karpathy 的方法里，查询输出会被归档回 Wiki。这让知识库越来越"厚"，但也带来了一个风险：AI 生成的内容和可靠来源的原始资料混在一起了。
长期来看，这会导致"知识库污染"——你不再确定哪些信息是可靠的一手资料，哪些是 AI 的推断或总结。如果 AI 在某个环节产生了一个错误的推断，这个错误会被后续的 AI 查询引用、放大，形成滚雪球效应。
Karpathy 在原文中没有正面回应这个问题，但有开发者建议的解决方案很直接：把 AI 生成的内容和原始来源分开存放。比如用 raw/（原始资料）和 compiled/（AI 编译）和 derived/（AI 查询产出）三个目录来区分。
在 Obsidian 里可以用标签或文件夹来标记内容的可靠性等级：#source/primary（一手资料）、#source/ai-compiled（AI 编译）、#source/ai-derived（AI 派生）。
趋势四：知识工作的自动化比编码自动化更普适
写代码毕竟是少数人的工作。但整理知识、做研究、写报告、交叉引用——这是所有知识工作者的日常。
Karpathy 的方法虽然是面向 AI 研究的，但核心模式完全可以迁移：
- 产品经理：把竞品分析、用户反馈、行业报告丢进
raw/，让 LLM 编译成一个按功能维度、用户痛点、市场趋势组织的 Wiki，然后在上面提问做决策 - 投资分析：把公司财报、行业新闻、专家访谈编译成一个投资 Wiki，自动交叉验证数据、发现不一致、生成分析报告
- 学术研究：把论文、数据集、实验笔记编译成一个研究 Wiki，自动生成文献综述和研究缺口分析
- 内容创作：把阅读笔记、灵感片段、素材库编译成一个创作 Wiki，根据主题生成大纲和初稿
本质上，任何"收集大量信息 → 理解关联 → 形成洞察"的工作流，都可以用这套模式。
2026 年的工具生态已经准备好了
Karpathy 说他目前用的还是"一堆脚本的拼凑"（hacky collection of scripts），认为这个方向有巨大的产品机会。
事实上，围绕 AI + 个人知识管理的工具生态在 2026 年已经相当成熟了：
Obsidian：依然是基石
Obsidian 在 2026 年 2 月刚突破了 150 万用户，同比增长 22%。它的优势在这个场景下几乎是不可替代的：本地优先（数据完全在你手里）、纯 Markdown（任何 AI 都能读写）、1500+ 社区插件、原生支持双向链接和图谱视图。
最关键的是，Obsidian 的 MCP 集成让 Claude Code 等 AI agent 可以直接读写你的 Vault。这意味着你可以坐在终端里，让 AI agent 直接操作你的知识库——创建笔记、建立链接、生成摘要、做健康检查——全部命令行完成。
Smart Connections 是目前最受欢迎的 Obsidian AI 插件。它用 RAG 让你可以跟整个 Vault 对话，AI 的回答会基于你自己的笔记。支持本地模型（通过 Ollama 或 LM Studio），也支持 Claude、GPT 等云端 API。
Khoj：开源 AI 第二大脑
Khoj 是一个自托管的 AI 第二大脑工具，可以连接 Obsidian、Notion、PDF、Word 等多种数据源。它支持自定义 agent、定时自动化、深度研究，可以用任何在线或本地 LLM。完全开源，免费使用。
COG：Claude + Obsidian + Git
一个有趣的新兴方案叫 COG（Claude + Obsidian + Git），本质上是一个自组织的第二大脑。Claude 负责整理和组织笔记，Obsidian 负责存储和展示，Git 负责版本控制。特别适合那种"擅长记笔记但永远不整理"的人。
Notemd：Obsidian 的 Wiki 链接插件
专门为 Karpathy 这种场景设计的插件。它会用 LLM 自动为你的笔记中的关键概念生成 Wiki 链接，创建对应的概念笔记，做网络研究补充内容。
实操：怎么从零搭一套
如果你想实践 Karpathy 的方法，这里有一条可行路径：
1. 搭建基础结构
在 Obsidian Vault 里创建三个核心目录：
vault/
├── raw/ # 原始资料（人工收集的可靠来源）
├── wiki/ # LLM 编译的知识 Wiki
├── derived/ # LLM 查询产出的内容
├── index.md # LLM 维护的总索引
└── CLAUDE.md # 给 AI agent 的指令文件
2. 配置内容采集
安装 Obsidian Web Clipper 浏览器扩展。在 Clipper 的设置里，配置好自动保存到 raw/ 目录，让它在剪藏的时候自动做以下处理：
- 打标签（来源类型、主题分类）
- 生成摘要
- 翻译（如果是外文内容）
- 下载关联图片到本地
3. 让 LLM 编译 Wiki
用 Claude Code 或其他 CLI agent 连接你的 Obsidian Vault（通过 MCP 或直接文件系统访问），然后给它一个任务：
"读取 raw/ 目录里的所有文件，为每个文件写一段摘要，然后识别其中的核心概念，为每个概念在 wiki/ 目录创建一个条目文件。条目之间用 Obsidian 的 [[双向链接]] 相连。维护一个 index.md 索引文件，列出所有条目和摘要。"
4. 持续增长
每次你往 raw/ 丢新资料，让 LLM 做一次增量编译——只处理新增内容，更新索引，补充相关条目的链接。
每周做一次"健康检查"——让 LLM 找矛盾、补缺失、发现新关联。
5. 在 Wiki 上提问
当 Wiki 积累到一定规模后，你可以直接问 LLM 各种问题。关键技巧：让 LLM 先读 index.md 找到相关条目，再读相关原文。这比让它一次性读完所有文件要高效得多。
输出尽量让它生成文件（Markdown、图表、幻灯片），而不是在对话框里显示文字。然后把有价值的输出归档到 derived/ 目录。
深层思考：知识的"编译"和"执行"
Karpathy 用"编译"这个类比，其实暗示了一个更深的思考框架。
在传统编程中：源代码 → 编译器 → 可执行程序 → 执行
在 Karpathy 的知识模式中：原始资料 → LLM → 结构化 Wiki → Q&A / 分析 / 报告
这个类比还可以继续延伸：
- 预处理（preprocessor）：Web Clipper 剪藏、格式转换、翻译
- 编译（compile）：LLM 把原始资料转成结构化的 Wiki 条目
- 链接（link）：LLM 建立概念之间的双向链接和索引
- 优化（optimize）：LLM 做健康检查，消除冗余、修复矛盾
- 执行（execute）：在 Wiki 上做 Q&A，生成报告和可视化
- 调试（debug）：发现知识缺口，补充新的原始资料
这个框架的优势在于，它把"模糊的知识管理"变成了"有明确步骤的工程流程"。每一步都是可自动化、可度量、可迭代的。
而且，就像 Karpathy 的 autoresearch 项目证明的那样——一旦你把流程定义清楚，AI agent 可以自主运行。你只需要写好"program.md"（知识库的编译规则），剩下的交给 AI 执行。
Karpathy 自己的进化轨迹
如果你把 Karpathy 近一年的公开动作串起来看，会发现一条清晰的演进路线：
2025 年 2 月：提出 "Vibe Coding" 概念——用自然语言描述意图，让 AI 写代码
2025 年底：在年度总结里提出 "LLM GUI" 的概念——LLM 应该用图片、幻灯片、可视化来跟人交互，而不只是文字
2026 年 3 月初：发布 autoresearch（21K Star）——用 Markdown 文件编程 AI agent，让它自主跑 ML 实验
2026 年 3 月底：分享 LLM Knowledge Base 方法——用 LLM 编译和维护个人知识库
你能看到一个一致的主题：让 AI 从"回答问题的对话框"变成"持续工作的自主系统" 。
Vibe Coding 是"你说，AI 做"。Agentic Engineering 是"你写指令，AI 自主执行"。LLM Knowledge Base 是"你提供原始资料，AI 自主编译、维护、增长知识系统"。
每一步都在减少人类的直接参与，增加 AI 的自主性。
这件事的意义
Karpathy 在推文最后说了一句值得玩味的话："我觉得这里有一个做出不可思议的新产品的机会，而不只是一堆脚本的拼凑。"
他说得对。目前的工具虽然多，但没有一个真正把这条完整的管线（收集 → 编译 → 索引 → 查询 → 输出 → 归档 → 健康检查）做成开箱即用的产品。
更重要的是，这个方向代表了一种范式转变：从"人整理知识"到"AI 整理知识，人做决策"。
过去十年的知识管理工具——从 Evernote 到 Notion 到 Obsidian——本质上都是在帮你"更好地手动整理"。它们给你更好的编辑器、更好的组织结构、更好的搜索。但整理工作本身还是你做。
Karpathy 的方法把这个逻辑翻转了。你不整理。你只管往 raw/ 里扔东西，整理是 AI 的活。你的精力应该花在"提好的问题"和"做判断"上。
这跟 AI 编程领域发生的事情完全同构。在 gstack 的模式里，你不写代码，你做产品决策；在 Karpathy 的模式里，你不整理知识，你做研究决策。
对于每一个知识工作者来说，这可能是 2026 年最值得花时间研究的 AI 应用方向。不是因为它能帮你"更快地做笔记"，而是因为它能帮你"更好地思考"。
Karpathy 原文：x.com/karpathy/st…
本文信息截至 2026 年 4 月 3 日。
