Agent X-Ray

LLM Wiki

来源 Andrej Karpathy 发布的详细模式文档，以 GitHub Gist 形式分享，是其同主题 X 推文的展开版本。

LLM Wiki

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

这是一份"想法文件"，设计目的是让你直接复制粘贴给自己的 LLM Agent（例如 OpenAI Codex、Claude Code、OpenCode / Pi 等）。它的目标是传达高层思路，具体细节会由你的 Agent 与你协作落地。

多数人使用 LLM 处理文档的体验是 RAG (检索增强生成)：你上传一批文件，LLM 在查询时检索相关片段并生成答案。这能用，但 LLM 每次都是从零开始重新发现知识，没有任何积累。问一个需要综合五篇文档才能回答的细微问题，LLM 每次都得去寻找并拼接相关片段，什么都沉淀不下来。NotebookLM、ChatGPT 文件上传以及多数 RAG 系统都是这个模式。

这里的思路不同。与其在查询时才从原始文档里检索，不如让 LLM 增量式地构建并维护一个持久化 wiki——一组结构化、相互链接的 Markdown 文件，位于你与原始资料之间。每当你添加新资料时，LLM 不只是把它索引起来备查，而是读取它、提取关键信息、将其整合进已有 wiki——更新实体页面、修订主题摘要、标注新数据与旧说法的矛盾、强化或挑战正在演进的综合结论。知识只编译一次，此后持续保持最新，而不是每次查询都重新推导。

这就是关键区别：wiki 是一个持久化的、可复利的产物。交叉引用已经建好；矛盾已经被标记；综合结论已经反映了你读过的所有内容。每新增一份资料、每提一个问题，wiki 都会变得更丰厚。

你几乎不会（或极少）亲自动笔编写 wiki——wiki 的全部内容都由 LLM 撰写和维护。你负责资料采集、探索方向、提出好问题。LLM 则完成所有琐碎工作——总结、交叉引用、归档、簿记，这些才是让一个知识库真正有长期价值所必需的工作。实际操作中，我一边开着 LLM Agent，一边开着 Obsidian。LLM 根据我们的对话做修改，我实时浏览结果——点开链接、查看图谱视图、阅读更新后的页面。Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。

这套方法可以应用在很多场景，比如：

• 个人向：追踪你自己的目标、健康、心理、自我提升——归档日记、文章、播客笔记，随时间推移构建一幅关于自己的结构化画像。
• 研究向：花几周或几个月深入一个主题——阅读论文、文章、报告，增量式构建一个完整 wiki，论点持续演进。
• 读书向：每读完一章就归档，逐步为人物、主题、情节线及其联系建页面。读完一本书，你就拥有了一部详实的伴读 wiki。想想那些粉丝 wiki，比如 Tolkien Gateway——由社区志愿者经年累月构建的数千个相互链接的页面，涵盖人物、地点、事件、语言。你完全可以一边读书一边个人化地搭建这样一套 wiki，由 LLM 负责全部交叉引用和维护工作。
• 企业/团队向：一个由 LLM 维护、由 Slack 消息、会议转录、项目文档、客户通话持续喂养的内部 wiki，可能有人类在关键更新上做审阅。wiki 能保持最新，是因为 LLM 承担了那些团队里没人愿意做的维护工作。
• 竞品分析、尽职调查、旅行规划、课程笔记、业余爱好深挖——任何需要随时间累积知识、并希望有组织而非零散堆放的场景。

架构

整体分三层：

原始资料 (Raw sources)——你精选的源文档集合。文章、论文、图片、数据文件。这一层不可变——LLM 只读不写。这是你的真相之源 (source of truth)。

Wiki——一个由 LLM 生成的 Markdown 文件目录。包括摘要页、实体页、概念页、对比页、总览、综合结论。这一层完全由 LLM 拥有：创建页面、在有新资料时更新页面、维护交叉引用、保持整体一致性。你只读，LLM 写。

Schema（模式约定）——一份文档（例如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md），告诉 LLM wiki 的结构、约定，以及在 ingest 资料、回答问题、维护 wiki 时应当遵循的工作流。这是关键的配置文件——它让 LLM 成为一个有纪律的 wiki 维护者，而不是一个泛泛的聊天机器人。你和 LLM 会随着时间共同演化这份 schema，摸索出适合你领域的做法。

操作 (Operations)

Ingest（摄入）。 你将一份新资料放入原始资料目录，并告诉 LLM 处理它。一个典型流程：LLM 阅读资料、与你讨论核心要点、在 wiki 中写入摘要页、更新索引、更新 wiki 中相关的实体页和概念页、向日志追加一条记录。单一资料可能会触及 10–15 个 wiki 页面。我个人倾向于一份资料单独 ingest 并全程参与——我会读摘要、检查更新、告诉 LLM 要重点强调什么。但你也可以一次性批量 ingest 多份资料，监督减少。

Query（问答）。 你向 wiki 提问。LLM 先在 wiki 中检索相关页面，读取后综合出带引用的答案。答案可以采用多种形式——Markdown 页面、对比表、幻灯片（Marp）、图表（matplotlib）、Canvas。关键洞察是：好答案可以被归档回 wiki，成为新的页面。

Lint（健康检查）。 定期让 LLM 对 wiki 做健康检查。关注：页面间的矛盾、已被新资料推翻的陈旧论断、没有入链的孤立页面、被反复提及却没有自己页面的重要概念、缺失的交叉引用、可以通过网络搜索补齐的数据空白。

有两个特殊文件，能帮 LLM（和你）在 wiki 壮大过程中始终保持可导航：

index.md 是内容导向的。它是 wiki 全部页面的目录——每一页列一条，附链接、一行摘要，以及可选的元数据（日期、源文件数量等），按类别组织。LLM 每次 ingest 都会更新它。回答问题时，LLM 先读索引找到相关页面，再进入详情。

log.md 是时间导向的。它是追加写入 (append-only) 的操作记录——ingest、query、lint 过程都会留痕。每条记录以一致的前缀开头（例如 ## [2026-04-02] ingest | 文章标题），使其可以用最简单的 Unix 工具解析。

工具

• Obsidian Web Clipper——将网页文章转成 Markdown 的浏览器扩展
• 本地下载图片——设置附件目录路径、绑定快捷键一键下载
• Obsidian 图谱视图——直观感受 wiki 的形状
• Marp——基于 Markdown 的幻灯片格式
• Dataview——按 frontmatter 查询页面
• qmd——本地 Markdown 搜索引擎，支持 BM25/向量混合检索与 LLM 重排
• Git——免费的版本历史、分支、协作

关键洞察

维护知识库真正繁琐的地方不是阅读，也不是思考——而是簿记。更新交叉引用、让摘要保持最新、在新数据推翻旧说法时加以标注、跨几十个页面保持一致。人类会放弃 wiki，是因为维护成本的增长快于其价值的增长。LLM 不会疲倦、不会忘记更新一个交叉引用、单次就可以触及 15 个文件。wiki 能一直保持良好维护，是因为维护的边际成本被压到了接近零。

人类的工作是：挑选资料、指引分析、提好问题、思考它们意味着什么。LLM 的工作是：其他所有事。

---

Related Documents

• LLM Wiki (Original)
• Karpathy LLM Knowledge Bases (X post 原文)
• Karpathy LLM 知识库 (X 推文中译)

---