积累的悖论

笔记越多，知识应该越多。但实际上，笔记越多，乱子也越多。

当你的 Vault 有 50 篇笔记时，你完全可以手动维护。你知道每篇笔记里有什么。你一边写一边打 [[链接]]。结构清晰整洁，因为都是近期建立的。

当你的 Vault 达到 500 篇笔记时，你就不再记得自己拥有什么了。半年前写的笔记里，有你后来重新发现再重新写过的想法。链接指向的是已经被重命名或重构的笔记。有些笔记一个链接和标签都没有——它们存在于 Vault 中，却不存在于你的心智模型里。跟不存在没什么两样。

这就是积累的悖论：你收集的知识越庞大，反而越难以触及。 维护连接所花费的精力，增长速度远远超过笔记本身的价值。到某个临界点，维护的摩擦超过了记笔记的收益。

大多数人解决这个问题的方式是抛弃旧笔记，重新开始。这个循环每 6 到 12 个月重复一次。你丢掉了一切写过的内容。

手动 Wiki 维护的三大负担

负担一：页面创建。 你提到的每一个概念、人物或项目，都值得拥有自己的页面。但决定什么值得建页面本身就是工作。“Transformer 架构”该单独建一篇笔记吗？那”注意力机制”呢——同一页还是分开？每一个决定都消耗脑力。几百篇笔记下来，这些脑力消耗就是一笔巨款。大多数人选择跳过这个决定，让连接慢慢腐烂。

负担二：写链接。 链接到你已知的内容时，写 [[wiki-links]] 很容易。但当你不知道某个概念存在时，根本无法链接它。你没办法链接到你已遗忘的东西。而且即使你知道，你还得手动输入链接、确认目标页面存在、确保链接文本有描述性。这是机械劳动。它不会让你的思考变得更好。

负担三：保持更新。 去年写的一篇笔记提到”GPT-4”是最前沿。今天已经是 GPT-5.5 了。这篇笔记错了吗？过时了？结合上下文还有用吗？你不重新读一遍就不知道。而重新读 500 篇笔记来检查准确性，没人会做这种事。过时信息就这样悄悄积累。

LLM Wiki 如何自动化这三件事

LLM Wiki 通过把架构工作交给 LLM 来解决这三个负担，同时把内容控制权留给你。

自动化页面创建。 你正常地在 sources/ 文件夹里写笔记。运行”Ingest Sources”命令时，LLM Wiki 读取每个来源，识别其中的实体和概念，为每一个创建专属页面。由 LLM 来判断什么值得建页面——不是你。它能够准确提取人物、理论、项目和技术术语，因为它理解文本的含义。

自动化链接编写。 它创建的每个页面都会获得指向相关页面的 [[双向链接]]。这些链接在语义上是准确的——它们基于含义来连接笔记，而非关键词匹配。当你打开一个新的 Wiki 页面时，反向链接区会显示所有引用它的来源。本来需要你花几小时手动建立的连接，几秒钟就完成了。

自动化更新。 重新对新来源执行提取时，LLM 会根据需要更新已有的 Wiki 页面。它添加新连接、标记来源间的矛盾、保持索引最新。如果一个新来源提到”GPT-5.5”，而你现有的”大语言模型”Wiki 页面还在引用”GPT-4”，LLM 会添加一条更新说明或调和这个差异。你不再需要重读旧笔记来维护准确性，也不必担心信息过时。重新提取的过程会搞定这一切。

一分钟演示

以下是使用 LLM Wiki 的典型日常：

你找到一篇关于检索增强生成的有趣文章。把要点复制到 sources/ 里的一个新笔记。花 2–3 分钟。
按 Cmd+P，输入”Ingest Sources”，回车。
等 15 秒。插件把你的来源发送给已配置的 LLM，它会提取实体、创建页面、建立链接。
打开 wiki/ 文件夹。现在你有了”检索增强生成”、“密集段落检索”和”混合搜索”三个页面——它们之间相互链接，并与已有 Wiki 中引用类似概念的所有页面相连。
打开 Graph View。三个新节点出现在你现有的知识图谱中，已经和其他节点连接好了。

从来源到结构化 Wiki，只需 15 秒。 这就是核心循环：写，提取，探索。写，提取，探索。

LLM Wiki 如何融入 Obsidian

LLM Wiki 不取代 Obsidian，而是扩展它。

同样的文件格式。 Wiki 页面是 wiki/ 文件夹里的纯 Markdown 文件。你可以手动编辑、改名或删除。它们不会被锁在数据库里。
同样的链接系统。 Wiki 页面使用同样的 [[维基链接]] 系统。它们和你的手动笔记一起出现在 Graph View 中。
同样的插件市场。 LLM Wiki 是一个社区插件。它与 Dataview、Templater、Kanban 以及你使用的其他插件和平共存。
你始终掌控。 如果 LLM 创建了你不需要的页面，删掉就行。如果链接错了，改掉就行。AI 辅助，你来决策。

LLM Wiki 需要什么

使用 LLM Wiki，你需要一个提供 API 访问的 LLM 服务商。插件将来源文本发送给服务商，服务商处理后返回结构化的 Wiki 内容。

支持的服务商：

DeepSeek — 性价比最优。推荐日常提取使用。DeepSeek V4-Flash 每百万 tokens 仅 $0.14。
OpenAI — GPT-5 系列。质量好，成本较高。在查询操作中需要最高精度时很有用。
Anthropic（Claude） — 查询和复杂推理表现出色。Claude Sonnet 4.6 在查询场景下达到了质量和成本的良好平衡。
Gemini — 输出速度快。Gemini-3.5-Flash 的输出速度大约是 GPT-5.5 的 4 倍，适合批量提取。
Ollama — 在本地运行模型。数据不会离开你的电脑。上下文窗口较小（8K–128K），因此 Ollama 最适合查询而非提取。

你可以为提取和查询配置不同的服务商。典型配置：用 DeepSeek 或 Gemini 做高性价比的提取，用 Claude 做高质量的查询回答。

思维转变

使用 LLM Wiki 需要对记笔记的思维方式做一个小小的调整。

使用 LLM Wiki 之前： “我来写，我来链接，我来整理。结构是我的责任。”

使用 LLM Wiki 之后： “我来写，AI 来整理，我来查询。”

你仍然要写好原始素材。AI 仍然需要高质量的输入——垃圾进垃圾出这个道理还是成立的。但页面创建、链接维护、索引更新这些机械工作，从你的肩膀上移到了 LLM 身上。

这让你能专注于真正重要的事情：思考、写作和探索连接——而不是维护基础设施。你会写得更多，因为整理的摩擦消失了。那些本来会停留在你脑中的碎片化笔记，变成了结构化的知识，因为从原始想法到 Wiki 页面的路径，不过是一条命令加十五秒钟。

下一步

你已经理解了手动维护为什么会在规模扩大时崩溃，LLM Wiki 如何自动化三大负担，以及你可以使用哪些服务商。

下一篇：从这里开始（三）：认识 Karpathy LLM Wiki —— 完整的安装、配置和首次提取指南。

在 GitHub 上查看

从这里开始（二）：为什么你的笔记需要 LLM Wiki