本文是对 Andrej Karpathy 提出的 LLM Wiki 范式的深度解读与实现设计。Karpathy 前特斯拉 AI 总监、OpenAI 联合创始人，其技术洞察一向以简洁深刻著称。LLM Wiki 是他对个人知识管理的一次范式级思考，值得每一位深度使用 LLM 的人理解。
原文出处: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
原文与精译对照
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 Wiki
一种使用大语言模型构建个人知识库的模式。
这是一个理念文件，设计初衷是让你复制粘贴到自己的 LLM Agent（如 OpenAI Codex、Claude Code、OpenCode / Pi 等）中使用。它的目标是传达高层理念，具体实现则由你的 Agent 与你协作完成。
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页面, 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 Agent，一边是 Obsidian。LLM 根据我们的对话进行编辑，我实时浏览结果——跟踪链接、查看图谱视图、阅读更新的页面。Obsidian 是 IDE；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.
- 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.
这可以应用于许多不同的场景。一些例子：
- 个人：追踪你自己的目标、健康、心理、自我提升——归档日记条目、文章、播客笔记，并随着时间的推移构建一个结构化的自我画像。
- 研究：在数周或数月内深入一个主题——阅读论文、文章、报告，逐步构建一个包含演进论点的综合 wiki。
- 读书：边读边归档每一章，为角色、主题、情节线索及其关联构建页面。最终你会得到一个丰富的伴读 wiki。想想像 Tolkien Gateway 这样的粉丝 wiki——数千个相互链接的页面，涵盖角色、地点、事件、语言，由志愿者社区历时数年建成。你可以在阅读时个人构建类似的东西，由 LLM 负责所有交叉引用和维护。
- 商业/团队：由 LLM 维护的内部 wiki，输入来自 Slack 线程、会议记录、项目文档、客户电话。可能有人在循环中审核更新。wiki 保持最新，因为 LLM 做了团队中没有人愿意做的维护工作。
- 竞争分析、尽职调查、旅行规划、课程笔记、爱好深入研究——任何你在随时间积累知识并希望它有条理而非零散的场景。
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.
架构
架构分为三层：
原始资料层——你精心策划的来源文档集合。文章、论文、图片、数据文件。这些是不可变的——LLM 读取但从不修改它们。这是你的事实来源。
Wiki 层——一个由 LLM 生成的 Markdown 文件目录。摘要、实体页面、概念页面、比较、概览、综合。LLM 完全拥有这一层。它创建页面，在新资料到达时更新它们，维护交叉引用，并保持一切一致。你阅读它；LLM 撰写它。
Schema 层——一个文档（如 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.
操作
摄取（Ingest）。 你将新资料放入原始集合，然后告诉 LLM 处理它。一个示例流程：LLM 阅读资料，与你讨论关键要点，在 wiki 中撰写摘要页面，更新索引，更新 wiki 中相关的实体和概念页面，并在日志中追加一条记录。单个资料可能会触及 10-15 个 wiki 页面。就我个人而言，我更喜欢一次摄取一个资料并保持参与——我阅读摘要，检查更新，并指导 LLM 强调什么。但你也可以批量摄取多个资料，减少监督。你需要开发适合你风格的工作流，并将其记录在 schema 中供未来会话使用。
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.
查询（Query）。 你向 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.
自检（Lint）。 定期让 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:
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.
索引和日志
两个特殊文件帮助 LLM（和你）在 wiki 增长时导航。它们服务于不同的目的：
index.md 是内容导向的。它是 wiki 中所有内容的目录——每个页面都列出链接、一行摘要，以及可选的元数据如日期或来源数量。按类别（实体、概念、来源等）组织。LLM 在每次摄取时更新它。回答查询时，LLM 先阅读索引找到相关页面，然后深入阅读。在中等规模（~100 份资料，~数百页面）下这出奇地有效，避免了基于嵌入的 RAG 基础设施需求。
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.
可选: CLI 工具
在某个时刻，你可能想构建一些小工具来帮助 LLM 更高效地在 wiki 上操作。最明显的一个是 wiki 页面的搜索引擎——小规模时索引文件足够，但随着 wiki 增长你需要适当的搜索。qmd 是个不错的选择：它是一个本地 Markdown 文件搜索引擎，混合 BM25/向量搜索和 LLM 重排序，全部在设备上运行。它既有 CLI（所以 LLM 可以 shell 调用），也有 MCP 服务器（所以 LLM 可以把它作为原生工具使用）。你也可以自己构建更简单的东西——需要时 LLM 可以帮你 vibe-code 一个简单的搜索脚本。
- 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.
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'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.
Tips and tricks
- Obsidian Web Clipper 是一个浏览器扩展，将网页文章转换为 Markdown。对于快速将资料收入原始集合非常有用。
- 本地下载图片。 在 Obsidian 设置 → 文件和链接中，将"附件文件夹路径"设为固定目录（如
raw/assets/）。然后在设置 → 快捷键中，搜索"Download"找到"为当前文件下载附件"并绑定快捷键（如 Ctrl+Shift+D）。剪辑文章后，按下快捷键，所有图片就会下载到本地磁盘。这是可选的但有用——它让 LLM 可以直接查看和引用图片，而不是依赖可能失效的 URL。注意 LLM 不能原生地在一次通过中读取带有内联图片的 Markdown——解决方法是让 LLM 先阅读文本，然后单独查看部分或全部引用的图片以获得额外上下文。有点笨拙但足够好用。 - Obsidian 的图谱视图 是查看 wiki 形状的最佳方式——什么与什么相连、哪些页面是枢纽、哪些是孤立页面。
- Marp 是一个基于 Markdown 的幻灯片格式。Obsidian 有它的插件。对于直接从 wiki 内容生成演示文稿很有用。
- Dataview 是一个 Obsidian 插件，可以在页面 frontmatter 上运行查询。如果你的 LLM 向 wiki 页面添加 YAML frontmatter（标签、日期、来源数量），Dataview 可以生成动态表格和列表。
- 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 的 Memex（1945）相关——一个个人的、精心策划的知识存储库，文档之间有联想轨迹。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.
注意
本文档刻意保持抽象。它描述的是理念，而非具体实现。确切的目录结构、schema 约定、页面格式、工具——所有这些都取决于你的领域、你的偏好、你选择的 LLM。上面提到的一切都是可选和模块化的——选择有用的，忽略不需要的。例如：你的资料可能只有文本，所以你根本不需要图片处理。你的 wiki 可能小到索引文件就是你所需的全部，不需要搜索引擎。你可能不关心幻灯片，只想要 Markdown 页面。你可能想要完全不同的输出格式集合。正确使用方式是把它分享给你的 LLM Agent，共同协作实例化一个适合你的版本。本文档的唯一任务是传达这个模式。你的 LLM 可以搞定其余一切。
设计理念深层剖析
对照原文之后，我们来剖析这套设计背后的深层理念。
RAG 的根本缺陷：无状态的知识消费
RAG（Retrieval-Augmented Generation）解决了 LLM 的知识时效性问题——让模型能访问训练数据之外的资料。但它没有解决一个更深层的问题：知识的结构性积累。
想象两个学生：
- RAG 学生：每次考试前把课本翻一遍，找到相关段落，然后组织答案。他从不做笔记。
- LLM Wiki 学生：每读完一章就做笔记，建立概念卡片，标注不同章节间的关联。考试时他直接看自己的笔记。
RAG 学生的问题是：每次都在重新理解。当问题需要综合 5 份文档时，他必须在有限的上下文窗口内同时处理所有材料。而 LLM Wiki 学生的笔记是预编译的——综合工作在摄取时已经完成，查询时只是读取结果。
这不是说 RAG 无用。RAG 适合一次性查询（“这份合同有什么风险？”），LLM Wiki 适合长期积累（“跟踪这个领域三个月的演进”）。Karpathy 的洞见是：对于个人知识库，后者才是常态。
RAG 到 LLM Wiki：从解释执行到编译执行
借用计算机科学的类比：
| 维度 | RAG | LLM Wiki |
|---|---|---|
| 执行模式 | 解释执行（Interpreted） | 编译执行（Compiled） |
| 运行时开销 | 高（每次检索+生成） | 低（读取预编译产物） |
| 前期开销 | 低（直接查询） | 高（摄取时编译） |
| 重复查询效率 | 不变 | 递增（越用越快） |
| 知识形态 | 原始文档 | 结构化中间表示 |
这个类比的关键是中间表示（Intermediate Representation）。编译器把源码翻译成 IR，使得优化和后续处理更高效。LLM Wiki 中的 Markdown 页面就是知识的 IR——它们不是原始文档的副本，而是经过提取、综合、链接后的结构化表示。
LLM Wiki 中的人机分工
传统知识管理中，人机分工是：
- 人类：阅读、思考、整理
- 计算机：存储、检索
LLM Wiki 中的人机分工是：
- 人类：策划来源、提出好问题、判断价值
- LLM：整理、交叉引用、一致性维护
注意"整理"从人类转移到了机器。这不是小事——整理（bookkeeping）正是大多数人无法坚持维护知识库的原因。它是低认知价值、高执行成本的工作：更新链接、检查一致性、重命名概念时更新所有引用…
LLM 擅长这种工作：
- 它有无限的耐心（不会厌烦）
- 它有完整的上下文（不会"忘记"更新某个页面）
- 它能并行处理（一次改 15 个文件）
而人类的优势在于品味（taste）：什么值得记录、哪些问题重要、不同资料间的深层关联意味着什么。这些需要判断力和领域直觉，是 LLM 的弱项。
个人化知识存储 Memex 的回归
Vannevar Bush 在 1945 年的文章《As We May Think》中设想了 Memex——一个个人化的知识存储设备，核心特征是联想轨迹（associative trails）：
“用户创建一条轨迹，将其命名，将其插入代码簿中，然后敲击键盘。于是，在他面前的是某本书中的特定页面… 他可以添加旁注、创建链接分支…”
万维网实现了文档互联，但有两个关键偏离：
- 公共而非个人：网页是为所有人设计的，不是为"你的"知识需求定制的
- 链接而非轨迹：超链接是静态的、无上下文的；而联想轨迹是路径——“我如何从 A 想到 B”
LLM Wiki 重新找回了这两个属性：
- 个人策展：wiki 中只有你放入的资料，交叉引用反映的是你的思维路径
- 动态轨迹：LLM 在摄取时创建的交叉引用，本质上是"从这份资料可以到达哪些已有概念"的自动发现
Bush 没能解决维护问题，因为 1945 年没有自动化的"书记员"。LLM 就是这个书记员。
架构深度解析
三层各司其职
flowchart TB
subgraph schema["Schema 层 (CLAUDE.md)"]
s1["人类编写，LLM 读取"]
s2["随使用共同演化"]
end
subgraph wiki["Wiki 层 (*.md)"]
w1["LLM 编写，人类只读"]
w2["可积累、可链接、可查询"]
end
subgraph raw["Raw 层 (原始资料)"]
r1["人类放入，双方只读"]
r2["不可变的事实来源"]
end
三层有不同的分工和边界：
| 层 | 谁写入 | 谁读取 | 核心规则 | 目的 |
|---|---|---|---|---|
| Raw | 人类（放入） | LLM | 一旦放入就不改 | 原始依据，有争议可回溯 |
| Wiki | LLM | 人类 | LLM 独占写入权 | 避免人机编辑冲突 |
| Schema | 人类主导 | LLM | 随使用慢慢调整 | 告诉 LLM 怎么维护 wiki |
Raw 层为什么只读：如果 LLM 生成的内容有问题，你可以回头查原始资料对质。这是整个知识库的"底本"。
Wiki 为什么不让人类直接改：你改了一处，下次 LLM 更新时可能又覆盖掉。正确的做法是通过 Schema 或对话告诉 LLM 你的意图，让它来改。
Schema 为什么需要一起养：刚开始你也不知道 wiki 该怎么组织，用着用着就摸索出规律了——比如实体页该有哪些字段、概念页怎么写。这些经验要沉淀回 Schema 里。
Index 和 Log：两条检索路径
flowchart TD
A([查询入口]) --> B["index.md\n空间维度\n「有什么」"]
A --> C["log.md\n时间维度\n「最近更新了什么」"]
B --> D["相关页面\n深入阅读"]
C --> E["近期活动\n上下文感知"]
找东西有两条路：按内容找，或者按时间找。
Index.md 负责"按内容找"：
- 按类别组织：实体、概念、来源，各归其位
- 结构规整：LLM 能直接读，人类也能一眼扫过
- 一行一个：摘要 + 链接，不废话
Log.md 负责"按时间找"：
- 只追加，不改历史：写错了就另起一行，别动旧的
- 日期前缀：
## [YYYY-MM-DD] operation | subject，方便grep和tail - 不只是流水账：对 LLM 来说，这是它的"短期记忆"——先看最近几条，就知道当前上下文
Karpathy 提到 grep "^## \[" log.md | tail -5 这个用法，其实体现了一个实用原则：格式对人类工具链友好，同时内容保持自然语言，LLM 也能读懂。两头不耽误。
Schema 不是配置，而是工作语言
Schema 不只是"配置文件"，而是你用来跟 LLM 沟通的工作语言。它把通用的 LLM 调教成" wiki 维护专家"。
一份好用的 Schema 通常包括：
- 目录怎么摆：wiki 文件夹的组织方式
- 页面长什么样：实体页、概念页、来源摘要页各自该有什么板块
- Frontmatter 写什么：YAML 字段、标签怎么打
- 操作流程：Ingest、Query、Lint 这些动作具体怎么做
- 质量标准：什么情况该新建页面、什么情况下更新旧的
Schema 是用出来的，不是一次写好的。刚开始你可能只写几条规则，用着用着发现"实体页应该有状态字段"、“概念页需要加反链”——这些经验不断反哺回 Schema，它就越写越准，LLM 也越干越顺手。
关键操作的 Prompt 设计
以下提供三个核心操作的完整 Prompt 设计。这些 Prompt 可以直接放入 CLAUDE.md 或作为 Agent 的 system prompt 使用。
Ingest（摄取）操作
触发条件：用户将新资料放入 raw/ 目录并指示处理
Prompt 模板：
1 | ## Operation: INGEST |
Query（查询）操作
触发条件：用户向 wiki 提出问题
Prompt 模板：
1 | ## Operation: QUERY |
Lint（自检）操作
触发条件：用户请求健康检查，或定期自动执行
Prompt 模板：
1 | ## Operation: LINT |
参考实现：最小可用 wiki
以下是一个可以直接使用的目录结构和 CLAUDE.md 模板。
目录结构
1 | my-wiki/ |
CLAUDE.md 完整模板
1 | # LLM Wiki Schema |
局限与注意事项
Karpathy 的原文是"理念文件"，保持理想化是合理的。但真用起来，你得知道它会在哪里掉链子。
LLM 会瞎编，错误还会累积
问题：LLM 在整理资料时可能生成错误信息。一旦写进 wiki，这些错误就有了"正式感"——有页面、有链接、有引用——看起来比聊天记录可信多了。下次查询时，LLM 读到这些错误内容，可能继续往外传，越传越离谱。
应对思路：
- Raw 层始终保留原始资料，有争议就回去对质
- Schema 里要求标出拿不准的地方（
> ⚠️ **Unverified**） - Lint 时做矛盾检测——胡说八道往往跟已知事实对不上
- 人别当甩手掌柜：Ingest 时扫一眼摘要，关键页面抽几本核对
资料多了会装不下
Karpathy 坦承 Index.md 在"~100 份资料，~数百页面"时还行。再往上：
- Index.md 本身可能撑爆 LLM 的上下文窗口
- LLM 每次查询要读的页面变多，响应越来越慢
- 维护操作的工作量不是线性增长的
应对思路：
- 把索引拆成多层（按主题分不同的 Index）
- 用本地搜索工具补位（比如 Karpathy 推荐的 qmd）
- 旧内容挪到 archive/ 目录，活跃 wiki 保持精简
Schema 写不好，效果就差
LLM Wiki 的表现很大程度上看 Schema 的脸色。Schema 模糊会导致：
- 页面结构东一个西一个
- 该建的链接没建
- 更新时逻辑混乱
现实情况：写出一份靠谱的 Schema 得迭代好几周。初期的 wiki 可能一团糟，需要反复 Lint 和重构，别指望一次到位。
LLM Wiki 不是 RAG 的替代品
它俩是分工关系，不是谁取代谁：
flowchart LR
A[Raw Sources] --> B["INGEST: LLM Wiki"]
B --> C[Structured Wiki]
C --> D["QUERY: direct read"]
B -.-> E{RAG 仍然有它的用场}
E --> F[大批还没处理的文档]
E --> G[实时数据，来不及进 wiki]
E --> H[临时 query，不在 wiki 覆盖范围内]
已积累的知识，LLM Wiki 查起来更顺手；刚到手的资料，RAG 响应更快。理想情况是两手抓：新东西先用 RAG 顶着，有空了再走 Ingest 流程进 wiki。
这些情况别硬上
- 高度结构化的数据：数据库、表格——Excel 和 SQL 不香吗
- 多人频繁改来改去的项目：wiki 是 LLM 独占写入，人类插一脚容易冲突
- 需要严格版本控制的文档：合同、规范——Git + 人工审核仍是标配
- 短期项目：搭 wiki 有前期投入，用不到一周的话，回本都回不来
总结
LLM Wiki 代表了一种范式的转移：从把 LLM 当作查询接口到把 LLM 当作知识编译器。其核心洞察是：
- 知识的复利来自于结构化的中间表示——不是原始文档的堆积，而是经过提取、综合、链接后的 wiki 页面
- 维护成本是知识库的最大瓶颈——LLM 解决了这个历史上阻碍个人 wiki 普及的核心问题
- 人机分工应基于各自的优势——人类负责策展和判断，LLM 负责执行和记账
- 简单架构胜过复杂基础设施——三层架构（Raw/Wiki/Schema）+ 两个特殊文件（Index/Log）足以支撑丰富的使用场景
Karpathy 在文末引用 Memex 不是随意的历史点缀，而是精准的定位：他设计的不是又一个笔记工具，而是Memex 在 LLM 时代的实现。Bush 的愿景等了 80 年，终于等来了它的维护者。
