AI·系统·创造·人将如何自处

Karpathy LLM Wiki · 中译

17分钟阅读

Karpathy LLM Wiki · 中译

翻译说明：本中译由 AIBuilder 社群发起，Codex 初翻，AI 学者审校，2026-04-20 发布首版。 原文：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

LLM Wiki

一种用 LLM 搭个人知识库的模式。

这是一份 idea file，设计出来就是让你直接复制粘贴给你自己的 LLM agent（比如 OpenAI Codex、Claude Code、OpenCode / Pi 等等）。它的目标，是传达这套做法的高层思路；至于细节，agent 会和你一起把它具体化。

核心想法

大多数人把 LLM 和文档放在一起时，体验看起来都像 RAG：你上传一堆文件，LLM 在查询时检索相关片段，然后生成答案。这样当然能用，但每问一个问题，LLM 都是在从头重新发现知识。它没有积累。

如果你问了一个很细的问题，需要综合五份文档，它每次都得重新去找、重新拼相关碎片。什么都没有真正长出来。NotebookLM、ChatGPT 文件上传，以及大多数 RAG 系统，基本都属于这一类。

这里的想法不一样。它不是在查询时才从 raw（源材料）里临时检索，而是让 LLM 增量地构建并维护一套持久 wiki。这套 wiki 是一组结构化、互相链接的 markdown 文件，夹在你和 raw sources（源材料）之间。

当你加入一个新来源时，LLM 不只是把它索引起来，等以后再检索。它会去读，抽取关键信息，并把这些内容整合进已有 wiki 里。它会更新实体页、修订主题摘要、标出新数据和旧说法冲突的地方、强化或挑战正在演化中的综合判断。知识被编译一次，然后持续保持最新，而不是每次查询都重新推导。

关键区别就在这里：wiki 是一个持久、会复利增长的产物。 交叉引用已经在里面了。冲突已经被标出来了。综合判断已经吸收了你读过的一切。每加一个来源、每问一个问题，这套 wiki 都会继续变丰富。

你几乎不需要亲手去写这套 wiki，或者至少很少需要。是 LLM 在写，也在维护。 你负责的是找来源、探索、问对问题。LLM 负责所有脏活累活：总结、交叉引用、归档、记账式维护，而这些恰恰是让一个知识库在长期里真正有用的关键。

实际操作里，我一般是一边开着 LLM agent，一边开着 Obsidian。LLM 根据我们的对话去改文件，我则实时浏览结果，点链接、看 graph view、读更新后的页面。Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。

这套模式可以用在很多不同场景里。举几个例子：

  • 个人：追踪自己的目标、健康、心理、自我提升；把日记、文章、播客笔记归进去，慢慢搭出一张关于自己的结构化图景。
  • 研究：围着某个主题连续几周或几个月深挖，读论文、文章、报告，并逐步长出一套有演化中 thesis（论点）的完整 wiki。
  • 读一本书：你一章一章地归档，顺手为人物、主题、情节线和它们之间的关系建页面。读到最后，你会得到一套很丰富的 companion wiki。可以想想 Tolkien Gateway 这种 fan wiki：成千上万互相链接的页面，覆盖角色、地点、事件、语言，是社区志愿者几年里一起搭出来的。你完全可以在自己读书时也做出类似的东西，只不过这次交叉引用和维护都由 LLM 来做。
  • 企业 / 团队：一套由 LLM 维护的内部 wiki，源头是 Slack 讨论、会议转录、项目文档、客户电话记录。也可以有人在环审阅更新。wiki 能保持新鲜，是因为那些谁都不想做的维护活，现在都由 LLM 接手了。
  • 竞品分析、尽调、旅行规划、课程笔记、兴趣深挖：只要是你在持续累积知识、又希望它们被组织起来而不是散落一地的场景，都适用。

架构

这里有三层：

Raw sources（源材料）：你策展出来的一组原始文档。文章、论文、图片、数据文件都算。这一层是不可变的：LLM 只读，不改。这是你的 source of truth（事实底座）。

The wiki（wiki 层）：一个由 LLM 生成的 markdown 文件目录。里面有摘要页、实体页、概念页、比较页、概览页、综合页。LLM 完整拥有这一层：新来源来了它会建页、改页、补交叉引用、维持一致性。你读它；LLM 写它。

The schema（schema 层）：一份文档（比如 Claude Code 用 CLAUDE.md，Codex 用 AGENTS.md），告诉 LLM 这套 wiki 怎么组织、遵循什么约定、在 ingest（摄入来源）、query（回答问题）、maintain（维护）时该走什么 workflow。它是关键配置文件。正是它让 LLM 成为一个守纪律的 wiki 维护者，而不是一个泛泛的聊天机器人。你和 LLM 会随着时间一起迭代这份 schema，看你的领域里什么做法最有效。

操作

Ingest（摄入）
你把一个新来源放进 raw collection（源材料集合），然后让 LLM 去处理。一个典型流程可能是：LLM 读这个来源，和你讨论关键 takeaway（带走点），在 wiki 里写一页摘要，更新 index，去改相关的实体页和概念页，并在 log 里追加一条记录。一个来源可能会触碰 10 到 15 个 wiki 页面。

我个人更喜欢一次 ingest 一个来源，而且保持参与：我会读摘要，看更新，并告诉它该强调什么。但你也可以少监督一点，改成批量 ingest 很多来源。最终走什么 workflow，要看什么适合你，再把它写进 schema，让未来的 session 也能沿用。

Query（查询）
你对这套 wiki 提问题。LLM 会去找相关页面，读它们，然后带引用地综合出一个回答。回答形式可以很多样：一页 markdown、一张比较表、一套 slide deck（Marp）、一张图（matplotlib）、一个 canvas。

这里最重要的洞察是：好的答案可以反过来归档回 wiki，变成新页面。 你刚问出来的那个比较、一段分析、一个新发现的连接，这些本身是有价值的，不该消失在聊天记录里。这样一来，你的探索也会像 ingest 进来的来源一样，继续在知识库里复利。

Lint（巡检）
隔一段时间，让 LLM 给这套 wiki 做一次健康检查。它应该去看：

  • 页面之间有没有冲突
  • 有没有过时说法已经被新来源推翻
  • 有没有 orphan pages（没有入链的孤儿页）
  • 有没有重要概念已经提过，但还没有自己独立成页
  • 有没有漏掉的交叉引用
  • 有没有数据空洞，值得用一次 web search 去补

LLM 很擅长提出新的待研究问题，也很擅长建议你该去找哪些新来源。这样这套 wiki 才能在变大时还维持健康。

索引与日志

随着 wiki 变大，有两个特殊文件能帮助 LLM 和你一起导航。它们作用不同：

index.md 是按内容组织的。它像这套 wiki 的总目录：每个页面有链接、有一句话摘要，也可以带上日期、来源数量等元数据。它按类别组织，比如 entities、concepts、sources 等。LLM 每次 ingest 都会更新它。回答问题时，LLM 会先读 index，找到相关页面，再钻进去细读。

这个办法在中等规模下效果 surprisingly good（出奇地好），比如大约 100 个来源、几百个页面时就够用了，而且你不用额外搭 embedding-based RAG（基于向量嵌入的检索）基础设施。

log.md 是按时间组织的。它是一份 append-only（只追加）的记录，写清“什么时候发生了什么”：ingest、query、lint pass（巡检）。一个很好用的小技巧是：如果每条记录都以稳定前缀开头（比如 ## [2026-04-02] ingest | Article Title），那这份 log 就能被简单的 unix 工具直接解析，比如 grep "^## \[" log.md | tail -5 就能给你最后 5 条。

这份 log 帮你看到 wiki 的演化时间线，也能帮助 LLM 理解最近做过什么。

可选：CLI 工具

随着时间推移，你可能会想做一些小工具，帮助 LLM 更高效地操作这套 wiki。

最显然的就是搜索引擎。小规模时，index 文件就够；再长大一些，你就会想要真正的搜索能力。一个不错的选项是 qmd：它是给 markdown 文件用的本地搜索引擎，支持 hybrid BM25/vector search（混合 BM25 + 向量检索）以及 LLM reranking（重排），而且全部 on-device（本机完成）。

它既有 CLI（LLM 可以直接 shell out 调它），也有 MCP server（LLM 可以把它当原生工具来用）。当然，你也可以自己搭一个更简单的版本，等需要时再让 LLM 帮你 vibe-code 一份朴素搜索脚本。

小技巧

  • Obsidian Web Clipper 是个浏览器扩展，可以把网页文章直接转成 markdown。它非常适合把来源快速收进 raw collection。
  • 把图片下载到本地。 在 Obsidian 的 Settings → Files and links 里，把 “Attachment folder path” 设成固定目录（比如 raw/assets/）。然后到 Settings → Hotkeys 里搜 “Download”，找到 “Download attachments for current file”，给它绑个快捷键（比如 Ctrl+Shift+D）。这样每次 clip 完一篇文章，按一下快捷键，里面所有图片都会下载到本地。这个不是必须，但很有用：这样 LLM 能直接看本地图片并引用它们，而不是依赖可能失效的 URL。注意，LLM 不能在同一趟里原生读“带内嵌图片的 markdown”，解决办法是先让它读正文，再分开查看部分或全部相关图片来补上下文。虽然有点笨，但已经够用了。
  • Obsidian 的 graph view 是观察整套 wiki 形状的最佳方式：谁和谁连着，哪些页面是 hub，哪些页面是 orphan。
  • Marp 是 markdown-based slide deck（基于 markdown 的幻灯片格式）。Obsidian 有它的插件。直接用 wiki 内容出展示，会很方便。
  • Dataview 是 Obsidian 插件，可以对页面 frontmatter 运行查询。如果你的 LLM 会给 wiki 页面加 YAML frontmatter（标签、日期、来源数等），Dataview 就能自动生成动态表格和列表。
  • wiki 本身其实只是一个 markdown 文件的 git repo。版本历史、分支、协作能力，全都是白送的。

为什么这套东西有效

维护知识库最烦人的部分，不是阅读，也不是思考，而是 bookkeeping（维护杂活）。

更新交叉引用、保持摘要不过时、标记新数据和旧说法的冲突、在几十个页面之间维持一致性，这些才是最累的。人们放弃 wiki，通常不是因为它没有价值，而是因为维护成本增长得比价值更快。

LLM 不会觉得烦，不会忘记顺手更新一个交叉引用，还能在一次处理里同时动 15 个文件。wiki 能保持被维护的状态，是因为维护成本被压到了接近零。

人的工作，是策展来源、引导分析、问出好问题，并思考这些东西到底意味着什么。LLM 的工作，是其他一切。

这个想法在精神上和 Vannevar Bush 的 Memex（1945）有亲缘关系：一套个人化、经过策展的知识存储，以及文档之间的 associative trails（联想路径）。Bush 的愿景其实比后来长成的 web 更接近这里：私人的、主动策展的，而且文档之间的连接本身和文档一样有价值。Bush 当年没法解决的问题，是谁来负责维护。LLM 正好填上了这一块。

注

这份文档故意保持抽象。它描述的是一种模式，不是某个具体实现。

目录结构怎么设计、schema 约定怎么写、页面格式长什么样、要不要加工具，这些都取决于你的领域、你的偏好和你使用的 LLM。上面提到的一切都是可选的、模块化的：有用就拿走，没用就忽略。

比如：

  • 你的来源也许全是文本，那你根本不需要图片处理。
  • 你的 wiki 也许很小，index 文件就完全够，不需要单独搜索引擎。
  • 你也许对 slide deck 没兴趣，只想要 markdown 页面。
  • 你也许想要一套完全不同的输出格式。

这份文档最正确的使用方式，就是把它分享给你的 LLM agent，然后和它一起把它实例化成真正适合你自己的版本。

这份文档唯一的任务，是把这套模式讲明白。剩下的，你的 LLM 会和你一起想出来。

欢迎反馈修订。如果你觉得某个术语译法可以更顺，或者哪一段更适合保留英文原词，请直接在候选阶段改。

关系图谱