抛开karpathy自带流量因素之外从另外一个角度也说明在构建AI知识库这个场景还远没有被满足有很多的人都受困于知识管理。次日karpathy就在Github上面公开了LLM wiki 的构想文件详细的阐述了这套知识库构建方案的架构和理念。到目前为止网上也有很多关于这套理念的实践比如使用Obsidian Claudidan LLM wiki来构建第二大脑但是Claude Code对于很多同学来说上手门槛确实有点高本篇文章我们把门槛降低一点使用WorkBuddy LLM wiki Obsidian来做实践。首先我们先大致先了解下LLM wiki 是个啥东西。他的核心观点是传统的RAG系统和NotebookLM/ChatGPT文件上传功能大部分都是先上传资料查询时召回相关知识片段然后临时综合性回答。但问题是每次问问题模型都是在重新从碎片里临时拼答案知识并没有被持续沉淀下来。karpathy 提出的LLM wiki 则是我们负责收集原始资料大模型读取这些资料然后增量维护一个结构化的Wiki不断的更新实体页、主题页、交叉引用、矛盾点和综合结论。也就是说他不再是查询时临时拼答案而是提前把知识编译成一个可持续演化的知识结构。相当于一次编译持续复用知识像滚雪球一样越滚越大。另外LLM Wiki 并不是一次性把所有资料重新总结一遍而是做增量更新编译新的知识时Agent 会先判断它对应哪些已有实体、概念和主题再决定是更新旧页面还是创建新页面如果新旧资料的说法不一致也不会直接覆盖而是同时保留来源、时间和适用范围并给出冲突提示。他的整体架构分为三个层级Raw层用于存放采集的原始资料比如我们看到的文章、论文、图像、数据文件、以及聊天记录等这些内容是不可变的LLM只负责读取但是不会修改它们这些内容是整个知识体系的事实来源。Wiki层相当编译层用于存放由LLM处理后的结构化知识包含摘要、实体页面、概念页面、比较、概述、综合理解等这一层主要是由LLM维护更新。Schema层这一层相当于是Claude Code 的CLAUDE.md或者Codex的AGENTS.md它告诉大模型Wiki的结构、约定以及处理资料来源、问题回答或者维护wiki时应该遵循的工作流程。简单来说raw层提供原始材料我们负责往里面存放wiki层是加工品由AI负责把原材料编译成结构化的知识schema层是生产规范指导AI怎么加工。以上就是关于LLM wiki的核心理念大家有一个简单的认知下面我们继续看如何实践。依赖工具实践过程中我们需要使用Workbuddy、Obsidian、Obsidian Web Clipper这些工具其中Workbuddy、Obsidian到对应的官网下载安装即可Obsidian Web Clipper是一款浏览器插件需要到Chrome扩展商店下载主要用于把网页内容提取为Markdown格式并保存到Obsidian Vault中。初始化工程首先我们打开 Obsidian点击【创建】在指定文件夹下创建一个新的仓库这里命名为kb-wiki并使用Git版本管理工具初始化仓库便于后续管理版本记录。然后打开WorkBuddy新建一个会话工作空间选择刚刚在Obsidian中创建的项目文件夹。这样Obsidian、WorkBuddy这两个软件的工作空间都指向了同一个本地目录只不过现在文件夹还是空的我们继续往下。整体架构根据前面的LLM Wiki的原则我们在Obsidian中把目录文件层级设置为如下结构其中AGENTS.md就相当于Schema层是指导WorkBuddy维护wiki的工作原则index.md是wiki内容的索引文件便于快速找到目标内容log.md是用于记录每次操作的记录比如什么时间写入了什么知识、新增了哪些内容等raw存放原始资料里面的目录结构可以自定义根据自己的实际需求进行分类wiki就是经过AI编译后结构化知识templates用于给AI生成wiki时参考的模板文件与wiki下面的目录结构一一对应。整体的目录结构和职责划分还是很简单清晰的我们在看整体的工作流程是怎么样的其中workbuddy的职责就是承担编译器负责对原始资料进行加工当然也可以用Claude Code、Codex等Agent工具而Obsidian更多的承担编辑器和UI视图的职责提供双向链接的功能并以可视化的方式呈现知识之间的关系还提供其它查询类的操作。可以看出整体流程中最为关键是数据怎么采集、知识怎么加工、用什么模型加工、如何被查询、怎么保持加工的质量能够稳定持续。下面我们围绕这些方面进一步展开。编写Wiki Schema前面说过Wiki Schema层相当于就是定义AGENTS.md文件指导Agent如何工作。可以说这是整个Wiki系统的灵魂它负责告诉Workbuddy的角色是啥、目录结构怎么维护、从哪里读取素材、素材怎么编译、摘要怎么写、链接怎么创建等等。下面是一份部分示例把上面的内容编写到项目的根目录AGENTS.md中这个文件的内容并不是一劳永逸或者一蹴而就的需要我们持续的维护更新直到表现稳定。数据采集前面我们已经把项目的目录结构和AGENTS.md定义清楚后项目的主体结构就搭建完成接下来就可以开始采集数据了。这一步主要看我们的搭建知识库的目的是什么这决定了我们需要采集哪些数据。如果是用于构建个人第二大脑那需要采集的数据要求就很多比如我们每天看过的重要文章、视频、参与过的会议、聊天、通话、文字记录等信息如果是做专题研究学习那么仅收集查阅过的优质论文、文章、报告即可。而收集的这些数据可能存在多个平台上非常分散想要把这些信息放入到项目的raw目录中还是很费劲的这里我们可以借助IMA和Obsidian Web Clipper用来收集整理数据。比如在电脑端浏览器中我看到一篇优质的文章我想把它加入我的知识库项目原始资料中就可以使用Obsidian Web Clipper插件把网页内容以markdown的格式直接添加到项目的raw目录中。而在移动端我的大多数内容来自微信公众号我想把优质的内容加入项目中操作路径相对更长得先把这篇公众号链接发送到电脑端然后在电脑端用浏览器打开在用Obsidian Web Clipper插件收藏到raw中。整个操作流程是断裂的有时候还会忘记在电脑端进行操作有价值的文章内容就流失掉了。这里我们可以使用IMA知识库作为中转站用来收集移动端的内容把在微信中看到的各类信息一键收藏到IMA知识库中这个方法对于微信生态的内容尤其友好。然后我们还要借助Workbuddy的定时任务定期的从IMA知识库中把新增的内容同步到项目raw目录中来自动化任务设置大致如下这样我们就能同时收集到电脑端和移动端看到的多数优质内容了。除了上面提到的两种情况外内容可能存在其它平台上比如飞书文档或钉钉文档中我们可以借助这些平台的CLI工具 Workbuddy自动化任务来实现数据的同步方式方法很多就不一一列举了。此外我们收集数据格式可能存在多样性有文档、图片、视频、音频、PPT、PDF、聊天记录等关键是要把这些格式的内容识别为文本这里可以借助多模态模型进行解析便于后续模型加工处理。需要注意的是原始资料的质量决定了Wiki的质量这里的核心原则是只收集高质量的内容宁缺勿滥否则我们的知识库就变成了垃圾进垃圾出。这里我通过Obsidian Web Clipper插件把之前写过的所有关于知识库和RAG的微信公众号文章都放入到项目的原始资料中来。编译知识原始资料采集完成后我们就可以开始让WorkBuddy编译知识了。打开WorkBuddy把工作空间指向kb-wiki这个目录在会话中告诉它阅读当前项目raw/中新增的文件按照项目根目录中的AGENTS.md的规范将它们编译到wiki/目录中并同时更新index.md和log.md文件WorkBuddy 就会阅读这些原始资料提炼出概念和实体知识并为每个有效来源创建摘要信息并在每个页面之间创建[[wikilinks]]双向链接这里生成的一系列的Markdown 文件都会放到 wiki 这个文件夹下。此外还会更新知识wiki的索引文件index.md以及把本次知识写入日志更新到log.md中。生成的这些文件并不是散乱的彼此之间会用双向链接关联起来我们在编辑器中查看不够直观但是在Obsidian中使用关系图谱功能查看就会以下图这样的知识图谱形式展示我们可以看到不同知识点、不同资料之间的关联点击某个知识点还可以直接跳转到对应知识文件去。到这一步就完成了知识的摄取接下来我们看如何查询知识。查询知识查询这里就非常简单了直接向WorkBuddy提问即可它会根据wiki中沉淀下来的知识进行综合回答。比如我问根据 Wiki解释一下LLM wiki的工作原理是什么它与传统的RAG有啥区别下面是回答截图可以看到索引文件index.md在查询时就派上用场了WorkBuddy在查询时会先读这个索引文件判断哪些页面跟当前问题相关然后在进一步读取这与我们从目录结构找到对应的章节知识是类似的做法可以大幅提高检索的效率。这里Wiki 页面的渐进式展开和 Skills 的渐进式披露的机制也非常一致。当然这里生效的前提是我们要在AGENTS.md中定义查询的工作流程让Agent先查index.md然后在加载wiki中的相关知识。另外对于有价值的回答还可以把结论写回wiki让知识越攒越厚。治理知识知识治理则是让Workbuddy定期检查一遍看整个知识库wiki有没有矛盾、有没有孤立页面链接有没有断保证知识库不会因为资料越多就越乱。这里可以通过Workbuddy的定时任务来实现自动化健康检查比如每周检查一次定时任务设置如下知识健康检查指令大致如下在企业场景中LLM wiki的局限在LLM wiki概念出现之后又有一大批自媒体在自嗨宣称RAG已死认为LLM wiki可以完全替代RAG做企业知识库成为企业知识库的新架构。但从我目前的感受来看LLM wiki这套理念还是更适合构建个人知识管理的需求放在企业场景中还是不太适合。首先数据规模的限制是一道门槛当wiki文档数量膨胀到成百上千个时每次新增知识编译或者查询时Token的消耗会显著上升甚至Index.md的索引内容可能就会撑爆上下文窗口存在高昂的成本和性能压力。其次就是权限管理企业级的知识库通常需要权限访问控制而LLM Wiki目前对细粒度的访问控制支持还不完善难以满足企业级安全合规要求。另外知识引用的可溯源性也存在隐患企业场景对来源追溯要求很高尤其是医疗、法律等严肃场景RAG方案可以明确这个回答是基于哪个文档中的那一段内容而LLM Wiki生成的内容本质上依赖于模型对原始知识的理解与重构是极有可能出现幻觉的存在生成错误知识关联的风险。一旦这类偏差被写入Wiki就可能会误导后续所有查询结果。因此LLM 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%免费】