2026-04-04 Andrej Karpathy.LLM Wiki

Refer To：《2026-04-04 Andrej Karpathy.LLM Wiki》。

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

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

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

这是一个想法文件，设计用途是复制粘贴到你自己的 LLM 代理中，例如 OpenAI Codex、Claude Code、OpenCode / Pi 等。它的目标是传达高层次的想法，具体实现则由你的代理与你协作完成。

The core idea

核心想法

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

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

The idea here is different. Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then kept current, not re-derived on every query.

这里的想法不同。它不是只在提问时从原始文档中检索，而是让 LLM 逐步构建并维护一个持久的 wiki——一组结构化、相互链接的 Markdown 文件，位于你和原始资料之间。当你加入一个新的资料来源时，LLM 不只是把它索引起来以便以后检索。它会阅读资料，提取关键信息，并将其整合到现有 wiki 中——更新实体页面，修订主题摘要，标记新数据与旧判断相矛盾的地方，强化或挑战正在演化的综合判断。知识被编译一次，然后持续保持更新，而不是每次提问都重新推导。

This is the key difference: the wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add and every question you ask.

这就是关键区别：wiki 是一个持久的、能够复利积累的成果物。交叉引用已经在那里。矛盾已经被标记。综合判断已经反映了你读过的一切。随着你加入每一个资料来源、提出每一个问题，wiki 都会变得更加丰富。

You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time. In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

你从不，或者很少，自己写 wiki——LLM 负责写作并维护全部内容。你负责资料来源、探索方向，以及提出正确的问题。LLM 负责所有繁重杂活——总结、交叉引用、归档、记账，这些工作才使知识库随着时间推移真正有用。实际使用中，我一边打开 LLM 代理，另一边打开 Obsidian。LLM 根据我们的对话进行编辑，我实时浏览结果——顺着链接查看、检查图谱视图、阅读更新后的页面。Obsidian 是集成开发环境；LLM 是程序员；wiki 是代码库。

This can apply to a lot of different contexts. A few examples:

这可以应用于许多不同场景。几个例子如下：

Personal: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.

个人用途：追踪你自己的目标、健康、心理、自我改进——归档日记、文章、播客笔记，并随着时间推移建立一个关于你自己的结构化图景。

Research: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive wiki with an evolving thesis.

研究用途：在数周或数月内深入研究一个主题——阅读论文、文章、报告，并逐步构建一个带有演化中论点的综合性 wiki。

Reading a book: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect. By the end you have a rich companion wiki. Think of fan wikis like Tolkien Gateway — thousands of interlinked pages covering characters, places, events, languages, built by a community of volunteers over years. You could build something like that personally as you read, with the LLM doing all the cross-referencing and maintenance.

读一本书：边读边归档每一章，为人物、主题、情节线索以及它们之间的连接建立页面。读到最后，你会得到一个丰富的伴读 wiki。可以想象 Tolkien Gateway 这样的粉丝 wiki——数千个相互链接的页面，覆盖人物、地点、事件、语言，由志愿者社区多年建设而成。你也可以在个人阅读过程中构建类似的东西，由 LLM 负责所有交叉引用和维护工作。

Business/team: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop reviewing updates. The wiki stays current because the LLM does the maintenance that no one on the team wants to do.

商业或团队用途：由 LLM 维护的内部 wiki，输入来自 Slack 讨论串、会议记录、项目文档、客户电话。可以让人类参与流程，对更新进行审阅。wiki 能够保持最新，因为 LLM 会完成团队中没人愿意做的维护工作。

Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives — anything where you're accumulating knowledge over time and want it organized rather than scattered.

竞争分析、尽职调查、旅行规划、课程笔记、兴趣爱好的深入研究——任何你在长期积累知识，并希望它被组织起来而不是散落各处的场景。

Architecture

架构

There are three layers:

它有三层：

Raw sources — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.

原始资料——你精心整理的源文档集合。文章、论文、图片、数据文件。这些资料是不可变的——LLM 可以读取它们，但绝不修改它们。这是你的事实来源。

The wiki — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.

wiki——一个由 LLM 生成的 Markdown 文件目录。包括摘要、实体页面、概念页面、比较、概览、综合分析。LLM 完全负责这一层。它创建页面，在新资料加入时更新页面，维护交叉引用，并保持整体一致。你阅读它；LLM 写作它。

The schema — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain.

规则文件——一个文档，例如 Claude Code 使用的 CLAUDE.md，或 Codex 使用的 AGENTS.md，用来告诉 LLM 这个 wiki 如何组织、有哪些约定，以及在导入资料、回答问题或维护 wiki 时应遵循什么工作流。这是关键配置文件——它让 LLM 成为一个有纪律的 wiki 维护者，而不是一个通用聊天机器人。你和 LLM 会随着时间一起演化这个规则文件，逐步弄清楚什么适合你的领域。

Operations

操作

Ingest. You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It's up to you to develop the workflow that fits your style and document it in the schema for future sessions.

导入。你把一个新资料放进原始资料集合，然后告诉 LLM 处理它。一个示例流程是：LLM 阅读资料，与你讨论关键收获，在 wiki 中写一个摘要页面，更新索引，更新 wiki 中相关的实体页面和概念页面，并在日志中追加一条记录。一个单一资料可能会影响 10–15 个 wiki 页面。就我个人而言，我更喜欢一次导入一个资料，并保持参与——我阅读摘要，检查更新，并指导 LLM 应该强调什么。但你也可以一次批量导入很多资料，减少监督。你需要根据自己的风格发展出合适的工作流，并把它记录到规则文件中，供未来会话使用。

Query. You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: good answers can be filed back into the wiki as new pages. A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.

查询。你基于 wiki 提问。LLM 搜索相关页面，阅读它们，并生成带引用的综合答案。答案可以根据问题采取不同形式——一个 Markdown 页面、一张比较表、一个幻灯片文稿（Marp）、一张图表（matplotlib）、一个画布。重要的洞见是：好的答案可以作为新页面重新归档到 wiki 中。你要求做的一次比较、一项分析、你发现的一种连接——这些都有价值，不应该消失在聊天历史中。这样，你的探索也会像导入资料一样在知识库中复利积累。

Lint. Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.

检查。定期让 LLM 对 wiki 做健康检查。需要查找的问题包括：页面之间的矛盾；已经被较新资料替代的过时判断；没有入站链接的孤立页面；被提到但没有独立页面的重要概念；缺失的交叉引用；可以通过网络搜索补齐的数据缺口。LLM 擅长提出新的调查问题和需要寻找的新资料。这能让 wiki 在增长过程中保持健康。

Indexing and logging

索引与日志

Two special files help the LLM (and you) navigate the wiki as it grows. They serve different purposes:

两个特殊文件会帮助 LLM 和你在 wiki 增长过程中导航。它们用途不同：

index.md is content-oriented. It's a catalog of everything in the wiki — each page listed with a link, a one-line summary, and optionally metadata like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.

index.md 面向内容。它是 wiki 中所有内容的目录——每个页面都有一个链接、一行摘要，也可以附带日期或资料数量等元数据。它按类别组织，例如实体、概念、资料来源等。LLM 在每次导入时更新它。回答问题时，LLM 先阅读索引，找到相关页面，然后深入阅读。这在中等规模下效果出奇地好，例如大约 100 个资料来源、数百个页面，并且避免了对基于嵌入的 RAG 基础设施的需求。

log.md is chronological. It's an append-only record of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. ## [2026-04-02] ingest | Article Title), the log becomes parseable with simple unix tools — grep "^## [" log.md | tail -5 gives you the last 5 entries. The log gives you a timeline of the wiki's evolution and helps the LLM understand what's been done recently.

log.md 按时间排序。它是只追加不修改的记录，记录发生了什么以及什么时候发生——导入、查询、检查。一个有用技巧是：如果每条记录都以一致前缀开头，例如 ## [2026-04-02] ingest | Article Title，日志就可以用简单的 Unix 工具解析——grep "^## \[" log.md | tail -5 可以得到最近 5 条记录。日志给你一条 wiki 演化的时间线，也帮助 LLM 理解最近已经做过什么。

Optional: CLI tools

可选：命令行工具

At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. qmd is a good option: it's a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server (so the LLM can use it as a native tool). You could also build something simpler yourself — the LLM can help you vibe-code a naive search script as the need arises.

到某个阶段，你可能会想构建一些小工具，帮助 LLM 更高效地操作 wiki。最显然的是为 wiki 页面建立搜索引擎——在小规模时，索引文件已经足够，但随着 wiki 增长，你会需要真正的搜索。qmd 是一个不错的选择：它是面向 Markdown 文件的本地搜索引擎，支持 BM25 / 向量混合搜索和 LLM 重新排序，全部在设备本地运行。它既有命令行界面，方便 LLM 通过 shell 调用，也有 MCP 服务器，使 LLM 能把它作为原生工具使用。你也可以自己构建更简单的工具——随着需要出现，LLM 可以帮助你用氛围编程的方式写一个朴素搜索脚本。

MinerU Document Explorer在QMD的基础上做了扩展。

1、MinerU在PDF的提取能力上仅次于LlamaIndex，是一款国产软件，并且是免费的；

2、QMD的作者是Shopify的CEO。

Karpathy的想法出来后，Github上已经有很多的实践，我们研究股票的系统也把底层框架换成了LLM Wiki。

Tips and tricks

技巧与窍门

Obsidian Web Clipper is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection.

Obsidian Web Clipper 是一个浏览器扩展，可以把网页文章转换成 Markdown。它对于快速把资料放进原始资料集合非常有用。

Download images locally. In Obsidian Settings → Files and links, set "Attachment folder path" to a fixed directory (e.g. raw/assets/). Then in Settings → Hotkeys, search for "Download" to find "Download attachments for current file" and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping an article, hit the hotkey and all images get downloaded to local disk. This is optional but useful — it lets the LLM view and reference images directly instead of relying on URLs that may break. Note that LLMs can't natively read markdown with inline images in one pass — the workaround is to have the LLM read the text first, then view some or all of the referenced images separately to gain additional context. It's a bit clunky but works well enough.

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

Obsidian's graph view is the best way to see the shape of your wiki — what's connected to what, which pages are hubs, which are orphans.

Obsidian 的图谱视图是观察 wiki 形态的最佳方式——哪些内容与哪些内容连接，哪些页面是枢纽，哪些页面是孤岛。

Marp is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from wiki content.

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

Dataview is an Obsidian plugin that runs queries over page frontmatter. If your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts), Dataview can generate dynamic tables and lists.

Dataview 是一个 Obsidian 插件，可以基于页面头部元数据运行查询。如果你的 LLM 给 wiki 页面添加 YAML 头部信息，例如标签、日期、资料数量，Dataview 就可以生成动态表格和列表。

The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free.

wiki 只是一个由 Markdown 文件组成的 git 仓库。你天然获得版本历史、分支和协作能力。

Why this works

为什么这种方式有效

The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.

维护知识库中最乏味的部分不是阅读或思考——而是记账式维护。更新交叉引用，保持摘要最新，标记新数据何时与旧判断矛盾，在几十个页面之间维持一致性。人类放弃 wiki，是因为维护负担增长得比价值更快。LLM 不会厌烦，不会忘记更新交叉引用，并且可以一次处理 15 个文件。wiki 能够持续维护，是因为维护成本接近于零。

The human's job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM's job is everything else.

人类的工作是筛选资料来源，指导分析方向，提出好问题，并思考这些内容究竟意味着什么。其余所有工作都是 LLM 的工作。

The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush's vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn't solve was who does the maintenance. The LLM handles that.

这个想法在精神上与 Vannevar Bush 在 1945 年提出的 Memex 有关——一个个人化、经筛选的知识存储系统，在文档之间拥有联想路径。Bush 的愿景比后来的网络更接近这里的模式：私有、主动整理，并且文档之间的连接与文档本身同样有价值。他当时无法解决的问题是：谁来维护。LLM 解决了这一点。

Note

说明

This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice. Everything mentioned above is optional and modular — pick what's useful, ignore what isn't. For example: your sources might be text-only, so you don't need image handling at all. Your wiki might be small enough that the index file is all you need, no search engine required. You might not care about slide decks and just want markdown pages. You might want a completely different set of output formats. The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document's only job is to communicate the pattern. Your LLM can figure out the rest.

本文档有意保持抽象。它描述的是想法，而不是某个具体实现。确切的目录结构、规则约定、页面格式、工具链——所有这些都取决于你的领域、你的偏好，以及你选择的 LLM。上面提到的一切都是可选且模块化的——选择有用的，忽略没用的。例如：你的资料可能全是文本，所以完全不需要图片处理。你的 wiki 可能足够小，只靠索引文件就够，不需要搜索引擎。你可能不关心幻灯片，只想要 Markdown 页面。你可能想要一套完全不同的输出格式。正确的使用方式，是把它分享给你的 LLM 代理，并共同实例化一个适合你需求的版本。这个文档唯一的工作，就是传达这种模式。其余部分，你的 LLM 可以自己弄清楚。

2026-04-04 Andrej Karpathy.LLM Wiki

2026-04-04 Andrej Karpathy.LLM Wiki

The core idea

Architecture

Operations

Why this works

热门主题

Recent Articles

2026-04-04 Andrej Karpathy.LLM Wiki

2026-04-28 潘乱.从红果到AI短剧：谁在革谁的命？

2020-12-10 王宁.潮流玩具风靡背后的心理学

2022-01-08 王宁.不做「你死我活」的生意

2026-05-13 Alex Wang.Meta's AI Chief On AI Beef, New Models And Life With Zuck