前段时间，大神 Andrej Karpathy 发了个两条推特，分享他是怎么做 LLM 知识库的。
他的核心思路其实很简单：
与其每次让 AI 去原始资料里翻答案，不如让 AI 帮你把知识编译成一个持续维护的 wiki。
这话听起来挺对。
但我自己试了试，又跟几个朋友聊完，发现一个问题——
LLM wiki 对学习研究场景是神器，但在内容创作场景和企业知识库场景则不一定。
今天就是和大家聊聊这事儿。
01 学习/研究场景：可以直接用
如果你是在学习、研究某个领域，Karpathy 这套方案几乎可以原样复制。因为这就是大神自己最开始的应用场景。
这套方案本身并不复杂，三层结构：Raw 层、Wiki 层，以及 Schema 层。
硬讲这三层概念太过干巴，我直接从头跑个案例给大家看更直观。
中间用到两个工具：Obsidian、Claude Code。这里默认大家都已经安装 Claude Code 并且会使用（也可以用你们常用的其它 AI 编程工具，如 Codex、Cursor、Qoder、Trae 等）。
打开 Obsidian，点击【创建】，在指定文件夹下创建一个新的仓库。
这就是你接下来的知识库大本营了，虽然现在还空空如也。没关系，继续下一步
用 Claude Code 中打开刚才在 Obsidian 创建的文件夹，然后把 Karpathy 的 llm-wiki.md 链接丢给 Claude Code。
参考这份LLM-wiki指南,在当前项目创建相应知识库结构，目前知识库还没有raw 资料，后续补充:https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
注：对新手来说，最方便的方法是用 IDE 打开然后运行 Claude Code
接着 Claude Code 就会根据 LLM-wiki 创建相应的知识库结构，首次创建的目录包括：raw、wiki、schema ，当然它们现在都还是空的。
比如我最近要研究 harness engineering，就可以将自己找到的博客、论文等资料，都以 mardown 的格式丢到 raw 这个文件夹下。
保存资料有个更方便的方法，就是用官方配套的 Obisidian Web Clipper，支持将你看到的好的文章、论文以及 YouTube 视频文稿，一键剪存到 Obisidian 中。
🔗：https://github.com/obsidianmd/obsidian-clipper
不过目前 Obisidian Web Clipper 不支持 B 站视频的剪存，我原本在官方项目中提了 PR 合并，不过没通过，Obsidian CEO 驳回的原因是：Obisidian Web Clipper 只处理从 Defuddle 处理后的内容。
后来我就想着在 Defuddle 项目上提交 PR，但由于没法在本地验证自己的 PR 是否成功，所以最后没提交，而是基于 Obisidian Web Clipper 做了个中文内容增强的插件，大家有需要可以直接使用。
🔗：https://github.com/nextcaicai/obsidian-clipper-cn
接着告诉 Claude Code 摄入 raw 文件夹新添加的资料。
摄入 raw 文件夹新添加的文章
AI 就会根据这些原始资料，自动生成系列 Markdown 文件，所有文件都放 wiki 这个文件夹下。
文件的内容可能某个概念、人物、产品、专题、摘要、索引、操作历史等等，其中有三个很重要的文件，包括：
index.md：内容目录，它会按类别组织，每篇 wiki 单行摘要，方便你快速浏览。
log.md：时间线记录，什么时候读了什么、更新了哪些页面。
schema（一般是 CLAUDE.md 或 AgentS.md）：就是规则文档，告诉 AI 怎么组织 wiki、怎么命名文件、怎么交叉引用等，后续你可以做自定义调整。
所有文件并不是散乱的，彼此之间会用链接关联起来。
这种关联在 IDE 中可能不够直观，
但在 Obsidian 中，是这么一张知识图谱，你随时可以查看不同知识点、不同资料之间的关联。
以上就是从 0 到 1 搭建 LLM-wiki ，并且完成初步内容摄取的全过程。
但你以为 LLM-wiki 这就到头了，还没有。完整的 LLM-wiki 工作流还包括后续的 Query（查询）和 Lint（整理）
Query 就是你有问题可以直接问 AI，AI 会去读相关页面，进行综合回答。回答得好，还可以把结论写回 wiki，也就是你的知识是越攒越厚的。
Lint 则是定期让 AI 检查一遍，看整个知识库有没有矛盾、有没有孤立页面、链接有没有断，保证你的知识库不会因为资料越多就越乱。
这就是 LLM-wiki 的完整工作流：从摄入到查询再到整理。
这套方案之所以对学习研究这么好用，是因为它可以 持续积累、反复查阅、强调关联。
你今天读一篇论文，下周读另一篇，两个月后突然发现——这两篇讲的是一个东西的不同侧面。
如果没有 wiki，你得靠记忆去翻。有了 wiki，LLM 会自动帮你把关联标出来。
而且 wiki 维护成本低，一次整理，长期受益。
这套方案还可以用在书籍阅读、个人目标追踪等方面，大家感兴趣的话我在下期分享。
02 内容创作场景：根据个人知识库调整
虽然 LLM-wiki 在学习研究场景特别好使，但如果你是做内容创作的，直接照搬 Karpathy 的方案可能会出问题。
问题出在哪？
你的知识库结构可能不一样。
Karpathy 的 wiki 是从 raw 到 wiki，核心是把外部信息进行结构化关联。
但内容创作者的知识库通常不是这个逻辑。比如我自己的知识库是经典的 IPO 结构：Input（输入）→ Processing（加工）→ Output（输出）。
Input：我看的书、文章、视频、新闻
Processing：我的想法、笔记、草稿
Output：我发布的碎片想法、文章、书籍、视频、专栏
如果我想让 AI 更好地理解我的思想和风格，应该喂给它的不是 Input，而是 Output。
为什么？因为 Input 是别人的东西，Output 才是我的东西。AI 要学的是“我怎么想”，不是“我看了什么”。
所以内容输出的场景下，我的 wiki 核心应该是基于 Output 的历史内容，而不是基于 Input 的原始资料。
当然，Input 也可以用 LLM-wiki 的方法去学习和消化，最后经过 Processing 再变成我自己的 Output。
这就是学习场景和内容场景的根本区别：
学习场景：重点是把外部知识内化，wiki 是终点。
创作场景：重点是把个人思考外化，wiki 只是中间站。
创作场景还要注意一个点，就是它可能会自动生成一些“看起来对但实际上和你的观点有所偏差”的内容。所以在 wiki 每次的生成和更新环节，我们还是要做个把关，确保它代表的是“你”的知识，不是“AI 猜的你”。
03 企业知识库：LLM wiki 可能不适用
最后，简单聊聊企业场景。
LLM wiki 爆火后，有不少关于 RAG 已死的论调，还有人认为它可以替代 RAG 做企业知识库。
我的观点是：小团队可以，大组织还不行。
虽然 wiki 听起来比 RAG 简单多了，不用搞向量数据库，不用做嵌入，每次新增还能自己更新。
但简单有简单的代价。
首先是它目前支持的规模上限很明显。Karpathy 自己的 wiki 是 100 篇文章、40 万字，这已经是个不小的体量了。当 wiki 膨胀到几百上千个文档时，index.md 可能就会超出上下文窗口，你还是得压缩、分片、或者引入检索——这就变成 RAG-over-wiki 了，不再是纯粹的 LLM wiki。
其次是权限管理，企业级 RAG 结合向量数据库通常有更成熟的 RBAC（基于角色的权限访问控制）方案，但 LLM-wiki 没有这东西，所以目前更多只能用在小团队或大组织的小部门中。
还有一个致命问题：引用精确性。
企业场景对来源追溯要求很高。RAG 可以告诉用户“这个结论来自第几页第几段”，但完全由 LLM 维护的 wiki 可能会幻觉出一个概念之间的错误关联。当这个错误写进 wiki，就会影响后续所有查询。
写在最后
Karpathy 的 LLM wiki 确实是个好东西，但得分场景。
学习研究场景，直接照搬，非常好用。
内容输出场景，借鉴结构，人工把关。
企业知识库，小规模可用，大规模还是得用 RAG。
说到底，没有最好的工具，只有最适合你场景的工具。
