L1ngg's Home

作者简介：Andrej Karpathy 是谁？#

对于关注人工智能发展的开发者来说，Andrej Karpathy 是无需过多介绍的先驱与导师级人物：

• OpenAI 联合创始人与创始研究员：深度参与早期技术探索与大模型浪潮。
• 前特斯拉（Tesla）人工智能与 Autopilot 总监：领导了 Tesla 自动驾驶视觉感知与神经架构的全面重构。
• 斯坦福大学经典课程 CS231n 主讲人：启发了全球整整一代深度学习工程师。
• 知名开源技术布道者：从纯 C 实现的 llama2.c / llm.c，到近年来风靡的技术概念「vibe coding」，Karpathy 始终站在用极简、深刻的代码和心智模型解构复杂系统的最前沿。

文章概要：LLM Wiki 究竟讲了什么？#

当人们使用 ChatGPT 文件上传、NotebookLM 或企业级 RAG 时，流程大多是：上传文档 $\rightarrow$ 提问 $\rightarrow$ 检索切片 $\rightarrow$ 临时生成答案。

Karpathy 敏锐地指出了这种模式的瓶颈：没有积累。系统每次都在“从零重新推导”，昨天的洞察与今天的资料彼此孤立，跨文档的矛盾与关联无法沉淀。

作为替代，Karpathy 提出了 LLM Wiki 模式：

1. 持久化中间层：LLM 不再只是检索器，而是负责构建和维护一组相互链接的 Markdown 文件（Wiki 层）。
2. 三层分工明确的架构：
   • 原始资料（Raw sources）：只读不可变的事实锚点。
   • Wiki 页面：LLM 编写的实体、概念、对比与综合分析，随新资料持续演进。
   • 规范（Schema）：如 CLAUDE.md 或 AGENTS.md，定义工作流与代码约定。
3. 生动的类比：

   Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。
   人类负责精选素材、提出好问题并阅读成果；LLM 则包揽总结、打标签、建立交叉链接、解决矛盾与清理归档等繁重劳动。

以下为该文的完整中文翻译。

核心想法#

大多数人使用 LLM 处理文档的体验，都类似于 RAG：上传一批文件，LLM 在你提问时检索相关片段，然后生成答案。这种方式能用，但每遇到一个问题，LLM 都在从头重新发现知识，没有积累。如果你提出一个需要综合五份文档才能回答的细致问题，LLM 每次都得重新找出并拼接相关片段，之前的工作没有沉淀下来。NotebookLM、ChatGPT 的文件上传功能，以及大多数 RAG 系统，都是这样工作的。

这里的想法有所不同。LLM 不只在查询时检索原始文档，而是逐步构建并维护一个持久保存的 Wiki：一组结构化、相互链接的 Markdown 文件，位于你与原始资料之间。加入新资料时，LLM 不只是为它建立索引，留待以后检索。它会阅读资料，提取关键信息，并将其整合进现有 Wiki：更新实体页面、修订主题摘要、标记新资料与旧有论断相矛盾的地方，并补强或质疑不断演进的综合分析。知识经过一次编纂后，会被持续更新，而不是每次查询都重新推导。

这就是关键区别：Wiki 是一个持久保存、价值不断累积的成果。 交叉引用已经建立，矛盾已经标记，综合分析已经反映了你读过的所有内容。你每加入一份资料、每提出一个问题，Wiki 都会变得更加丰富。

你从不，或者很少，亲自编写 Wiki——所有内容都由 LLM 编写和维护。你负责搜集资料、探索问题，以及提出恰当的问题。LLM 则承担所有繁琐工作：总结、建立交叉引用、归档，以及各种整理维护。这些工作使知识库能够随着时间推移真正发挥作用。实际使用时，我会在一边打开 LLM Agent，另一边打开 Obsidian。LLM 根据我们的对话修改内容，我则实时浏览结果：沿着链接阅读、查看图谱视图、阅读更新后的页面。Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。

这种模式可以用于许多不同场景。例如：

• 个人生活：记录自己的目标、健康、心理状态和自我提升过程——归档日记、文章和播客笔记，随着时间推移，逐步形成对自己的结构化认识。
• 研究：用数周或数月深入研究一个主题——阅读论文、文章和报告，逐步构建内容全面的 Wiki，并不断发展自己的核心论点。
• 阅读一本书：边读边归档各章内容，为人物、主题、情节线索及其联系建立页面。读完时，你就有了一份内容丰富的配套 Wiki。可以想想 Tolkien Gateway 这样的粉丝 Wiki：志愿者社区花费多年时间，建立了数千个相互链接的页面，涵盖人物、地点、事件和语言。你也可以在阅读过程中为自己构建类似的东西，让 LLM 完成所有交叉引用和维护工作。
• 企业／团队：由 LLM 维护内部 Wiki，资料来自 Slack 讨论串、会议转录、项目文档和客户通话记录，也可以让人参与审核更新。Wiki 能保持最新，是因为 LLM 承担了团队里没有人愿意做的维护工作。
• 竞品分析、尽职调查、旅行规划、课程笔记、深入探索兴趣爱好：只要你在不断积累知识，并希望把它们组织起来，而不是任其散落，都可以使用这种模式。

架构#

共有三层：

原始资料（Raw sources）：你精选并收集的源文档，包括文章、论文、图片和数据文件。这些资料不可变：LLM 可以读取，但绝不修改。它们是你的事实依据。

Wiki：一个存放 LLM 生成的 Markdown 文件的目录，其中包含摘要、实体页面、概念页面、比较分析、总览和综合分析。这一层完全由 LLM 负责。它创建页面，在新资料到来时更新页面，维护交叉引用，并保持各处内容一致。你负责阅读，LLM 负责编写。

规范（Schema）：一份文档，例如 Claude Code 使用的 CLAUDE.md，或 Codex 使用的 AGENTS.md。它告诉 LLM：Wiki 如何组织、有哪些约定，以及在导入资料、回答问题和维护 Wiki 时应遵循哪些工作流程。这是最关键的配置文件，让 LLM 成为遵循规范的 Wiki 维护者，而不只是一个通用聊天机器人。随着你逐渐弄清哪些做法适合自己的领域，你和 LLM 会共同演进这份规范。

操作#

导入（Ingest）。 你把一份新资料放进原始资料集合，并让 LLM 处理。一个示例流程是：LLM 阅读资料，与你讨论要点，在 Wiki 中写一篇摘要，更新索引，更新 Wiki 中相关的实体页面和概念页面，最后向日志追加一条记录。一份资料可能涉及 10–15 个 Wiki 页面的修改。我个人更喜欢一次导入一份资料，并参与其中：阅读摘要、检查更新，指导 LLM 应重点关注什么。你也可以一次批量导入多份资料，减少人工参与。你需要形成适合自己的工作流程，并将它记录在规范中，供后续会话遵循。

查询（Query）。 你针对 Wiki 提问。LLM 搜索相关页面，阅读内容，再综合生成带引用的答案。答案可以根据问题采用不同形式：Markdown 页面、对比表格、幻灯片（Marp）、图表（matplotlib）或画布。这里重要的一点是：好的答案可以作为新页面存回 Wiki。 你要求完成的一次比较、一份分析，或你发现的一种联系，都有价值，不应该消失在聊天历史里。这样，你的探索成果就会像导入的资料一样，在知识库中不断积累。

检查（Lint）。 定期让 LLM 检查 Wiki 的健康状况，查找以下问题：页面之间的矛盾、已被新资料取代的过时论断、没有任何入链的孤立页面、被提及却没有独立页面的重要概念、缺失的交叉引用，以及可以通过网络搜索补足的资料空白。LLM 擅长建议值得继续调查的新问题，以及值得寻找的新资料。这能让 Wiki 在不断增长的过程中保持健康。

索引与日志#

随着 Wiki 不断增长，有两个特殊文件可以帮助 LLM 和你浏览其中的内容。它们各有用途：

index.md 面向内容。它是 Wiki 的总目录：每个页面都有一个链接、一句话摘要，还可以附带日期或来源数量等元数据。目录按类别组织，例如实体、概念和资料。每次导入资料时，LLM 都会更新它。回答问题时，LLM 先阅读索引，找到相关页面，再深入阅读。在中等规模下——大约 100 份资料、数百个页面——这种方式的效果出乎意料地好，也省去了搭建基于 embedding 的 RAG 基础设施的需要。

log.md 按时间顺序组织。它是一份只追加、不改写的记录，记载什么时候发生了什么，包括资料导入、查询和检查。一个实用技巧是：让每条记录都以统一格式开头，例如 ## [2026-04-02] ingest | Article Title，这样就能用简单的 Unix 工具解析日志。比如，grep "^## \[" log.md | tail -5 会给出最近五条记录。日志呈现了 Wiki 的演进时间线，也帮助 LLM 了解最近做过什么。

可选：CLI 工具#

到某个阶段，你可能会想开发一些小工具，帮助 LLM 更高效地操作 Wiki。最明显的例子就是 Wiki 页面搜索引擎：规模小时，索引文件就足够了；但随着 Wiki 增长，你会需要更完善的搜索能力。qmd 是一个不错的选择：它是面向 Markdown 文件的本地搜索引擎，结合 BM25、向量搜索和 LLM 重排，全部在本机运行。它既提供 CLI，让 LLM 可以通过 shell 调用，也提供 MCP server，让 LLM 可以把它当作原生工具使用。你也可以自己做一个更简单的工具：有需要时，让 LLM 帮你通过 vibe coding 写一个基础搜索脚本。

提示与技巧#

• Obsidian Web Clipper 是一个浏览器扩展，可以把网页文章转换为 Markdown。它非常适合快速把资料加入原始资料集合。
• 把图片下载到本地。 在 Obsidian 的 Settings → Files and links 中，把 “Attachment folder path” 设置为固定目录，例如 raw/assets/。然后进入 Settings → Hotkeys，搜索 “Download”，找到 “Download attachments for current file”，为它绑定一个快捷键，例如 Ctrl+Shift+D。剪藏文章后，按下快捷键，就会把所有图片下载到本地。这一步可选，但很有用：LLM 可以直接查看和引用图片，而不必依赖可能失效的 URL。需要注意的是，LLM 无法原生地在一次读取中同时读懂 Markdown 文本及其内嵌图片。一个变通办法是让 LLM 先读取文本，再单独查看部分或全部引用图片，补充上下文。这有些笨拙，但效果足够好。
• Obsidian 的图谱视图 最适合用来观察 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 相通：一个由个人精选和维护的知识存储，文档之间有相互关联的路径。Bush 的设想与这里描述的模式，比与后来实际形成的 Web 更接近：私有、主动维护，而且文档之间的联系与文档本身同样有价值。他没有解决的部分，是由谁来维护。现在由 LLM 来承担。

说明#

本文有意保持抽象。它描述的是想法，而不是某个具体实现。确切的目录结构、规范约定、页面格式和工具选择，都取决于你的领域、偏好以及所选的 LLM。上面提到的所有内容都是可选且模块化的：选取有用的部分，忽略不适合你的部分。例如，你的资料可能只有文本，那么就不需要图片处理；你的 Wiki 可能足够小，只用索引文件就够了，完全不需要搜索引擎；你可能不关心幻灯片，只想要 Markdown 页面；也可能需要完全不同的输出格式。正确的使用方式，是把这份文档分享给你的 LLM Agent，与它一起构建一个符合你需求的版本。本文唯一的任务是传达这种模式，剩下的细节可以由你的 LLM 来解决。

1. 计算范式转移：从“查询时推导”到“入库时编译”#

传统 RAG 与 LLM Wiki 的本质区别，可以用编译器原理做类比：

传统 RAG 就像解释型脚本语言，每次提问都在实时运行解释器；而 LLM Wiki 则像是预编译（Ahead-of-Time Compilation）：在资料录入阶段，Agent 就已经完成了分词、语法分析、符号表建立（index.md）和引用链接（Wiki Links），将非结构化文档“编译”成了结构化、高密度的知识图谱。

当你真正发起 Query 时，Agent 面对的不再是杂乱无章的几百篇生语料，而是一个已经被梳理过的结构化索引。这种架构的推理质量与 token 效率，远高于在查询时临时调用长上下文硬算。

2. 破除知识管理的“熵增死局”#

任何尝试过用 Notion、Obsidian 或 Logseq 构建知识库的人，都绕不开一个宿命：知识库的消亡从来不是因为缺乏优质信息，而是死于维护负担的熵增。

• 我们擅长收集：浏览器插件一键剪藏，几天就能攒出上百篇优秀文章；
• 我们厌恶整理：每加一篇新文章，需要给相关页面打标签、更新旧摘要、建立反向链接、检查与两年前某个论断的冲突。

这正是 Karpathy 所说的：“人们放弃 Wiki，是因为维护负担增长得比价值更快。”

「Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库」这个比喻之所以击中靶心，是因为它真正把 LLM 的比较优势发挥到了极致：

• LLM 擅长无休止的模式匹配、格式对齐和批量文件修改（批处理 15 个关联 Markdown 毫不费力）；
• 人类则专注在最擅长的高阶抽象——选题、审美、价值判断和关键问题定义。

这种分工重构让维护知识库的边际阻力几乎归零。

3. 去中心化架构的哲学：Markdown + 规范文件#

在 AI 产品越来越倾向于把数据锁在封闭云端（如各类 AI 记事本应用）的今天，Karpathy 坚持采用极其朴素的方案：

• 存储介质：本地 Markdown 文件 + Git 版本控制
• 路由机制：index.md + log.md + 纯文本/BM25 检索
• 智能驱动：项目级规范文件（如 AGENTS.md / CLAUDE.md）

这种选择看似“复古”，实则具备巨大的工程韧性：

1. 防供应商锁定（Lock-in Free）：模型会迭代，Claude 3.5 换成 3.7，或者切换到本地开源模型，Wiki 依然是一套干净的 Markdown 文件，完全不需要重新建库或迁移数据库。
2. Git 是天生的防腐层：Agent 一次性修改了十几个文件，只要敲一个 git diff，变更一目了然。你可以像 Code Review 一样审查 Agent 对你世界观的改动，随时回滚。
3. 极低的基础设施包袱：不需要维护 Docker、向量数据库（pgvector/milvus）或复杂的 Python 检索服务，一个简单的 CLI 工具（甚至单机 shell 脚本）就能驱动。

4. 落地实践中的真实挑战#

尽管愿景极具吸引力，在真正落地 LLM Wiki 时，仍有几个现实问题需要解决：

1. 级联幻觉与静默漂移（Silent Drift）：
   如果 Agent 在某次 Ingest 过程中出现事实理解偏差，并将错误论断写进了核心概念页，未来的新资料导入和查询就会把这个错误页面当作“基石真实”继续演绎，导致知识库出现“静默漂移”。
   对策：必须坚决执行 Karpathy 强调的 Raw sources 不可变 原则，任何 Wiki 结论必须附带可追溯到 Raw Sources 的显式引用，并在 Ingest 后由人快速浏览 Diff。
2. Token 消耗与调用延迟：
   一次 Ingest 修改 10–15 个文件，意味着多轮 Agentic Tool Loop（读取索引 $\rightarrow$ 读取实体 $\rightarrow$ 编辑页面 $\rightarrow$ 追加日志），单次成本可能在几美分到数毛钱不等。对于高频信息流，需要设置过滤漏斗，只把高价值的长青知识（Evergreen Notes）送入 Wiki 编译流程。
3. 模式扩展：团队级知识治理：
   团队协作最头疼的不是缺少文档，而是“文档写完即过时”。如果把 LLM Wiki 的理念搬到工程团队中：以 Git 仓库为中枢，将 Slack 讨论、RFC、PR 描述作为 Ingestion 源，由定时触发的 CI Agent 运行 Lint，自动标记过时接口与冲突设计，或许能真正终结“文档墓地”的行业顽疾。