AI-Wiki

定义

增量更新，是指在 LLM Wiki Layer 已经建立之后，当出现新资料时，不重新让模型从头读取和重建全部原始资料，而是仅处理新增或变更的部分，并将处理结果合并进现有 Wiki。

它针对的是一种常见低效模式：每次有新内容就把整批资料重新喂给模型、重新清理、重新结构化、重新建链接。增量更新要避免的正是这种“每次从头开始”的工作方式。

在本文语境里，它是 Wiki 层“持续维护”能力的一部分：系统先对原始资料做一次性结构化处理，生成可供后续交互使用的 Markdown 知识库；之后所有交互主要围绕 Wiki 展开，而当有新资料进入时，执行的是对 Wiki 层的增量维护，而不是对全部原始文件的全量重建。

在本文档中的具体语境

该概念出现于对 Andrej Karpathy 所提出的 LLM Wiki Layer 工作方式的说明中。原文把工作流程概括为四步：

一次性处理全部原始资料，由 LLM 完成清理、结构化和建立链接。
生成干净、结构化的 Markdown 知识库。
后续交互基于这个 Wiki 进行，而不再反复读取原始资料。
当有新资料时，执行自动更新，也就是增量更新 Wiki 层，而不是重建整个系统。

因此，增量更新不是脱离上下文的通用术语，而是 LLM Wiki Layer 设计中的关键运行机制。它服务的目标非常明确：当数据集合不断扩展时，Wiki 仍能持续演化，而不会因为每次新增资料都触发全量重算，导致 Token、时间和维护成本失控。

为什么重要

支撑持续维护

如果没有 增量更新，知识库每次遇到新增资料都要重新处理全部内容，那么系统很难长期运行。随着资料数量从十几份增长到数百、数千份，全量重建会越来越慢，也越来越贵。

而增量更新让 Wiki 层从“一次性整理结果”变成“可持续维护的知识系统”。这正呼应原文对 Wiki Layer 的定位：它不是临时缓存，而是一个持续进化的 AI 知识库。

降低重复成本

原文批评的核心问题之一，就是模型反复读取同一批资料，造成 Token 疯狂消耗、效率极低。增量更新直接解决这一点：

已经处理过、且未变化的内容，不需要再次清理和结构化；
已经建立好的页面、元数据和内部链接，不需要从头生成；
模型只需要把计算资源放在新增或变化的部分上。

这与原文给出的整体收益一致：Wiki Layer 的总体效果是 Token 消耗可减少 70%-90%，而增量更新正是支撑这一收益能在长期使用中持续成立的重要机制之一。

让知识库适应不断扩展的数据集合

原文明确指出，Wiki 层适合“数据在不断更新或扩展”的场景，也强调知识库可扩展到数百甚至数千文档。要实现这种可扩展性，不能依赖每次全量重建；必须依赖一种只处理差异的维护方式，这就是 增量更新。

换句话说，增量更新不是锦上添花，而是让 LLM Wiki Layer 真正适用于长期知识积累场景的基础条件。

与原始资料不可变规则的关系

原始资料是单一真相源

原文把原始资料所在位置定义为“单一真相源”，并明确要求：原始文件不可手动编辑。这个规则非常关键，因为它划定了 增量更新 的作用边界。

在这一架构中：

原始资料负责保存最初采集到的原貌内容；
Wiki 负责保存清理、结构化、链接化之后的知识表达；
更新动作发生在 Wiki 层，而不是通过人工改写原始资料来“同步”知识库。

因此，增量更新并不意味着去改动原始资料库本身，而是意味着：当原始资料库中出现新增内容，或某份资料被系统识别为有新版本时，Agent 依据规则重新处理相关差异，并把结果合并进 Wiki。

更新的是知识表达，不是事实源本身

这是一个常见误解：很多人会把“更新知识库”理解为“覆盖旧文件”。但在本文的语境中，事实源始终保留在原始资料层，Wiki 只是围绕这些资料形成的结构化知识层。

所以，增量更新更准确地说，是对知识表达层的维护：

补充新页面；
修改受影响页面的结构化内容；
更新内部链接与元数据；
在必要时处理新旧版本之间的冲突。

它不是把过去的积累简单抹掉后重写一遍，而是在保留知识库整体连续性的前提下进行演化。

关键机制与组成

虽然原文没有展开算法细节，但已经给出了构成 增量更新 的几个必要要素。

1. 差异驱动，而不是全量重跑

最核心的机制就是只处理“新增或变更部分”。这意味着更新的触发逻辑不是“项目里有任何新动作，就全部重建”，而是“识别出哪些资料是新的、哪些内容受影响，再只处理这些部分”。

这一定义本身，就是它区别于一次性初始化构建的关键。

2. 合并进现有 Wiki，而不是另起一套知识库

原文强调的是“把结果并入现有 Wiki”。这说明更新后的产物应继续留在原来的知识体系中，包括：

延续既有页面组织；
延续既有 Markdown 结构；
延续内部双链 页面名称；
延续既有元数据要求。

也就是说，增量更新的目标不是生成一批孤立的新文件，而是维护同一个持续演化的 Wiki。

3. 依赖预先定义的规则文件

原文将“指令与模板”列为 Wiki 层三大核心组件之一，并明确指出规则文件中不仅要定义清理标准、模板规则、链接创建逻辑、元数据字段要求，还要定义“知识库更新策略”以及“Agent 如何处理更新和冲突”。

这意味着 增量更新 不是临时拍脑袋决定怎么改，而是需要预先制度化。至少在概念上，规则文件需要回答以下问题：

新资料进入后，采用什么模板；
哪些页面需要新建，哪些页面需要补充；
内部链接如何追加或修正；
遇到内容冲突时按什么原则处理；
哪些元数据字段必须更新。

没有这些预定义规则，所谓“增量更新”就容易退化为不稳定的、一次一议的人工覆盖。

4. 自动维护能力

原文在工作原理中直接使用“自动更新”来描述这一过程，说明 增量更新 理想上是由 Agent 按规则执行的持续维护流程，而不是每次都依赖人工重新整理所有资料。

这与 Loop Engineering 的思路也能形成呼应：真正可长期运行的系统，不是只会做一次转换，而是能在条件触发时按既定规则继续维护状态。

细节与边界

###增量更新 不等于简单覆盖

这是本文必须强调的边界。增量更新 的重点不是“拿新内容把旧内容替换掉”，而是面向长期知识积累的维护方式。

与简单覆盖相比，它至少多了三层要求：