去年开始用 Obsidian 做知识管理时，我走过一段弯路。
看到好文章就剪藏，读到好论文就写笔记，听到好播客就记要点。三个月后，我的 raw/ 目录里躺了 200 多篇文章。
问题随之而来——
想找半年前读过的某个观点，翻遍笔记也找不到；同样的概念在五篇笔记里都记过，但彼此没有关联；新读到的资料和旧结论矛盾，根本没注意到；每次问 AI 问题，它都要重新读一遍我的资料，之前聊过的理解没有留下来。
这就是典型的 RAG 困境：每次都在重新发现知识，没有积累。
后来看到 Karpathy 在推特上分享了一个想法：
让 LLM 帮你维护一个持久的 Wiki，而不是每次从原始文档中检索。
我照着搭了自己的 LLM Wiki，效果不错——
每添加一篇文章，LLM 自动更新 10-15 个相关页面；随时提问，答案有引用、有对比、有分析；问答内容被保存，成为知识库的一部分。
下面说说具体怎么做。
01 核心架构
系统分三层。
raw 目录，放资料的地方。所有文章、论文、报告都丢在这里。关键是这些文件不可变——LLM 可以读，但永远不会改。
wiki 目录，知识库，LLM 的领地。所有 Markdown 文件都由它生成和维护，包括概念页、主题页、总目录和日志。
CLAUDE.md，系统的”宪法”，告诉 LLM 该如何行为：目录结构、页面规范、如何建立交叉引用等。
没了。Obsidian 和 LLM 只是共享同一个目录，没有复杂的集成。
02 快速开始：5 步搭建你的 Wiki
想试试？几步就行。
第一步，初始化知识库。
打开大模型的聊天窗口（Claude Code 或其他 LLM），粘贴 Karpathy 的 gist 内容，然后加上提示词：
按照上面的内容，帮我搭建一个知识库。LLM 会自动创建 CLAUDE.md、SCHEMA.md 等配置文件，以及基础的目录结构。配置不用你写。
第二步，收集文章。
用 Obsidian Web Clipper 或手动把 5-10 篇文章存到 raw/ 目录。
第三步，编译 Wiki。
在目录中打开 LLM，输入：
读取 raw/ 中的所有文件，编译一个 Wiki。LLM 会阅读所有文档，识别关键概念和主题，创建结构化的 wiki 页面，用 [[wikilinks]] 建立交叉引用，并生成总目录 index.md。
打开 Obsidian 的图谱视图，你会看到一张相互连接的知识网络。
第四步，提问题。
Wiki 建好后，就可以开始提问了：
根据 Wiki，总结一下 RAG 系统的主要挑战。或者
对比一下 Spec-Driven Development 和 Test-Driven Development。LLM 会阅读相关 Wiki 页面，综合答案并附带引用。有价值的问答可以存为 analysis/ 新页面，回填到 Wiki 里。
第五步，检查和维护。
定期让 LLM 做健康检查：
扫描整个 Wiki，找出矛盾、孤立页面、可以合并的重复内容，以及缺失但值得创建的新页面。或者让它推荐新主题：
看看 Wiki 和 raw/ 目录，建议 5 个值得补充的新文章主题。LLM 经常能发现你没注意到的联系和空白。修复方式很简单——让 LLM 直接执行修复：更新页面、添加链接、创建缺失页面。
就这样。Obsidian 负责渲染和查看，LLM 负责生成和维护，两者共享同一个目录。
03 工作流：怎么用
知识库建好后，日常使用就三件事：
摄入——每天或每周把新文章丢进 raw/，让 LLM 读取并整合到 Wiki 中。
查询——随时提问，LLM 基于 Wiki 内容回答，有引用、有对比、有分析。
检查——每周让 LLM 扫描 Wiki，找矛盾、找孤立页面、找缺失的概念，然后让它直接修复。
你负责筛选资料、提问、判断质量，LLM 负责总结、归档、交叉引用、维护一致性。
04 为什么这个模式有效
以前用传统笔记工具，最大的问题是：维护负担增长得比价值快。
每新增一篇笔记就要手动更新索引，每新增一个概念就要手动加交叉引用，发现矛盾？很可能没注意到。资料多了，检索效率直线下降。所以人类会放弃 Wiki——不是不想维护，是真的没时间。
但 LLM 不会厌倦，不会忘记更新交叉引用，可以一次修改 15 个文件，维护成本接近零。
我负责筛选资料、提问、判断质量，LLM 负责总结、归档、交叉引用、维护一致性。Wiki 越用越丰富，而不是越用越乱。
05 进阶技巧
善用 Obsidian 图谱视图。 打开图谱视图，你能直观看到页面之间的连接关系——哪些是枢纽页面、哪些是孤岛。
用 Marp 做幻灯片。 安装 Obsidian 的 Marp 插件，让 LLM 生成 Markdown 幻灯片。
用 Dataview 做动态列表。 如果 LLM 给 Wiki 页面添加了 YAML frontmatter，Dataview 可以运行查询。
关于规模。 Karpathy 说过，他的 Wiki 在约 100 篇文章、40 万词时表现良好，不需要 RAG。关键在于 _index.md——LLM 先读这个总目录，再深入相关文章。规模再大可能需要搜索工具或基于 embedding 的检索。
06 结语
LLM 比我们更擅长维护结构化知识。
它们不会忘记添加反向链接，不会让文章半途而废，能在几秒内阅读 50 篇文章并生成一致的摘要。
你负责判断——哪些源值得添加、问什么问题、保留哪些输出。LLM 负责苦力活——组织、链接、总结、维护。
正如 Karpathy 所说：
你几乎不需要手动编写或编辑 Wiki，那是 LLM 的领域。这里有机会做出一款出色的新产品，而不是一堆蹩脚的脚本。
在那款产品出现之前，Obsidian + Claude Code 已经能帮你实现 90% 的效果——今天就能用，而且可能是你已经有的工具。
这个模式的精神源头，可以追溯到 Vannevar Bush 在 1945 年提出的 Memex 愿景：
一个个人的、精心策划的知识库，文档之间有”联想轨迹”相连。
Bush 的愿景比万维网更接近这个模式：私人的、积极策划的、文档间的连接与文档本身一样有价值。
他没解决的问题是：谁来做维护工作？
现在，LLM 能搞定。
你的知识库，可以开始生长了。
参考链接：