前几天 AI 概念大神 Andrej Karpathy 写了一条推文，讲自己如何用LLM做个人知识库： 最近我发现有一件事非常有用，就是利用大型语言模型（LLMs）为各种感兴趣的研究主题构建个人知识库。这样一来，我近期处理的文本量中，用于操作代码的部分大幅减少，而用于操作知识（以 Markdown 和图片形式存储）的部分则显著增加。 结果推文非常火爆，超过千万阅读。于是今天他写了一个完整指南，我编译了一下，并对原文之下的高质量留言，也做了摘选。

先给大家做一个总括。

这篇文章解决的是一个多数人都有但说不清楚的问题：你用大模型处理过的知识，为什么留不下来？

现在大多数人用大模型处理文档的方式叫 RAG（检索增强生成），说白了就是你扔一堆文件进去，每次提问时模型临时翻找、临时拼凑答案。能用，但知识没有积累。问一个需要综合五份文档才能回答的问题，模型每次都得从零开始找、从零开始拼。什么都没沉淀下来。

Karpathy 的思路反过来：别让模型每次临时翻书了，让它替你维护一套持续更新的笔记。具体说，就是让大模型把你喂给它的资料逐步编译成一组互相链接的 Markdown 文件（也就是一个 wiki），像程序员维护代码库一样。每加一份新资料，模型不会只是存起来，它会读懂、提取要点、更新已有页面、标注矛盾、补充交叉引用。知识被"编译"一次就沉淀下来，越积越厚。

这个模式的分工一目了然：人类负责选材料、问问题、做判断；大模型负责所有苦力活，总结、归档、交叉引用、保持一致性。人类之所以会放弃维护 wiki，是因为维护负担的增速超过了价值增速。大模型消除了这个瓶颈，它不会烦、不会忘、一次操作能同时更新十几个页面。

下面是正文。

LLM Wiki：一种用 LLM 构建个人知识库的模式

这是一份创意文档，设计初衷是让你复制粘贴到自己的 LLM Agent 中（比如 OpenAI Codex、Claude Code、OpenCode / Pi 等）。它的目标是传达核心理念，具体细节由你的 Agent 与你协作完成。

一、核心理念

大多数人使用 LLM（大语言模型）处理文档的体验是 RAG（Retrieval-Augmented Generation，检索增强生成——即模型不靠自己的记忆回答问题，而是先从你上传的文档中检索相关片段，再据此生成答案）：你上传一批文件，LLM 在查询时检索相关片段，然后生成答案。这能用，但 LLM 每次都在从零重新发现知识，没有任何积累。问一个需要综合五份文档的微妙问题，LLM 每次都得重新找到并拼凑相关碎片。什么都没有沉淀下来。NotebookLM（Google 的笔记本 AI 产品）、ChatGPT 的文件上传以及大多数 RAG 系统都是这样工作的。

这里的思路不同。放弃查询时才从原始文档中检索的做法，让 LLM 逐步构建和维护一个持久化的 wiki，一组结构化、相互链接的 Markdown 文件（一种轻量级的纯文本格式，可以用任何编辑器打开），作为你和原始资料之间的中间层。当你添加新资料时，LLM 不会只是把它索引起来留待日后检索，它会阅读、提取关键信息、整合进现有 wiki，更新实体页面、修订主题摘要、标注新数据与旧结论的矛盾之处、用新证据去强化或推翻已有的综合判断。知识被编译一次就沉淀下来、持续更新，不用每次查询时从头推导。

这就是关键区别：wiki 是一个持久的、不断复利增长的产物。 交叉引用已经建好了，矛盾已经被标记了，综合判断已经反映了你读过的所有内容。每添加一个新资料源、每提出一个新问题，wiki 都在变得更丰富。

你几乎不用（或极少）亲自写 wiki——LLM 负责编写和维护全部内容。你负责的是资料筛选、探索方向和提出正确的问题。LLM 做所有苦力活——总结、交叉引用、归档和 bookkeeping（指维护知识库一致性所需的大量琐碎更新工作，如同记账），这些工作才是让知识库随着时间推移真正有用的关键。在实际操作中，我一边开着 LLM Agent（能执行操作的 AI 助手，不只是聊天，还能读写文件、运行命令），一边开着 Obsidian（一款流行的本地 Markdown 笔记软件，支持双向链接和图谱视图）。LLM 根据我们的对话进行编辑，我实时浏览结果——跟踪链接、查看图谱视图、阅读更新后的页面。Obsidian 是 IDE（集成开发环境），LLM 是程序员，wiki 是代码库。

这个模式适用的场景远不止一种，举几个例子：

个人领域：追踪你自己的目标、健康、心理、自我提升——归档日记、文章、播客笔记，随着时间构建一幅关于你自己的结构化全景。

研究领域：在数周或数月内深入一个课题——阅读论文、文章、报告，逐步构建一个带有演进论点的综合性 wiki。

阅读一本书：逐章归档，为人物、主题、情节线索建立页面，标注它们之间的关联。读完后你就拥有了一部丰富的伴读 wiki。想想粉丝 wiki，比如 Tolkien Gateway（托尔金百科，一个由粉丝社区维护的《魔戒》系列百科全书）——数千个相互链接的页面，涵盖人物、地点、事件、语言，由志愿者社区历经数年构建。你可以在阅读过程中由 LLM 做所有交叉引用和维护工作，个人也能构建这样的东西。

商业/团队：由 LLM 维护的内部 wiki，输入来源是 Slack 讨论、会议记录、项目文档、客户通话。可以有人类参与审核更新。wiki 之所以能保持更新，是因为 LLM 承担了团队中没人愿意做的维护工作。

竞争分析、尽职调查、旅行规划、课程笔记、爱好深挖——任何你在持续积累知识并希望它被组织起来而非散落各处的场景。

二、架构

分为三层：

原始资料源（Raw Sources） ——你精心筛选的源文档集合。文章、论文、图片、数据文件。这些是只读的——LLM 从中读取但绝不修改，原始资料永远保持原样。这是你的权威来源（source of truth，当信息冲突时以此为准）。

Wiki ——一个由 LLM 生成的 Markdown 文件目录。摘要、实体页面、概念页面、对比分析、概览、综合判断。这一层完全由 LLM 拥有。它创建页面、在新资料到达时更新页面、维护交叉引用、保持一切一致。你负责阅读，LLM 负责写。

Schema（模式定义） ——一份配置文档（例如 Claude Code 的 CLAUDE.md 或 OpenAI Codex 的 AGENTS.md——这些是各家 AI 编程工具的项目配置文件，告诉 AI 该遵循什么规则），定义 wiki 的结构是怎样的、约定是什么、在摄入资料、回答问题或维护 wiki 时应遵循什么工作流。这是关键配置文件——它让 LLM 成为一个有纪律的 wiki 维护者，而非一个通用聊天机器人。随着你对自己领域的理解加深，你和 LLM 会一起迭代这份文档，让它越来越好用。

三、操作

摄入（Ingest）。你把新资料放进原始资料集，然后让 LLM 处理它。一个典型流程：LLM 阅读资料，与你讨论关键要点，在 wiki 中写一个摘要页面，更新索引，更新 wiki 中相关的实体和概念页面，并在日志中追加一条记录。一个资料源可能触及 10-15 个 wiki 页面。我个人偏好逐条摄入资料并全程参与——我读摘要、检查更新、引导 LLM 强调什么。但你也可以批量摄入大量资料，减少监督。怎么做取决于你自己，找到适合你的工作流后，记在 Schema 里，下次开新会话时 LLM 就能沿用。

查询（Query）。你针对 wiki 提问。LLM 搜索相关页面、阅读它们、综合出带引用的答案。答案可以根据问题采取不同形式——一个 Markdown 页面、一个对比表格、一套幻灯片（Marp，一种把 Markdown 转成演示文稿的工具）、一张图表（matplotlib，Python 制图库）、一个画布。重要洞察：好的答案可以作为新页面归档回 wiki。 你请求的一次对比分析、一个分析结论、你发现的一个关联，这些都值得留下来，不应该消失在聊天历史中。这样，你的探索就像摄入的资料源一样，在知识库中实现复利增长。

检查（Lint——借用编程术语，原指代码静态检查工具，这里指对知识库做系统性的健康检查）。定期让 LLM 对 wiki 做健康检查。寻找：页面之间的矛盾、已被更新资料取代的过时论断、没有任何入站链接的孤儿页面（orphan pages，即没有其他页面链接到它的"孤岛"页面）、被提及但缺少独立页面的重要概念、缺失的交叉引用、可以通过网络搜索填补的数据缺口。LLM 擅长建议新的调查问题和新的资料来源。这让 wiki 在增长过程中保持健康。

四、索引与日志

两个特殊文件帮助 LLM（和你）在 wiki 增长时进行导航。它们的用途不同：

index.md 面向内容。它是 wiki 中所有内容的目录——每个页面列出链接、一行摘要，以及可选的元数据（如日期或资料源计数）。按类别组织（实体、概念、资料源等）。LLM 在每次摄入时更新它。回答查询时，LLM 先读索引找到相关页面，再深入查看。这在中等规模（约 100 个资料源、数百个页面）下效果出奇地好，避免了基于 embedding（嵌入向量，一种把文本转成数字向量以便计算相似度的技术）的 RAG 基础设施的需求。

log.md 面向时间线。它是一个只追加的记录（append-only，只增不改不删），记录发生了什么以及何时发生——摄入、查询、检查。一个实用技巧：如果每条记录以统一的前缀开头（例如 ## [2026-04-02] ingest | Article Title），日志就可以用简单的 Unix 命令行工具解析——grep "^## \[" log.md | tail -5 就能给你最后 5 条记录。日志给你 wiki 演进的时间线，帮助 LLM 了解最近做了什么。

五、可选：CLI 工具

到了某个阶段，你可能想构建一些小工具来帮助 LLM 更高效地操作 wiki。最显然的是一个 wiki 页面搜索引擎——在小规模下索引文件就够用了，但随着 wiki 增长，你需要正式的搜索能力。qmd 是个不错的选择：它是一个本地 Markdown 文件搜索引擎，支持 BM25/向量混合搜索（BM25 是经典的关键词匹配算法，向量搜索则通过语义相似度匹配，混合使用兼顾精确匹配和语义理解）和 LLM 重排序，全部在本地设备上运行。它同时有 CLI（命令行界面，LLM 可以通过 shell 调用）和 MCP 服务器（Model Context Protocol，Anthropic 提出的让 AI 连接外部工具的标准协议，LLM 可以把搜索引擎作为原生工具调用）。你也可以自己造一个更简单的——LLM 可以帮你随需编写一个朴素的搜索脚本。

六、技巧与窍门

Obsidian Web Clipper 是一个浏览器扩展，可以把网页文章转换为 Markdown。对快速把资料收入原始资料集非常有用。

把图片下载到本地。 在 Obsidian 的设置 → 文件和链接中，把"附件文件夹路径"设为一个固定目录（如 raw/assets/）。然后在设置 → 快捷键中搜索"Download"，找到"下载当前文件的附件"并绑定一个快捷键（如 Ctrl+Shift+D）。剪藏一篇文章后按快捷键，所有图片就会下载到本地磁盘。这不是必需的但实用——它让 LLM 可以直接查看和引用图片，而不用依赖可能失效的 URL。注意 LLM 目前不能一次性原生阅读带内嵌图片的 Markdown——变通方法是让 LLM 先读文本，然后单独查看部分或全部引用的图片以获取额外上下文。有点笨拙但够用。

Obsidian 的图谱视图（Graph View，以节点和连线的方式可视化所有笔记之间的链接关系）是查看 wiki 全貌的最佳方式——什么和什么连接在一起，哪些页面是枢纽，哪些是孤儿。

Marp 是一种基于 Markdown 的幻灯片格式。Obsidian 有它的插件。用于直接从 wiki 内容生成演示文稿。

Dataview 是一个 Obsidian 插件，可以对页面的 frontmatter（YAML 格式的元数据头，写在 Markdown 文件最顶部，用于存储标签、日期等结构化信息）运行查询。如果你的 LLM 在 wiki 页面中添加了 YAML frontmatter，Dataview 可以生成动态表格和列表。

Wiki 就是一个由 Markdown 文件组成的 git 仓库（git 是程序员用的版本管理工具，能追踪每次修改、随时回滚、支持多人协作）。 你免费获得版本历史、分支和协作能力。

七、为什么这个模式有效

维护知识库中令人厌烦的部分从来都不在阅读或思考，全在记账上。更新交叉引用、保持摘要时效性、标注新数据与旧结论的矛盾、在数十个页面间保持一致性。人类之所以放弃 wiki，是因为维护负担的增长速度超过了价值的增长速度。 LLM 不会厌倦、不会忘记更新某个交叉引用、而且能在一次操作中触及 15 个文件。Wiki 能保持被维护的状态，是因为维护成本接近于零。

人类的工作是筛选资料、指导分析方向、提出好问题、思考这一切意味着什么。LLM 的工作是剩下的一切。

这个理念的精神源头可以追溯到万尼瓦尔·布什（Vannevar Bush）1945 年提出的 Memex——一个私人的、精心策划的知识存储，文档之间有关联路径。相比后来万维网实际走向的方向，布什的愿景其实更接近 Karpathy 描述的这个模式：私密的、主动策划的，文档之间的连接与文档本身一样有价值。他没解决的问题是：谁来做维护？LLM 解决了。

八、说明

这份文档刻意保持抽象。它描述的是理念，而非具体实现。确切的目录结构、Schema 约定、页面格式、工具链——所有这些都取决于你的领域、你的偏好和你选择的 LLM。上面提到的一切都是可选的、模块化的——取你所需，忽略其余。例如：你的资料源可能全是纯文本，那你完全不需要图片处理。你的 wiki 可能足够小，索引文件就是你需要的全部，不需要搜索引擎。你可能不在乎幻灯片，只想要 Markdown 页面。你可能想要一套完全不同的输出格式。正确的用法是把这份文档丢给你的 LLM Agent，然后一起协作，搭出一个适合你需求的版本。这份文档唯一的任务就是把这个模式讲清楚。剩下的你的 LLM 能搞定。

精选高质量留言

1. dkushnikov — "趋同验证"

我独立走到了相同的模式——看到它被如此清晰地描述，是一种趋同验证，说明这个架构在根本上是对的。我们围绕 Obsidian 和 Claude Code 构建了两个开源工具：Obsidian Seed（通过对话生成个性化的 vault 结构和 reader-context.md 配置文件）和 Mnemon（知识提取管道，包含 7 种资料类型专用模板——因为论文需要方法论严谨性检查，而播客需要发言者归属和信噪比分析）。关键补充：个性化是一等层级。同一篇文章，不同读者 → 不同的摘要、不同的关键想法、不同的标签。"种子"不只是资料源——它是"资料源 + 读者画像 + 模板"的组合。

2. peas — "LLM 是我的速记员，不是代笔"

我从二月开始构建了一个语音优先版本。大多数知识系统在"采集"环节就失败了，而非"综合"。我散步时对着 Telegram 录语音备忘，Whisper（OpenAI 的语音转文字模型）转写，LLM 分类器打标签并路由，综合器更新互联的知识节点。70 多条语音备忘录编译成了 100 个知识节点和若干已发布的博客文章。最重要的约束：LLM 必须是编辑，而非写手——每句话都必须溯源到用户实际说过的内容。空白之处标 [TODO: ...]，而非用幻觉填充。陀思妥耶夫斯基口述给妻子做速记；LLM 是我的速记员，不是我的代笔。此外，交叉链接用机械规则生成（标题匹配、slug 模式匹配、共现分析），不让 LLM 生成——避免幻觉连接，让知识图谱可信赖。

3. bluewater8008 — "在生产环境跑了数周的实战经验"

我们已经在生产环境中跨多个知识领域运行这个模式数周了。几条经验：① 先分类再提取——50 页报告和 2 页信函需要不同的处理方式，不分类就只会得到千篇一律的浅层摘要；② 给索引分配 token 预算——我们用四级渐进披露（L0 约 200 token 的项目上下文，每次会话都加载；L1 约 1-2K 的索引；L2 约 2-5K 的搜索结果；L3 才是 5-20K 的完整文章），不到需要时不读全文；③ 每种实体类型一个模板，人物页和事件页需要不同的必填字段，7 种类型是甜蜜点（sweet spot，即效果与复杂度的最佳平衡点）；④ 每个任务产出两个输出——用户要的东西是输出一，对 wiki 相关文章的更新是输出二。不写进 Schema，LLM 就会让知识蒸发在聊天历史里；⑤ 人类拥有最终验证权——LLM 综合信息时可能不标来源，你不主动检查就不会发现。把来源引用写进 Schema 规则，并预留时间抽检 wiki 本身。

4. xoai — "做成了一个 Go 单体二进制"

做了 sage-wiki——一个跨平台的 Go 单体二进制程序。sage-wiki init --vault 在已有的 Obsidian vault 上初始化，或在空文件夹里运行。sage-wiki compile --watch 增量编译资料源为带概念、反向链接和交叉引用的 wiki 文章。sage-wiki search 和 sage-wiki query 做关键词搜索和带引用的问答。sage-wiki serve 把 wiki 暴露为 MCP 服务器，任何 LLM Agent 都能操作它。Lint 功能也做了——捕捉不一致、建议缺失连接、填补空白。查询输出归档回 wiki 那一刻，知识库就真正开始复利增长了。每个你问过的问题都在让它更擅长回答下一个问题。

5. umbex — "用 cron 心跳实现自动化摄入"

我做了类似的东西，但用结构化文件系统和 cron 心跳（cron 是 Linux 的定时任务调度器，"心跳"指按固定频率自动执行的任务）实现。系统能自动监控 inbox 文件夹、把内容路由到对应领域、用持久事实更新 foundations/（长期不变的知识底座）、用临时信息更新 data/current/（时效性数据），然后更新每个领域的 state.md（当前状态摘要）。每天早上收集所有 state.md 生成 brief.md 并构建仪表盘。摄入、路由、合并、摘要四层分离。

6. tkgally — "让 Claude Code 每晚自动维护知识库"

过去几个月我一直在用 Claude Code 构建一本日英词典。项目的复杂性让我对整体设计和未来方向的把握感到不安。所以我在仓库中创建了一个 planning/ 目录，把这份 LLM wiki 文档放进去，让 Claude 开始构建一个知识库，供未来数周数月项目持续增长时参考。我设置了定时任务让 Claude Code 每晚自动维护这个知识库。 开局看起来不错，期待看到效果。

7. mpazik — "最先崩溃的是查询和结构"

实践中最先崩溃的是两件事：查询（超过几百页后你没法靠读文件来提问，索引文件前期能用但不能规模化）和结构（frontmatter、命名约定、文件夹规则不知不觉就长出来了，到了某个点你发现自己在跟工具打架，没法专心做正事）。这让我反过来做：放弃让文件慢慢变成数据库的路线，直接从结构化数据出发，渲染为 Markdown。 数据进入事务日志，在 SQLite 中索引，每个实体显示为可编辑的 Markdown 文件，编辑内容再回写。索引不再是 Agent 手动维护的文件，它就是一个数据库查询，永远是最新的。我围绕这个思路在做 Binder。

8. localwolfpackai — "给知识库加一个偏见发散检查"

建议在摄入/查询操作中加入偏见发散检查（Divergence Check）。每次 LLM 更新概念页时，强制生成一个隐藏的 ## 反论与数据缺口 部分。如果你连续摄入 5 篇赞扬某个 UI 框架的文章，LLM 应该被要求搜索（或模拟）对该框架最有力的批评。相当于给你的认知盲区装了一面镜子。最近越来越注意到自己的偏见了……也许只是我吧。

9. Astro-Han — "一行安装，即插即用"

把它做成了一个即插即用的 skill（技能文件，让 AI Agent 遵循特定工作流的配置），适用于 Claude Code / Cursor / Codex。一行安装：npx add-skill Astro-Han/karpathy-llm-wiki，然后告诉 Agent "ingest this URL"，它就会处理从原始资料到 wiki 编译、交叉引用和索引更新的全流程。让我真正领悟的一点是：一旦建立起三层流（raw → wiki → index），每个新资料源都在真正丰富现有文章，而不只是堆积。Wiki 在复利增长。

10. flyersworder — "从单篇摘要到跨论文高阶模式提取"

我们从三月中旬开始做 LENS——聚焦于从论文中提炼跨文献的高阶模式，而非摘要单篇内容。核心思路：LLM 从研究论文中提取结构化的权衡关系（tradeoffs）、架构变体和智能体模式（agentic patterns），然后聚合为跨论文的知识结构——一个矛盾矩阵（灵感来自 TRIZ 创新方法论，记录哪些技术解决哪些权衡）、一个架构目录（按组件槽位组织的变体）、一个智能体模式目录（涌现出的类别）。一条洞察可能有 10 篇以上论文作为支撑。新论文通过规范词汇表自动归入已有结构，不需要人工整理。读了 Karpathy 的文章后，我们直接加了两个功能：Lint（6 项健康检查加自动修复）和事件日志。