大模型知识库教程（非常详细）：搞懂Karpathy的Wiki，看这一篇就够了！

这两天Andrej Karpathy 连着发了几份关于LLM Wiki的材料。一份是 2026 年 4 月 4 日发布的llm-wiki.mdgist一份是 4 月 5 日关于个人知识库工作流的长帖。后面还有一个更具体的例子叫Farzapedia。我一开始也以为这只是又一种“个人知识库工作流”。但把这几份材料放在一起看会发现它比传统知识库多出来的不只是 Obsidian、Markdown 或者索引。它补上的是原始资料和问答结果之间那层长期存在、持续更新、能反复被 Agent 利用的 wiki 中间层。如果只看“能回答问题”这件事和很多 RAG 系统有点像。但如果把“知识会不会留下来会不会随着使用慢慢长出来”也算进去两者就不是一回事了。太长不看版• 传统知识库更像“提问时再检索”LLM Wiki更像“先把知识编译成一个持续存在的中间层”。• 这套思路里有三层raw sources是事实源wiki是 LLM 维护的知识层schema是规则层。•schema很像AGENTS.md/CLAUDE.md它决定了 wiki 怎么组织、怎么 ingest、怎么 query、怎么做健康检查。• 这份 gist 被 Karpathy 明确写成了一个idea file。意思不是直接交付成品而是把思路交给别人的 Agent由它结合具体需求往下实现。• Karpathy 提到在大约100 篇资料、40 万词的规模下靠索引和摘要已经能撑起不少查询但这句话本身有边界。• 新例子Farzapedia很有意思它不是“做给人看的第二大脑”而是“做给 Agent 用的个人百科”。• 我自己看下来LLM Wiki很特别的地方是它让知识不只被检索还会被回写、被校验、被慢慢复利。它多出来的是一层中间层Karpathy 在原文里先对比了最常见的文档使用方式。大多数人现在用 LLM 和文档打交道基本都是 RAG 思路上传一批文件提问时检索相关片段然后生成答案。这个模式能用也已经很普及。问题在于它天然不积累。你今天问一次“这 5 篇文章共同说明了什么”模型会去找 5 次片段、拼 1 次答案。过两天你换个问法它大概率还要再做一遍。LLM Wiki想补的就是这层缺口。它不是在查询时临时去原始资料里捞信息而是先把资料整理成一层持续存在的 wiki。这里面会有摘要、概念页、实体页、对比页、综合页、索引页也会有交叉引用和后续修订。如果换个更直白的说法传统知识库更像“临时检索”LLM Wiki 更像“先编译再查询”。把两者放在一起看差异会更清楚维度常见 RAGLLM Wiki主要动作查询时检索原文片段先把知识编译成结构化 wiki中间产物通常很薄甚至没有有持续存在的 Markdown 知识层问答后的沉淀常常留在聊天记录里好的结果可以回写成新页面模型角色检索后回答持续维护知识系统典型风险每次都要重新发现知识wiki 变大后需要治理与校验这里倒也不是说 RAG 不重要了。更像是多了一层以前经常缺席的东西原始资料和最终回答之间多了一个会被持续维护的知识层。它本身就是一个idea fileKarpathy 在 4 月 5 日那条“这条推文火了”的补充里专门解释了一件事他为什么把这件事整理成 gist。他的说法很有意思。在 LLM agent 时代很多时候不一定非要先分享一个完整 app 或一份完整代码。也可以先把思路写成一个相对抽象的idea file再交给对方的 Agent 去结合自己的场景落地。这其实也解释了为什么llm-wiki.md会写得比较克制。它没有把目录结构、字段、模板、工具链一次性写死而是有意留出空间。不同的人拿到它之后可以往个人笔记、研究资料库、团队 wiki甚至是像Farzapedia这种个人百科方向去延伸。这样看LLM Wiki不只是一个知识库模式也有点像一种新的分发方式• 分享的不是成品• 分享的是一种结构化思路• 接力完成落地的是接收方自己的 AgentKarpathy 原文里有一个很精准的比喻Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.Obsidian 是 IDELLM 是程序员wiki 是代码库。这么说的话idea file大概就相当于一份设计文档——你拿到它交给你的 Agent它帮你把项目搭起来。这个角度我觉得挺值得记一下。因为它和传统“发仓库、发模板、发产品”的感觉不太一样。三层结构并不复杂但第三层很关键如果只看结构这套东西其实不难理解。LLM 知识库工作流,来自nash_su图里有三层•Raw sources文章、论文、图片、数据文件、代码仓库。这一层只读不改是事实源。•The wiki由 LLM 生成和维护的 Markdown 目录。摘要、实体页、概念页、对比页、综合页都在这里。wiki 里还有两个关键的特殊文件下一节会展开。•The schema告诉 LLM 这个 wiki 应该怎么组织、怎么命名、怎么摄取、怎么回答、怎么做 lint 的规则文档。第一层和第二层都比较直观。更容易被忽略的反而是第三层schema。Karpathy 在 gist 里举的例子也很清楚对 Claude Code 来说这层可以是CLAUDE.md对 Codex 来说这层可以是AGENTS.md。它更像一份运行约定至少会定义这几件事• 目录怎么分• 页面该长成什么样• ingest / query / lint 各自走什么流程• 什么时候允许自动写什么时候必须人工复核没有这层LLM 当然也能整理资料但每次整理的方式可能都不一样。命名会漂页面结构会漂引用习惯也会漂。有了这层以后wiki 才更像一个能长期维护的系统而不只是一个被聊天记录慢慢堆出来的文件夹。这个地方其实也正好把LLM Wiki和我们平时理解的“记笔记工具”区分开了。index.md和log.md其实是两个不同的导航器gist 里还有一个很具体、但容易被略过的点是index.md和log.md的分工。Karpathy 并没有把“索引”当成一句笼统的话而是把它拆成了两个特殊文件•index.md是面向内容的目录•log.md是面向时间的记录index.md更像内容地图。里面按类别列出页面、链接和一行摘要。LLM 在回答问题时先读这个目录再往下钻具体页面。log.md则像一条按时间追加的流水。什么时候 ingest 了一篇新资料什么时候做了一次 query什么时候跑了一次 lint都能往里记。这两个文件放在一起作用其实挺不一样•index.md帮你回答“这里都有什么”•log.md帮你回答“最近发生了什么”这一点很像软件项目里“目录索引”和“变更记录”的关系。一个管空间一个管时间。而且这也能帮助理解为什么 Karpathy 会说在中等规模下单靠索引和摘要就已经很有用。因为这里的“索引”并不是一句空话而是一层真正能导航、能缩小范围、能减少无效读取的中间结构。为什么Farzapedia这个例子很具体新素材里我觉得最有帮助的是Farzapedia这个例子。Farza 让 LLM 读取了大约2500条个人材料包括日记、Apple Notes 和一部分 iMessage 对话最后生成了400篇相互链接的个人百科文章。这些文章不是单纯为了“把自己存下来”。他原话里有一句很关键这个 wiki 不是为我建的而是为我的 agent 建的。这一下就把方向讲清楚了。很多个人知识库最后都停在“方便我回头翻”。Farzapedia这个例子展示的是另一种方向把你的个人材料整理成 Agent 能理解、能导航、能钻取的文件系统。而且 Farza 讲得很具体不是泛泛地说“Agent 可以用”。他的描述是直接把 Claude Code 拉起来从index.md开始让 Agent 一层层钻到需要的页面。比如他举的一个查询是想给新产品做 landing page于是让 Agent 去他的 wiki 里找最近喜欢过的图片、电影、竞品页面和一些长期记下来的审美线索最后综合出文案和视觉方向。这时候wiki 就已经不只是“记忆容器”了更像 Agent 的长期工作底稿。Karpathy 后来转发这个例子时还补了四个点我觉得也很能说明问题• 它是显式的你能看到 AI 到底知道什么、不知道什么• 它是你的数据留在本地不锁在某个模型厂商里• 它更像file over app因为底层就是一组通用文件• 它是BYOAI的你可以换 Claude、Codex 或别的模型继续用这些话听上去有点理想化但放在Farzapedia这个例子里反而很具体。它把“个人记忆”“可导航文件系统”和“Agent 工作上下文”这三件事接到了一起。这个思路让我想到之前写过的《记住不难想起才难Clawdbot 的内存架构与压缩前刷新》当时 Clawdbot 做的事情更小——把聊天记忆存成 Markdown 文件。Farzapedia算是把这条路往前推了一大步不只是存记忆而是把记忆编译成一个 Agent 能自主导航的文件系统。开始复利的往往是回写这一步LLM Wiki还有一个让我印象很深的地方是它不是把“提问”当成消耗而是当成继续积累的一部分。这点在两张图里都能看出来。LLM Wiki 与传统知识库对比,yanhua1010一旦问答结果可以回写成新页面知识的生命周期就会变得不太一样。比如一次对比分析、一页总结、一张图、一份幻灯片本来都可能只是聊天里的临时产物。回写之后它们会变成后续查询的新上下文。所以这套东西和传统知识库最大的差别不只是“能不能回答”而是回答完之后东西会不会留下来。如果把这个过程写成最简的闭环其实也就三步• ingest 新资料• query 已有 wiki• 把有价值的输出 file back 到 wiki然后再加一层 lint定期看哪里矛盾、哪里过期、哪里断链。这样一来它更像一个会慢慢长出来的系统而不是一个回答过就结束的问答界面。如果你关注过《Claude Code 长任务为什么不容易跑偏》那篇会发现 Claude Code 的 runtime 也在做类似的事——通过压缩和摘要让上下文在长会话里不至于断掉。LLM Wiki的 file back 可以看作是把这个思路从“单次会话”拉到了“跨会话”的尺度。Karpathy 自己怎么用这套东西如果只看 gist容易把它理解成一套抽象设计。但放回 4 月 5 日那条长帖里会发现他的使用方式其实挺具体• 原始资料会进raw/类型包括文章、论文、代码仓库、数据集和图片• 网页资料会用 Obsidian Web Clipper 转成 Markdown• 图片会尽量下载到本地方便 LLM 后续直接引用• Obsidian 被他当成一个 IDE 式前端用来同时看原始资料、编译后的 wiki 和派生输出• 派生输出不只是一段文本也可能是 Markdown 页面、Marp 幻灯片、matplotlib 图gist 里还补了一个细节我觉得也很有用Karpathy 自己更偏好一次 ingest 一份来源并且会参与这个过程看摘要、看更新、再决定强调什么。这点其实挺能说明他的真实预期。它不是完全无人值守的一键流水线更像一种“人和 Agent 一起维护知识层”的工作流。他还提到了一个更往后的方向随着 wiki 规模继续增长可以考虑用合成数据做微调让 LLM 把知识“记进权重”而不只是放在上下文窗口里。这一步他自己也还在探索但方向已经写出来了——wiki 不只是终点也可以是训练数据的来源。如果把这套完整的工作流展开看大概是这样LLM Wiki 完整架构,AYi_AInotes那它是不是就不需要 RAG 了Karpathy 原文里有一句很容易被单独摘出来传播的话在他这个规模下大约100 篇资料、40 万词不一定需要很复杂的 RAG 基础设施。这句话我觉得可以记但最好连着前提一起记。它成立的原因不是模型突然不需要检索了而是他先让模型把资料整理成了一个更有结构的知识层。查询时先读index.md再去看摘要、概念页和相关页面路径已经比直接翻原始资料短很多。所以在主题相对聚焦、规模还没有继续膨胀的时候index summaries concept pages确实可能替掉一部分复杂检索。但它并不是一个放之四海而皆准的结论。如果数据量继续上去知识域越来越杂或者结果本身要求很强的可追溯性这套东西大概率还是要和更正式的检索、引用、校验机制一起配合。Karpathy 自己其实也留了边界。他在 gist 里专门提到human owns verification。也就是说wiki 可以交给 LLM 维护但最后的验证责任还是在人。社区里已经有人在跑了gist 发出来不到两天评论区已经有不少人在分享自己的实践。有人把这套模式用在了日英词典项目里每天定时让 Agent 更新知识库跑了几周觉得还不错。也有人在做交易终端把每笔交易、每条 alert 都 ingest 进 wiki让 Agent 基于历史表现给出提醒。评论区里有一条经验总结写得比较实在摘几条我觉得有用的•先分类再提取。不同类型的文档报告 vs. 信件 vs. 会议记录应该走不同的处理流程不要一刀切。•给索引设一个 token 预算。读 index 的时候控制篇幅不要每次都把全文拉进来。•每种实体类型一个模板。人物页和事件页需要不同的字段不要只用一个通用模板。•每次任务产出两份东西。一份是回答用户的输出一份是回写 wiki 的更新。如果不在 schema 里写清楚这一条LLM 做完就忘了。•人负责校验。LLM 可以综合但不一定会引用来源。在 schema 里加上引用要求自己也要定期抽查。还有人直接写了 CLI 工具比如sage-wiki、CRATE实现了 compile / query / lint 的完整闭环。也有人用 Go 写了一个单二进制文件一个命令就能初始化 Obsidian vault 并开始编译。这些工具和实践当然还很早期但至少说明这个模式确实在不同场景下跑得通。为什么这件事会让很多人有感觉从这次的 gist、长帖到后面的Farzapedia其实能看到一个很一致的方向大家感兴趣的不只是“知识存在哪里”而是“能不能留下一层 Agent 下次还用得上的结构化结果”。这也是我觉得LLM Wiki最有意思的地方。它没有把重点放在“记更多”而是放在“留下更稳定的中间层”。这个中间层既能给人看也能给 Agent 用既能继续查询也能继续维护既是文件也是工作上下文。一个有意思的历史呼应gist 最后还提到了一个人名Vannevar Bush。1945 年Bush 在一篇文章里描述过一个叫Memex的设想——一种私人的、持续整理的知识存储系统文档之间通过关联路径相互连接。Karpathy 提到这个对比倒不是在给自己贴标签。他的意思更像是Bush 当年设想的那套东西和后来的万维网不太一样。Memex 更私人、更注重主动整理、更看重文档之间的联系本身。而 Bush 没解决的那个问题——“谁来做维护”——现在 LLM 可以接过去了。知识库这类系统人类放弃维护的速度通常比知识增长的速度更快。LLM 不会觉得烦不会忘了更新一条交叉引用一次操作可以同时改十几个文件。维护的成本接近零wiki 才有可能真的活下来。这大概也是为什么这套东西让不少人觉得“对了”——不是因为技术上有多复杂而是它终于把“谁来维护”这个老问题交给了一个不会累的角色。我自己看完后留下的三个感受如果把这几份材料合在一起我自己最后留下来的不只是“这个点子挺好”。更像是三件事。1. 它把 Agent 的“记忆”从黑盒往显式工件拉了一步很多时候我们说一个 Agent “越来越懂你”或者“越来越懂项目”其实很难回答一个问题它到底懂了什么这些东西又存在哪。LLM Wiki比较特别的地方是它尽量把这层东西落成文件。你能看到目录、页面、索引、日志、反向链接也能看到哪些结论是后来补进去的哪些地方还没整理好。对个人场景来说这让“记忆”不再那么黑盒。对团队场景来说这也意味着很多本来只存在于聊天窗口里的过程开始有机会变成能被后续协作继续利用的工件。之前在《2026 AI Memory 最新综述》那篇里我们聊过 Agent 记忆的 4W 分类框架。LLM Wiki做的事情其实正好对应了其中“记什么、存在哪、怎么取”这几个问题——只不过它给出的答案是记成文件存在本地靠索引去取。2. 它最有价值的未必是回答更准而是知识不会轻易蒸发我自己看完以后最在意的其实不是“这套东西能不能把问题答得更漂亮”。而是它在努力解决另一件常见的小事很多不错的分析、比较、总结最后都停在聊天记录里。过几天要再用又得重新做一遍。file back这一步看起来只是多存一份文件实际上是在改变知识怎么积累。一旦这件事做起来问答就不再只是消耗上下文也开始变成生产上下文。3. 真正麻烦的地方最后还是治理这大概也是我对这类系统最保守的一点。把 Markdown、Obsidian、Agent、索引、图谱连起来并不是最难的部分。更难的通常是后面那些不那么显眼的事• 页面怎么命名• 引用怎么保留• 什么内容能自动写什么内容要人工看• 哪些结论已经过期• 哪些页面只是写得顺但并不可靠如果要说这篇读完能带走什么我觉得不只是一个新模式而是一个提醒知识系统一旦想长期运行最后绕不开结构、回写和校验。如果今天真想试一下可以先从一个很小的闭环开始这几份材料读下来我反而不太会把它理解成“上来就把整个人生、整个团队知识都喂进去”。更自然的起点可能是先拿一个范围很窄、你最近确实反复在看的主题试一下。比如• 一组正在跟踪的论文和文章• 一个产品方向的竞品资料• 某个持续写了几周的研究主题• 一小批和当前项目强相关的会议记录、截图、网页和笔记如果只想先感受一下这套东西和传统知识库到底差在哪我觉得最小闭环大概够了先准备一个小的raw/目录只放同一主题下的几份资料。写一页很短的AGENTS.md或CLAUDE.md先把目录、页面格式和引用要求说清楚。让 Agent ingest 一份来源看看它会不会更新摘要、索引和相关页面。然后问一个确实需要跨资料综合的问题而不是只问单篇摘要。如果这次回答有保存价值就把它 file back 回 wiki。最后自己回头看一眼链接通不通来源在不在判断是不是写过头了。走完这一圈通常就能比较直观地感觉到两件事• 这套方式到底有没有帮你留下东西• 你愿不愿意继续维护这层中间层如果这两件事都成立再慢慢往更大的范围走节奏可能会稳一点。写在最后如果只用一句话总结这次的LLM Wiki我会更愿意这么说它比传统知识库多出来的是一层会被持续维护、持续回写、也持续被 Agent 消费的 wiki 中间层。这层东西一旦存在原始资料、查询结果、图表、摘要、对比和后续修订就不再只是一次性产物。它们会慢慢变成同一个系统里彼此相连的部分。这大概也是为什么很多人看完之后第一反应不是“我想再做一个笔记软件”而是“这像不像一套给 Agent 用的长期工作底座”。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】