Karpathy 的 llm-wiki 几周冲上五千星：让 AI 别每次都从头学一遍
Karpathy 的 llm-wiki 几周冲上五千星：让 AI 别每次都从头学一遍
每开一个新对话，AI 都像第一天上班。你上周教过它的事、它上次费劲查清的资料、你们一起得出的结论——下一个 session 全部归零，重新解释一遍。这是今天用 AI 工作最大的隐性浪费。Andrej Karpathy 四月初甩出的一个 gist——llm-wiki——给了一个解法，几周内冲到五千多星（截至本文，原始 gist 已累计三万五千多星）。它不是模型、不是产品，只是一个模式：让 LLM 自己建一个 wiki 并持续维护，每用一次都更聪明。
这一篇拆三件事：llm-wiki 的真机制到底是什么、它和炒作的边界在哪、以及你怎么给自己的 AI 装上这层记忆。
本期看点
- llm-wiki —— Karpathy 提出的模式：不靠模型记忆，而是让 LLM 把知识写进一堆 markdown 文件并持续维护，知识在文件里累积，不在模型脑子里。
- 三层架构 —— 原始素材（只读不改）、wiki（LLM 全权维护）、schema（一份说明书，规定 wiki 长什么样）。这三层的分工是整个模式的骨架。
- RAG（检索增强生成） —— 主流做法：每次提问临时去文档堆里捞相关片段拼答案。llm-wiki 要替代的就是它"每次从零捞"的毛病。
- 复利（compounding） —— 知识一旦写进 wiki 就留下了，交叉引用建好了、矛盾标记过了，下次直接用。越用越省，这是 agent 真正的复利来源。
一、它到底是什么：把知识从模型脑子里挪到文件里
先把这条推文的来龙去脲讲清。六月三日，AI 基础设施公司 SiliconFlow 发了条推文，回复在 Karpathy 名下：
"@karpathy 的 llm-wiki 几周冲到五千多星。理念：别在每个 session 重新发现知识。让一个 LLM 构建并维护一个 wiki，每次用都更聪明。这里教你怎么用 opencode + OMO + SiliconFlow 自建一个。"
这条只是二手转述，真东西在 Karpathy 四月四日的 gist 原文里。他要对付的靶子是 RAG——retrieval-augmented generation，检索增强生成。RAG 是现在喂资料给 AI 的主流办法：你上传一堆文档，提问时系统临时去文档里捞出相关片段，拼进提示词让模型作答。Karpathy 一句话点破它的毛病——它"每次提问都从头重新发现知识"。捞片段、拼答案、用完即弃，模型从不沉淀，问一百次同一类问题就重新捞一百次。
llm-wiki 反过来：不让模型在回答时临时捞，而是让模型提前把知识消化成结构化的 wiki 页面，存成文件。下次再问，它读的是自己上次整理好的成品，而不是原始素材的碎片。差别用一句话讲——RAG 把图书馆的检索目录交给你，llm-wiki 让 AI 先把书读了写成笔记，你看笔记。
二、真机制：三层架构 + 三个动作
很多人看到"让 AI 维护 wiki"就以为是丢个文件夹让它瞎写。真机制比这讲究，核心是三层分工，每层归属权清清楚楚。
第一层是原始素材，只读不改。你收集的文章、论文、网页，AI 可以读但永远不动它们。这是事实的锚，防止 AI 把自己的二手总结当成原始证据。
第二层是 wiki，AI 全权维护。一堆 markdown 文件：每篇素材一页摘要、每个人物或产品一页实体卡、每个概念一页解释，外加页面之间的交叉引用。Karpathy 原话："LLM 完全拥有这一层。它创建页面，在新素材进来时更新页面，维护交叉引用，保持一切一致。"
第三层是 schema，一份配置说明书（比如一个 CLAUDE.md 文件），规定 wiki 的结构、命名约定、工作流程。Karpathy 说这份说明书"让 LLM 成为一个有纪律的 wiki 维护者，而不是一个普通聊天机器人"。这层是整个模式能不能跑起来的关键——没有它，AI 写出来的就是一团乱麻。
三层之上是三个动作，构成维护循环：
吃（ingest）：丢一篇素材进去，AI 读完、跟你讨论要点、写一页摘要、更新索引、刷新相关的实体页和概念页、记一笔日志。Karpathy 给的量级是——一篇素材进来可能牵动十到十五个 wiki 页面。
问（query）：你提问，AI 去 wiki 里搜相关页面、带引用合成答案，并把这次问出来的有价值的新发现反过来归档成新页面。问的过程本身也在喂养 wiki。
查（lint）：定期体检——找矛盾、找过时的说法、找没人引用的孤儿页、找缺失的交叉引用和数据空洞。这一步是 wiki 不腐坏的保险。
两个固定文件托底：一个 index.md 当目录，每次吃素材都更新；一个 log.md 只增不改，按 ## [日期] ingest | 标题 这种可解析的前缀记流水。
三、为什么它能产生复利
Karpathy 给的判断很硬：wiki 是一个"持久的、产生复利的产物"。他点出复利的来源——"交叉引用已经建好了，矛盾已经被标记过了。"
这句话值得拆开。RAG 模式下，你问第一遍和问第一百遍，系统干的活一样多——都得从原始文档现捞现拼。成本是平的，永远不下降。llm-wiki 模式下，第一次吃一篇素材确实花力气（要写摘要、建实体页、连交叉引用），但这力气只花一次。之后所有相关的提问，读的都是这次沉淀的成品。第一次贵，后面越来越便宜。
这就是 agent 的复利和模型的复利的区别。模型变强靠的是参数和训练数据，那是模型厂商的事，你管不着。agent 变强靠的是它身边那层不断累积的知识，那是你能控制的复利。一个挂着精心维护知识库的普通模型，干特定领域的活可以稳稳压过一个什么都不记的顶配模型。
更关键的是分工没变——Karpathy 强调"人类判断仍是核心"："你负责找素材、探索、问对问题。LLM 干所有的粗活。"wiki 不替你思考，它替你记住、整理、保持一致。你出判断，它做苦力。
四、真机制和炒作的边界
五千星之后，围着这个模式长出一圈实现——有人做成开源 app（lucasastorian/llmwiki），有人封成各家 agent 都能用的 skill（Astro-Han/karpathy-llm-wiki），SiliconFlow 这条推文推的是 opencode + OMO 自建路线。热度起来了，得把真东西和被吹过头的部分分清。
真的值钱的部分：知识沉淀这个思路本身。把"每次从零"换成"持续累积"，这个方向对得没话说，任何重复用 AI 处理同一领域的人都该往这个方向走。
容易被吹过头的部分：以为装个工具就自动变聪明。三层里最难的是第三层 schema 和第三个动作 lint——也就是定规矩和做体检，这两件恰恰最难自动化，最吃人的纪律。wiki 不会自己保持干净，AI 写嗨了照样写出一堆孤儿页、自相矛盾的说法、越积越多的过时信息。没人定期 lint，三个月后这个 wiki 就是个新的垃圾堆，比 RAG 还难用。Karpathy 那句"有纪律的维护者"不是修辞——纪律是这套东西的成败点，而纪律来自那份 schema 说明书，不来自模型本身。
还有一层得说破：这个模式天然偏向你反复深耕的领域。一次性的问题，建 wiki 的前期成本根本收不回，老老实实用 RAG 或者直接问更划算。llm-wiki 是给"长期、重复、同一战场"准备的，不是万能替代品。
五、这套东西，这个内容工厂已经在跑
把 Karpathy 的三层架构摆出来对照，会发现一件事：你正在读的这篇文章，就是用这个模式生产的。
这个内容工厂的目录结构和 llm-wiki 几乎逐项对应——一个 raw/ 放用户丢进来的原始素材，规矩是"只丢不管、不可变"，这就是第一层只读素材；一个 wiki/ 由 AI 全权维护，下面分 sources/（每篇素材一页摘要）、concepts/（人物产品术语实体页）、topics/（选题）、published/（复盘），这就是第二层；一份 CLAUDE.md 规定所有页面必须带 YAML frontmatter、页面之间用 [[wikilinks]] 互链、每次操作前后更新排期，这就是第三层 schema。连两个托底文件都在——index.md 当索引，log/current.md 按日期记流水。三个动作也在：吃（ingest）、写（produce）、评（feedback）。
这不是巧合。Karpathy 四月提出的模式，把很多人摸索中的"给 AI 建记忆层"这件事讲清楚了、给了名字。它能几周冲五千星，正是因为大量已经在土法上马的人，终于看到了一个被系统化的样板。
对从业者意味着什么
对个人：你和 AI 反复打交道的那个领域——你的代码库、你追的某个赛道、你的客户资料——别再每个 session 重头教。建一个文件夹当 wiki，写一份说明书（schema）规定它怎么长，让 AI 吃素材时顺手维护。从最小可用开始：一个 index.md、一个 log.md、一个约定俗成的页面格式，就能跑。难的不是搭，是坚持 lint。
对团队：团队的知识沉淀别只躺在 Notion 里给人看，要存成 AI 读得动的结构化格式。一份给人看的 wiki 和一份给 agent 读写的 wiki，差别在 schema 够不够严、交叉引用够不够全。把团队 wiki 改造成 agent 能吃能写的形态，新人和新 agent 上手成本会一起降。
对做 agent 产品的：记忆层正在从"对话历史"升级成"结构化、可累积、会被 lint 的知识库"。谁能把第三层 schema 和 lint 这两件最难自动化的事做好，谁就握住了 agent 复利的真正抓手——不是更大的上下文窗口，是更干净、越用越厚的那层知识。
引用
- SiliconFlow 推文（介绍 llm-wiki 并给出 opencode + OMO + SiliconFlow 自建路线，英文，2026-06-03）：https://x.com/SiliconFlowAI/status/2062054848762450324
- Andrej Karpathy 原始 gist《LLM Wiki》（模式原文，2026-04-04，本文三层架构、三动作、复利论述均出自此）：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- oh-my-openagent（OMO）项目主页（opencode/codex 的多 agent 编排插件，自建路线用到）：https://github.com/code-yeongyu/oh-my-openagent