AI非常聪明，但是要把它用好，却不容易！
核心原因在于，我们给的上下文信息不够，使得它并不充分的了解我们。
因为很多信息是在我们的脑子里面的，很难凭空让AI知道，比如：熟悉的业务领域、做过的项目、踩过的坑、经验判断、思维方式、表达方式等。
为了使其更好的完成任务，我们每次和 AI 对话时，都不得不重新交代这些上下文信息，一遍又一遍的复述就很麻烦。
那么这里的解法是，把这些信息维护到个人知识库，让AI在执行任务之前先去读取这部分信息，这样就能让AI更好的掌握充分的上下文信息了。
但是知识库维护起来是很麻烦的，维护成本甚至超过了收益成本，这也导致很多人没法持续坚持下去。
那么维护这个事情是否可以让AI来帮我们做？
因此，这里我们介绍一种针对于懒人的知识库方案，Obsidian + LLM wiki + Agent。
什么是LLM wiki ？
LLM wiki 是karpathy今年4月在Github上公开的一份个人知识库构想文件，大致描述了个人知识库构建方案的架构和理念，但没有说明具体如何实现。
他指出了传统RAG检索的弊端，每次问答都是从海量的知识碎片里面去寻找相似的文档，然后在临时组装生成答案，知识和经验并没有被持续沉淀下来。
而LLM wiki则是提前把知识编译成一个可持续演化的知识结构，一次编译，持续复用。它的核心是在知识整理这个环节去下功夫的，让大模型去做了人不想做的事情。
LLM wiki整体架构分为三层：
- raw层，用于存放采集的原始资料，比如我们收集的文章、论文、图像、数据文件、以及聊天记录等，这些内容是整个知识Wiki的事实来源，是不可变的，LLM只负责读取但是绝不能修改它们。
- wiki层，相当编译层，用于存放由LLM处理后的结构化知识，包含摘要、实体、概念、比较、概述、综合理解等，这一层主要是由LLM维护更新，基于raw层的知识编译而成，人仅负责审核。
- schema层，定义整个知识系统的维护规范，通常定义为CLAUDE.md或者AGENTS.md，它告诉大模型Wiki的结构、约定以及处理资料来源、问题回答或者维护wiki时应该遵循的工作流程。
根据LLM Wiki的理念，一个简陋的主体目录文件结构大致设计如下：
目录文件按职能可以分两类：
一、主流程目录，承载知识从源到产物的状态流
- raw存放原始资料，供下游编译使用。
- wiki就是经过AI编译完成后的结构化页面，按照摘要、实体、概念、比较、概述、综合理解 进行组织。
其中raw和wiki内部的目录结构没有固定标准，可以结合实际的应用场景调整，不一定要遵循这一套规则。
二、支撑目录，服务于编译过程本身
- AGENTS.md就相当于Schema层，是指导 LLM 维护整个知识库的工作原则，文件命名取决于我们用的Agent是什么，如果是Codex则是AGENTS.md，如果是Claude Code 则是CLAUDE.md，如果是Workbuddy，则是.workbuddy/MEMORY.md，遵循Agent的记忆规则定义即可。
- templates用于给AI生成wiki时参照的模板文件，与wiki下面的目录结构一一对应，确保生成的同一种类型文件结构都是一样的，便于维护管理。
- index.md是wiki内容的索引文件，它相当于一本书的目录结构，便于快速找到目标内容，
- log.md、_reports共同提供了可观察性，log记录操作日志，_reports记录健康检查报告。
三个核心操作包括知识编译、知识查询、健康检查，具体的规则均维护在Schema 层中。
以上就是LLM wiki的核心机制，而整个知识的载体是用的Obsidian。karpathy在方案中也做了一个形象的比喻，Obsidian 就像是集成开发环境（IDE），LLM 是程序员，而wiki则是代码库。
为什么要用Obsidian？
然后我们看为啥要用Obsidian这块笔记软件，用Notion、IMA、NotebookLM不行吗？
Obsidian的优势是完全本地化和数据自主，不被平台绑定。它所有的笔记都以Markdown格式保存在电脑本地，而不是保存在厂商的服务器上，完全不用担心数据泄漏、或因平台停止服务而迁移笔记等问题。
并且这种文件形态非常适合 Agent 工作。WorkBuddy / Codex / Claude Code 可以直接读取目录、创建页面、修改链接和维护索引，每次变化都能定位到具体文件，还可以通过 Git 留下记录。
而云端笔记如果要接入本地 Agent 进行管理，通常只能通过官方提供的命令行工具或者 MCP 服务来完成，执行链路更长，耗时更久。
Obsidian另一个重要的优势是，支持用双向链接去关联知识，通过[[笔记标题]]语法，就能在两篇笔记间创建双向链接，形成一个非线性的、发散的网状知识结构，像我们大脑联想的方式。我们在做知识检索的时候，就能通过这些关联链接，查询到相关的知识。
而且 Obsidian 的插件生态非常丰富、并可定制化，进一步提供了扩展空间，从模板、查询、版本管理到发布和可视化，都可以按需添加。
在整套系统中，Obsidian 同时承担存储底座、人机操作界面和知识观察窗口三种角色；
对于一套需要长期使用的个人知识库，本地自主、结构开放、变更可追踪和能力可扩展，Obsidian是非常有优势的。
看一个案例实践
通过上面的介绍，大家应该大致了解了整个知识库的运作原理以及Agent、Obsidian等工具承担的职责。下面通过一个具体的案例来看整个搭建的流程。
这里我们会用到一个开源项目叫claude-obsidian，它是基于LLM wiki架构实现的一整套个人知识库搭建工作流插件，提供了全流程Skill，包括项目初始化、知识摄入、知识查询、知识治理，另外还提供自主研究、知识回写、热查询、本地向量检索方案等。
要注意的是，大家不要被其名称误导，它不仅支持在claude code中使用，还支持在Codex、Pi等Agent中使用。
项目初始化
首先我们打开 Obsidian，点击【创建】，在指定文件夹下创建一个新的仓库，这里命名为llm-wiki-claude-v2，并使用Git版本管理工具初始化仓库，便于后续管理变更。
然后在该仓库路径下启动Claude-Code 或者 Codex会话，并输入/claude-obsidian:wiki指令初始化项目。
在这一步，它会询问我们创建知识库的主要用途是啥？并罗列出了6种模式让我们选择，每一种模式对应的目录结构设计是不同的。
这里我们选择项目研究，最终搭建出来的项目结构如下：
如果选择其它的模式，wiki这一层的目录结构会存在差异，因为它是由标准基础结构+模式特有层组合而成的。
下面是标准的基础结构：
wiki内部的目录结构的设计本质上是对知识的抽离模型的设计，不同应用场景的知识库结构存在很大不同的。
因此直接创建套用karpathy提出的标准化结构，并不一定适合所有场景。
Claude Obsidian这个项目它内置了6种知识库场景，每种模式的具体的目录结构可以看项目源码中的wiki这个skill下的modes文件，这里不做展开。
知识摄入
通过上一步，我们完成了仓库的初始化操作，就可以进行知识的摄入了。
这里我找一篇之前写过的公众号文章《向量检索、知识图谱与 LLM Wiki：RAG 被嘲笑了三年，但企业还是离不开它》，作为知识源，先加入.raw文件夹中，然后进行知识编译。
这里我们可以借助Obsidian Web Clipper浏览器插件快速采集网页端的文章内容，它会把网页主体内容以markdown的格式直接添加到当前打开的Obsidian Valut 中的指定目录中。
知识摄入操作使用如下命令：
/claude-obsidian:wiki-ingest
基于单篇文章最终新建了16个页面，主要抽离了6个核心概念、5个实体对象、并抽离出文章中的重要观点、以及下一步知识补足建议。
结合原文内容以及编译结果，整体质量还是很不错的，实体和概念以及观点都能一一对应。
并且，在Obsidian中可以看到整个wiki知识的图谱关系，如下：
增量编译
知识摄入不是一次完成的，那么在多次摄入时，如何实现增量编译，而不是全量编译呢？
增量编译的功能，其实在摄入命令内部已经实现了。即使我们重复的执行这个编译命令，也不会反复编译知识。只有有新的文件加入时才会真正触发编译逻辑。
因为每次执行摄入命令时都会为参与本次编译的文件生成内容hash值，然后在.raw/.manifest.json 文件中检查是否存在相同 hash；如果命中则跳过该文件编译，未命中则正常处理。
编译完成后，在把本次摄入的源文件hash值记录到.manifest.json中，下次再 摄入时会直接跳过。
问题查询
知识查询操作使用如下命令：
/claude-obsidian:wiki-quey rag有哪些检索技术？
检索结果如下图：
其中红框中的答案是高度符合原文表达的。
如果我们采用RAG的检索策略，先把原始文章进行分块、向量化、入向量库中，然后按照语义和关键词检索知识片段，这样是没有办法达到这种效果的。因为原文中并不直接存在这种可以回答问题的结论，相关的知识是分散在各个段落中的。
而LLM wiki这种方式能够找到，是因为它经过LLM的消化理解，对原文的内容进行了一次编译，生成了一系列的核心结论、实体关系等知识。
比如编译后的wiki中就存在一份可以用于直接回答这个问题的知识。在编译阶段就把所有的检索技术跟RAG检索这个domains建立了关系。
它的检索链路，是先查wiki/index.md这个索引文件，然后在按需查找下一层级相关页面，这里跟Skill的渐进式披露机制类似。
避免把所有的wiki加载到上下文中，导致上下文爆炸。这种机制可以提升检索效率、同时能减少Token的消耗。
Claude Obsidian还做了一个优化措施，每次操作后，无论是写入还是查询，都会把本次关键上下文写入到hot.md文件中，大约500词，注意这里写入是直接覆盖。
后续会话过程中，无论是新开会话还是跨项目使用，都会优先读取hot.md的缓存内容，相比直接读index + N 个页面，单次 query 能省下 70%+ 的 token。
它是通过本地文件把会话关键信息持久化保存，确保上下文在不同会话中能够被衔接，无需我们重复解释，让下一次 query 不必从零开始，从而节省很多的Token消耗。
高价值答案归档
如果这个回答质量高，具有沉淀价值，我们可以把对话内容归档到wiki中去，使用如下命令：
/claude-obsidian:save
结果如下：
这样就把刚刚对话的问题和答案以及参考的wiki页面写入到wiki/questions中去了。
当我下次再问同样的问题时，这里我打开一个新的会话询问问题：
从结果可以看出，它没有重新去wiki里面找相关的页面然后在组织答案，而是直接基于现成答案进行回答的，回答的内容与前面完全一致。
自动研究
知识摄入处理流程是：我们提供资料，Agent帮我们整理。但是实际情况是，我们提供的资料难免会有空缺。
比如前面我只加入了一篇文章，关于RAG知识体系还差很多内容，我想补足Agentic RAG这部分知识到wiki中来，但是又没有高质量的知识摄入，这时候就可以用autoresearch的能力，自动补足缺口知识。
使用方式如下：
它的工作流程是，根据我们输入的Topic，分解成3-5个搜索角度，跑3轮大约45次webSearch。
第一轮，围绕主题从不同角度分别去找资料；第二轮，基于第一轮发现的空白和矛盾，在做针对性搜索；第三轮，如果仍然存在关键缺口，就继续补充，否则就进入整理阶段。
最后把结果沉淀到wiki中。
过程听起来很好，但是实践下来你会发现效果很糟糕，这里我的经验是：
autoresearch仅适合补足空白知识，并且主题范围越小，结果越好。因为它是联网搜索去抓取内容，你主题定得太大，它可能抓回来一堆主题分散的资料，并且这里还要限定抓取的信息源，优先抓官方文档，避开营销软文。
在编写提示词的时候，就需要花些功夫，把研究主题聚焦、研究范围写明确、约束条件写清楚，像上面的示例一样。
健康检查
通过前面可以发现，整个知识摄入过程完全取决于大模型的处理，一开始笔记少的时候，靠人工确认没啥问题，但是知识库页面增长后，人工也审核不过来，问题就会开始出现，比如：孤立页面、死链接、过期结论、缺失页面、交叉引用缺失、元信息缺失、索引漂移等。
这时候就需要定期检查知识是否健康状态，可以执行如下命令进行健康检查：
/claude-obsidian:wiki-lint
这个skill会帮我们完成上面这些维度的检查，检查完成后，它会在wiki/meta下面生成一份检测报告，告诉当前知识库哪里有问题，哪些可以自动修，哪些需要人工判断。
这一步很重要，建议定期检测，比如每周就执行一次健康检查，让知识库wiki保持健康状态。LLM wiki是一个会长期生长的系统，只要持续摄入，就需要持续治理。
数据采集
原始信息是整个知识系统的源头，知识采集这个动作就是知识进入编译的第一步。
这一步主要看我们的搭建知识库的目的是什么，这决定了我们需要采集哪些数据。
如果是用于构建个人第二大脑，那需要采集的数据要求就很多，比如我们每天看过的重要文章、视频、参与过的会议、聊天、通话、文字记录等信息；如果是做专题研究学习，那么仅收集查阅过的优质论文、文章、报告即可。
而收集的这些数据可能存在多个平台上，非常分散，想要把这些信息放入到项目的raw目录中，还是很费劲的，这里我们可以借助IMA和Obsidian Web Clipper用来收集整理数据。
比如，在电脑端浏览器中，看到一篇优质的文章，想把它加入我的知识库项目原始资料中，就可以使用Obsidian Web Clipper插件把网页内容以markdown的格式直接添加到项目的raw目录中。
而在移动端，我的大多数内容来自微信公众号，我想把优质的内容加入项目中，操作路径就相对更长，得先把这篇公众号链接发送到电脑端，然后在电脑端用浏览器打开，在用Obsidian Web Clipper插件收藏到raw中。整个操作流程是断裂的，有时候还会忘记在电脑端进行操作，有价值的文章内容就流失掉了。
这里可以使用IMA知识库作为中转，用来收集移动端的信息，把在微信中看到的各类信息一键收藏到IMA知识库中，这个方法对于微信生态的内容尤其友好。
操作路径：点击分享 -> 用小程序打开 -> 选择IMA，这样内容就自动被解析并保存到IMA知识库中去了。
然后我们还在借助Workbuddy的定时任务，定期从IMA知识库中把新增的有价值的内容同步到Valut 目录中来，自动化任务设置大致如下：
这样我们就能同时收集到电脑端和移动端看到的多数优质内容了。
除了上面提到的两种情况外，内容可能存在其它平台上，比如飞书文档或钉钉文档中，我们可以借助这些平台的CLI工具 + 自动化任务来实现数据的同步，方式方法很多，就不一一列举了。
此外，我们收集数据格式可能存在多样性，有文档、图片、视频、音频、PPT、PDF、聊天记录等，关键是要把这些格式的内容识别为文本，这里可以借助多模态模型进行解析，便于后续模型加工处理。
需要注意的是，原始资料的质量决定了Wiki的质量，这里的核心原则是，只收集高质量的内容，宁缺勿滥，否则我们的知识库就变成了垃圾进垃圾出。
LLM wiki 衍生的问题
人的判断权不能交出去
上面的这套流程执行下来，刚开始的时候体验非常好，感觉一切都很美妙，我们只需要负责筛选、往里面投喂信息，LLM 自动就把知识编译到wiki中去，知识库仿佛拥有了“自动生长”的能力。
但是随着深入使用，问题也开始浮出水面。
全流程中，人做的唯一的事情的就是往知识库中喂信息，其它事情大模型帮我们全干完了，这些知识并没有经过我们大脑的理解、判断、加工，这些知识严格来说就并不属于我们，随着时间的推移，知识库中的知识越累越多，我们对这些知识反而越来越陌生。
并且知识的质量我们是没法保证的。因为LLM并不知道哪些信息重要，哪些结论值得保留，哪些内容应该被丢弃。
回到开头提到的问题，个人知识库太难维护下去了，LLM 能不能帮我维护？
现在 LLM确实 能降低了维护成本，但如果维护过程完全自动化，知识库的质量就别指望有多高。
这里其实存在一个不可能三角关系，要同时做到低成本维护、高质量知识、个人内化，是不太可能的。
因此，关键问题是：LLM 可以帮我维护到什么程度？哪些环节可以自动化，哪些环节必须由人参与？
我认为两个环节人一定要把好关，第一是信息筛选环节，人要判断什么样的知识能流入知识库中；第二是知识编译阶段，需要指导大模型关注重点，并review生成的结果。
其实karpathy自己也有提到，他倾向于单篇知识摄入，并且会全程参与进去，会去阅读LLM生成的摘要，并检查更新的内容，指导LLM关注重点知识。
有价值的知识库，是不太可能自动长出来的，还是需要依靠人和 LLM 在协作中逐步长起来，LLM负责降低知识整理和结构化的时间成本，但是人仍然要参与筛选、判断、提问和内化。
体量变大后的性能瓶颈
这套方案的性能瓶颈在于，知识体量大起来以后，每次的编译成本和查询成本都会变大。
前面讲的查询流程，默认是先查wiki中索引文件 index.md，然后再渐进式加载相关页面。这种方式对于几十到几百个 Wiki 页面的知识库是没啥问题的，但当 wiki 持续变大之后，检索效率就会下降，Token 消耗也会变大。
要持续的维护大体量知识库，需要充足的Token预算。
要解决查询的性能瓶颈，可以集成 qmd 本地检索方案。它的核心流程是：
- 先把 wiki 页面拆分为小的 chunk；
- 给每个 chunk 生成上下文前缀，确保这个 chunk 脱离原文也能被理解；
- 基于这些 chunk 构建 BM25 关键词索引；
- 查询时先用 BM25 召回候选片段，再用向量相似度做语义重排；
- Agent 读取命中的原始页面，再生成最终答案。
可以看到这里其实是使用了RAG检索的策略，也可以看出LLM wiki 和RAG并不是互斥的。
即使有了 LLM Wiki 仍然是需要 RAG的，他们两者定位其实完全不同。
这里可以用编译时 和 运行时来理解。LLM Wiki 是编译时产物，把原始材料预处理成高质量的知识页面；RAG 是运行时手段，在查询时刻做精准召回。
Wiki 在构建阶段就把散落的材料固化为完整的语义单元，每个页面自带元数据、关系使用双链符号记录、层级结构支持渐进式披露。
RAG 的重心是检索链路，它不会帮忙理解并整理这些内容，原来分散的资料依然分散，矛盾的还是矛盾的，过期的还是过期的。
适用的场景
从第一性原理出发，我们创建知识库的最终目的一定是为某个场景服务，是要有用的。
LLM wiki 更适合需要长期积累、反复复用、并且依赖个人判断的知识场景，而不是一次性问答场景。
第一类是专题研究，当我们持续研究 RAG、Agent、AI Coding、行业趋势等主题时，会不断收集文章、论文、报告和实践案例，用 LLM wiki 编译成概念、实体、观点、问题和关系，就能逐步形成自己的研究地图。
第二类是工作经验沉淀。比如产品经理、研发、运营、咨询顾问、投资研究等岗位，日常会产生大量项目文档、会议纪要、复盘记录、方案判断和踩坑经验。这些信息分散在聊天、文档和脑子里，平时很难被复用。通过 wiki 把它们结构化后，后续写方案、做决策、回答问题时，AI 就可以先读取这些背景信息，给出更贴近自己业务语境的结果。
第三类是内容创作。对于长期写公众号、做课程、做视频的人来说，之前写过的文章、表达习惯、常用案例、核心观点都很重要。把这些内容维护成 wiki 后，AI 就能基于你已有的知识体系做延展，减少风格漂移和重复解释。
结语
到这里，我们已经介绍了LLM wiki这套个人知识库构建方案和实践过程，并分享了存在的一些问题和应用场景
最后，还是建议先从一个高频、明确的小场景开始，人参与进去，把它做深、做稳，能真正用起来。
本文由作者@叶小钗，授权发布于平台，未经许可禁止转载。