原文地址：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

这是一个创意文件（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（托尔金网守）这样的粉丝百科——数千个相互链接的页面，涵盖人物、地点、事件、语言，由志愿者社区耗费数年心血建成。在阅读时，你可以在个人层面构建出类似的东西，而 LLM 会替你完成所有的交叉引用和维护工作。
• 商业/团队层面： 由大语言模型维护的内部 wiki，数据来源可以是 Slack 讨论串、会议记录、项目文档、客户电话。或者让人类介入环路（human-in-the-loop）来审查更新。因为大语言模型承担了团队中没人愿意做的维护工作，所以该 wiki 能够始终保持最新状态。
• 竞品分析、尽职调查、旅行规划、课程笔记、爱好深挖——任何你需要长期积累知识且希望它们井然有序而非散落一地的场景都适用。

架构

包含三个层级：

原始资料（Raw sources）——你精心收集的源文档集合。包括文章、论文、图片、数据文件。它们是不可变的（immutable）——大语言模型只会读取它们，绝不会对其进行修改。这是你的“单一事实来源（source of truth）”。

Wiki——由大语言模型生成的 markdown 文件目录。包含摘要、实体页面、概念页面、对比、概述和综合论述。大语言模型完全拥有这一层级。它负责创建页面，在新资料到来时更新页面，维护交叉引用，并保持所有内容的一致性。你负责阅读，大语言模型负责编写。

架构规范（The schema）——一个文档（例如，用于 Claude Code 的 CLAUDE.md，或用于 Codex 的 AGENTS.md），用来告诉大语言模型这个 wiki 是如何结构化的、有哪些约定俗成的规则，以及在摄取资料、回答问题或维护 wiki 时应遵循哪些工作流。这是关键的配置文件——正是它让大语言模型成为一个严谨的 wiki 维护者，而不仅仅是一个普通的聊天机器人。随着你逐渐摸索出适合自己所在领域的模式，你和大语言模型将随着时间的推移共同进化这份规范。

操作流程

摄取（Ingest）。 你将一份新资料丢入原始资料集合中，并告诉大语言模型去处理它。一个工作流示例：大语言模型阅读这份资料，与你讨论核心要点，在 wiki 中撰写摘要页面，更新索引，更新 wiki 中相关的实体和概念页面，并在日志中追加一条记录。单一的一份资料可能会触及 10 到 15 个 wiki 页面。就我个人而言，我更喜欢一次摄取一份资料并保持全程参与——我会阅读摘要，检查更新，并指导大语言模型应当强调什么内容。但你也可以在较少监督的情况下批量摄取大量资料。这取决于你如何开发适合自己风格的工作流，并将其记录在架构规范中供未来的会话使用。

查询（Query）。 你向 wiki 提出问题。大语言模型会搜索相关页面，阅读它们，并综合出一个带有引用的答案。答案的形式可以根据问题而有所不同——可以是一个 markdown 页面、一张对比表格、一份幻灯片（Marp）、一张图表（matplotlib）或者一块画布。一个重要的见解是：好的答案可以作为新页面归档回 wiki 中。你要求的某个对比、某项分析、或者你发现的某种联系——这些都是有价值的，不应该消失在聊天记录里。通过这种方式，你的探索会像摄取原始资料一样，在知识库中不断产生复利积累。

数据检查（Lint）。 阶段性地要求大语言模型对 wiki 进行健康检查。寻找：页面之间的矛盾之处、已被新资料推翻的陈旧主张、没有入站链接的孤立页面、被提及但尚未建立独立页面的重要概念、缺失的交叉引用，以及可通过网络搜索填补的数据空白。大语言模型非常擅长建议你提出新问题去调查，以及寻找新资料。这能让 wiki 在不断增长的过程中保持健康。

索引与日志记录

在 wiki 不断扩充的过程中，有两个特殊文件能帮助大语言模型（以及你）在其中导航。它们有着不同的用途：

index.md 面向内容。 它是 wiki 中所有内容的目录——每个页面都以链接、一句话摘要的形式列出，还可以选择加上日期或来源计数等元数据。它按类别（实体、概念、资料等）进行组织。LLM 会在每次摄取时更新它。在回答查询时，大语言模型会先读取索引以寻找相关页面，然后再深入阅读这些页面。在中等规模下（约 100 份资料，数百个页面），这种方法的效果出奇的好，并能免去部署基于向量嵌入（embedding）的 RAG 基础设施的需求。

log.md 按时间顺序排列。 这是一个只追加不修改的记录，记录了在何时发生了什么事——包括摄取、查询和检查（lint）。一个小提示：如果每条记录都以一致的前缀开头（例如 ## [2026-04-02] ingest | 文章标题），那么这个日志就能用简单的 Unix 工具来解析——例如使用 grep "^## \[" log.md | tail -5 就能获得最后 5 条记录。日志为你提供了 wiki 演进的时间线，也能帮助大语言模型了解最近做了哪些工作。

可选配置：CLI 工具

在某个阶段，你可能会想构建一些小工具来帮助大语言模型更高效地操作 wiki。最显而易见的莫过于一个针对 wiki 页面的搜索引擎——在规模较小时，索引文件就足够了，但随着 wiki 的增长，你会需要真正的搜索功能。qmd 是一个不错的选择：它是一个用于 markdown 文件的本地搜索引擎，具备混合 BM25/向量搜索以及 LLM 重排功能，且全部在设备端运行。它既提供了 CLI（让大语言模型可以通过命令行调用），也提供了 MCP 服务器（让大语言模型可以将其作为原生工具使用）。你也可以自己构建更简单的工具——当需要时，大语言模型可以帮你 vibe-code 一个简单的搜索脚本。

提示与技巧

• Obsidian Web Clipper 是一款将网页文章转换为 markdown 的浏览器扩展。对于快速将资料存入原始资料库非常有用。
• 将图片下载到本地。 在 Obsidian 的“设置 → 文件与链接”中，将“附件文件夹路径（Attachment folder path）”设置为一个固定目录（例如 raw/assets/）。然后在“设置 → 快捷键”中，搜索“下载（Download）”以找到“下载当前文件的附件（Download attachments for current file）”，并将其绑定到一个快捷键（例如 Ctrl+Shift+D）。剪辑文章后，按下该快捷键，所有图片就会下载到本地硬盘中。这是可选项，但非常有用——它能让 LLM 直接查看和引用图片，而无需依赖可能失效的 URL。需要注意的是，大语言模型无法在一次遍历中原生读取带有内联图片的 markdown 文件——目前的变通方案是让大语言模型先读取文本，然后再单独查看部分或全部被引用的图片以获取额外的上下文。这虽然有些繁琐，但也足够奏效。
• Obsidian 的关系图谱（graph view） 是查看 wiki 形态的最佳方式——什么与什么相连，哪些页面是枢纽节点，哪些是孤立节点，一目了然。
• Marp 是一种基于 markdown 的幻灯片格式。Obsidian 有对应的插件。这对于直接从 wiki 内容生成演示文稿非常有用。
• Dataview 是一款可以在页面 frontmatter（前言/元数据）上运行查询的 Obsidian 插件。如果你的 LLM 会在 wiki 页面中添加 YAML frontmatter（标签、日期、资料来源计数等），Dataview 就可以生成动态的表格和列表。
• 该 wiki 说到底只是一个存放 markdown 文件的 Git 仓库。 你可以免费获得版本历史、分支功能和协作能力。

为什么这套方法行得通

维护知识库最枯燥的部分并非阅读或思考——而是记账式的整理工作。更新交叉引用、保持摘要处于最新状态、在出现与旧观点相悖的新数据时做记录、在几十个页面之间保持一致性。人类之所以会放弃使用 wiki，是因为维护负担的增长速度超过了其所产生的价值。但 LLM 不会感到厌倦，不会忘记更新交叉引用，并且能够一次性处理 15 个文件。正因为维护成本趋近于零，wiki 才得以被长期维护下去。

人类的职责是精选资料、主导分析方向、提出好问题，并思考这一切背后的意义。而 LLM 的职责则是搞定剩下的所有事情。

这一理念在精神上与范内瓦·布什（Vannevar Bush）在 1945 年提出的 Memex（记忆延展机）一脉相承——那是一个个人的、经过精选的知识库，文档之间有着联想式的关联轨迹。相较于后来万维网（Web）的发展形态，布什的愿景更接近于此：私密、积极的人工筛选，且文档之间的联系与文档本身同等重要。当时他无法解决的问题是“由谁来做维护工作”。现在，LLM 搞定了这一点。

注

本文档有意保持了抽象。它描述的是一种理念，而不是具体的实现。确切的目录结构、架构规范、页面格式和工具——所有这些都将取决于你的领域、你的偏好以及你选择的大语言模型。上面提到的所有内容都是可选且模块化的——取其精华，弃其糟粕。例如：你的资料可能只有纯文本，因此你根本不需要图片处理。你的 wiki 可能足够小，仅凭索引文件就够了，无需搜索引擎。你可能根本不在乎幻灯片，只想保留 markdown 页面。你也可能想要一套完全不同的输出格式。使用本文档的正确方式，是将其分享给你的大语言模型智能体，并与它携手将其具象化为一个符合你需求的版本。这份文档唯一的任务就是传达这种设计模式。剩下的，你的大语言模型自有分晓。