llm_wiki/raw/llm-wiki.md

title, source, author, published, created, description, tags, rating

title	source	author	published	created	description	tags	rating
llm-wiki	https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f			2026-04-23	llm-wiki. GitHub Gist: instantly share code, notes, and snippets.	clippings	4

LLM WikiLLM 维基

A pattern for building personal knowledge bases using LLMs.

使用 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代理（例如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并非仅在查询时从原始文档中检索信息，而是 逐步构建并维护一个持久的维基 ——一个结构化、相互关联的Markdown文件集合，介于您和原始资料之间。当您添加新资料时，LLM不仅为其建立索引以供后续检索，而是会读取它、提取关键信息，并将其整合到现有的维基中——更新实体页面、修订主题摘要、标注新数据与旧声明之间的矛盾，强化或挑战不断演进的合成知识。知识被一次性编译后，便 保持更新 ，而非每次查询时重新推导。

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.

这是关键的区别： 维基是一个持久且累积的产物。 交叉引用已经存在。矛盾之处已经被标记。综合内容已经反映了你所阅读的一切。随着你添加的每个资料和提出的每个问题，维基会变得越来越丰富。

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承担所有繁琐的工作——包括总结、交叉引用、归档和记账，这些工作使知识库随着时间的推移变得真正有用。实际上，我一边打开LLM代理，一边打开Obsidian。LLM根据我们的对话进行编辑，我实时浏览结果——点击链接、查看图表视图、阅读更新后的页面。Obsidian是集成开发环境（IDE）；LLM是程序员；维基是代码库。

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. 阅读一本书 ：在阅读过程中逐章归档，为角色、主题、情节线索及其相互关联构建页面。最终，你将拥有一个丰富的伴侣维基。可以将粉丝维基类比为 托尔金之门 ——涵盖角色、地点、事件、语言等数千个相互链接的页面，由志愿者社区经过多年构建而成。你也可以在阅读过程中亲自构建类似的内容，而大型语言模型（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）维护的内部维基，内容来源于Slack线程、会议记录、项目文档和客户通话。可能包含人工审核更新的环节。维基能够保持最新状态，因为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.

维基 — 一个由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）维基的结构、规范，以及在进行资料摄入、回答问题或维护维基时应遵循的工作流程。这是关键的配置文件——它使得 LLM 成为一名有纪律的维基维护者，而不是一个通用的聊天机器人。随着您了解哪些适用于您的领域，您和 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读取来源，与你讨论关键要点，在维基中编写摘要页面，更新索引，更新维基中相关的实体和概念页面，并在日志中添加条目。一个来源可能会涉及10-15个维基页面。我个人更喜欢一次摄取一个来源并保持参与——我阅读摘要，检查更新，并指导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.

查询。 你向维基提问。LLM（大型语言模型）会搜索相关页面，阅读它们，并综合引用生成答案。答案的形式会根据问题不同而有所变化——可以是Markdown页面、比较表格、幻灯片（Marp）、图表（matplotlib）或画布。一个重要的见解是： 好的答案可以作为新页面添加到维基中。 你要求比较、分析、你发现的联系——这些都是有价值的，不应该消失在聊天记录中。这样，你的探索就像摄取的知识源一样，在知识库中累积。

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）对维基进行健康检查。查找以下问题：页面之间的矛盾、被较新资料取代的过时说法、没有入站链接的孤立页面、提到的重要概念但缺乏自己的页面、缺失的交叉引用、可以通过网络搜索填补的数据空白。LLM擅长提出需要调查的新问题和寻找的新资料。这有助于维基在成长过程中保持健康。

Indexing and logging索引和日志记录

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

两个特殊文件帮助 LLM（和您）随着维基的增长而导航。它们有不同的用途：

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 是以内容为导向的。它是维基中所有内容的目录——每个页面都列出了链接、一行摘要，以及可选的元数据，如日期或来源数量。按类别（实体、概念、来源等）组织。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 | 文章标题 ），那么日志就可以用简单的 Unix 工具进行解析—— grep "^## \[" log.md | tail -5 可以显示最后 5 条记录。日志为你提供了维基演变的时间线，并帮助大型语言模型理解最近做了什么。

Optional: CLI tools可选：CLI 工具

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）在维基上更高效地运行。维基页面上的搜索引擎是最明显的一个——在小规模上，索引文件就足够了，但随着维基的增长，你需要一个真正的搜索引擎。 qmd 是一个不错的选择：它是一个用于Markdown文件的本地搜索引擎，具有混合BM25/向量搜索和LLM重新排序功能，所有操作都在设备上完成。它既有命令行界面（LLM可以调用它），也有MCP服务器（LLM可以将其作为本地工具使用）。你也可以自己构建一个更简单的工具——LLM可以帮助你根据需要编写一个简单的搜索脚本。

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可以直接查看和引用图片，而不是依赖可能失效的URL。请注意，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. 黑曜石的图形视图 是查看维基结构的最理想方式——了解哪些内容相互关联，哪些页面是枢纽，哪些是孤岛。
• 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 有一个插件支持它。这对于直接从维基内容生成演示文稿非常有用。
• 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 为维基页面添加了 YAML 前置内容（标签、日期、来源计数），Dataview 可以生成动态表格和列表。
• The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free. 维基只是一个包含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.

维护知识库的繁琐之处不在于阅读或思考——而是记账。更新交叉引用、保持摘要最新、记录新数据与旧主张的矛盾、在数十页中保持一致性。人类放弃维基是因为维护负担增长的速度超过了其价值。大型语言模型不会感到厌倦，不会忘记更新交叉引用，并且可以在一次遍历中触及15个文件。维基之所以能够持续维护，是因为维护成本几乎为零。

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.

这个想法在精神上与范内瓦·布什的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.

本文档故意保持抽象。它描述的是概念，而不是具体的实现。确切的目录结构、模式约定、页面格式、工具——所有这些都取决于你的领域、你的偏好以及你选择的LLM。上述提到的所有内容都是可选的和模块化的——选择有用的部分，忽略不用的部分。例如：你的来源可能只有文本，因此你根本不需要图像处理。你的维基可能足够小，以至于索引文件就足够了，不需要搜索引擎。你可能不关心幻灯片，只想使用Markdown页面。你可能需要完全不同的输出格式集。正确使用本文档的方法是与你的LLM代理分享，并共同工作以实例化一个符合你需求的版本。本文档的唯一任务是传达模式。你的LLM可以自行解决其余问题。