LLM Wiki 模式：用 LLM 增量构建、持续维护的持久化知识库——llm_wiki 项目实战指南

导读：本文围绕本仓库的奠基性设计文档 llm-wiki.md 展开，系统讲解一种与"查询时检索"（RAG）截然不同的知识库构建范式——让 LLM 把资料编译成一份持久、互相链接的 Markdown Wiki，并持续维护它。读完本文，你将掌握三层架构、Ingest/Query/Lint 三大操作、index.md/log.md 导航体系、可选 CLI 工具与 Obsidian 配套技巧，并看到这一抽象模式在 llm_wiki 桌面应用中的具体落地（schema 模板、两步链式 ingest、持久化队列、语义 Lint 等源码级实现）。

核心思想：从"每次重新检索"到"编译一次、持续保鲜"

大多数人使用 LLM 处理文档的方式是 RAG：上传一批文件，查询时 LLM 检索相关片段并生成答案。这种方式可行，但存在一个根本问题——LLM 每次都在从零"重新发现"知识，没有积累。当问题足够刁钻、需要综合五篇文档时，LLM 每次都不得不重新寻找、拼合相关碎片。NotebookLM、ChatGPT 文件上传以及大多数 RAG 系统都是这个工作模式。

llm-wiki.md 提出的想法完全不同：不要在查询时直接从原始文档检索，而是让 LLM 增量构建并维护一份持久化的 Wiki——一份位于你和原始资料之间、结构化的、互相链接的 Markdown 文件集合。当你加入一份新资料时，LLM 不只是为后续检索建索引，而是真正阅读它、提取关键信息、把它整合进已有 Wiki：更新实体页面、修订主题综述、标注新数据与旧论断的矛盾之处、强化或挑战正在演进的综合结论。知识被"编译一次"然后"持续保鲜"，而不是在每次查询时重新推导。

这带来了一个关键差异：Wiki 是一件持续积累、不断复利的资产。交叉引用已经就位，矛盾已经被标记，综述已经反映了你读过的所有内容。每加入一份资料、每提出一个问题，Wiki 都会变得更丰富。

你几乎（或完全）不需要自己写 Wiki——写作与维护全部由 LLM 完成。你负责选题、探索、提出好问题；LLM 负责所有苦力活——总结、交叉引用、归档、记账，这些才是让知识库长期真正有用的部分。实践中可以这样分工：一边开着 LLM Agent（如 Claude Code、OpenAI Codex、OpenCode / Pi 等），另一边开着 Obsidian；LLM 根据对话编辑文件，你在 Obsidian 里实时浏览结果——跟随链接、查看图谱、阅读更新后的页面。Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。

这一模式适用于多种场景：

• 个人：跟踪目标、健康、心理、自我提升——归档日志条目、文章、播客笔记，逐步构建关于自己的结构化图景；
• 研究：在数周或数月内深入一个主题——阅读论文、文章、报告，增量构建一份含演进论点的综合性 Wiki；
• 读书：边读边归档每一章，为角色、主题、情节线索及其联系建立页面，读完即获得一部内容丰富的伴读 Wiki，类似 Tolkien Gateway 那种由社区志愿者多年共建的千页互链 Wiki，你可以用 LLM 在个人阅读中独立构建；
• 商务/团队：由 LLM 维护的内部 Wiki，投喂 Slack 线程、会议纪要、项目文档、客户通话，可选人工审核更新——LLM 完成了团队里没人想做的维护工作，Wiki 因此保持新鲜；
• 竞品分析、尽职调查、旅行规划、课程笔记、爱好深挖——任何需要长期积累并希望"有条理而非散落"的知识场景。

在 llm_wiki 项目中，这一思想已被完整实现为桌面应用：官方 README.md 明确将 llm-wiki.md 列为项目的基础方法论，并声明遵循其核心架构——三层架构、三大操作、index.md 目录、log.md 日志、[[wikilink]] 交叉引用、YAML frontmatter、Obsidian 兼容以及"人策展、LLM 维护"的分工。

三层架构：Raw Sources → Wiki → Schema

模式文档定义了三个层次：

Raw Sources（原始资料层）——你精选收集的源文档：文章、论文、图片、数据文件。它们不可变——LLM 只读不改，这是你的事实来源（source of truth）。

The Wiki（Wiki 层）——一个由 LLM 生成的 Markdown 文件目录：综述、实体页、概念页、对比页、总览、综合页。这一层完全由 LLM 拥有：创建页面、新资料到达时更新、维护交叉引用、保持一致性。你读它，LLM 写它。

The Schema（Schema 层）——一份告诉 LLM "Wiki 如何组织、约定是什么、摄取/问答/维护时应遵循什么工作流"的文档（Claude Code 用 CLAUDE.md、Codex 用 AGENTS.md 是常见载体）。这是关键配置文件——正是它让 LLM 成为"训练有素的 Wiki 维护者"而非"通用聊天机器人"。Schema 由你与 LLM 随着实践共同演进。

仓库中的实例化：schema.md 与 purpose.md

llm_wiki 在落地时保留了 Schema 层（每个项目根目录的 schema.md），并额外引入了原模式没有的 purpose.md——"Wiki 的灵魂"，定义目标、关键问题、研究范围与演进中的论点，LLM 每次 ingest 和 query 都会读取它获取上下文，并可根据使用模式建议更新。创建项目时，应用会同时写入 schema.md 和 purpose.md（见 create-project-dialog.tsx）。

从源码 templates.ts 可见，项目内置了 Research、Reading、Personal Growth、Business、General 五套场景模板，每套模板的 schema 都覆盖六类基础要素：

Schema 要素	内容示例（来自 templates.ts）
页面类型（Page Types）	entity→wiki/entities/、concept→wiki/concepts/、source→wiki/sources/、query→wiki/queries/、comparison→wiki/comparisons/、synthesis→wiki/synthesis/、overview→wiki/（每项目一份）
命名约定（Naming Conventions）	文件一律 kebab-case.md；实体用官方名（openai.md、gpt-4.md）；概念用描述性名词短语（chain-of-thought.md）；资料用 author-year-slug.md（wei-2022-cot.md）；问题用问句 slug
YAML Frontmatter	所有页面含 type / title / tags / related / created / updated；source 页另含 authors / year / url / venue
索引格式（Index Format）	wiki/index.md 按类型分组列出所有页面，每项 - [[page-slug]] — 一句话描述
日志格式（Log Format）	wiki/log.md 按时间倒序记录活动：## YYYY-MM-DD 下的动作条目
交叉引用与矛盾处理	用 [[page-slug]] 链接；矛盾时在相关页面记录、建立 query 页跟踪、链接双方资料、证据充足后写入 synthesis 页解决

各模板还会追加领域专属页面类型与 frontmatter：Research 模板增加 thesis（含 confidence、status）、methodology、finding（含 source、replicated）；Reading 模板增加 character（含 role）、theme、plot-thread、chapter（含 pages）；Personal 模板增加 goal（含 progress）、habit（含 streak）、reflection、journal；Business 模板增加 meeting（含 attendees、action_items）、decision（ADR 风格，含 supersedes）、project、stakeholder。这些正是"Schema 让 LLM 成为有纪律的维护者"的直观体现。

三大核心操作：Ingest、Query、Lint

Ingest（摄取）

把一份新资料丢进原始资料集，告诉 LLM 处理它。文档给出的示例流程：LLM 阅读资料 → 与你讨论要点 → 在 Wiki 写一份摘要页 → 更新索引 → 更新相关实体页与概念页 → 在日志中追加一条记录。一份资料可能触及 10–15 个 Wiki 页面。文档建议倾向"逐份摄取 + 保持参与"（你读摘要、检查更新、引导 LLM 强调什么），但也支持低监督批量摄取；具体工作流由你自行发展并写进 schema，供后续会话复用。

llm_wiki 将这一步骤强化为两步链式思考（Two-Step Chain-of-Thought）：Step 1 先让 LLM 读源并产出结构化分析（关键实体/概念/论点、与现有 Wiki 的关联、矛盾与张力、结构建议）；Step 2 再让 LLM 基于分析生成 Wiki 文件（含 frontmatter 的摘要页、带交叉引用的实体/概念页、更新的 index.md/log.md/overview.md、待人工判断的 review 项、供 Deep Research 用的搜索词）。在 ingest.ts 中还能看到对模式文档的进一步工程化：

• SHA256 增量缓存：源文件内容先哈希再摄取，未变更文件自动跳过，节省 token 与时间；
• 持久化摄取队列：串行处理避免并发 LLM 调用，队列持久化到 .llm-wiki/ingest-queue.json，应用重启后仍存活，失败任务自动重试——ingest-queue.ts 定义了 MAX_RETRIES = 3；
• 源文件夹自动监听：raw/sources/ 外部新增/编辑/删除会自动触发与应用内一致的 ingest/删除生命周期；
• 源头可追溯：每个生成的页面在 YAML frontmatter 中带 sources: [] 字段，回链到贡献它的原始文件。

Query（查询）

你向 Wiki 提问。LLM 搜索相关页面、阅读它们、带引用地综合答案。答案形式可随问题而异——Markdown 页、对比表、幻灯片（Marp）、图表（matplotlib）、画布。文档强调一个关键洞见：好答案可以归档回 Wiki 变成新页面。你要求的对比、一次分析、发现的联系都是有价值的，不应消失在聊天记录里——这样你的探索会像摄取进来的资料一样在知识库中复利。

llm_wiki 的对应实现：聊天会话的 Save to Wiki 功能会把有价值的回答归档到 wiki/queries/，随后自动 ingest 以把实体/概念提取进知识网络；Deep Research 生成的成果页同样保存到 wiki/queries/（如 deep-research.test.ts 中 wiki/queries/research-topic.md 的保存路径）。

Lint（体检）

定期请 LLM 对 Wiki 做健康检查，查找：页面之间的矛盾、被新资料取代的过时论断、没有入链的孤立页、被频繁提及却缺少独立页面的重要概念、缺失的交叉引用、可通过联网搜索填补的数据缺口。LLM 还擅长建议值得研究的新问题、值得寻找的新资料——这让 Wiki 在增长中保持健康。

llm_wiki 实现了完整的 Lint 系统（lint.ts）：先是结构性检查（类型为 orphan、broken-link、no-outlinks 等，见 lint.ts，且 index.md/log.md 会被排除在孤立页检查之外），再让 LLM 对页面摘要做语义分析，输出四类问题（lint.ts）：

• contradiction：两个或多个页面存在冲突论断；
• stale：信息看起来过时或被取代；
• missing-page：重要概念被大量引用却无专属页面；
• suggestion：值得加入 Wiki 的问题或资料。

每条结果以结构化块（---LINT: type | severity | title--- / PAGES: ... / ---END LINT---）输出，便于解析与展示，并会过滤掉"页面其实已存在"的误报。

索引与日志：index.md 与 log.md

两个特殊文件帮助 LLM（和你）在 Wiki 增长时导航，二者用途不同：

index.md 面向内容。它是 Wiki 中所有内容的目录——每个页面列出链接、一句话摘要、可选元数据（日期、来源数），按类别（实体、概念、资料等）组织。LLM 每次摄取都会更新它。查询时 LLM 先读 index 找到相关页面，再深入阅读——在中等规模（约 100 份资料、数百页）下效果出奇地好，且避免了嵌入向量式 RAG 基础设施。

log.md 面向时间。它是只追加（append-only）的"何时发生了什么"记录——摄取、查询、lint 均记入。文档给出一个实用技巧：如果每条记录以统一前缀开头（如 ## [2026-04-02] ingest | Article Title），日志就能用简单的 Unix 工具解析：

grep "^## \[" log.md | tail -5

即可得到最近 5 条记录。日志提供了 Wiki 演化的时间线，帮助 LLM 理解近期完成过什么。

llm_wiki 在实现中把 index.md、overview.md、log.md 视为应用拥有的聚合文件（ingest.ts 中的 AGGREGATE_WIKI_PATHS）：即使模型输出遗漏了 log.md，应用也会自动追加一条摄取日志条目（ingest.ts），并明确指示模型不要自行生成这三个聚合文件，从而保证大 Wiki 不会被模型输出整体重写。

可选：CLI 工具（本地搜索）

随着 Wiki 增长，你可能想构建帮助 LLM 更高效操作 Wiki 的小工具。搜索是其中最显而易见的——小规模下 index 文件足够，但 Wiki 变大后需要真正的搜索。文档推荐了 [qmd]（原文档中链接的工具，本地 Markdown 搜索引擎，提供混合 BM25/向量检索与 LLM 重排，全在本地设备运行）：它既有 CLI（LLM 可 shell 调用），也有 MCP server（LLM 可当作原生工具）。你也可以自建更简单的方案——LLM 能帮你即兴编写一个朴素的搜索脚本。

说明：本仓库未内置 qmd，但提供了等价能力——tokenized 搜索 + 图谱相关性扩展的可选向量语义检索（LanceDB），以及供外部 Agent 调用的本地 HTTP API 与 MCP server（详见 README.md 的 "Local HTTP API + MCP Server" 一节）。

实用技巧

• Obsidian Web Clipper：浏览器扩展，把网页文章转成 Markdown，非常适合快速把资料送入原始资料集。llm_wiki 更进一步提供了自研的 Chrome 扩展（extension/ 目录，Manifest V3），基于 Mozilla Readability.js 提取正文、Turndown.js 转 Markdown，裁剪后自动触发两步 ingest。
• 本地化下载图片：Obsidian 设置 → Files and links，把 "Attachment folder path" 设为固定目录（如 raw/assets/）；再到设置 → Hotkeys 搜索 "Download"，为 "Download attachments for current file" 绑定快捷键（如 Ctrl+Shift+D）。裁剪文章后按下快捷键，所有图片即下载到本地磁盘。这是可选但有用的做法——让 LLM 能直接查看、引用本地图片，而不是依赖可能失效的 URL。注意：LLM 无法在单次读取中直接阅读含内嵌图片的 Markdown，变通方案是让 LLM 先读文本，再单独查看部分或全部引用图片以获得额外上下文——有点笨拙，但足够好用。
• Obsidian 图谱视图：观察 Wiki 形态的最佳方式——什么连着什么、哪些页面是枢纽、哪些是孤儿。
• Marp：基于 Markdown 的幻灯片格式，Obsidian 有对应插件，可直接从 Wiki 内容生成演示文稿。
• Dataview：Obsidian 插件，对页面 frontmatter 运行查询。若 LLM 为 Wiki 页面添加 YAML frontmatter（标签、日期、来源数），Dataview 就能生成动态表格与列表。
• Git 仓库：Wiki 本质上就是一个 Markdown 文件的 git 仓库——免费获得版本历史、分支与协作能力。

为什么这套模式有效

维护知识库最繁琐的部分不是阅读或思考，而是记账：更新交叉引用、保持摘要新鲜、标注新数据与旧论断的矛盾、维持几十个页面的一致性。人放弃 Wiki 是因为维护负担的增长快于价值的增长。而 LLM 不会厌倦、不会忘记更新交叉引用、一次能触碰 15 个文件——维护成本趋近于零，Wiki 因此得以持续维护。

人的工作是策展资料、引导分析、提出好问题、思考这一切意味着什么；LLM 的工作是其余所有事。

这一思想与 Vannevar Bush 1945 年提出的 Memex 精神相通——一个私人的、精心策展的、文档间带关联路径的知识存储。Bush 的愿景比 Web 最终演变成的样子更接近于此：私密、积极策展、文档之间的联系与文档本身同等重要。他当时无法解决的问题是"谁来维护"——LLM 恰好补上了这一环。

结语：模式抽象，按需取用

正如文档结尾所述：这份文档刻意保持抽象，描述的是思想而非具体实现。确切的目录结构、Schema 约定、页面格式、工具链——都取决于你的领域、偏好与所选的 LLM。文中所有内容都是可选、模块化的——取你所需，忽略其余：例如你的资料全是纯文本，就不需要图片处理；Wiki 足够小，index 文件就够用，无需搜索引擎；你不在乎幻灯片，只要 Markdown 页面；你可能想要完全不同的输出格式。正确的用法是把它分享给你的 LLM Agent，协作实例化一个适合你的版本——文档唯一的职责是传达模式，其余细节交给 LLM 解决。llm_wiki 项目正是这条路径的一个完整示范：它保留了抽象模式的全部骨架，并用桌面应用、知识图谱、Deep Research 等工程化能力让这套模式开箱即用。