LLM Wiki 方法论：让 AI 维护一座可增长的知识库

LLM Wiki 是一种把 AI 放进知识管理流程的方法：人负责策展和判断，LLM 负责阅读、整理、交叉引用和维护 Wiki。它不是把资料丢进一个聊天窗口，而是让知识以 Markdown 页面、索引和关系网的形式长期沉淀。

传统 RAG 更像查询时系统：用户提问，系统检索片段，把片段塞进上下文，再让模型回答。LLM Wiki 更像编译时系统：资料先被整理成结构化知识页面，之后的查询和写作都基于这座持续更新的 Wiki。

为什么普通笔记会失控

个人知识库通常不是死在“没有开始”，而是死在“无法维护”。刚开始记录时，任何笔记都很有价值；半年后，问题会集中出现：

• 同一个概念被重复写了多次。
• 旧链接失效，但没人发现。
• 原始资料很多，真正可复用的总结很少。
• 文章、论文、项目记录之间没有关系。
• 搜索能找到关键词，却找不到结构化答案。

LLM Wiki 的核心目标，是让维护成本降下来。模型不怕重复劳动，适合做摘要、归档、交叉引用、索引更新和一致性检查；人类则保留判断权，决定哪些资料值得进入系统，以及哪些结论可以对外发布。

三层结构

raw/        原始资料，不直接改写
wiki/       模型生成和维护的 Markdown 知识页
AGENTS.md   约束模型如何阅读、整理、更新和校验

raw：事实来源

raw/ 适合保存不可变的原始资料，例如：

• 文章全文。
• 论文 PDF 或摘录。
• 访谈 transcript。
• 项目会议记录。
• 截图、数据文件、原始链接。

这一层尽量只读。它的价值是可追溯：当 Wiki 页面里的结论需要复核时，可以回到 raw 资料查证。

wiki：可维护知识

wiki/ 是 LLM 主要工作的地方。它可以包含：

• 概念页：解释一个技术概念。
• 实体页：记录一个项目、人物、公司、工具。
• 来源摘要：把长资料整理成结构化摘要。
• 对比页：比较多个方案的边界和选择条件。
• 索引页：把分散页面串起来。

Wiki 页面不是一次性摘要，而是可持续更新的知识节点。每次新增资料，都可能更新多个相关页面。

AGENTS：维护规则

如果没有规则，模型很容易把知识库写成风格混乱的散文。AGENTS.md 或类似规则文件，需要说明：

• 哪些目录可读，哪些目录可写。
• frontmatter 必须包含哪些字段。
• 引用和来源怎么标注。
• 什么时候创建新页面，什么时候更新旧页面。
• 如何处理不确定信息。
• lint 或检查命令是什么。

这个文件相当于知识库的开发规范。

三个核心动作

收录

收录不是简单复制，而是把资料放到系统里：

1. 读取 raw 资料。
2. 判断资料类型。
3. 生成来源摘要。
4. 更新相关概念页。
5. 补充索引页或对比页。
6. 标注来源和置信度。

好的收录结果应该让未来的自己不用重新读完整资料，也能理解它的价值和适用边界。

查询

查询时，LLM 不应该只凭上下文窗口临时发挥，而应该读取已有 Wiki 页面，再回到 raw 来源核对关键事实。回答里要说明哪些是已记录知识，哪些是推断，哪些需要后续验证。

检查

检查是 LLM Wiki 的维护关键。可以定期让模型做：

• 查找孤立页面。
• 查找重复概念。
• 查找缺少来源的结论。
• 查找过期工具、价格、版本号。
• 更新索引和导航。

这类工作人类很容易拖延，但模型适合持续做。

和 RAG 的关系

RAG 是查询时范式：知识在提问时临时组装。

LLM Wiki 是整理时范式：知识提前被整理成结构化页面，并在之后持续维护。

二者不是互斥关系。RAG 适合从大量原始资料里快速找片段，LLM Wiki 适合把已经理解过的内容沉淀成长期知识。

和博客的关系

知识库适合保存完整过程，博客适合发布经过筛选和编辑的内容。一个实用流程是：

raw 资料 -> wiki 消化 -> 博客文章 -> 项目复盘或作品集

这也是当前博客的方向：它不是把知识库原封不动公开，而是从知识库中选出适合外部阅读的条目，整理成更清晰的文章。

公开博客要比 Wiki 更克制：删掉内部路径、去掉不完整推断、补足读者背景、明确适用场景。这样文章才不是知识库切片，而是一篇真正能被外部读者理解的技术博客。