LLM Wiki
编译摘要
1. 浓缩
- 核心结论1: LLM Wiki 的关键不是"把文档交给模型回答"，而是在 raw source 与查询之间建立一个持久、可维护、可链接的编译层。
- 关键证据: 传统 RAG 在每次查询时重新检索片段、重新拼接答案；LLM Wiki 则在新增 source 时先读取、提炼、整合到 wiki，更新 entity、topic、comparison，并标记新旧判断的冲突。
- 这意味着知识不再只在一次聊天中临时生成，而是变成可继续维护的 Markdown 资产。交叉引用、矛盾、综合判断和索引都可以被后续问题复用。
- 核心结论2: 该模式的基础架构是三层：不可变 raw sources、由 LLM 维护的 wiki、约束 LLM 行为的 schema。
- 关键证据: raw 是 source of truth，LLM 只读；wiki 是 LLM 生成和维护的结构化层；schema 类似
AGENTS.md 或 CLAUDE.md，规定目录、格式、工作流、命名、引用和维护规则。
- 作者把 Obsidian 类比为 IDE、LLM 类比为程序员、wiki 类比为 codebase。这个比喻揭示了 Wiki 不是静态笔记堆，而是需要持续重构、lint 和版本管理的知识代码库。
- 核心结论3: LLM Wiki 的操作闭环包括 ingest、query 和 lint，且 query 产物也可以回填为新页面。
- 关键证据: ingest 时，一篇 source 可能触及 10-15 个 wiki 页面；query 时，回答、对比表、分析和 slide deck 都可以作为有价值产物归档；lint 时，LLM 检查矛盾、过时判断、孤儿页、缺失链接和数据缺口。
- 这使知识库从"读后摘要"转向"研究系统"。人的角色是选择 source、提出问题和判断方向；LLM 负责交叉引用、归档、同步和维护这些低意愿但高价值的工作。
2. 质疑
- 关于"维护成本接近零"的质疑: LLM 可以降低格式整理和交叉引用成本，但不会自动保证判断正确。真正昂贵的部分会转移到 source 选择、证据审查、冲突裁决和 schema 设计。
- 关于规模的质疑: 作者认为中等规模下
index.md 足够好，但随着页面数量、同义概念和跨主题引用增长，单一索引会变成瓶颈。届时仍可能需要本地搜索、结构化 metadata、lint 脚本或混合检索。
- 关于一致性的质疑: Wiki 是会累积的资产，也会累积错误。早期错误定义如果被后续页面复用，会产生概念债务；因此 lint 不是附属功能，而是 LLM Wiki 能否长期可信的核心动作。
- 关于团队场景的质疑: 企业内部 wiki 涉及权限、隐私、审计、责任归属和人工 review。LLM 能维护页面，不等于组织已经解决"谁批准事实进入稳定知识层"的问题。
3. 对标
- 与 RAG 对标: RAG 更像运行时检索，LLM Wiki 更像提前编译。前者适合临时回答，后者适合长期研究、概念积累和多轮输出复用。
- 与编译器缓存对标: raw source 类似源码，wiki 类似中间表示和编译产物，schema 类似构建规则。每次新增 source 后重新整理相关页面，相当于增量编译知识。
- 与 Memex 对标: Memex 设想的是个人知识存储与关联路径；LLM Wiki 的新增条件是，LLM 可以承担维护关联路径的成本。
- 与软件工程对标: Wiki 需要 index、lint、git history、schema 和重构，这些都更接近 codebase 维护，而不是传统笔记管理。
关联概念