Karpathy 的原文见：https://github.com/karpathy/llm-wiki

下面，跟着我逐字逐句来解读。

LLM Wiki

原文：A pattern for building personal knowledge bases using LLMs.

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 在大多数工具里只是个"检索机器"，而不是"思考伙伴"。

这份 idea 文件不一样。它说的是：让 LLM 做一个持续维护 wiki 的角色，你负责方向，它负责把所有细节执行到位。

核心思想（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.

我太熟悉这个体验了。

用各种 AI 工具问过问题，上传过 PDF 问过问题，用各种"知识库"工具试过——每次都是同一个流程：上传文件，问问题，得到答案，关掉。没有任何"积累"发生。今天问的问题和昨天问的问题之间没有任何关联，LLM 不会因为"你之前处理过这篇文章"就变得更快或者更准。

更难受的是多文档综合。假设我在研究一个课题，需要综合五份不同的论文才能回答一个问题——每次问，LLM 都得从五份文档里重新找线索、重新拼凑。没有跨文档的上下文，没有已经建立好的关联。

这种感觉就像每次考试都让你从零翻书，临场发挥。没有人会在考前说"对，这次考试不会用到上次考试的任何结论"——但 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.

这段话我读了三遍。

关键在这个词：incrementally builds and maintains。

不是"每次查询时重新发现"，而是"增量构建并持续维护"。新增一个来源，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.

compounding artifact这个词用得妙。

复利，本金生利息，利息再滚入本金。Wiki 也是一个复利系统——每加一个来源，wiki 的价值不只是增加那一个来源的价值，而是那个来源和所有已有知识之间产生的连接网络的价值。

跨引用已经有了，矛盾已经被标注了，综合结论已经形成了。你不需要每次从零开始拼凑——这些"文书工作"LLM 已经帮你做好了。

原文：

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.

人类负责三件事：筛选来源、探索方向、提出好问题。LLM 负责所有文书工作——总结、跨引用、整理、维护。

他的使用场景描述得很具体：一边是 LLM Agent，一边是 Obsidian。LLM 根据对话做编辑，他实时浏览结果。Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。

刚开始折腾 ai+Obsidian 的时候，最大的问题是"LLM 只是在回答问题"。现在想想，问题的根源就在这里——LLM 的输出进了对话就消失了，没有变成 wiki 里可以持续积累的资产。

应用场景（This Can Apply to a Lot of Different Contexts）

原文：

• 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.
• 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.
• 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.
• 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.

五个场景，我最感兴趣的是"阅读一本书"这个。

Tolkien Gateway 的类比让我愣住了一下——那个 wiki 有几千个页面，覆盖人物、地点、事件、语言，由社区志愿者多年维护才做成。一个人读一本书，凭什么能建立一个同等规模的知识库？

Karpathy 的回答是：LLM 做所有的跨引用和维护工作。

老实说，这个场景对我吸引力最大。我之前做过 ai 拆书，每个月读好几本书，读的时候零零碎碎有感触，读完过一个月就忘得差不多。如果有一个 wiki，读完一本书就自动生成一个人物关系图谱、主题分析、时间线——那这本书才算真正读进去了。

架构（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.

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.

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 and your LLM of choice.

三层架构，单向数据流，很清晰。

Raw sources 是 source of truth，LLM 只读不写。这很重要——原始文档是锚，任何时候都可以回滚。Wiki 是 LLM 的作品，LLM 写，人类读。Schema 是玩法说明书，告诉 LLM 文件该怎么组织、摄取新来源的标准流程是什么。

Schema 是我之前没有仔细想过的东西。在 obsidian 中有模板 template，但是模板都是用来规定元数据的，而不是文件内容。

我折腾 Obsidian 的时候，遇到的最大问题是"命名不统一"——A 页面叫"AI Agent"，B 页面叫"智能体"，说的是同一个东西但没有关联。Schema 就是来解决这个问题的：文件该长什么样、命名约定是什么、什么情况下该合并、什么情况下该新建——这些规则提前定好，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.

一次 Ingest 影响 10-15 个 wiki 页面，这个数字让我吃了一惊。

之前我的工作流是：读文章 → 写笔记 → 存进 Obsidian。笔记和当时处理这篇文章的认知可能就绑定在那篇文章本身，顶多更新了一篇笔记。

但 Ingest 不一样。一篇来源进入 wiki，可能同时需要：写摘要页、更新 index、更新相关概念页、更新相关实体页、修正矛盾、补充引用、写日志。一次来源，多点开花。

Karpathy 偏好一次一个来源、深度参与。我也是这个风格——但我也想试试批量处理的速度感。

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.

这个洞察我太喜欢了：好的答案值得归档。

以前我让 LLM 做分析，做完就看完了，聊完就消失了。那个分析质量很高，但不存在了。下次问同样的问题，LLM 得重新生成一遍。

现在不一样了。如果一个回答质量很好，我会让它归档成 wiki 的一页。下次相关问题，直接引用。

探索本身也成了 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.

Lint 是 wiki 的"体检"。

我之前的笔记系统最大的问题不是"没有"，是"从来不回头看"。写完就放着，过时就过时了，矛盾就矛盾了，没有人检查。

Lint 解决的就是这个问题——wiki 是一个活的系统，不是一次性的文档整理。定期检查矛盾、过时、孤立页面、缺失引用，LLM 还会主动建议新问题和新来源。

这比我自己回头检查高效太多了。

索引与日志（Indexing and Logging）

原文：

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

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.

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.

两个导航文件，各有分工。

index.md 是内容目录，回答"wiki 里有什么"。log.md 是时间线，回答"发生了什么"。LLM 回答问题的时候先读 index 找到相关页面，然后 drill down。这个方案在中等规模下不需要向量检索，朴素但有效。

log.md 用 Unix 工具解析这个技巧很实用。grep "^## \[" log.md | tail -5——查最近五条记录，一句话的事。

可选：CLI 工具（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 all you need, 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.

qmd 看起来是个有意思的工具——本地搜索，支持 BM25 和向量混合搜索，还有 MCP server。我试了一下，配置很麻烦，使用 claude 帮我的 mac 配置甚至都没成功，卡在 CPU 的问题上。我目前用的是 obsidian cli 工具。

提示与技巧（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.
• Download images locally. In Obsidian Settings → Files and links, set "Attachment folder path" to a fixed directory (e.g. 资源目录/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'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.
• Marp is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from wiki content.
• 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.
• The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free.

Obsidian 生态的这些工具组合起来很有威力。

Web Clipper 是收集器，Graph View 是感知器，Dataview 是查询器，Marp 是输出器。一套工具链，从摄入到呈现全覆盖。

这里值得一提的是，Dataview 是一个 obsidian 第三方插件，是个基于 YAML frontmatter 的查询器。如果 LLM 生成的页面有 YAML frontmatter，Dataview 就可以根据 frontmatter 生成动态的表格和列表。但是，现在新版的 obsidian 自带了 Bases 功能，也可以实现类似的功能。不过，claude code 还无法直接从 Bases 中查询到信息。Dataview 不知道可以不可以被 ai 调用，有试过的小伙伴可以分享下。

另外 Git 免费附送版本历史——wiki 改错了可以回滚，分支管理也不是问题。

为什么这有效（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.

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.

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.

这段话是整份文件最打动我的部分。

维护知识库最累的从来不是读和想，是文书工作——更新跨引用、保持摘要最新、标注矛盾、维护一致性。这些事情人类做着做着就放弃了，因为成本增长快于价值增长。

这一点我在之前的文章6年1000小时1张图：我对Obsidian的全部理解中也有写到过：

1）起步区 (1 - 200 条)：处于兴奋期，每一条笔记都是可见的，连接是显而易见的。

2）蜜月区 (200 - 500 条)：系统最高效的时期。此时笔记数量达到一定规模，你会感觉到系统很强大且可靠。

3）摩擦区 (500 - 1000 条)：这是熵增开始显著的阶段。维护成本开始上升，标签开始变得不一致，冗余出现，大脑开始感觉到手动链接和分类的阻力。

4）劝退区 (1000 条以上)：一旦突破这个数量级，依靠"手工作坊"式的维护（手动加双链、手动分类、手动打标签等）会很快失效。此时系统进入高熵状态，洞察和启发减少。

也就是说当笔记数量在 1000 条以内，你可以靠"脑力"强行记住笔记的位置。但超过这个阈值，大脑无法再作为主要的索引器。此时，如果不引入自动化或更高级的检索机制（如 AI 向量检索），用户就会经历一些心理活动然后变成"松鼠"：假装"保存了"就是"掌握了"，实际上这些笔记变成了再也用不上的"僵尸数据"，直到你下定决心重构一把。

LLM 不会厌倦，不会忘记，不会偷懒，可以一次改十五个文件。

文书工作交给 LLM，思考工作交给人类。这是最自然的分工。

Vannevar Bush 的 Memex 是这个思想的先驱——1945 年他就在想私人、主动维护的知识库，文档之间的连接和文档本身一样有价值。但他解决不了"谁来维护"的问题。七十年后，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.

这份文件是"道"，不是"术"。

它不规定具体的目录结构、Schema 规范、页面格式。所有组件都是可选的——按需取用。

正确的方式是：把这东西丢给你的 LLM Agent，然后协作演进出一套适合你的版本。具体怎么落地，让 LLM 和你一起定。

我的感受

读完这份文件，我最大的感受是：我折腾知识管理三年，走的弯路突然连起来了。

我之前遇到的所有问题的根源，都是把 LLM 只当成"检索工具"而不是"维护伙伴"。每次用完就消失了，没有积累，没有维护，没有复利。

LLM Wiki 解决的就是这个根本问题：不是更努力地使用工具，是换一套工作的范式。

文书工作交给 LLM，思考工作交给自己。Wiki 越往后越丰富，维护成本接近零。

这是我见过的最接近"数字第二大脑"的设计——不是存储，是编译。不是检索，是维护。