知识管理这个概念比计算机还早。1945 年Vannevar Bush 在《Atlantic Monthly》上发了篇文章叫《As We May Think》提出了一个叫 Memex 的概念——一台可以装载所有书籍和记录并能把各种材料串连起来的机器。这大概就是个人知识库的最初概念。Bush 说知识与知识之间的连接有时比知识本身都重要。问题是谁来维护这些连接呢时间过去了这么久工具换了一个又一个——Notion、Obsidian、Roam Research、Logseq。始终没有解决一个问题维护成本永远高于知识价值。直到到了 2020 年 RAG 技术迸发一度被当做解药。RAG的思路是不要让人去维护知识库让AI每次直接去原始文档里搜索答案。上传文件-问问题-AI 帮你找。RAG 让LLM 能够查询到训练数据以外的信息避免了幻觉。但是它有一个根本的问题——知识不累积。对于一个查询AI 都要重新从原始文档中检索、重新拼接出一个答案。你上传了 50 篇文章它来回在里面搜索你问了个需要综合 5 篇才能回答的问题RAG 有可能只找到 2-3 篇有用段落并给出一个片段答案。更重要的是当你以后再问相似问题的时候它还要重新拼一遍永远不会学习到下次会更好。RAG 让你的 LLM 当了搜索引擎。每次问问题它都在重新翻课本。一个不整理笔记每次考试都重新翻书的学生。ICLR 2026 有一篇论文印证了这个问题现有的 memory agent包括 RAG 系统在增量信息处理方面表现不足它们擅长在静态文档里找答案但不擅长随着时间推移累积理解。Karpathy 几天前发了一条引爆讨论的推文给出了一个不同的思路别让 LLM 当搜索引擎了让它当编译器。Karpathy 把他的方案整理成了一个 Gist 发在 GitHub 上叫 LLM Wiki。直接把这个 Gist 复制给你的 AI agentagent 就能帮你搭一套出来。Karpathy 说 RAG 的工作方式是你上传一批文件LLM 在查询时检索相关片段生成答案。这个方式有一个核心问题——知识没有被累积。每次问一个需要综合多篇文档的微妙问题LLM 都要重新找、重新拼。而 LLM Wiki 的方式是LLM 持续构建和维护一个持久化的 wiki——一组结构化的、互相链接的 markdown 文件夹在你和原始素材之间。新素材进来LLM 读取、提取关键信息整合进已有的 wiki——更新实体页、修订主题摘要、标注新旧矛盾。Obsidian 是 IDELLM 是程序员wiki 是代码库。你负责 sourcing找素材、exploration探索方向和 asking the right questions问对问题LLM 负责摘要、交叉引用、归档、维护。LLM Wiki 可以应用的场景个人成长追踪目标、健康、心理学把日记、文章、播客笔记整合成对自己越来越清晰的认知画像深度研究花几周甚至几个月钻研一个话题读论文、报告、文章逐步构建一个带演化论点的综合 wiki读书逐章入库LLM 自动维护人物页、主题线、情节线索。团队/企业用 LLM 维护内部 wiki喂养源是会议纪要、项目文档、客户通话记录等。**竞品分析、尽职调查、旅行规划、课程笔记、爱好深挖**任何需要长期积累知识的场景都适用。LLM WIKI基本原理拆解Karpathy 的设计很简洁三层架构。最底层是 Raw Sources你的原始素材——论文、文章、笔记、数据文件。硬规则不可变。LLM 只读不写这是你的数据源真相。中间层是 WikiLLM 全权负责的区域。摘要、实体页、概念分析、交叉引用全在这里。你可以读但不需要自己写。Karpathy 强调 wiki 就是一个 git repo天然有版本历史、分支、协作能力。最上层是 Schema整个系统的灵魂。一个配置文件告诉 LLM 你的知识库结构规范、写作约定、处理工作流。如果你用 Claude Code这个文件叫CLAUDE.md如果你用 OpenAI Codex叫AGENTS.md。Karpathy 强调这个文件是你和 LLM 共同演进的——随着你搞清楚什么结构适合你的领域不断调整。这三层的关系Schema 定规则Raw 提供原材料Wiki 是成品。你只负责素材和问问题。Ingest编译也可以理解为素材入库是最核心的操作。你丢一篇新文章进来LLM 不是存起来等以后搜索而是认真读完更新 wiki 中所有相关页面——实体页、摘要、交叉引用。一篇新素材可能会更新 10-15 个 wiki 页面。Karpathy建议一次给一篇素材保持参与感。你读 LLM 生成的摘要检查更新引导它该强调什么。当然你也可以批量导入、减少监督看你的风格。关键是把工作流摸索清楚然后写进 Schema 让未来的会话复用。Query查询跟 RAG 类似但有两个关键区别。第一LLM 先读 index.md 找到相关页面再钻进去读细节——不是在原始文档里暴力检索。第二好的查询结果可以回流到 wiki 中成为新页面。Karpathy 说查询的答案可以是多种形式markdown 页面、对比表、slide deck用 Marp、chart用 matplotlib、canvas。不管形式是什么有价值的内容不应该消失在聊天记录里。Lint检查容易被忽略但极其重要。定期让 LLM 做健康检查页面之间有没有矛盾有没有新数据推翻了旧结论有没有孤立页面没有入链有没有被多次提到但没有独立页面的概念数据缺口能不能通过 web search 补上Karpathy 说 LLM 在这个环节特别擅长建议新的研究方向和新的素材来源纯人工维护 wiki 时这是最难的。index.md是整个 wiki 的目录每个页面一行摘要加链接按类别组织。在约 100 篇素材、数百个 wiki 页面的规模下index.md 加上 LLM 的上下文窗口就够用了不需要 embedding 向量数据库。log.md是变更日志记录每次操作发生了什么。Karpathy 建议用统一前缀格式比如## [2026-04-02] ingest | Article Title这样一条 grep 命令就能快速检索历史grep ^## \[ log.md | tail -5拿到最后 5 条记录。实战搭建你的 LLM Wiki如果你想动手试试有两条路径路径 A从零搭建Karpathy 原版方案。用 Obsidian Claude Code从 Karpathy 的 Gist 复制模板自己调教 Schema。适合想深入理解原理、完全定制化的人。Nick Spisak 做了一条 7 分钟的实操视频教程从建目录到跑第一个 Ingest 全程演示还介绍了用 CLI 工具自动抓取网页到知识库的技巧推荐配合着看。路径 B直接用 Farza 的 skill。FarzaTV 把 Karpathy 的 idea file 落地成了一个完整的 Claude Code skill开源在 GitHub 上。他把自己全部 2500 篇日志、备忘录、iMessage 聊天记录都导入系统自动生成了 417 篇结构化的个人维基文档。他将这套知识库取名为Farzapedia可在farza.com/knowledgehttps://farza.com/knowledge查看实时演示。如果你不想从零学习数据架构模板直接套用法尔扎Farza的这套思路是最快上手的方式。下面先按路径 A 讲完整流程路径 B 的用户可以参考 Farza 的设计要点。第一步建目录结构在 Obsidian 中创建一个新 vaultplaintextmy-wiki/ ├── raw/ # 原始素材不可变 │ └── assets/ # 图片等附件 ├── wiki/ # LLM 生成的知识页面 ├── index.md # 内容目录 ├── log.md # 变更日志 └── CLAUDE.md # Schema 配置wiki使用 Git 对其进行版本管控每次大模型完成内容入库摄取后都提交更新记录随时可按需回退版本。如果你用 Farza 的 skill目录结构更丰富——他按类型分类了 people/、projects/、places/、philosophies/、patterns/、tensions/、decisions/、eras/ 等几十个类别每类都有明确的什么内容放这里的定义和文章结构模板。初期建议用简单结构等积累多了再参考 Farza 的分类体系重构。第二步写 Schema这是最重要的一步。CLAUDE.md 告诉 Claude Code 你的知识库怎么运作。你可以直接从 Karpathy 的 Gist 里复制他的模板来改核心内容包括wiki 的目录结构和页面命名规则摘要的写作格式和长度要求交叉引用的约定怎么链接、什么时候该建新页面Ingest / Query / Lint 的具体工作流你对 LLM 输出风格的偏好这个文件是你和 LLM共同演进的随着你摸索出什么结构适合你的领域持续更新它。Farza 在这个基础上更进一步。他的 skill 里定义了两条核心原则anti-cramming不要把所有内容塞进少数大页面和anti-thinning创建了页面就要持续丰富它不要留空壳。他还要求 LLM 当writer而不是filing clerk——不是盲目归档信息而是先解读内容含义再将其整理撰写成维基条目。写作风格上他要求内容采用维基百科式文风中立客观避免堆砌形容词每篇文章最多包含2 条直接引语让事实本身说话。这些规范写进 Schema 后LLM 会自动遵守。第三步素材入库网页文章是最常见的素材来源。推荐用Obsidian Web Clipper浏览器插件一键把网页转成 markdown 存入 raw/ 目录。比手动复制粘贴干净得多。Nick Spisak 的教程里提到还可以用 CLI 工具自动抓取网页到知识库适合批量采集场景。如果你用 Farza 的 skill支持的数据格式和来源非常多Day One 日记、Apple Notes、Obsidian vault、Notion 导出、iMessage、CSV、邮件、Twitter/X 存档甚至能自动检测未知格式并写解析器。图片处理有个坑值得注意。剪藏下来的文章图片通常还是外链过几个月链接一挂文章就残了LLM 读不了挂掉的图片链接。方案是把附件统一存到raw/assets/目录。但实操下来按文件夹存附件是更好的选择。在 Obsidian Settings - 文件与链接 - 附件存储路径选当前文件夹下指定的子文件夹子文件夹名称设为attachments。这样每篇文章的图片都在自己的attachments/里文章多了也不会混成一团。配好之后给Download attachments for current file绑一个快捷键比如 CtrlShiftD。Settings - Hotkeys 里搜Download就能找到。剪藏完文章后按一下所有图片就下载到本地了。LLM 不能直接读 markdown 里的内嵌图片但它可以先读文字再单独查看图片获取额外上下文有点麻烦但能用。PDF 论文可以直接扔进 raw/ 目录。Claude Code 能读 PDF就是 token 消耗大一些。第四步跑第一个 Ingest把素材放到 raw/ 目录下然后在 Claude Code 里执行“请阅读 raw/ 目录下的新文章按照 CLAUDE.md 的规范进行 Ingest讨论关键要点写摘要页更新相关实体页和概念页更新 index.md追加 log.md。如果你用 Farza 的 skill命令更简单/wiki ingest导入数据/wiki absorb编译成 wiki。/wiki cleanup审计清理/wiki breakdown发现缺失页面/wiki status统计状态等命令。skill会每处理 15 条数据做一次自动 checkpoint检查新增页面数、重写流水账页面、拆分过长页面等。第一轮跑完用 Obsidian 打开输出检查质量。重点检查摘要是不是抓准要点了还是流水账交叉引用是不是有道理是不是有没建页面的实体或概念有问题再调整 CLAUDE.md 中的规范重新跑一遍。前期多花点时间调教 Schema后续会越来越省心。第五步日常使用日常主要是Ingest 和 Query。往 raw/ 里扔素材让 LLM Ingest对着 wiki 提问让 LLM Query。随着素材增多你会发现回答质量在持续提升——这就是知识复利。定期跑一次 Lint。Karpathy 说 LLM 做健康检查时往往会给你惊喜它会建议你没想过的研究方向和素材来源。Obsidian 的图谱视图Graph View是监控 wiki 健康状况的利器。一眼就能看出哪些页面是枢纽大量连接、哪些是孤岛零连接。如果你给 wiki 页面加了 YAML frontmatter标签、日期、来源数量还可以用Dataview插件生成动态表格和列表。可选进阶搜索工具当你 wiki 规模超过百篇素材后index.md 可能不够用了。Karpathy 提到了qmd——一个本地 markdown 搜索引擎支持 BM25 向量混合搜索加 LLM 重排序完全在本地运行。它有 CLILLM 可以直接调用和 MCP serverLLM 可以当原生工具用。注意 qmd 不是从 Obsidian 插件里装的需要单独安装。当然你也可以让 LLM 帮你写一个简单的搜索脚本按需来就行。实战中容易踩的坑Schema 太抽象LLM 输出质量不稳定。Karpathy 在 Gist 里特意说了他的文档故意保持了一点抽象和模糊因为有太多方向可以走。但实际搭建时Schema 越具体LLM 的输出质量越高。建议在 Schema 里写清楚摘要多少字、用什么语气、交叉引用的触发条件是什么、什么情况下该建新页面。Ingest 质量一次不好别急。第一篇素材 Ingest 完之后检查输出调整 Schema再跑一遍。Karpathy 认为你和 LLM 是共同进化的将你踩过的坑和调参经验写进 Schema 之后再使用会越来越顺。**不着急一篇一篇导入。**虽然批量导入在一开始节省时间但很容易出问题而你还不太熟悉 Schema导入出错很难 debug这样很难反馈到 Schema 上调整。等你调教好 Schema 后也不迟批量导入。wiki 页面加了 YAML frontmatter 会更好用。给每个 wiki 页面加上 tags、date、source_count 等元数据配合 Obsidian 的 Dataview 插件可以生成动态表格和列表大幅提升浏览效率。这个可以让 LLM 在 Ingest 时自动加。不过也有实战用户反馈 Dataview 在这个场景下实用性一般如果你不熟悉 Dataview 的查询语法前期可以先跳过把精力放在 Schema 调教上。Git 自动 commit 保平安。建议配置 Obsidian 的 Git 插件每 10 分钟自动 commit。LLM 批量修改文件时万一改乱了随时可以回滚。这是 AI 操作文件系统的必要保障。关于实际效果的诚实评价。AI 少年aehyok按照 Karpathy 的方法完整搭建了自己的 LLM Wiki他总结里说“最终个人知识库的效果怎么样还待进一步的使用确定我个人知识库的关联度确实很低。但最起码从搭建的过程中还是学到了不少东西。”LLM Wiki 解决的是维护成本的问题但不解决知识有没有用的问题。素材质量、你投入的思考深度、以及你是否有明确的探索方向这些才是知识库价值的根本。工具再好喂进去的如果是垃圾产出的也只是结构化的垃圾。写在最后知识管理的下一个范式回头看这段历史有一条清晰的演进线从 Bush 的 Memex1945到 Engelbart 的 Augment1968再到 Notion、Obsidian 这些现代工具人类一直在尝试解决同一个问题——怎么让知识积累而不是散落。解决方案一直在变但瓶颈始终是同一个维护成本。RAG 试图绕过维护这个问题结果是连积累本身也绕过了。LLM Wiki 的思路不同它保留了积累把维护交给了 LLM。Karpathy 在 Gist 末尾引用了 Bush 的话来收尾我觉得这段话放到现在依然精准Bush 的愿景比后来的互联网更接近这个方向——私密的、主动策划的、文档之间的连接和文档本身一样有价值。Bush 当年解决不了的部分是谁来做维护。LLM 现在能做了。Reddit 的 r/RAG 社区最近在讨论我们真的需要 embedding 吗——有人提出让 LLM 先把原始文档编译成结构化 wiki然后在编译后的高质量文章上做 embedding 作为 fallback效果可能比在原始 chunk 上做 embedding 好得多。这意味着知识编译和知识检索未必是替代关系未来很可能是互补关系。还有一个更大胆的观点值得提一下。LM Market Cap 的分析文章指出了一个经常被忽视的事实在个人规模的知识库下编译后的 wiki 不超过 1-2M tokens整个 wiki 可以直接塞进现代 LLM 的上下文窗口。这意味着查询时根本不需要任何检索——直接把整个 wiki 当上下文传给 LLM得到完美的召回率。RAG 的优势在于处理海量数据但在个人知识库这个场景下编译 全量上下文可能是更简单、更准确的方案。当然随着你的知识库增长迟早会超过上下文窗口的上限这时候再引入检索也不迟。学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%免费】