LLM Wiki
定义
LLM Wiki 是一种知识组织与问答工作模式：先让大模型把原始资料持续整理、重写、交叉引用并沉淀成结构化 Markdown wiki，再让后续查询和回答优先建立在这套 wiki 上，而不是每次都重新从原始材料开始理解。
在本文语境里，它被明确拿来对比 RAG 式做法。后者更倾向于在用户提问时，从 raw documents 里即时捞取 chunk，再现场拼接回答；前者则强调先 ingest、再沉淀、再复用，使知识在多次处理后成为一个可维护、可审计、可交叉引用的知识库。
原文概括得很直接：RAG 更像“每次重算”，LLM Wiki 更像“持续编译”。两者不是绝对对立，但默认重心不同。
与传统 RAG 的区别
RAG 的默认模式
传统 RAG 的工作重心，通常放在“问的时候再去找”：
- 原始材料保持为文档集合
- 用户提问后再检索相关 chunk
- 模型基于临时取回的片段拼出答案
- 这次问答中形成的理解，往往不会自动沉淀成长期知识资产
这种方式的优点是启动快、对原文改写少，但问题也很明显：模型每次都要重新做一遍定位、理解、拼接，理解过程本身不太会累积。
LLM Wiki 的默认模式
LLM Wiki 则把重点前移：
- 先收集 raw sources，例如文章、论文、会议记录、代码讨论
- 再由 LLM 读取并更新 wiki 页面
- 页面类型不是单一摘要，而是一组互相支撑的页面结构
- 以后再问问题时，Agent 优先先读 wiki，再组织回答
原文点名的沉淀页面包括：
- summary
- entity page
- concept page
- overview
- index
- log
也就是说，LLM Wiki 不把“理解”只发生在回答那一刻，而是把理解前置为一种持续维护行为。
原版 LLM Wiki 的最小结构
原版 LLM Wiki 的设计非常克制，核心是一个清晰的三层结构。
1. Raw sources
原始材料层保存原文，关键约束是：不被 LLM 修改。
这层的作用不是输出最终知识页面，而是作为证据和追溯基础存在。这样做的意义在于：
- 原始上下文不因总结而丢失
- 后续可重新校验 LLM 写入内容
- 审计时可以回溯知识从何而来
2. Wiki
第二层是由 LLM 维护的 Markdown 页面，也就是知识库本体。
这一层不是简单复制原文，而是把信息整理成适合长期维护的页面：
- 概念页解释某个术语或方法
- 实体页记录人物、项目、系统、工具等对象
- summary 页压缩单个来源的要点
- overview 和 index 用来组织入口与导航
- log 记录 ingest、更新、决策和维护轨迹
这正是“wiki 会累积理解”的核心。
3. Schema
第三层是 schema，也就是规则文件，例如文中提到的 CLAUDE.md、AGENTS.md 一类。
它的作用不是存知识，而是规定：
- 页面应如何写作
- 维护动作应如何执行
- 交叉引用如何补齐
- 更新时应遵守哪些边界
- 什么内容该自动改，什么内容该交给人审
因此，原版最小结构可以概括为：
- raw sources：原始材料，不被 LLM 修改
- wiki：LLM 维护的 Markdown 页面
- schema：规定写作与维护规则
在本文中的语境
本文把 LLM Wiki 视为一种“让知识持续复利”的工作模式，而不是单次问答技巧。
原文使用了一个很贴切的类比：
- Obsidian 像 IDE
- LLM 像 programmer
- wiki 像 codebase
这个类比的重点是：wiki 不是静态笔记堆，而是一个可持续维护的知识代码库。模型不是只在用户提问时临时回答，而是在平时也承担整理、重构、补链、查缺补漏的维护任务。
运行角色分工
LLM Wiki 并不意味着“全自动替代人”。原版模式下，人和 LLM 的职责分工很明确。
人负责什么
人主要负责高判断成本的工作，包括：
- 选择值得建立和维护的主题
- 决定哪些材料应进入知识库
- 判断页面是否写对、写全、写偏
- 审核重要更新
- 在冲突信息之间做最终取舍
换句话说，人负责选题、判断和审阅。
LLM 负责什么
LLM 则负责高频、繁琐、结构化的维护工作，包括：
- 整理原始资料
- 生成或更新摘要页
- 拆分并维护 entity page 与 concept page
- 补全 双链 和交叉引用
- 更新 overview 和 index
- 发现并提示孤儿页
- 维护 log 与改动痕迹
这种分工的意义，不在于完全自动化，而在于把“高频维护成本”交给模型，把“最终判断权”保留给人。
关键机制与最小运行闭环
原文对原版的最小闭环有一个很明确的总结：用最少的东西先跑起来。
典型最小集合包括：
- raw
- wiki
- schema
- index
- log
- ingest
- query
- lint
ingest
ingest 是把新资料纳入知识库的入口。每次 ingest 后，Agent 不应只把原文丢进仓库，而是要更新相关页面。
MVP 阶段的验收标准也很朴素：一次 source 输入后，系统应能稳定更新 summary、entity、concept、index、log，并且人能看懂每个 Git diff。
query
query 阶段的核心思想是：后续问答优先读 wiki，而不是反复从原始材料重新开始。
这意味着查询本身使用的是“已经沉淀过的理解”，而非每次都对 raw source 重新做全量认知计算。
lint
lint 则承担知识库维护检查功能，例如：
- 页面是否缺少链接
- 是否存在孤儿页
- 某些 claim 是否过期
- index 是否缺入口
- 结构是否违反 schema
原版中，对“知识变旧”的处理还比较轻，更多是通过 lint 发现 stale claim。
核心价值：知识会复利，理解会累积
本文强调 LLM Wiki 的价值，不是“回答得更花哨”，而是“知识资产能积累”。
具体体现在几个层面：
1. 不再每次都从原始材料开始
如果每次问答都重新从 raw documents 捞 chunk，那么系统虽然能回答，但对同一批材料的理解不会稳定沉淀。
LLM Wiki 的思路是把多次 ingest 形成的理解留下来，使后续问题站在前次整理结果之上继续推进。
2. 知识结构会越来越完整
随着更多资料进入系统，wiki 不只是页数增加，还会出现：
- 更完整的概念解释
- 更细的实体关系
- 更可用的 index
- 更清楚的 overview
- 更连续的 log 和演化轨迹