指令遵循悬崖：为什么在系统提示中多加一条规则会破坏另外三条

你的系统提示最初只有十二行，运行得非常顺畅。后来产品团队要加语气规范，法务部门要加免责声明，安全团队又追加了三条约束。现在你有了四十条规则，模型却忽略了其中一半——而且每次忽略的还不是同一批。

这就是指令遵循悬崖：当你在提示中多加一条规则时，不仅仅是这条新规则的合规率下降——昨天还运转良好的其他规则也会跟着失稳。而且与大多数工程故障不同，这种失败方式令人抓狂地不确定。

悬崖的实证形态

IFScale 基准测试的最新研究描绘了一幅清晰的图景。研究人员对二十个模型在指令密度从 10 到 500 条的区间内进行了评估，结果揭示出三种截然不同的退化模式。

阈值衰减是最乐观的情形。Gemini 2.5 Pro 和 o3 这类擅长推理的模型，在大约 150 条指令以内能保持接近完美的合规率，之后急剧下降。它们看起来坚不可摧，直到突然垮塌。

线性衰减是大多数生产级模型的表现。GPT-4.1 和 Claude 3.7 Sonnet 在整个指令密度区间内呈现出稳定、可预测的准确率损失。每增加一条指令，都会对现有指令的合规率造成微小但可量化的损耗。

指数衰减是较小模型的失效模式。Claude 3.5 Haiku 和 Llama 4 Scout 在最初几十条指令内就迅速崩溃，随后稳定在 7–15% 的准确率低谷——基本上等同于随机合规。

令人警醒的结论：即便是最顶尖的前沿模型，在最大指令密度下也只能达到 68% 的准确率。而且这与上下文窗口的大小无关。Goldberg 等人的研究发现，推理性能在大约 3,000 个 token 时就开始退化——远低于任何模型的技术上限。限制不在于记忆，而在于注意力。

规则为何相互冲突

悬崖不仅仅是数量的问题，更在于那些单独看来完全兼容的规则之间产生的隐性冲突。

设想一个系统提示，同时包含"始终以正式英语回复"和"匹配用户的沟通风格"两条规则。当用户以随意的语气写作时，这两条规则就产生了矛盾。模型不会标记这个冲突——它会悄悄地选出一个赢家，而且每次请求可能选的不同。

这类优先级冲突以组合方式倍增。十条规则产生 45 对潜在冲突，四十条规则则产生 780 对。你无法手动逐一审查，模型也不会告诉你它何时在处理歧义。它只是悄悄地丢弃一条规则，寄希望于你不会注意到。

关于指令层级的研究证实了这一点：LLM 默认将所有指令视为大致相同的优先级。没有内置机制可以声明"这条规则比那条更重要"。模型从训练数据中学到的是指令通常不会相互矛盾，因此当真的出现矛盾时，它的行为本质上是未定义的。

这种失效模式尤为隐蔽，因为它看起来像随机的不合规。你看到模型偶尔忽略第 7 条规则，于是重新措辞让它更加强调。这修复了第 7 条，却悄悄地破坏了第 12 条——而你要等两周后用户反馈才会发现。

"迷失在中间"问题让情况更糟

位置效应进一步加剧了优先级问题。模型对提示开头和结尾的指令给予不成比例的关注，而对中间部分的信息权重不足。这种"迷失在中间"效应意味着，在一个有 40 条规则的提示中，第 15 到 25 条规则所获得的关注，系统性地少于第 1–5 条或第 35–40 条。

更糟糕的是，这种位置偏差还与语义相似性相互作用。研究表明，与任务概念相关的无关信息比完全不相关的噪声造成的损害更大。如果你有五条关于格式的规则和三条关于语气的规则，模型可能会将它们混为一谈，产生的输出只是部分满足了几条规则，却一条都没有完整遵守。

思维链提示——常被建议作为补救措施——在这里提供的保护相当有限。研究表明，模型在采用推理技术时，对噪声输入的敏感性反而更高。额外的推理步骤给了模型更多机会在相互冲突的信号中迷失。

分解：首要的缓解策略

应对悬崖最有效的模式是分解——将一个庞大的系统提示拆分成多个专门化的提示，每个提示只负责整体行为中的一个狭窄切片。

基于路由的分解使用轻量级分类器（通常本身也是一个 LLM）对传入请求进行分类，并路由到专门的提示。一个客服系统可以将账单问题路由到包含 8 条账单专属规则的提示，将技术问题路由到包含 10 条故障排查规则的提示，将一般咨询路由到包含 6 条对话规则的提示。每个子提示都保持在悬崖阈值以下。

层级指令集建立明确的优先级层次。不是将四十条规则并列在同一层级，而是定义三到五条不可逾越的"宪法性"规则，十到十五条大多数情况下适用的操作规则，以及一组在与上层规则冲突时可以让步的风格偏好。你通过提示结构直接编码这种层级，使用清晰的措辞，如"以下规则覆盖所有后续指令"。

流水线分解将任务拆分为顺序执行的阶段，每个阶段有自己聚焦的提示。内容审核系统可以用一个提示分类意图，第二个提示起草回复，第三个提示对照安全规则核验草稿。没有任何单个提示承载超过十到十五条约束。

这种方式的代价是延迟和成本。基于路由的系统增加了一个分类步骤，流水线会成倍增加 API 调用次数，层级提示需要精心设计架构。但另一个选择——一个随机忽略三分之一规则的单一提示——代价更高。

让你保持在悬崖边缘以下的实用模式

除了分解之外，若干工程实践也有助于在生产环境中管理指令密度。

系统性地审查冲突。 逐对枚举你的规则，并追问："是否存在某种用户输入，会让这两条规则建议不同的输出？"这很繁琐，但能捕捉到那些导致非确定性失败的矛盾。如果你有超过二十条规则，可以用基于 LLM 的冲突检测器来自动化这一过程。

按规则追踪合规率，而非总体合规率。 一个平均遵循 90% 规则的系统，可能完美遵循了规则 1–8，却从未遵循规则 9–10。独立追踪每条规则的合规率并随时间绘图。在用户发现问题之前，你就能从数据中看到悬崖的存在。

有意识地利用首因效应。 将最高优先级的规则放在提示的开头和结尾。将灵活的、低优先级的指导方针放在中间。这并不优雅，但它与注意力实际运作的方式相符。

优先使用约束而非指令。 "绝不讨论竞争对手产品"比"当用户询问竞争对手时，在承认其问题的同时将对话引导到我们产品的优势上"更容易让模型遵守。前者是一条清晰的边界规则，后者需要判断，而这种判断与其他规则的交互方式是不可预测的。

像对待代码一样对提示进行版本控制和测试。 每次添加规则都应触发一个回归测试套件，检查所有现有规则的合规性，而不仅仅是新增的那条。如果添加第 41 条规则导致第 17 条的合规率从 95% 降至 70%，你会在上线前就发现它。

关于指令密度的不舒服真相

指令遵循悬崖揭示了我们构建 LLM 驱动产品方式中的一个根本性张力。产品团队以功能为单位思考：每个新需求就是多加一条规则。但提示合规性不是线性的——它是一个预算，你每添加一条规则，就从这个预算中为所有其他规则支出一点。

模型会变得更强。推理模型已经将悬崖阈值推高了不少。但即便是前沿模型，悬崖依然存在——只是更远一些。将架构建立在"可以往单个提示里塞无限规则"这一假设之上，就是在沙子上建房子。

那些能稳定交付 LLM 产品的团队，都是把系统提示当成性能关键系统来对待的团队：进行性能分析、度量，并毫不留情地精简。不是因为简洁在哲学上令人愉悦，而是因为指令合规性的数学规律要求如此。