LLM Wiki 深度解读：让大语言模型成为你的知识编译器

本文是对 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 一个简单的搜索脚本。

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

提示与技巧

• 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）：

“用户创建一条轨迹，将其命名，将其插入代码簿中，然后敲击键盘。于是，在他面前的是某本书中的特定页面… 他可以添加旁注、创建链接分支…”

万维网实现了文档互联，但有两个关键偏离：

1. 公共而非个人：网页是为所有人设计的，不是为"你的"知识需求定制的
2. 链接而非轨迹：超链接是静态的、无上下文的；而联想轨迹是路径——“我如何从 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	人类	版本化	知识产物
Schema	人类+LLM	LLM	共同演化	行为契约

Raw 不可变的意义：如果 LLM 生成的 wiki 内容有争议，你可以回溯到原始资料核实。这是知识库的"可审计性"。

Wiki LLM 独占写入的意义：避免人机冲突。如果人类直接编辑 wiki，下次 LLM 更新时可能覆盖人类修改。解决方案是：人类通过 Schema 和对话指导 LLM，而非直接改文件。

Schema 共同演化的意义：它是人类向 LLM 传递意图的主要通道。随着 wiki 增长，你会发现"实体页面应该包含什么字段"、“概念页面如何组织”——这些约定要记录到 Schema 中。

Index.md 与 Log.md 的双轨导航

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，便于 Unix 工具解析
• 时间线价值：不仅是审计，更是 LLM 的"短期记忆"

Karpathy 提到 grep "^## \[" log.md | tail -5 这个技巧，暗示了混合人机接口的设计哲学：LLM 能读懂自然语言，但保留结构化前缀让人类工具链也能处理。

Schema 的本质：领域特定语言

Schema 不是"配置"，而是一种领域特定语言（DSL）。它的作用是把通用 LLM 转化为" wiki 维护专家"。

一个好的 Schema 应该包含：

1. 目录结构约定：wiki 文件夹如何组织
2. 页面类型模板：实体页、概念页、来源摘要页各应该有什么结构
3. Frontmatter 规范：YAML 字段、标签体系
4. 工作流指令：Ingest/Query/Lint 各操作的步骤
5. 质量准则：什么情况下应该创建新页面、什么时候更新旧页面

Schema 的演进是 LLM Wiki 使用的元学习过程：你用得越多，越清楚什么约定有效，Schema 就越精确，LLM 的表现就越好。

关键操作的 Prompt 设计

以下提供三个核心操作的完整 Prompt 设计。这些 Prompt 可以直接放入 CLAUDE.md 或作为 Agent 的 system prompt 使用。

Ingest（摄取）操作

触发条件：用户将新资料放入 raw/ 目录并指示处理

Prompt 模板：

## Operation: INGEST

You are processing a new source document for the wiki. Follow this workflow:

### Step 1: Read and Understand
- Read the source document in `raw/`
- Identify: main topics, key entities, core claims, data points
- Note any connections to existing wiki content (you may read index.md first)

### Step 2: Discuss with User (if interactive)
- Summarize the key takeaways in 3-5 bullet points
- Highlight surprising or contradictory findings
- Ask the user what aspects they want emphasized

### Step 3: Update Wiki
Create or update the following (as needed):

1. **Source Summary Page**: `wiki/sources/<source-slug>.md`
   - Frontmatter: title, date, source_type, tags
   - Content: summary, key points, notable quotes, your reflections

2. **Entity Pages**: `wiki/entities/<entity-name>.md` (for each significant entity)
   - Create if new; update if exists
   - Add backlink to the source page

3. **Concept Pages**: `wiki/concepts/<concept-name>.md` (for each core concept)
   - Create if new; update if exists
   - Synthesize with existing descriptions

4. **Update Index**: `wiki/index.md`
   - Add new pages to appropriate categories
   - Update counts if applicable

5. **Append Log**: `wiki/log.md`
   - Format: `## [YYYY-MM-DD] ingest | <Source Title>`
   - List pages created/updated

### Rules
- Prefer updating existing pages over creating new ones if concept overlap > 70%
- When updating, preserve existing content and append new insights
- Flag contradictions with existing wiki content explicitly
- All wiki pages must use `[[WikiLink]]` syntax for internal links

Query（查询）操作

触发条件：用户向 wiki 提出问题

Prompt 模板：

## Operation: QUERY

The user has asked a question. Answer using the wiki as your primary knowledge source.

### Step 1: Discover Relevant Pages
1. Read `wiki/index.md` to identify potentially relevant pages
2. Read the most relevant pages (use judgment on how many)
3. Follow `[[WikiLinks]]` to discover related content

### Step 2: Synthesize Answer
- Cite specific wiki pages in your answer
- If wiki lacks sufficient information, say so clearly
- Consider creating a new wiki page if the answer is valuable and reusable

### Step 3: Optional Filing
If the answer meets ANY of these criteria, create `wiki/queries/<query-slug>.md`:
- Required synthesis across 3+ pages
- Contains novel connections not explicitly stated in wiki
- Formats knowledge in a useful new way (comparison, timeline, etc.)
- User indicates it should be preserved

Frontmatter for query pages:
```yaml
---
title: <descriptive title>
date: <YYYY-MM-DD>
type: query-response
sources:
  - [[page1]]
  - [[page2]]
tags: []
---
```

Lint（自检）操作

触发条件：用户请求健康检查，或定期自动执行

Prompt 模板：

## Operation: LINT

Perform a health check on the wiki. Report findings by category.

### Checklist

**Contradictions**
- [ ] Scan for statements on different pages that conflict
- [ ] Flag severity: minor (wording) / major (factual)

**Staleness**
- [ ] Identify claims that newer sources may have superseded
- [ ] Check dates on source pages vs. claims on concept pages

**Structural Issues**
- [ ] List orphan pages (no inbound [[WikiLinks]])
- [ ] List important concepts mentioned but lacking pages
- [ ] Identify missing cross-references between related pages

**Completeness**
- [ ] Spot data gaps that could be filled (suggest web searches)
- [ ] Identify under-developed pages (< 200 words with high link count)

### Output Format

```markdown
## Lint Report [YYYY-MM-DD]

### Contradictions
- [ ] Page A claims X, but Page B claims Y (severity: major)
...

### Staleness
- [ ] Concept "Z" last updated 2024-01, but source "New Paper" (2024-06) contradicts
...

### Structural Issues
- Orphan pages: [[Page1]], [[Page2]]
- Missing pages for: Concept X, Entity Y
- Missing cross-references: Page A ↔ Page B

### Completeness
- Suggest search: "latest research on topic Z"
- Under-developed: [[Concept X]] (150 words, 8 inbound links)

### Recommendations
1. ...
2. ...
```

After reporting, ask the user which issues to fix, then execute fixes following INGEST rules.

参考实现：最小可用 wiki

以下是一个可以直接使用的目录结构和 CLAUDE.md 模板。

目录结构

my-wiki/
├── CLAUDE.md              # Schema / 行为契约
├── raw/                   # 原始资料层（不可变）
│   ├── articles/
│   ├── papers/
│   ├── books/
│   └── assets/            # 本地下载的图片
├── wiki/                  # Wiki 层（LLM 管理）
│   ├── index.md           # 内容目录
│   ├── log.md             # 时间线日志
│   ├── sources/           # 来源摘要页
│   ├── entities/          # 实体页（人物、组织、地点等）
│   ├── concepts/          # 概念页（理论、方法、术语等）
│   ├── queries/           # 查询产物（可选回写）
│   └── meta/              # 元页面（关于 wiki 本身）
└── .git/                  # 版本控制

CLAUDE.md 完整模板

# LLM Wiki Schema

## Overview

This is a personal knowledge base maintained by an LLM agent. The human curates sources and asks questions; the LLM does all writing and maintenance.

## Directory Structure

```
raw/          - Immutable source documents (human puts, both read)
wiki/         - LLM-generated markdown (LLM writes, human reads)
  index.md    - Content catalog, updated on every ingest
  log.md      - Append-only chronological log
  sources/    - Source summary pages
  entities/   - Pages for people, organizations, places, etc.
  concepts/   - Pages for theories, methods, terminology
  queries/    - Valuable query responses filed as pages
  meta/       - Pages about the wiki itself
```

## Page Templates

### Source Page (`wiki/sources/<slug>.md`)

```markdown
---
title: <Source Title>
date: <YYYY-MM-DD>
source_type: article|paper|book|podcast|video
tags: []
---

# Summary

<2-3 paragraph summary>

## Key Points

- <point 1>
- <point 2>

## Notable Quotes

<quote>

> ## Entities Mentioned
> 
> - [[Entity Name]]

## Concepts Discussed

- [[Concept Name]]

## Reflections

<LLM's own analysis and connections to existing wiki content>
```

### Entity Page (`wiki/entities/<name>.md`)

```markdown
---
title: <Entity Name>
type: person|organization|place|product
created: <YYYY-MM-DD>
updated: <YYYY-MM-DD>
tags: []
---

# <Entity Name>

<Description>

## Key Information

| Attribute | Value |
|-----------|-------|
| Type | ... |
| Related | ... |

## Appearances in Sources

- [[Source Page]]

## Related Entities

- [[Other Entity]]

## Related Concepts

- [[Concept]]
```

### Concept Page (`wiki/concepts/<name>.md`)

```markdown
---
title: <Concept Name>
created: <YYYY-MM-DD>
updated: <YYYY-MM-DD>
tags: []
---

# <Concept Name>

<Definition and explanation>

## Related Sources

- [[Source Page]]

## Related Concepts

- [[Other Concept]]

## Related Entities

- [[Entity]]

## Evolution of Understanding

<How this concept's treatment has evolved as new sources were added>
```

## Conventions

1. **WikiLinks**: Use `[[Page Name]]` for internal links. Prefer links over plain text mentions.
2. **Frontmatter**: Every page must have YAML frontmatter with at least `title` and `date`.
3. **Updates**: When updating a page, update the `updated` field in frontmatter.
4. **Contradictions**: If new sources contradict existing wiki content, note it explicitly with a `> ⚠️ **Contradiction**` callout.
5. **Index Format**: Maintain `wiki/index.md` as:
   ```markdown
   # Wiki Index

   ## Sources
   - [[Source Title]] — one-line summary

   ## Entities
   - [[Entity Name]] — one-line summary

   ## Concepts
   - [[Concept Name]] — one-line summary
   ```
6. **Log Format**: Append to `wiki/log.md`:
   ```markdown
   ## [YYYY-MM-DD] <operation> | <subject>
   - Action: description
   - Pages affected: [[Page1]], [[Page2]]
   ```

## Operations

<Insert the INGEST, QUERY, LINT prompts from Section 4 here>
```

### 5.3 初始 index.md 和 log.md

**wiki/index.md**:

```markdown
# Wiki Index

This is the content catalog. Updated automatically on every ingest.

## Sources

*(Empty — will be populated on first ingest)*

## Entities

*(Empty — will be populated on first ingest)*

## Concepts

*(Empty — will be populated on first ingest)*

## Queries

*(Empty — will be populated when valuable queries are filed)*
```

**wiki/log.md**:

```markdown
# Wiki Log

Append-only chronological record of all wiki operations.

## [YYYY-MM-DD] init | Wiki Created
- Action: Initialized wiki structure
- Pages created: [[index]], [[log]]

批判与边界

Karpathy 的原文是"理念文件"，保持理想化是合理的。但作为实践者，我们需要清醒认识这个模式的局限性。

幻觉传播风险

问题：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 和重构。

与 RAG 的互补关系

LLM Wiki 不是 RAG 的替代，而是预处理层：

flowchart LR
    A[Raw Sources] --> B["INGEST: LLM Wiki"]
    B --> C[Structured Wiki]
    C --> D["QUERY: direct read"]
    B -.-> E{RAG still useful for}
    E --> F[Large unprocessed document collections]
    E --> G[Real-time data not yet ingested]
    E --> H[Ad-hoc queries outside wiki scope]

对于已积累的知识，LLM Wiki 更高效；对于新到达的资料，RAG 更即时。理想架构是两者结合：新资料先用 RAG 应急，随后通过 Ingest 进入 wiki。

什么场景不适合

• 高度结构化数据：数据库、电子表格——用传统工具更好
• 频繁变更的协作项目：多人同时修改 wiki 会导致冲突
• 需要严格版本控制的文档：法律文档、规范——Git + 人工审核仍是必需的
• 短期项目：搭建 wiki 有前期成本，使用周期 < 1 周可能不划算

总结

LLM Wiki 代表了一种范式的转移：从把 LLM 当作查询接口到把 LLM 当作知识编译器。其核心洞察是：

1. 知识的复利来自于结构化的中间表示——不是原始文档的堆积，而是经过提取、综合、链接后的 wiki 页面
2. 维护成本是知识库的最大瓶颈——LLM 解决了这个历史上阻碍个人 wiki 普及的核心问题
3. 人机分工应基于各自的优势——人类负责策展和判断，LLM 负责执行和记账
4. 简单架构胜过复杂基础设施——三层架构（Raw/Wiki/Schema）+ 两个特殊文件（Index/Log）足以支撑丰富的使用场景

Karpathy 在文末引用 Memex 不是随意的历史点缀，而是精准的定位：他设计的不是又一个笔记工具，而是Memex 在 LLM 时代的实现。Bush 的愿景等了 80 年，终于等来了它的维护者。