LLM Wiki Layer
定义
LLM Wiki Layer 是一种面向大模型协作的知识中间层：先把原始资料一次性读全、清洗、结构化、补充元数据、建立文档间链接，再输出为可持续维护的 Markdown Wiki；此后模型的主要阅读对象不再是反复上传的原始文件，而是这套稳定演进的 Wiki 知识库。
它的核心思想很明确：后续交互基于持续维护的 Wiki，而不是每次重新读取原始 PDF、网页、笔记或电子表格。
这使它不仅是一个导出流程，更像一个长期存在的工作层。用户不是“每问一次就让模型重新理解一遍世界”，而是先把知识整理成模型容易消费的结构，再让模型站在这个结构上继续工作。
要解决的问题
LLM Wiki Layer 主要针对一个常见但常被忽视的浪费：用户在 ChatGPT、Claude、Gemini 等系统里处理文档时，经常会重复上传同一批资料，导致模型一遍又一遍重新读取、重新理解、重新推理。
原文归纳了这类重复读取带来的四个直接问题：
- Token 成本过高：同样的内容每次都要重新进入上下文，意味着重复付费或重复占用上下文窗口。
- 上下文不连续：模型无法在多次会话、多个文件之间天然保留稳定关系，需要每次重新拼装。
- 信息碎片化：答案建立在临时抽取和临时理解之上，跨文档的重要关系容易被忽略。
- 效率低：同样问题反复从头推理，系统缺乏“已经整理过”的中间结果。
在这一语境中，它也被当作对传统 RAG 工作方式的一种修正：不是每次从原始材料中临时检索、临时拼接，而是先把知识沉淀成一个长期可复用的表示层。
基本机制
LLM Wiki Layer 的基本流程可以概括为四步：
- 一次性处理原始资料：让 LLM 读取全部原始材料，而不是只在提问时临时读取局部片段。
- 完成清洗与结构化：去掉广告、格式噪声、技术垃圾等无关内容，整理成干净的 Markdown 表达。
- 建立链接与元数据：补充日期、作者、标签、摘要等字段，并创建文档间的内部链接，如
页面名称。 - 转入持续维护阶段：后续问答、写作、检索主要基于这套 Wiki；新资料到来时做增量更新，而不是整库重建。
这里最关键的不是“把文件转成 Markdown”本身，而是把原本零散、异构、重复解释的资料，变成一套可被模型稳定引用的知识图谱化文本层。
典型组成
原文将这种工作层拆成三类核心组成。
不可变原始资料区
这一层用于保存所有原始输入，可能包含：
- HTML 网页
- PDF 文档
- 文本笔记
- 截图图片
- 电子表格
- 其他原始数据
其边界非常明确：这里是“单一真相源”，只存放原始资料，不手工改写内容。这样做的目的，是把“原始输入”与“已整理知识”分开，避免人在整理过程中把源材料污染掉，也便于之后追溯、校验与重新处理。
Wiki 核心工作区
这是整个 LLM Wiki Layer 的中心。这里存放由 LLM 自动生成和维护的 Markdown 页面，通常包括：
- 清理后的结构化内容
- 文档内外的内部链接，如
条目 - 元数据字段，如日期、作者、标签、摘要
- 文档之间的关系表达与图谱化连接
后续大多数交互都应该优先基于这一层，而不是重新回到原始资料。换句话说，模型真正“读”的对象，从临时文件集合切换成了稳定的 Wiki 工作区。
指令与模板规则区
这一层不直接存知识，而是存“如何整理知识”的规则。原文提到，这些独立配置可定义：
- 数据清理标准，例如去广告、去格式垃圾
- 模板使用规则，不同文档类型套用不同结构
- 链接创建逻辑，决定哪些页面应互相连接
- 元数据字段要求，例如日期、作者、标签、摘要等必填项
- 知识库更新策略，包括新增资料与冲突处理方式
因此，LLM Wiki Layer 不是只靠模型临场发挥；它依赖规则区把清洗、结构化、链接和更新过程尽可能标准化、可重复化。
持续维护与增量更新
LLM Wiki Layer 的一个关键边界是：它不是一次性导出结果，而是持续维护的知识工作层。
如果把它当成“把一批文件转换成 Markdown 然后结束”的静态任务，就只完成了一半。原文强调，当有新资料进入时，应采用增量更新方式：只处理新增或变化部分，并把结果并入现有 Wiki，而不是把整个知识库推倒重来。
这种增量模式有几个现实意义：
- 保留已有页面、链接和关系结构，避免重复劳动；
- 让知识库能够随着资料增长持续演进；
- 使模型在后续协作中面对的是越来越完整的稳定语义层，而不是每次都换一套临时上下文。
这也解释了为什么它常被描述为一种“工作方式”或“范式转变”，而不只是一个小技巧。
在本文档语境中的理解
在本 Wiki 的语境里，LLM Wiki Layer 更接近 Context Engineering 的长期化、资产化版本：它不是只为某一次运行拼装上下文，而是先把领域知识沉淀成稳定的知识底座，再供后续检索、写作、分析与 Agent 使用。
如果说 Harness Engineering 更关注“一次运行如何配置环境、工具和约束”，那么 LLM Wiki Layer 关注的是“模型长期依赖哪一层知识表示来理解世界”。前者偏单次执行环境，后者偏持续积累的知识工作层。
它也与 Loop Engineering 可形成互补：循环系统可以围绕这套 Wiki 做检索、生成、验证和更新，而不必在每轮循环里都回到大量原始文件重新起步。
预期收益
原文给出的直接收益包括：
- Token 节省约 70%-90%；
- 回答质量提升，因为信息已先被清洗、结构化并建立关联；
- 检索效率提升，因为面对的是可全文搜索、可跳转的 Wiki，而不是零散原件；
- 可扩展性增强，知识库可扩展到数百甚至数千文档；
- 工作流更顺滑，可配合 Obsidian 形成可视化知识图谱与“第二大脑”式使用体验；
- 隐私更可控，原文强调数据可保留在本地而不必持续上传云端。
其中“70%-90%”是本文最醒目的量化收益，也是它被传播时经常与 Andrej Karpathy 关联的原因之一。
适用场景
原文给出了较明确的适用条件。通常在以下情况，建设 LLM Wiki Layer 的收益会更明显：
- 同一主题下已经积累了 10-20 个以上文档；