你的 LLM 正在疯狂消耗 Token：Karpathy 找到了一种节省 90% 的方法

这篇文章讨论的是一种受 Andrej Karpathy 启发的知识库构建方式：Wiki Layer，也可以理解为 “LLM Wiki”。

大语言模型的一个核心低效点，是它们经常需要反复上传、读取和处理同一批原始文件。每一次提问，模型都可能重新消耗大量 token 去读 PDF、网页、文本、截图或其他资料；不同文件之间的上下文关系也容易丢失，重要连接可能被遗漏，最终答案质量也会下降。

Wiki Layer 的思路很直接：让 LLM 只对原始资料做一次清洗、结构化和链接。完成后，模型不再直接处理混乱的原始文件，而是围绕一个干净、有结构、相互连接的知识库工作。

这样做的结果是：重复查询时可以大幅节省 token，答案质量和相关性更高，文档之间自动建立连接，还能形成可视化知识图谱。随着时间推移，这个知识库也可以持续增长和更新。

Wiki Layer 的结构

整个系统围绕三个核心部分搭建。

第一部分是 raw/：这里保存所有不可变的源文件，包括 HTML 页面、PDF、文本笔记、截图、表格，以及其他原始资料。这个文件夹不手动编辑，它是整个系统的事实来源。

第二部分是 wiki/：这是主要知识库。里面是由 LLM 生成和维护的干净 Markdown 文件。后续模型主要与这一层互动，而不是反复读取原始资料。

第三部分是指令和模板：这些文件定义系统规则，包括如何清洗数据、使用哪些模板、怎样创建内部链接、添加哪些元数据，以及知识库未来如何更新。

第一步，建立项目文件夹，并把已有资料放入 raw/ 子文件夹。

第二步，启动结构化代理。在 Claude 或其他支持文件和代码能力的强模型中，提供专门的系统提示词。这个代理负责清理技术噪音、广告和不必要格式，把内容转成可读 Markdown，套用预设模板，创建 [[Page_Name]] 这种内部 wiki 链接，并添加元数据和文档关系。

第三步，把项目文件夹作为 Obsidian 知识库打开。这样你立刻能获得可视化知识图谱、全文搜索，以及在相关笔记之间快速跳转的能力。

第四步，使用完成后的知识库。之后你不用每次都上传几十个文件，只需要告诉模型：在 wiki/ 文件夹里的 Wiki 数据库中工作。模型就可以从一个清洗过、结构化、互相连接的知识系统里检索信息。

它首先提升 token 效率：模型不必每次提问都重新读取原始文件。

它也提高准确性：信息已经被清理、组织，并且建立了连接，模型更容易找到相关内容。

它更容易扩展：知识库可以增长到数百甚至数千份文档。

它改善工作流：Obsidian 把这些 Markdown 文件变成一个可视化的“第二大脑”。

它也更有隐私优势：资料可以保留在本地机器上，不必全部上传到云端。

如果你已经有 10 到 20 份以上围绕同一主题的文档，或者你的资料会持续更新和扩展，就值得考虑这种方式。

如果你经常生成内容、报告、研究材料或想法，或者处理个人、商业、机密信息，这种结构也很适合。

代理提示词可以完全定制。你可以在指令文件中定义不同文档类型使用哪些模板，需要哪些元数据字段，比如日期、作者、标签、摘要等；也可以定义笔记之间如何创建链接，以及代理在遇到更新和冲突时应该怎么处理。

因此，Wiki Layer 不只适用于个人笔记，也适用于营销、软件开发、学习、健康、商业分析等很多领域。

Karpathy 的 Wiki Layer 把一堆混乱文件变成真正的 AI 知识库。

一旦花时间完成初始搭建，你会得到一个持续演化的系统。它不仅能显著提升 LLM 工作速度，也能改善回答质量，因为模型面对的不再是杂乱原始材料，而是一个已经清洗、压缩、结构化并互相连接的知识层。

这篇文章最重要的启发是：不要让 LLM 每次都从零开始读原始资料。先让它把资料整理成可长期复用的知识库，再让它基于这个知识库工作。这样节省的不是一点 token，而是整个工作流中的重复认知成本。