以下是 Andrej Karpathy 在 GitHub 上发布的 LLM Wiki 文档的中文翻译。

一种利用大语言模型构建个人知识库的模式

这是一份「理念说明文档」，设计初衷是供你直接复制粘贴到你自己的 LLM 智能体中使用（例如 OpenAI Codex、Claude Code、OpenCode / Pi 等）。它的目标是传达高层设计思想，而你的智能体将在与你协作的过程中，共同完善具体实现细节。

核心理念

大多数人与 LLM 和文档的交互体验都停留在 RAG（检索增强生成）模式：你上传一批文件，LLM 在查询时检索相关片段，然后生成答案。这种方式可行，但 LLM 每次回答问题都要从零开始重新「发现」知识，无法实现积累。如果你问一个需要综合五份文档才能回答的细微问题，LLM 每次都不得不重新查找并拼凑相关片段——没有任何知识被沉淀下来。NotebookLM、ChatGPT 的文件上传功能，以及大多数 RAG 系统，都是这样工作的。

而本文提出的思路截然不同：我们不是仅在查询时从原始文档中检索，而是让 LLM 增量式地构建并维护一个持久化的 Wiki——一个位于你与原始资料之间的、结构化的、相互链接的 Markdown 文件集合。当你添加新资料时，LLM 不只是将其索引以备后续检索，而是会主动阅读、提取关键信息，并将其整合进现有的 Wiki 中：更新实体页面、修订主题摘要、标注新数据与旧结论的矛盾之处、强化或挑战正在演进的综合性认知。知识被编译一次，随后持续更新，而非每次查询都重新推导。

这才是关键区别：Wiki 是一个持久存在、可复利增长的知识产物。交叉引用已经建立，矛盾点已被标记，综合结论已涵盖你读过的所有内容。每添加一份资料、每提出一个问题，Wiki 都会变得更丰富。

你几乎不需要（或极少）亲手撰写 Wiki——LLM 负责全部内容的编写与维护。你的职责是筛选资料、探索方向、提出好问题；而 LLM 承担所有繁琐工作：摘要、交叉引用、归档、记录——正是这些让知识库随时间推移真正变得有用。实践中，我通常一侧打开 LLM 智能体对话窗口，另一侧打开 Obsidian。LLM 根据我们的对话实时编辑内容，而我则在 Obsidian 中即时浏览结果：追踪链接、查看图谱视图、阅读更新后的页面。Obsidian 是 IDE，LLM 是程序员，Wiki 就是代码库。

适用场景

这一模式可应用于多种情境，例如：

  • 个人成长：追踪目标、健康、心理、自我提升——归档日记、文章、播客笔记，随时间构建关于自己的结构化认知图谱。
  • 学术研究：对某一主题进行数周或数月的深度探索——阅读论文、文章、报告，逐步构建一个包含演进性论点的综合性 Wiki。
  • 阅读书籍：边读边归档每一章，为人物、主题、情节线及其关联建立独立页面。读完后，你将拥有一份丰富的伴读 Wiki。想象一下像「托尔金百科」（Tolkien Gateway）那样的粉丝维基——数千个相互链接的页面涵盖人物、地点、事件、语言，由志愿者社区经年累月共建。你完全可以借助 LLM 自动完成交叉引用与维护，在个人阅读过程中构建类似的知识体系。
  • 团队/企业：由 LLM 维护的内部 Wiki，输入源包括 Slack 讨论、会议纪要、项目文档、客户访谈等，可辅以人工审核更新。因为无人愿意承担的维护工作交由 LLM 完成，Wiki 才能始终保持最新。
  • 其他场景：竞品分析、尽职调查、旅行规划、课程笔记、爱好深研……任何你需要随时间积累知识、并希望其有序组织而非零散分布的场景。

架构设计

整个系统分为三层：

  1. 原始资料层（Raw sources）
    你 curated（精选整理）的源文档集合：文章、论文、图片、数据文件等。这些内容是不可变的——LLM 只读取，从不修改。这是你的「单一事实来源」（source of truth）。

  2. Wiki 层
    由 LLM 生成的 Markdown 文件目录：摘要页、实体页、概念页、对比分析、综述、综合论述等。这一层完全由 LLM 所有：它创建页面、在新资料加入时更新内容、维护交叉引用、确保整体一致性。你负责阅读，LLM 负责撰写。

  3. 模式规范层（The schema）
    一份配置文档（例如给 Claude Code 的 CLAUDE.md，或给 Codex 的 AGENTS.md），用于告诉 LLM：Wiki 的结构如何组织、遵循哪些约定、在处理资料、回答问题或维护 Wiki 时应执行哪些工作流。这是关键配置文件——它让 LLM 成为一个有纪律的 Wiki 维护者，而非通用聊天机器人。你与 LLM 将随着实践深入，共同迭代演化这份规范，使其更契合你的领域需求。

核心操作流程

📥 资料摄入（Ingest）

你将新资料放入 raw/ 集合，并指令 LLM 进行处理。典型流程如下：LLM 阅读资料 → 与你讨论关键要点 → 在 Wiki 中撰写摘要页 → 更新索引 → 更新相关的实体页与概念页 → 在日志中追加记录。一份资料可能联动更新 10–15 个 Wiki 页面。

我个人偏好逐份摄入并保持参与：我会阅读摘要、检查更新、引导 LLM 关注重点。但你也可以选择在较少监督下批量摄入多份资料。关键在于：找到适合你风格的流程，并将其记录在 schema 中，供后续会话复用。

❓ 查询问答（Query）

你针对 Wiki 提出问题。LLM 会搜索相关页面、阅读内容，并综合生成带引用的答案。答案形式可依问题灵活变化：Markdown 页面、对比表格、幻灯片（Marp 格式）、图表（matplotlib）、画布等。

关键洞察：优质的答案可以反哺回 Wiki，作为新页面归档。你请求的对比分析、你发现的新关联、你完成的深度解读——这些都有价值，不应消失在聊天记录中。如此，你的每一次探索，都能像新摄入的资料一样，在知识库中持续复利增长。

🧹 健康检查（Lint）

定期请 LLM 对 Wiki 进行「体检」，关注以下方面：

  • 页面间的矛盾陈述
  • 已被新资料推翻的过时结论
  • 无入链的孤立页面（orphan pages）
  • 被多次提及但尚无独立页面的重要概念
  • 缺失的交叉引用
  • 可通过网络搜索补全的数据缺口

LLM 擅长主动建议值得探究的新问题、值得追踪的新资料源。这能确保 Wiki 在规模增长的同时保持健康。

索引与日志：两个导航辅助文件

随着 Wiki 规模扩大，两个特殊文件可帮助 LLM（和你）高效导航：

  • index.md（内容导向）
    Wiki 的内容目录：列出每个页面的链接、一句话摘要，可选附加元数据（如日期、来源数量）。按类别组织（实体、概念、资料等）。每次资料摄入后，LLM 都会更新它。回答查询时，LLM 先读索引定位相关页面，再深入查阅。在中等规模下（约 100 份资料、数百页面），这种方式效果出奇地好，无需依赖基于向量嵌入的 RAG 基础设施。

  • log.md（时间导向）
    仅追加的事件日志：记录每次摄入、查询、健康检查的时间与内容。实用技巧：若每条记录以统一前缀开头（如 ## [2026-04-02] ingest | 文章标题），即可用简单 Unix 工具解析——例如 grep "^## \[" log.md | tail -5 可快速查看最近 5 条记录。日志为你呈现 Wiki 的演进时间线，也帮助 LLM 理解近期已完成的工作。

可选扩展：CLI 工具链

当 Wiki 规模进一步扩大，你可能希望构建小型工具，帮助 LLM 更高效地操作 Wiki。最典型的是站内搜索引擎：小规模时 index.md 已足够，但规模增长后需要更专业的搜索能力。

推荐工具：qmd——一款本地 Markdown 文件搜索引擎，支持混合 BM25/向量检索 + LLM 重排序，全部离线运行。它同时提供 CLI（供 LLM 通过 shell 调用）和 MCP Server（供 LLM 作为原生工具集成）。当然，你也可以用 LLM 辅助「vibe coding」快速写一个简易搜索脚本，按需迭代。

实用技巧与工具推荐

  • Obsidian Web Clipper：浏览器插件，可将网页文章一键转为 Markdown，极大提升资料入库效率。
  • 本地保存图片：在 Obsidian 设置 → 文件和链接 中，将「附件默认存放路径」设为固定目录（如 raw/assets/）；再在 快捷键 中搜索「Download」，为「下载当前文件的附件」绑定快捷键（如 Ctrl+Shift+D）。剪藏文章后按下快捷键，所有图片即自动下载至本地。虽非必需，但强烈建议：这能让 LLM 直接查看和引用图片，避免依赖可能失效的外链。注：当前 LLM 无法单次读取含内联图片的 Markdown，变通方案是让 LLM 先读文本，再按需单独查看相关图片以补充上下文——虽稍显繁琐，但效果足够好。
  • 图谱视图（Graph View）：Obsidian 原生功能，是观察 Wiki 结构形态的最佳方式：哪些页面相互连接、哪些是枢纽、哪些是孤立点，一目了然。
  • Marp：基于 Markdown 的幻灯片格式，Obsidian 有官方插件。适合直接将 Wiki 内容生成演示文稿。
  • Dataview：Obsidian 插件，可基于页面 Frontmatter（YAML 元数据）执行查询。若你的 LLM 在生成页面时自动添加标签、日期、来源数等元数据，Dataview 就能动态生成表格与列表。
  • 版本控制友好：Wiki 本质就是一个存 Markdown 文件的 Git 仓库，天然支持版本历史、分支协作，零成本获得工程级能力。

为什么这个方法有效？

维护知识库最耗人的部分，从来不是阅读或思考，而是事务性维护：更新交叉引用、保持摘要时效性、标注新旧结论冲突、确保数十页面间的一致性……人类放弃维护 Wiki，往往因为维护成本增速远超其带来的价值。而 LLM 不会厌倦、不会遗漏更新、能单次操作 15 个文件。因为维护成本趋近于零，Wiki 才能持续保持鲜活。

  • 人的角色：筛选资料、引导分析、提出好问题、思考整体意义。
  • LLM 的角色：其余一切——执行、归档、链接、校验、迭代。

思想渊源

这一理念在精神上呼应了 Vannevar Bush 的 Memex 构想（1945）：一个个人化、精心策展的知识存储系统，文档之间通过「联想轨迹」（associative trails）相互关联。Bush 的愿景更接近本文方案，而非后来演化的开放互联网——它是私有的、主动维护的，文档间的连接本身与文档内容同等重要。他当年未能解决的难题是：「谁来承担维护工作？」如今，LLM 接过了这一职责。

重要说明

本文档刻意保持抽象，描述的是模式（pattern）而非具体实现。确切的目录结构、schema 约定、页面格式、工具选型……都将取决于你的领域、偏好与所选 LLM。上文提及的所有组件均为可选且模块化的：取你所需，弃你不用。

例如：若你的资料纯文本，就无需处理图片；若 Wiki 规模很小，index.md 已足够，无需额外搜索引擎；若你只想要 Markdown 页面，可忽略幻灯片输出；若你需要完全不同的输出格式，完全可以自定义。

正确使用方式是：将本文档分享给你的 LLM 智能体，与它协作，实例化出一个契合你需求的版本。本文档的唯一使命，是清晰传达这一模式。其余细节，你的 LLM 自会与你共同推演完善。

原文