这个提示词去年还有意义：AI 系统中的机构知识衰减
当你从一位刚刚离职的工程师那里接手一个 AI 系统时，会有一种特殊的恐惧感袭来。系统提示词长达数百行，有一个叫 evals/ 的文件夹里存着 340 个测试用例却没有 README，代码中的注释写着 # 不要修改这里——找 Chen 问 而 Chen 已经联系不上了。
你不知道为什么客服机器人被禁止在星期二讨论定价，不知道哪些评估用例是为了捕捉六个月前的回归问题而写的，哪些只是随机示例，也不知道屏蔽某些产品类别的护栏究竟是法律要求、合规实验，还是某人因为某个副总裁看到了一条糟糕的输出而随手加上的。
系统还在运行。目前如此。但你无法安全地修改任何东西。
这就是 AI 系统中的机构知识衰减——它在结构上与工程师们抱怨了几十年的遗留代码问题截然不同。理解这种差异，是构建能够超越其创建者的系统的第一步。
为什么 AI 系统比代码衰减得更快
传统软件有一个救命稻草：它是静态的。你在 2021 年写的函数在 2021 年做的事，它现在还在做。你可能不知道为什么当初那样写，但至少行为是稳定且可检查的——你可以阅读代码。
AI 系统没有这种特性。三件事使它们对知识衰减特别脆弱：
模型更新会悄悄破坏提示词。 一月份精心设计的可靠提示词，可能在三月份因为底层模型更新而表现不同。与会抛出编译器错误的废弃库不同，模型更新是无声无息到来的。提示词还在运行，只是输出会以微妙的方式漂移，没有人注意到，直到某件重要的事情崩溃。
提示词的脆弱性不同于代码。 在系统提示词中修改一个句子——加上"简洁"这个词，调整语气指令，重新排列两个段落——都可能级联成意想不到的行为变化。这种依赖关系是语义层面的，不是语法层面的。没有类型系统来捕获回归。
评估数据集会在无人察觉中过时。 声称"覆盖 95% 的生产错误用例"的评估数据集，编码了一个在撰写当天成立的断言。随着模型改进、产品范围扩大、边缘案例转移，这个断言会悄悄变成错误。与废弃的 API 不同，没有任何废弃警告。
研究发现，大约 20-25% 的架构决策在两个月内就有了过期的证据，而 86% 的陈旧假设只在事故发生时被动地发现，而不是通过系统性追踪。
三种会衰减的制品
AI 系统中的机构知识集中在三类制品中，每一类的衰减方式都不同。
系统提示词
系统提示词是最明显的制品，但其背后的原理才是真正的知识。为什么指令放在末尾？（因为 LLM 预测下一个 token——如果把指令放在前面，模型可能在读到指令之前就开始生成内容。）为什么角色被定义为"有帮助但持怀疑态度的助手"而不只是"有帮助的助手"？（因为在测试中，更有帮助的变体幻觉引用的频率高出 30%。）为什么用户输入部分周围有分隔符？（因为没有它们，某些注入模式在早期测试中成功了。）
让做出这些选择的工程师离开，你就有了一个看起来武断的提示词。每次修改都变成了赌博，因为你不知道自己违反了哪些不变量。
提示词缺陷的分类将可维护性失败——硬编码的提示词、测试不足、文档不完善——列为与更明显的语义和结构缺陷并列的独特失败类别。可维护性失败往往导致其他失败，因为没有文档的提示词会被错误修改。
评估数据集
评估数据集是结晶成测试用例的知识。每个测试用例都编码了一个判断：这个输入应该产生这种输出，以及我们为什么关心到要对其进行测量。
当原理没有文档记录时，评估集就变成了货物崇拜工程学。团队通过他们不理解的测试，无法解释失败的测试，并基于感觉而不是有原则的覆盖率分析添加新用例。更糟糕的是，当 模型更新以使以前失败的用例现在通过的方式改变行为时，没有人知道这是真正的改进还是被掩盖的回归。
评估事实表框架——一种评估文档的结构化方法——提出了每个评估数据集应该记录的五个维度：背景（谁创建了它以及为什么）、范围（它测量什么能力）、结构（数据组成和来源）、方法（操作程序）以及对齐（可靠性和有效性声明）。很少有团队系统地记录这五者中的哪怕一个。
护栏
护栏是知识衰减最危险的地方。阻止某些输出的护栏之所以存在，是因为有人决定收益大于成本。这个决定通常涉及上下文：法律审查、具体事故、合规要求、产品原则。当上下文消失时，你只剩下一条无法被质疑的规则。
问题不仅仅是护栏变得不透明——它们变得不可移动。团队不愿意删除或修改他们不理解的规则。所以护栏不断累积。为不再存在的失败模式设计的规则留在生产中。对旧模型版本有意义的规则与新模型产生摩擦。系统变得越来越脆弱，不是因为护栏是错的，而是因为没有人能判断哪些还是对的。
