你的收藏夹里面躺着多少篇好文章？三百篇？五百篇？你真正打开重新阅读过的，可能不超过五篇。
我并不是在进行批评，我自己也同样如此，刷到一篇干货文章，顺手收藏了，觉得以后会用到它，但「以后」从来没有到来过。那些文章在收藏夹里面慢慢过期，知识从来没有沉淀下来，仅仅是换了个地方堆放着。
karpathy前段时间发了条推文，说自己的Token消耗从写代码转向了构建个人知识库，一千七百多万阅读量。评论区一堆人都在说「我也是我也是」。这件事戳中了太多人的痛点，知识管理这个场景，远远没有被满足过。
他第二天就在GitHub上面公开了LLM Wiki的构想文件。我读完之后觉得，这个人确实把问题的根源给抓住了。
传统RAG你每次提出问题，模型都是从碎片里面临时拼凑答案，拼完就扔掉。你昨天花了三十秒综合出来的精彩回答，今天要是再问一个相关问题，它就重新检索，重新拼接，重新推理，完全不记得上次做过什么。每次都是从零开始。
karpathy的思路不一样，他说不要让模型每次都从原始文档里面检索，让它维护一个Wiki。你负责收集原始资料往raw目录里面扔，模型读取这些资料，增量维护一个结构化的Wiki，持续更新实体页和主题页，交叉引用和矛盾点也跟着进行更新，综合结论也一并维护。知识不再是一次性的拼接，而是编译成可持续演化的结构，一次编译，持续复用，像滚雪球越滚越大。
增量更新才是精髓所在。新增一份资料进来，Agent先判断它对应哪些已有实体和概念，决定是更新旧页面还是创建新页面。新旧说法不一致的时候不直接覆盖，保留来源、时间和适用范围，给出冲突提示。
整套架构其实就三层，挺简单的。raw层存放你采集的原始资料，文章、论文之类，不可变，模型只读不写。wiki层是编译后的结构化知识，包含摘要、实体页之类的内容，交叉引用也在这里面，模型全权进行维护。schema层就是AGENTS.md，相当于给AI编写的工作手册，定义Wiki的结构、约定和流程。
简单来讲，raw层提供原材料你负责往里面存，wiki层是加工品AI负责编译，schema层是生产规范指导AI怎么加工。
我看到这个构想之后就想动手试试，但Claude Code上手门槛确实有点高，很多人看到命令行就退缩了。我换了个思路，选用AISet来做编译器，门槛降了不少。
实操其实挺快。先运用Obsidian建一个仓库，命名kb-wiki，借助Git初始化方便后续版本管理。然后打开AISet，新建会话，工作空间指向刚在Obsidian里面创建的项目文件夹。这样一来，两个软件的工作空间都指向同一个本地目录，Obsidian当编辑器和可视化视图，AISet当编译器干活，数据不用手动搬，流程是通的。
目录结构按照三层来进行划分，AGENTS.md被放置在项目根目录里面，负责界定AI的角色以及工作规范，index.md则是内容索引方便进行快速定位，log.md用来记录每次操作的时间、内容和变更情况。raw用来存放原始资料，wiki用来存放编译完成后的结构化知识，templates则是用来存放供AI进行wiki生成工作时参考的模板文件。
AGENTS.md这个文件我一开始撰写得比较粗糙，后面边用边改，一直到表现稳定为止。它负责向AISet说明你的角色到底是什么，目录结构应当怎么去维护，素材从哪里读取，怎么进行编译，摘要怎么撰写，链接怎么去创建。这份文件并不是一劳永逸的，需要持续开展维护更新工作直到表现稳定，这一点我是踩了坑之后才发现的，一开始撰写得太理想化了，运行了几轮之后发现AI按照字面意思理解会搞出一些匪夷所思的目录结构，必须根据实际表现反复对措辞进行调整。
数据采集这块取决于你搭建知识库的目的。要是个人第二大脑就得采集每天看过的重要文章，视频和会议记录也得收录进去，聊天内容同理。要是专题研究就仅收录优质论文和报告。
电脑端要是看到优质文章，我就运用Obsidian Web Clipper插件直接把网页内容转换成markdown存放至raw目录里面。移动端大部分内容来自微信公众号，我后来选用IMA知识库充当中转站，微信里看到的好内容一键收藏到IMA，接着依靠AISet的定时任务定期把IMA新增内容同步到raw目录，这样一来自动化就顺畅了，不会因为操作路径断裂导致有价值的内容流失掉。
有一点不能忘，原始资料的质量决定着Wiki的质量，仅收集高质量内容，宁缺勿滥，否则知识库就沦为垃圾进垃圾出了。
我把之前撰写过的关于知识库的文章全放入raw目录，然后打开AISet，向它下达指令，阅读当前项目raw/中新增的文件，依照AGENTS.md的规范编译至wiki/目录中，并且对index.md和log.md进行更新。
AISet就开始阅读这些原始资料，提炼出概念和实体知识，为每个有效来源进行摘要创建，同时在页面之间创建双向链接。你回过头去看生成的那些markdown文件，会发现每页顶上都带有来源标注和关键词标签，页尾有与其他知识点的关联引用，从一个概念出发可以跳至另一个相关概念，不用手动去搜索。这个体验与传统收藏夹完全不同，以前你保存过一篇文章，下次想找相关知识得依靠记忆翻找收藏夹，现在点两下就跳至了，省去了大半翻找的时间。
这些文件彼此之间依靠双向链接进行关联，在Obsidian编辑器里进行查看不够直观，但要是运用关系图谱功能去看就会以知识图谱的形式展示出来，知识点之间的连线像蜘蛛网一样铺展开来，点击一个节点就能跳至另一个，比在编辑器里一个个寻找文件直观多了。
走到这一步，知识的摄取工作就算是搞定了，接下来的查询环节就挺简单了，直接向AISet抛出问题就行，它会凭借wiki里面沉淀下来的知识内容给出综合性的解答。
比方说我去提问，让它根据Wiki来解释一下LLM wiki的工作原理究竟是什么，并且说说它跟传统的RAG到底有啥区别，AISet就会先从index.md里面去判断究竟哪几个页面跟这个问题是相关的，接着逐页去阅读内容，把分散在不同页面里的那些信息给综合起来交给你，这个过程跟从目录里面找到对应章节是比较类似的，检索的效率得到了大幅度的提高。
要是回答具备价值，还可以把结论给写回到wiki当中，让知识越攒越厚实，这也就是所谓的知识复利效应，你每次进行查询的时候，其实都是在往知识库里面添加一层新的理解。
至于知识治理，则是让AISet定期去检查一遍，看看整个知识库里面有没有存在矛盾的地方，有没有孤立的页面，链接有没有断掉的情况，借此来保证知识库不会因为资料越来越多就变得越来越乱。我自己亲自跑了两轮治理之后发现，有些页面之间确实存在着说法不一致的情况，AISet会给出冲突提示，你来决定怎么进行处理就行，这个环节不能完全交给AI自己去闭环跑，必须得有人参与到审核当中来。
不过我得说实话，LLM Wiki这套理念其实更适合个人的知识管理工作，要是放到企业场景里面去，就有几个比较明显的局限了。
头一个就是数据规模的问题，当wiki文档膨胀到成百上千个的时候，每次新增知识进行编译或者开展查询的Token消耗就会显著地上升，index.md的索引内容都有可能把上下文窗口给撑爆，成本和性能方面的压力不小。
其次则是权限管理的问题，企业级知识库通常需要细粒度的访问控制，谁能看什么内容、谁能改什么内容都得管起来，LLM Wiki目前针对这块的支持还不够完善，在多人协作的场景下比较容易出乱子。
再有就是引用溯源方面的隐患了，企业场景对于来源追溯的要求是很高的，尤其是医疗法律这类严肃的场景，RAG可以明确地告诉你答案是基于哪个文档的哪一段内容，而LLM Wiki生成的内容从根本上来说是依赖于模型对原始知识的理解与重构的，可能会出现幻觉，存在着生成错误知识关联的风险，偏差一旦被写入Wiki，就可能误导后续的所有查询结果，所以企业要是运用的话，必须得有个审核机制，不能让AI自己闭环跑完就直接入库。
我的建议是先从一个小主题开始搞起，比方说就二十篇文章左右的量，把从采集到编译再到查询以及治理的整个流程给跑通，接着再根据实际使用当中碰到的问题去逐步调整AGENTS.md的措辞，而不是一上来就去追求一个大而全的知识库。
