AI-Wiki

文档概览

这篇文章是一个面向普通实践者的介绍性方案文，核心在于解释为什么与大模型协作时，反复上传同一批文件是一种高成本、低连续性的工作方式，并提出以 LLM Wiki Layer 替代“每次都从原始文件重新读起”的流程。

文中的中心论断非常明确：不要每次让模型读原始文件，而是让它读取一个持续维护、结构化的知识库。 这个知识库以 Markdown 为主要承载格式，并通过内部链接、元数据和页面关系形成可持续更新的知识层。

文章把这一做法归纳为四步工作原理：

一次性处理原始文件。
生成结构化 Markdown Wiki。
后续交互主要基于 Wiki，而不是再去重复读取原始文件。
当新增资料出现时，只做增量更新，而不是整体重建。

原文给出的效果判断是：Token 消耗可减少 70% 到 90%，并且答案质量会显著提升。

要解决的问题

文章开头首先指出一个常见但经常被忽略的现象：如果用户经常使用 ChatGPT、Claude 或 Gemini 处理文档，很可能一直在重复上传同样的文件。

原文列出的后果有四项，而且都很具体：

Token 疯狂消耗：同样的 PDF、笔记、资料，在每次提问时都要重新读取、重新理解、重新处理，因此每轮都要为重复读取付费。
上下文丢失：模型无法在多个文件之间建立持久联系，跨文档关系每次都要重新恢复。
答案质量下降：因为重复处理时信息被切碎，重要关系容易被忽略，回答更容易碎片化。
效率低下：同样的问题，每次都要从头推理，无法站在已经整理过的知识结构上继续工作。

原文还给出了一个更强的判断：这不只是用户操作不熟练，而是传统 RAG 使用方式的一类根本缺陷。这里的批评重点不在检索本身，而在于系统没有形成可持续的、结构化的知识中间层，导致每次都像第一次处理资料。

核心方案：LLM Wiki Layer

文章把解决方案归于 Andrej Karpathy 提出的思路：建立一个“Wiki 层”，作为原始资料与后续 LLM 交互之间的长期知识中间层。

其核心表述可以直接概括为：

不要每次让模型读原始文件，而是读一个持续维护、结构化的知识库。

这个知识库不是临时摘要，也不是单次会话缓存，而是一个可以不断维护、不断更新、可以被人和模型共同使用的 Markdown Wiki。

与直接把原始资料塞给模型不同，Wiki 层强调先做一次系统性的知识整理：

先读取全部原始资料。
再清理噪声与格式垃圾。
把内容转换为干净、统一、可链接的 Markdown 页面。
通过页面间链接和元数据建立持久关系。
之后的大部分问答、写作和检索，都优先基于这层知识库进行。

这样，模型每次接触的就不再是杂乱无章的原始文件集合，而是已经提炼、关联、结构化过的知识系统。

工作原理四步

原文将 LLM Wiki Layer 的工作原理明确拆成四个步骤。

1. 一次性处理原始文件

在初始阶段，LLM 会读取全部原始资料。这里的重点不是“每次问答都读”，而是“首次集中处理一次”。

处理内容包括：

清理无关噪声。
去掉广告与技术垃圾。
重新组织内容结构。
抽取可长期保留的信息。
为后续链接和页面组织做准备。

2. 生成结构化 Markdown Wiki

处理后的输出不是继续保留在原格式里，而是生成一套干净、结构化的 Markdown 页面，形成 Wiki 知识库。

这一点很关键，因为文章强调的是“结构化”和“可维护”，而不仅仅是“把文件转成文本”。生成后的 Wiki 具备以下特征：

内容已经清洗过。
页面结构统一。
可插入元数据。
可建立内部链接。
可形成文档关系图谱。

3. 后续交互基于 Wiki

一旦 Wiki 层建立完成，后续主要交互对象就不再是 raw/ 中的原始资料，而是 wiki/ 中已经沉淀好的知识页面。

也就是说，用户不用在每次提问时重新上传几十个文件，而是可以直接告诉模型使用 wiki/ 中的知识库数据。模型面对的是更短、更干净、更有关联的信息集合，因此响应效率和答案质量都会更高。

4. 新资料到来时做增量更新

文章特别强调，新增资料出现时，应该更新 Wiki 层，而不是重头再处理全部内容。

这意味着该方案追求的是持续演化，而不是一次性构建后静态存放。随着新文档、新笔记、新网页不断进入，系统只需要把新部分并入既有知识结构中，保持知识库长期可用。

效果判断与量化收益

原文给出了一个非常醒目的量化判断：

Token 消耗减少 70%–90%。
答案质量显著提升。

70%–90% 这一范围的含义是：节省幅度并非固定值，而会取决于资料是否重复使用、原始文件有多大、后续交互频率多高、知识是否经常扩展等因素。但文章的立场很明确：只要你在反复处理同一批资料，Token 浪费通常就会非常明显，而 Wiki 层正是为了解决这种重复成本。

答案质量提升的原因，按照原文逻辑，主要不是模型参数突然更强了，而是输入材料发生了变化：

信息已经被清理过，噪声更少。
内容已经结构化，重点更明确。
页面之间建立了关联，跨文档关系更容易保留。
不用在每次会话里从零开始恢复上下文。

三大核心组件

文章把 Wiki 层落地为三个主要组成部分，分别对应原始资料、结构化知识库和规则定义。

raw/：不可变的原始资料库

raw/ 用来存放所有原始材料。原文列举的类型包括：

HTML 网页
PDF 文档
文本笔记
截图图片
电子表格
任何原始数据

raw/ 的核心约束有两个：

它是单一真相源。
它永不手动编辑。

这意味着 raw/ 的职责不是美化内容，也不是给人日常阅读，而是作为最初事实材料的保留区。这样做的意义在于：

避免后续整理时把原始证据改坏。
保留可追溯来源。
让 Wiki 层的任何整理都可以回到原始材料核对。

wiki/：由 LLM 维护的核心知识库

wiki/ 是文章中的真正工作核心。这里存放的是由 LLM 自动生成和维护的 Markdown 文件，也是模型后续交互的主要工作空间。

原文明确列出 wiki/ 中会包含：

清理后的结构化内容
内部链接（如 页面名称）
元数据，如日期、作者、标签
文档间的关系图谱

与 raw/ 的“只存证、不编辑”不同，wiki/ 承担的是“知识表达层”的职责。后续问答、研究、写作、搜索、跳转，主要都发生在这一层。

instructions/：规则与模板定义处

文章将第三部分描述为独立的规则定义区域，用来存放配置、模板和处理策略。原文列出的规则类别包括：

数据清理标准，例如去除广告和格式垃圾
模板使用规则
链接创建逻辑
元数据字段要求
知识库更新策略

它的作用是把“如何整理知识”从临时口头要求变成稳定规则，从而让 Agent 的处理结果更一致，也更适合长期维护。

实操流程

文章给出了一个四步搭建流程，重点不是理论，而是如何真正把这个结构跑起来。

第一步：创建项目结构

原文给出的目录结构是一个最小可用模板，包含：

raw/：原始资料
wiki/：LLM 生成的知识库
instructions/：规则和模板
.claude/：Agent 配置

随后把所有现有资料都放入 raw/。这里强调的是：资料先统一进入原始资料区，再由后续流程进行结构化，而不是人工先散乱处理一遍。

第二步：启动结构化 Agent

文章建议在 Claude，或任何支持文件操作的强 LLM 中，配置专门的系统提示词，让 Agent 自动完成结构化处理。

原文列出的 Agent 具体动作包括：

清理文件中的技术垃圾、广告、无用格式
将所有内容转换为干净的 Markdown
应用预定义模板
创建内部 Wiki 链接，如 页面名称
添加元数据
建立文档间关系