这个提示词去年还有意义：AI 系统中的机构知识衰减

当你从一位刚刚离职的工程师那里接手一个 AI 系统时，会有一种特殊的恐惧感袭来。系统提示词长达数百行，有一个叫 evals/ 的文件夹里存着 340 个测试用例却没有 README，代码中的注释写着 # 不要修改这里——找 Chen 问 而 Chen 已经联系不上了。

你不知道为什么客服机器人被禁止在星期二讨论定价，不知道哪些评估用例是为了捕捉六个月前的回归问题而写的，哪些只是随机示例，也不知道屏蔽某些产品类别的护栏究竟是法律要求、合规实验，还是某人因为某个副总裁看到了一条糟糕的输出而随手加上的。

系统还在运行。目前如此。但你无法安全地修改任何东西。

这就是 AI 系统中的机构知识衰减——它在结构上与工程师们抱怨了几十年的遗留代码问题截然不同。理解这种差异，是构建能够超越其创建者的系统的第一步。

为什么 AI 系统比代码衰减得更快

传统软件有一个救命稻草：它是静态的。你在 2021 年写的函数在 2021 年做的事，它现在还在做。你可能不知道为什么当初那样写，但至少行为是稳定且可检查的——你可以阅读代码。

AI 系统没有这种特性。三件事使它们对知识衰减特别脆弱：

模型更新会悄悄破坏提示词。 一月份精心设计的可靠提示词，可能在三月份因为底层模型更新而表现不同。与会抛出编译器错误的废弃库不同，模型更新是无声无息到来的。提示词还在运行，只是输出会以微妙的方式漂移，没有人注意到，直到某件重要的事情崩溃。

提示词的脆弱性不同于代码。 在系统提示词中修改一个句子——加上"简洁"这个词，调整语气指令，重新排列两个段落——都可能级联成意想不到的行为变化。这种依赖关系是语义层面的，不是语法层面的。没有类型系统来捕获回归。

评估数据集会在无人察觉中过时。 声称"覆盖 95% 的生产错误用例"的评估数据集，编码了一个在撰写当天成立的断言。随着模型改进、产品范围扩大、边缘案例转移，这个断言会悄悄变成错误。与废弃的 API 不同，没有任何废弃警告。

研究发现，大约 20-25% 的架构决策在两个月内就有了过期的证据，而 86% 的陈旧假设只在事故发生时被动地发现，而不是通过系统性追踪。

三种会衰减的制品

AI 系统中的机构知识集中在三类制品中，每一类的衰减方式都不同。

系统提示词

系统提示词是最明显的制品，但其背后的原理才是真正的知识。为什么指令放在末尾？（因为 LLM 预测下一个 token——如果把指令放在前面，模型可能在读到指令之前就开始生成内容。）为什么角色被定义为"有帮助但持怀疑态度的助手"而不只是"有帮助的助手"？（因为在测试中，更有帮助的变体幻觉引用的频率高出 30%。）为什么用户输入部分周围有分隔符？（因为没有它们，某些注入模式在早期测试中成功了。）

让做出这些选择的工程师离开，你就有了一个看起来武断的提示词。每次修改都变成了赌博，因为你不知道自己违反了哪些不变量。

提示词缺陷的分类将可维护性失败——硬编码的提示词、测试不足、文档不完善——列为与更明显的语义和结构缺陷并列的独特失败类别。可维护性失败往往导致其他失败，因为没有文档的提示词会被错误修改。

评估数据集

评估数据集是结晶成测试用例的知识。每个测试用例都编码了一个判断：这个输入应该产生这种输出，以及我们为什么关心到要对其进行测量。

当原理没有文档记录时，评估集就变成了货物崇拜工程学。团队通过他们不理解的测试，无法解释失败的测试，并基于感觉而不是有原则的覆盖率分析添加新用例。更糟糕的是，当模型更新以使以前失败的用例现在通过的方式改变行为时，没有人知道这是真正的改进还是被掩盖的回归。

评估事实表框架——一种评估文档的结构化方法——提出了每个评估数据集应该记录的五个维度：背景（谁创建了它以及为什么）、范围（它测量什么能力）、结构（数据组成和来源）、方法（操作程序）以及对齐（可靠性和有效性声明）。很少有团队系统地记录这五者中的哪怕一个。

护栏

护栏是知识衰减最危险的地方。阻止某些输出的护栏之所以存在，是因为有人决定收益大于成本。这个决定通常涉及上下文：法律审查、具体事故、合规要求、产品原则。当上下文消失时，你只剩下一条无法被质疑的规则。

问题不仅仅是护栏变得不透明——它们变得不可移动。团队不愿意删除或修改他们不理解的规则。所以护栏不断累积。为不再存在的失败模式设计的规则留在生产中。对旧模型版本有意义的规则与新模型产生摩擦。系统变得越来越脆弱，不是因为护栏是错的，而是因为没有人能判断哪些还是对的。

Meta 如何在规模上处理这个问题

Meta 内部数据管道工具说明了系统性知识提取在实践中的样子。他们的 AI 代理缺乏对散布在数千个代码库文件中的未记录设计模式、跨模块依赖关系和命名约定的理解。这些隐性知识只存在于工程师的脑子里。

他们的解决方案：一个使用 50 多个专门 AI 代理的预计算引擎，系统地提取和编码这些知识。每个代理回答每个模块的特定问题——这个组件配置什么、常见的修改模式是什么、哪些非显而易见的模式会导致失败、存在哪些跨模块依赖关系。产生的上下文文件是刻意紧凑的：每个 25-35 行，为可导航性而非全面性而构建。

结果是显著的。AI 上下文覆盖从 5% 扩展到 100% 的代码模块。以前需要约两天工程师咨询的任务在约 30 分钟内完成。质量分数在三轮审查中可量化地提高了。

"指南针，而不是百科全书"这一关键设计原则直接适用于 AI 系统文档。你不是试图捕获一切；你是试图给下一位工程师一个可靠的方向感，让他们能够安全地推理变化。

真正有效的文档原语

有几种具体制品可以解决这个问题，没有一种需要大量工具投资才能开始。

提示词原理文件。 在每个系统提示词旁边存储一个配套文件，记录：为什么结构是这样排序的，哪些具体措辞被测试后被拒绝了，提示词针对哪个模型版本进行了优化，以及主要版本之间发生了什么变化。这等同于你的提示词的提交信息——使代码有意义的上下文。

评估来源日志。 对于每个评估数据集，记录覆盖率声明（"设计用于捕捉三月份事故的回归，当时机器人在星期二给出了定价"）、组成原理（为什么是这些示例，以这个比例），以及任何模型版本依赖关系。当你添加一个测试用例时，添加一句话解释它防范什么失败模式。

护栏理由注释。 像安全控制一样对待护栏：记录威胁模型。这条规则防止什么失败模式？触发事件或决策是什么？重新考虑它的阈值是什么？一个过期日期或审查触发器（"如果我们升级到下一个主要模型版本则重新评估"）使维护契约变得明确。

带认识论标记的决策日志。 不是所有知识都同样可靠。基于 10,000 个示例的受控实验的决策与基于一个工程师直觉的决策是不同的。研究提出了三级认识论分类：猜想（L0）、有直接证据支持的实质性主张（L1），以及有多个独立验证的经过证实的主张（L2）。带有认识论级别文档的决策更容易适当地重新审视——你知道需要多少证据才能推翻它们。

保持文档活跃

未维护的文档变成了负担——它在实际系统漂移时给出错误的信心。三种做法有帮助：

模型更新时的自动评估触发器。 配置你的评估管道，在底层模型版本更改时自动运行。这不会告诉你什么崩溃了或为什么，但它告诉你发生了变化——这是知道文档需要审查所需的最低信号。

提示词版本控制作为一等实践。 像代码变更一样对待提示词变更：版本控制，经过审查，在提交信息或变更日志中捕获原理。"我们为什么改变这个？"这个问题应该始终可以从仓库历史中得到回答。

明确的有效期窗口。 有些文档无限期有效；其他文档会过期。一个写着"这个评估集是为 GPT-4 上下文窗口设计的"的注释，应该在模型更改时触发审查。使有效条件变得明确——而不是希望有人会记得检查——是有帮助的文档和误导性文档之间的区别。

组织问题

没有所有权，文档就不会发生。更深层的问题是：随着团队变化，谁负责确保 AI 系统保持可解释性？

在认真思考过这个问题的组织中出现的模式是将基础设施和内容所有权分离。平台团队拥有版本控制基础设施、评估管道、使文档成为可能的工具。个别 AI 系统所有者——构建客服机器人、代码审查助手、推荐系统的团队——拥有其特定系统的文档，包括提示词、评估和护栏。

不起作用的是：将文档视为项目完成时的一次性活动。AI 系统不是发布后就完事了。随着模型更新、产品需求演变、边缘案例被发现，它们需要持续维护。文档必须被视为与代码具有相同维护节奏的活跃制品。

今天你可以做什么

如果你正在接手一个没有文档的 AI 系统，在修改之前从考古学开始。阅读系统提示词的每个部分，写下你认为每个部分做什么以及为什么。测试你的理论。明确记录空白——"这个部分的目的不清楚"比沉默更有用，因为它标志着需要解决的问题。

如果你正在构建 AI 系统，在你被诱惑跳过文档之前就写好它。你记得为什么做出某个选择的时间，是在你刚做出选择之后。三个月后，你不会记得了。六个月后，你可能不在团队里了。

当 Chen 写下那个提示词时它是有意义的。当从未见过 Chen 的人需要修改它时，它仍然可以有意义——但前提是 Chen 记录了原因。

这不是文档问题。这是工程纪律问题。像大多数工程纪律问题一样，在一开始解决它比在它崩溃后修复要便宜得多。