我看到这个第一感受是：这个项目可能对知识星球、Slax Reader 和 Slax Note 都会有思路启发。

原文发布于 2026 年 4 月 2 日（X/Twitter 推文），随后于 4 月 4 日发布了配套的 GitHub Gist「idea file」。以下为推文全文及 Gist 完整翻译。

一、推文正文#

LLM 知识库#

我最近发现一种非常有用的做法：用大语言模型来构建个人知识库，服务于各类研究课题。

这样一来，我最近消耗的 token 中，越来越大的比例不再用于操控代码，而是用于操控知识——以 Markdown 和图片的形式存储。最新一代的大模型在这方面表现相当出色。

具体是这样的：

数据摄入（Data Ingest）： 我把各类源文档（文章、论文、代码仓库、数据集、图片等）索引到一个 raw/ 目录下，然后用大模型增量「编译」出一套 Wiki。这套 Wiki 就是一组按目录结构组织的 .md 文件，包含对 raw/ 中所有数据的摘要、反向链接，还会把数据归类为不同概念、为每个概念撰写文章，并将它们相互关联。

要把网页文章转成 .md 文件，我喜欢用 Obsidian Web Clipper 扩展。我还设了一个快捷键来下载文章中的所有相关图片到本地，这样大模型就能方便地引用它们。

问答（Q&A）： 真正有趣的是，当你的 Wiki 积累到一定规模后（比如我某个近期研究课题的 Wiki 已经有大约 100 篇文章、约 40 万字），你可以向大模型代理提出各种复杂问题，它会自己去 Wiki 里查找、研究，然后给出答案。

我本以为需要用到花哨的 RAG 技术，但事实证明，大模型自己维护索引文件和各文档的简要摘要就已经做得很好了——在这个不算太大的规模下，它能相当轻松地读取所有重要的相关数据。

输出： 相比在终端里获取纯文本回答，我更喜欢让大模型生成 Markdown 文件、幻灯片（Marp 格式）或 matplotlib 图表，然后在 Obsidian 里查看。你可以想象，根据不同的查询需求，还可以有很多其他可视化输出格式。很多时候，我会把这些输出结果「归档」回 Wiki 里，以此增强知识库，为后续查询服务。这样，我自己的每一次探索和提问都会在知识库中「累积」下来。

质检（Linting）： 我会让大模型对 Wiki 进行「健康检查」——比如发现不一致的数据、补全缺失的数据（借助网页搜索）、发现值得撰写新文章的有趣关联等等，以此逐步清理 Wiki 并提升其整体数据质量。大模型非常擅长提出进一步值得追问和研究的问题。

额外工具： 我发现自己还会开发一些小工具来处理数据。比如我用 vibe coding 快速搭了一个针对 Wiki 的小型朴素搜索引擎，既可以直接通过 Web UI 使用，但更多时候是让大模型通过命令行当作工具来调用，用于处理更大规模的查询。

进一步探索： 随着仓库不断增长，自然会开始考虑合成数据生成和微调，让大模型把这些数据「内化」到权重里，而不仅仅依赖上下文窗口。

总结（TLDR）： 从若干来源收集原始数据，然后由大模型编译成 .md Wiki，再由大模型通过各种命令行工具对其进行问答和增量增强。

你几乎永远不需要手动编写或编辑 Wiki——那是大模型的领地。我认为，这里完全有空间诞生一款了不起的新产品，而不只是一堆拼凑的脚本。

二、推文评论区补充（Karpathy 本人回复摘录）#

关于增量编译的问题： 目前这并不是一个完全自动化的过程。我一次手动添加一个来源，特别是在早期阶段会深度参与。等到积累了一定量之后，大模型就「理解」了这个模式，每添加一篇新文档就轻松多了——我只需要说「把这篇新文档归档到我们的 Wiki 里：（路径）」。

关于目录结构： 目前没有复杂结构，因为我刻意保持极简和扁平——就是嵌套目录下的 .md 文件、.png 文件，加上少量 .csv 和 .py，schema 在 AGENTS.md 里维护。大模型非常容易理解这种结构。任何自定义功能都可以轻松地用 vibe coding 做出工具来。

三、Gist 完整版：LLM Wiki#

以下翻译自 Karpathy 于 4 月 4 日发布的 GitHub Gist「idea file」（原文链接）。这是一份「理念文档」，旨在传达整体思路，你可以直接把它复制粘贴给自己的大模型代理（如 OpenAI Codex、Claude Code、OpenCode / Pi 等），由代理与你协作完成具体搭建。

核心理念#

大多数人使用大模型处理文档的方式都像 RAG：你上传一批文件，大模型在查询时检索相关片段，然后生成回答。这能用，但大模型每次提问都在从零开始重新发现知识，没有任何积累。如果你问一个需要综合五篇文档才能回答的细致问题，大模型每次都得重新找到并拼凑相关的碎片。什么都没有沉淀下来。NotebookLM、ChatGPT 的文件上传，以及大多数 RAG 系统，都是这个模式。

这里的思路截然不同。与其在查询时才从原始文档中检索，不如让大模型增量构建并维护一套持久化的 Wiki——一组结构化的、相互链接的 Markdown 文件，位于你和原始资料之间。当你添加一个新来源时，大模型不是仅仅把它索引起来留待后用，而是读取它，提炼关键信息，然后整合到现有 Wiki 中——更新实体页面，修订主题摘要，标注新数据与旧说法的矛盾，强化或挑战正在演进的综合分析。知识被编译一次，然后持续更新，而非每次查询时重新推导。

这就是关键区别：Wiki 是一个持久化的、不断累积的产物。 交叉引用已经建好了，矛盾已经被标记了，综合分析已经反映了你读过的全部内容。每添加一个来源、每提出一个问题，Wiki 都变得更加丰富。

你几乎永远不需要自己动手写 Wiki——大模型负责全部的编写和维护。你负责的是策划来源、探索方向、提出好的问题。大模型做所有的苦力活——摘要、交叉引用、归档、簿记——这些才是让一个知识库真正长期有用的关键。在实际操作中，我一边开着大模型代理，一边开着 Obsidian。大模型根据我们的对话进行编辑，我则实时浏览结果——跟踪链接、查看图谱视图、阅读更新后的页面。Obsidian 是 IDE；大模型是程序员；Wiki 是代码库。

这个模式可以应用于很多场景，举几个例子：

  • 个人成长： 跟踪你的目标、健康、心理状态、自我提升——将日记条目、文章、播客笔记归档，逐步构建出关于自己的结构化全景。
  • 学术研究： 在数周或数月内深入钻研一个课题——阅读论文、文章、报告，增量构建一套全面的 Wiki，逐步形成不断演进的论点。
  • 读书： 逐章归档，为角色、主题、情节线索以及它们之间的联系建立页面。读完之后你会拥有一套丰富的伴读 Wiki。想想像 Tolkien Gateway 那样的粉丝 Wiki——数千个相互链接的页面，覆盖角色、地点、事件、语言，由一个社区的志愿者花费数年建成。你可以在阅读过程中自己搭建类似的东西，而大模型负责所有的交叉引用和维护工作。
  • 商业/团队： 由大模型维护的内部 Wiki，喂入 Slack 对话、会议记录、项目文档、客户电话。可以让人类审核更新。Wiki 能保持时效性，因为大模型完成了团队中没人愿意做的那些维护工作。
  • 竞品分析、尽职调查、旅行规划、课程笔记、兴趣爱好深挖——任何随着时间推移不断积累知识、且需要将知识组织起来而非散落各处的场景。

架构#

共分三层：

原始素材（Raw Sources） ——你精选的源文档集合。文章、论文、图片、数据文件。这些是不可变的——大模型只读不改。这是你的事实之源。

Wiki ——一个由大模型生成的 Markdown 文件目录。包括摘要、实体页面、概念页面、对比分析、概览、综合分析。大模型完全拥有这一层。它创建页面，在新来源到达时更新它们，维护交叉引用，保持一切一致。你来读；大模型来写。

Schema（配置层） ——一份文档（例如为 Claude Code 准备的 CLAUDE.md，或为 Codex 准备的 AGENTS.md），告诉大模型 Wiki 的结构是什么样的、有哪些约定、以及在摄入来源、回答问题或维护 Wiki 时应遵循什么工作流程。这是核心配置文件——它让大模型成为一个训练有素的 Wiki 管理员，而不是一个泛泛的聊天机器人。你和大模型会随着时间推移共同演进这份文档，逐步摸索出适合你的领域的最佳实践。

操作#

摄入（Ingest）。 你把一个新来源放入原始素材集合，然后让大模型处理它。一个典型的流程是：大模型读取来源，与你讨论关键要点，在 Wiki 中写一页摘要，更新索引，更新 Wiki 中所有相关的实体和概念页面，并在日志中追加一条记录。单一来源可能会触及 10-15 个 Wiki 页面。就我个人而言，我更喜欢一次摄入一个来源并保持参与——我会读摘要、检查更新、引导大模型该强调什么。但你也可以一次批量摄入多个来源、减少人工监督。你需要自己摸索出适合自己风格的工作流，并将其记录在 Schema 中，供未来的会话参考。

查询（Query）。 你针对 Wiki 提问。大模型搜索相关页面，读取它们，然后综合出一个附有引用的答案。答案可以有不同的形式——一页 Markdown、一张对比表、一套幻灯片（Marp）、一张图表（matplotlib）、一块画布。重要的洞察是：好的答案可以作为新页面归档回 Wiki。 你提出的对比、分析、发现的关联——这些都很有价值，不应该消失在聊天记录里。这样，你的每一次探索都和摄入的来源一样，在知识库中不断累积。