核心来源Andrej Karpathy 原始 Gist2026-04-04后续实践FarzapediaFarza2500 条日记 → 400 篇 Wiki整理时间2026 年 6 月关键词LLM Wiki、Karpathy、知识库、RAG 替代、Obsidian、Agent 记忆引言为什么这件事值得你花时间2026 年 4 月 4 日Andrej KarpathyOpenAI 联合创始人、特斯拉前 AI 总监在 X 上发了一条推文介绍了他正在实践的LLM Wiki工作流——让 LLM 把绝大多数 token 消耗用于构建一个可演化的个人知识库。这条推文在 X 上获得了1700 万 浏览量。12 小时内他整理出的idea file概念文件在 GitHub Gist 上获得了2100 stars。一周之内GitHub 上出现了7 个以上的开源实现。为什么这么火因为它解决了一个真实痛点过去两年我们一直在用 RAG检索增强生成来做知识库但 RAG 有一个根本性问题——每次查询都在重新发现知识没有积累There’s no accumulation。LLM Wiki 提出了一个截然不同的思路让 LLM 持续编译和维护一个结构化的维基百科而不是在每次查询时从原始文档中实时检索。这篇文章将完整拆解 LLM Wiki 的技术架构、实现细节、与 RAG 的本质区别以及真实世界的落地案例。一、什么是 LLM Wiki1.1 核心思想一句话版LLM Wiki 让 LLM 充当全职知识库管理员持续编译、检查和链接 Markdown 维基式文档。1.2 与 RAG 的本质区别大多数人与 LLM 文档交互的方式是RAG 模式用户提问 → 上传文档 → LLM 检索相关片段 → 生成回答这个流程每次都在从零开始重新发现知识。如果你问一个需要综合 5 篇文档的微妙问题LLM 每次都要重新找到并拼凑相关片段。没有任何积累。LLM Wiki 的模式完全不同原始文档 → LLM 编译 → 结构化 WikiMarkdown 文件集合 ↓ 用户提问 → LLM 读取 Wiki → 生成回答Wiki 已预编译好关键区别维度RAGLLM Wiki知识处理时机查询时实时检索摄入时预编译跨文档综合每次重新拼凑已预综合在 Wiki 中矛盾检测无自动标记新旧数据矛盾人类可读性原始文档结构化 Markdown人类可直接阅读积累性无每次重新检索有Wiki 持续生长适合规模大规模文档百万级中等规模~100 篇文档40 万字Karpathy 的原话“这个方法在约 100 篇文章、40 万字规模下的效率显著优于传统 RAG且完全人类可读、可审计基本摆脱了供应商锁定。”1.3 谁在维护 WikiLLM 负责写和维护人类负责思考和引导。你几乎不直接手写 Wiki 内容LLM 负责总结、创建反向链接、归纳概念、创建页面、彼此链接你负责提供原始资料、引导分析方向、提出好问题Karpathy 把这套系统的角色分配比喻为Obsidian IDE前端查看器 LLM 程序员全职维护 Wiki Wiki 代码库持续演进的工件二、架构设计三层结构LLM Wiki 的架构极其朴素但每个设计决策都有深意。┌─────────────────────────────────────────────┐ │ Schema模式层 │ │ 告诉 LLM Wiki 的结构约定和工作流 │ │ (CLAUDE.md / AGENTS.md) │ └─────────────────────────────────────────────┘ ↕ 指导 ┌─────────────────────────────────────────────┐ │ The WikiWiki 层 │ │ LLM 生成的 Markdown 文件集合 │ │ 摘要 / 实体页面 / 概念页面 / 综述 │ └─────────────────────────────────────────────┘ ↕ 读取不修改 ┌─────────────────────────────────────────────┐ │ Raw Sources原始源层 │ │ 文章 / 论文 / 代码仓库 / 数据集 / 图片 │ │ 不可变LLM 只读不写 │ └─────────────────────────────────────────────┘2.1 第一层Raw Sources原始源内容你收集的所有原始素材——论文、技术博客、代码仓库、数据集、图片等多模态内容位置raw/目录关键原则不可变Immutable。LLM 从这里读取但永远不修改它们。这是你的真相来源Source of Truth无结构设计这一步没有任何结构核心目标只有一个——最大化原始信息的完整性2.2 第二层The WikiWiki 层内容LLM 生成的 Markdown 文件集合类似一个由 AI 自动撰写和维护的维基百科LLM 全权负责创建页面、更新页面新源到达时、维护交叉引用、保持一致性你负责读取在 Obsidian 里查看原始数据、编译好的 Wiki、以及衍生的可视化内容Wiki 中的典型页面类型页面类型内容示例摘要页单篇文档的总结summary_quantum_computing_basics.md实体页人物/组织/产品等实体entity_andrej_karpathy.md概念页技术概念的深度解析concept_react_planning.md综述页跨文档的综合分析synthesis_llm_agent_architectures.md比较页多个事物的对比comparison_langgraph_vs_crewai.md2.3 第三层Schema模式层形式一个 Markdown 文件Karpathy 用CLAUDE.mdCodex 用AGENTS.md作用告诉 LLMWiki 是如何组织的、约定是什么、摄入源/回答问题/维护 Wiki 的工作流分别是什么这是让 LLM 成为有纪律的 Wiki 维护者而非通用聊天机器人的关键配置文件协同演进你和 LLM 一起演进这个文件——随着你弄清楚什么对你的领域有效不断更新它三、核心操作流程LLM Wiki 有三个核心操作Ingest摄入、Query查询、Lint检查。3.1 Ingest摄入从原始源到 Wiki这是 LLM Wiki 最关键的操作——把新源编译进 Wiki。典型流程以单篇文档为例1. 你把新源拖入 raw/ 目录 2. 告诉 LLM 处理它 3. LLM 读取源文档 4. LLM 与你讨论关键要点可选Karpathy 建议参与 5. LLM 在 Wiki 中写入摘要页面 6. LLM 更新 index.md索引 7. LLM 更新相关的实体页面和概念页面 一篇源文档可能触及 10-15 个 Wiki 页面 8. LLM 向 log.md 追加一条记录Karpathy 的实践建议逐篇摄入 保持参与他倾向于一次摄入一篇源保持参与——阅读摘要、检查更新、引导 LLM 强调什么也可以批量摄入如果你信任 LLM也可以一次批量摄入多篇文章减少监督工作流程由你开发把适合你风格的工作流程记录在 Schema 文件中供未来会话使用3.2 Query查询问 Wiki 问题1. 你向 LLM 提问 2. LLM 先读 index.md 找到相关页面 3. LLM 钻取drill into相关页面 4. LLM 综合答案并附引用答案可以有不同的形式取决于问题输出形式工具适用场景Markdown 文件直接写入 Wiki深度分析报告比较表格Markdown 表格多方案对比幻灯片MarpObsidian 插件演示汇报图表matplotlib数据可视化重要洞察好的答案可以存回 Wiki 作为新页面。你要求的比较、分析、发现的联系——这些都有价值不应该消失在聊天历史中。这样你的探索就和摄入的源一样在知识库中持续积累。3.3 Lint检查保持健康随着 Wiki 增长需要定期体检你请给 Wiki 做一次健康检查 LLM 会查找 ✗ 页面之间的矛盾A 页说 XB 页说非 X ✗ 过时的结论新源已推翻旧说法 ✗ 孤立页面没有入链没人能找到 ✗ 被提到但没有独立页面的概念知识缺口 ✗ 缺失的交叉引用相关页面没有互链 ✗ 可以通过网络搜索填补的数据缺口 LLM 还擅长 ✓ 建议接下来应该研究什么问题 ✓ 建议应该寻找什么新源这保证了 Wiki 在增长过程中保持健康、一致、无孤立知识。四、两个特殊文件index.md 和 log.md这两个文件帮助 LLM和你在 Wiki 增长时导航。它们服务于不同目的。4.1 index.md内容索引定位内容导向的目录内容Wiki 中每个页面的链接 一句话摘要 可选元数据日期、源计数组织方式按类别组织实体、概念、源等更新时机LLM 在每次摄入时更新它查询时使用回答问题时LLM先读 index.md找到相关页面然后钻取它们为什么在中等规模下不需要 RAGKarpathy 的报告“在他的规模下约 100 篇文章、40 万词更复杂的 RAG 基础设施并不是严格必要的。LLM 会持续更新索引文件维护文档的简短摘要它能相当不错地读取并关联重要的相关材料。”换句话说index.md 就是一个手工维护的、比向量检索更可靠的索引。在 ~100 篇文档的规模下这已经足够好。4.2 log.md操作日志定位时间顺序的记录内容发生了什么、什么时候——摄入、查询、检查操作的追加式记录格式技巧如果每个条目以一致的前缀开头例如## [2026-04-02] ingest | Article Title日志可以用简单的 Unix 工具解析——grep ^## [ log.md | tail -5给出最近 5 个条目作用给你 Wiki 演进的时间线帮助 LLM 理解最近完成了什么五、工具生态LLM Wiki 的工具栈极其朴素但每个工具都有明确分工。5.1 核心工具工具角色关键功能ObsidianWiki 的前端 IDE查看 Markdown、图谱视图、Marp 幻灯片、Dataview 查询LLM Agent全职 Wiki 维护者Claude Code / OpenAI Codex / OpenCode / Pi 等Git版本控制Wiki 就是 Git 仓库——自动获得版本历史、分支、协作5.2 Obsidian 插件生态插件功能使用场景Obsidian Web Clipper把网页文章转换为 Markdown快速把源文档弄进 raw/ 集合MarpMarkdown 幻灯片格式从 Wiki 内容直接生成演示文稿Dataview对页面 frontmatter 运行查询如果 LLM 给 Wiki 页面添加 YAML frontmatter标签、日期、源计数Dataview 可以生成动态表格和列表Graph View内置可视化 Wiki 图谱看 Wiki 的形状——什么连什么哪些页面是枢纽哪些是孤立页面5.3 可选搜索工具当 Wiki 增长到 index.md 不够用时可以加搜索工具。qmd推荐本地 Markdown 文件搜索引擎混合 BM25 / 向量搜索 LLM 重排序全部在设备上运行隐私友好既有 CLILLM 可以 shell 调用它又有 MCP ServerLLM 可以把它当作原生工具也可以自己写LLM 可以帮你 vibe-code 一个朴素的搜索脚本按需构建。5.4 图片处理技巧Obsidian 设置技巧Karpathy 推荐设置 → Files and links → Attachment folder path 设为固定目录例如 raw/assets/ 设置 → Hotkeys → 搜索 Download → 找到 Download attachments for current file → 绑定快捷键例如 CtrlShiftD剪辑文章后按快捷键所有图片下载到本地磁盘。这让 LLM 可以直接查看和引用图片而不是依赖可能失效的 URL。注意LLM 不能一次性原生读取带内联图片的 Markdown——解决方法是让 LLM 先读文本然后单独查看部分或所有引用的图片以获得额外上下文。有点笨拙但足够好用。六、真实案例Farzapedia理论听起来好但真实世界有人用起来了吗有。而且效果很惊艳。6.1 Farza 的实践Karpathy 发推两天后开发者Farza就用这套思路做了一个东西——Farzapedia。他把以下内容交给 LLM “编译”2500 条日记 Apple Notes 笔记 部分 iMessage 对话 ↓ LLM 编译 400 篇结构化 Markdown 文章 涵盖朋友、创业项目、研究方向、 甚至最喜欢的动漫及其个人影响 全部带反向链接6.2 Farzapedia 的关键设计Farza 说了一句非常关键的话“这个 Wiki不是给我看的是给我的 Agent 看的。”Wiki 的文件结构和反向链接对任何 Agent 来说都非常容易爬取。他可以在 Wiki 上启动 Claude CodeAgent 从index.md出发就能精准定位到需要的页面。而基于文件系统的知识库Agent 天然就能理解反而好用得多。6.3 实际使用案例Farza 举了一个例子设计新产品的落地页时他问 Agent“去看看最近启发我的图片和电影给我一些文案和视觉方向的建议。”Agent 从 Wiki 里翻出了他关于吉卜力纪录片的笔记他截图过的 YC 公司落地页他几年前保存的 1970 年代 Beatles 周边设计然后给出了一个融合这些灵感的方案。这件事情的妙处在于Agent 主动跨多个概念页面综合出了人类可能忽略的联系。七、Karpathy 四原则Karpathy 看到 Farzapedia 之后专门发了一条推文列出了这种方式做 AI 个性化的四个原则。这四个原则其实才是整件事最值得拆开讲的部分。原则一Explicit显性化你的 AI 记住了什么在 ChatGPT、Claude 的记忆功能里这件事是黑箱——你不知道它记了什么不知道它漏掉了什么不知道哪天它会把两段记忆搞混。LLM Wiki 不一样。知识全在 Markdown 文件里打开就能看。哪条信息准确、哪条需要修正、哪条根本没被收录一目了然。原则二Yours属于你数据在你自己的电脑上。不在 OpenAI 的服务器里不在 Anthropic 的数据库里。你换 AI 供应商知识库跟着你走。你删掉某段记忆它就真的消失了不会留在某个你够不到的地方。原则三File over App文件优先于应用这个概念来自 Obsidian 创始人 Steph Ango 的一篇文章。知识存成Markdown 和图片——两种最通用的格式。这意味着你可以用 Obsidian 看 你可以用 VS Code 编辑 你可以用 grep 搜索 你可以写脚本批量处理 你可以让任何 agent 直接读取 不被任何一个 App 锁死。原则四BYOAI自带 AI你可以用 Claude、用 GPT、用 Codex、用开源模型都行。因为知识库是标准 Markdown 文件任何能读 Markdown 的 AI 都能用。没有供应商锁定。八、为什么 LLM Wiki 现在才火你可能会问这个思路听起来不复杂为什么是现在8.1 关键使能条件条件2024 年前2026 年现在LLM 上下文窗口4K-32K tokens不够读大量文档128K-2M tokens可以一次读几十个 Wiki 页面LLM 代码/工具能力弱难以自动化维护 Wiki强Claude Code / Codex 可以自主维护文件系统Agent 框架成熟度早期不稳定LangGraph / CrewAI 等让 Agent 持久化任务可行人们对 RAG 的失望RAG 是唯一选择越来越多人发现 RAG 在中等规模下不够好8.2 Agent 时代的范式转变Karpathy 在推文中提到一个观点“在 LLM Agent 时代分享具体代码或应用的意义正在变弱。现在只需要分享想法然后把它交给 Claude、Grok 等 Agent它就可以根据你的需求自动搭建一个属于你自己的个人知识库。”这意味着 LLM Wiki 不只是一个 AI 工具而更像是一种元框架meta-framework。它不依赖某个具体模型或技术栈而是在尝试定义一种人类与 AI 协作管理知识的方式。随着模型不断迭代、框架持续演进让 LLM 帮助编译并维护一个持续生长的 Wiki这一模式反而具备更长期的稳定性和适用性。九、适用场景LLM Wiki 可以应用于很多不同的上下文。Karpathy 列了一些例子9.1 个人场景个人成长追踪追踪自己的目标、健康、心理、自我提升——归档日记条目、文章、播客笔记随着时间推移建立关于自己的结构化画像读书笔记每读一章归档一章为人物、主题、情节线索建立页面并连接。读完时你拥有一个丰富的伴侣 Wiki类似《魔戒》粉丝维基 Tolkien Gateway——数千个互链页面由志愿者社区多年构建。你可以在阅读时个人构建类似的东西LLM 做所有的交叉引用和维护9.2 专业场景研究在几周或几个月内深入研究一个主题——阅读论文、文章、报告逐步建立一个有演进论点的综合 Wiki商业/团队由 LLM 维护的内部 Wiki由 Slack 线程、会议记录、项目文档、客户电话提供信息。可能有人类在回路中审查更新。Wiki 保持最新因为 LLM 做了团队中没人想做的维护工作竞争分析、尽职调查、旅行规划、课程笔记、爱好深挖——任何你随着时间推移积累知识并希望它有组织而不是分散的地方十、LLM Wiki 的局限性诚实评估LLM Wiki 并不是万能的。10.1 规模限制Wiki 规模推荐检索方式原因 100 篇文档index.md 人工维护LLM 可以直接读取并理解 index100-500 篇index.md 简单搜索qmdindex 开始不够用需要轻量搜索500-2000 篇向量搜索qmd 的向量模式需要语义检索2000 篇传统 RAG 基础设施Wiki 模式可能不够需要混合方案关键点LLM Wiki 和 RAG 不是互斥的。大规模下可以用LLM Wiki结构化知识 RAG大规模检索的混合方案。10.2 维护质量依赖 LLM 能力Wiki 的质量上限取决于 LLM 的能力上限。如果 LLM 犯总结错误、遗漏关键联系、错误链接Wiki 的质量会退化。缓解方法人类在回路Human-in-the-loopKarpathy 建议逐篇摄入时保持参与定期 Lint主动检查 Wiki 健康用更好的模型Claude Opus / GPT-5 的总结质量显著优于小模型10.3 冷启动成本建立一个有用的 Wiki 需要摄入相当数量的源文档Karpathy 的例子是 ~100 篇。在开始阶段Wiki 的查询质量可能不如直接用量化索引的 RAG。但一旦跨过冷启动门槛Wiki 的积累效应会显著优于 RAG。十一、快速上手从零开始建你的 LLM Wiki如果你被说服了想试试这是一个最小可行路径步骤 1建立目录结构mkdir-p~/llm-wiki/raw# 原始源文档mkdir-p~/llm-wiki/raw/assets# 原始源中的图片mkdir-p~/llm-wiki/wiki# Wiki 主目录touch~/llm-wiki/wiki/index.md# 内容索引touch~/llm-wiki/wiki/log.md# 操作日志touch~/llm-wiki/CLAUDE.md# Schema给 Claude Code 的指令步骤 2写 Schema 文件在CLAUDE.md中告诉 LLM Wiki 的结构约定。以下是一个最小模板# LLM Wiki Schema ## 目录结构 - raw/ : 原始源文档不可变 - wiki/ : Wiki 页面LLM 维护 - wiki/index.md : 内容索引 - wiki/log.md : 操作日志 ## 摄入工作流 1. 读取 raw/ 中的新源 2. 生成 Wiki 页面摘要、实体、概念 3. 更新 index.md 4. 追加 log.md ## Wiki 页面格式 每个页面应包含 - YAML frontmattertitle、tags、date、source_count - 正文Markdown 格式 - 反向链接部分## Backlinks步骤 3摄入第一批文档1. 把 3-5 篇你想读的论文/文章放进 raw/ 2. 启动 Claude Code / Codex 3. 把 CLAUDE.md 的内容告诉它 4. 说请处理 raw/ 中的第一篇文档 5. 参与讨论检查输出 6. 重复直到所有文档处理完毕步骤 4用 Obsidian 查看1. 安装 Obsidian 2. 打开 ~/llm-wiki/ 作为 Vault 3. 查看 wiki/ 目录中的页面 4. 打开 Graph View 看图谱形状步骤 5提问并观察问 Wiki 一个问题观察 LLM 是否 ✓ 正确找到了相关页面 ✓ 综合了多个页面的信息 ✓ 给出了带引用的答案十二、与 RAG 的混合方案LLM Wiki 并不是要完全取代 RAG。在生产环境中两者可以互补用户提问 │ ├─→ 先查 Wiki精确、综合好、人类可读 │ ├─→ 再查向量数据库大规模、语义检索 │ └─→ 合并结果 → 生成回答建议策略知识类型推荐方案原因精心阅读过的文档LLM Wiki已预综合质量高大量未精细阅读的文档RAG覆盖面广需要跨文档综合的分析LLM Wiki综合已预编译在 Wiki 中简单事实检索RAG速度快不需要综合十三、2026 年的趋势判断基于 Karpathy 的原创工作和后续社区反应以下是几个值得关注的趋势13.1 “编译式知识库将挑战检索式知识库”过去两年RAG 是 LLM 知识库的标准答案。2026 年我们预计会看到更多编译式LLM Wiki 风格方案出现尤其是在中等规模100-1000 篇文档场景下。13.2 开源实现将涌现Karpathy 的 Gist 发布仅一周GitHub 上就出现了 7 个以上的开源实现。我们预计专门的 LLM Wiki 管理工具类似 Hugo/Hexo 但专为 LLM 维护设计Obsidian 插件的专门化LLM Wiki 专用插件MCP Server 的标准化让任何 Agent 都能读写 Wiki13.3 文件优先哲学将获得更多认可File over App不是一个新概念但 LLM Wiki 给了它一个新的、强有力的论据。我们预计会看到更多基于标准文件格式Markdown、JSON、CSV的 AI 工具而不是封闭的数据库。13.4 Agent 个性化将不再依赖黑箱记忆Farzapedia 展示了一条路Agent 的记忆可以是一个显式的、人类可读的、可审计的Wiki。这意味着你可以检查和修正 Agent 的记忆你可以把记忆迁移到不同的 Agent你可以让多个 Agent 共享同一个 Wiki十四、结语这件事的更大意义LLM Wiki 在技术上的创新其实不大——它没有引入新的算法、新的模型架构、新的训练方法。它的创新在于工作流的重新设计把 LLM 从查询时实时检索者变成持续编译和维护者。这听起来像一个微小的改变但它从根本上改变了知识库的积累性——从每次重新发现变成持续生长和演进。Karpathy 在他的 Gist 最后引用了 Vannevar Bush 1945 年的 Memex 概念——一个个人的、精心管理的知识存储文档之间有联想路径。Bush 的愿景更接近 LLM Wiki 而不是今天的 Web——私人、主动管理、文档之间的连接和文档本身一样有价值。Bush 无法解决的谁来做维护问题LLM 处理了。这就是 LLM Wiki 的更大意义它可能是实现 Memex 愿景的最接近的方案——70 多年前设想的思维扩展器在今天由 LLM 担任全职图书管理员而成为可能。参考资源资源链接类型Karpathy 原始 Gistgithub.com/karpathy/…/llm-wiki权威来源FarzapediaX: FarzaTV真实案例qmd 搜索工具github.com/tobi/qmd工具Obsidianobsidian.md前端 IDEAndrej Karpathy 推文x.com/karpathy/status/…原始推文