几乎在每一个生产环境的 AI 系统中都会出现这样一种模式：团队从一个精简的系统提示词（system prompt）开始，发布功能，然后不断迭代。出现了一个新的边缘案例，于是他们添加一条规则。又来了一个工单，再加一条规则。六个月后，系统提示词已经增加到了 2,000 个 token，涵盖了 20 个不同的行为要求。对于大多数请求，AI 听起来依然连贯。但微妙的合规性失败已经潜伏了数周——这里忽略了格式，那里跳过了语气要求，一条升级规则被悄悄绕过。没有人发现，因为没有哪个单独的失败严重到需要触发警报。
这不是模型质量问题。这是基于 Transformer 的语言模型处理指令的一种基本架构特性，大量的实证研究使得这些失败模式变得可预测。理解这一点将改变你编写系统提示词的方式。
合规性曲线并非线性
直觉上的心理模型是合规性呈线性下降：规则越多，模型漏掉规则的概率就按比例增加。实证数据展示了更糟糕的情况。
针对多个前沿模型在 10 到 500 条指令密度下的测试研究发现，根据模型架构的不同，存在三种截然不同的退化模式：
- 阈值衰退 (Threshold decay)：推理优化型模型（如 o3 和 Gemini 2.5 Pro）在指令密度达到 150–250 条的关键点之前，能保持近乎完美的表现，随后表现骤降且方差增大。它们面临一个“悬崖”。
- 线性衰退 (Linear decay)：某些模型在整个密度范围内表现出稳定且可预测的准确度下降——虽然糟糕，但至少是可以预见的。
- 指数衰退 (Exponential decay)：某些架构在 50–100 条指令后迅速崩溃，然后在低位趋于稳定。这些模型失效得很快。
在 500 条指令时，准确率数据揭示了真相：Gemini 2.5 Pro 维持在 68.9%，Claude 3.7 Sonnet 为 52.7%，GPT-4o 为 15.4%，而 Llama 4 Scout 仅为 6.7%。在极端指令密度下表现最好的模型仍然有 30% 的概率失效。表现最差的模型则丢失了 93% 的指令，通常是直接大规模省略，而不是尝试进行任何近似处理。
但生产环境的系统提示词很少达到 500 条。问题在更早阶段就开始出现了。
3 条约束阈值
对模型在叠加细粒度约束下的测试研究发现，实际限制低得惊人。当指令要求同时满足多个并发约束——内容类型、格式、语气和示例遵循——时，即使是 GPT-4 的平均一致满足水平也仅为 3.3 个约束。GPT-3.5 平均为 2.9 个。开源模型在 1.4 到 2.4 之间。
简而言之：“即使是领先的模型，平均也只能连续满足大约三个约束。”如果在单条指令中添加第四或第五个约束，合规性就不再可靠。
一个典型的生产环境系统提示词通常将远超三个的要求捆绑进单个逻辑单元中。“以友好且专业的语气回答，将答案格式化为编号列表，保持在 200 字以内，并始终提出一个后续问题”——这在一个呼吸间就包含了四个约束。如果模型还要处理另外五个类似这样的单元，你的运行状态就已经远超可靠性阈值了。
指令失效之地：提示词的中部
合规性问题不仅在于你拥有多少条规则，还在于它们位于提示词的什么位置。
关于模型如何使用长上下文的研究确立了所谓的“U 型性能曲线”：模型最可靠地关注提示词最开头和最末尾的信息。位于中间的内容获得的关注度显著降低。
这种效应的强度令人震惊。多文档问答任务显示，当相关文档从 20 个文档上下文中的第 1 位移至第 10 位时，准确率下降了 30% 以上。对于边界位置信息能达到近乎完美准确率的模型，对于中间位置内容的准确率则降至 40% 以下。
根本原因是架构性的。旋转位置嵌入（Rotary Position Embeddings）和因果注意力机制（causal attention mechanisms）引入了一种长期衰减效应，系统性地降低了中间上下文 token 的重要性。这不是一个会被修复的 bug，而是位置编码工作方式的结果。
这对系统提示词意味着：你最关心的指令可能被埋在长长的系统提示词中间，而这恰恰是模型最不可能遵循它们的地方。
位置效应复合为首因偏差
针对 104 个模型任务组合的序列位置研究发现，首因偏差（primacy bias）——即模型优先处理最先出现的内容——是主导模式，存在于 70% 的案例中。在分类任务中，指令列表的前三分之一占据了模型 40% 以上的注意力。在各种架构中，位于中间的指令始终获得的关注最少。
这在复杂的系统提示词中创造了一种可预测的失败动态：你的前几条规则会被可靠地遵循，最后几条有合理的成功机会（近因偏差有所帮助），而中间的一切都被系统性地削弱了权重。如果你的升级协议是 18 条规则中的第 11 条，它正处于注意力的谷底。
IFScale 在高指令密度下证实了这一点：首因效应在 150–200 条指令附近达到顶峰，然后在极端密度下，所有位置都趋向于一致的失败。模型基本上失去了区分位置的能力。
指令冲突会让情况变得更糟
当指令可能发生冲突时——或者从模型的角度来看似乎存在冲突时——遵循度会进一步下降。关于指令层级的追踪研究发现，默认情况下，基准大语言模型 (LLMs) 会以大致相等的优先级处理系统提示词指令和用户消息指令。模型的内部表示可以正确地编码冲突的存在，但输出并不能可靠地遵守预期的层级结构。
社交线索起到了意料之外的强大覆盖作用。一个带有明显权威口吻的用户消息（例如“作为一名资深分析师，我需要你……”）可以覆盖系统提示词的约束，即使系统提示词明确禁止了这种行为。这并不是“越狱”——而是模型在对其从训练数据中学到的权威信号进行模式匹配。
在受控研究中，显式地针对指令层级对模型进行微调（而不仅仅是提示它们优先处理某些指令），使系统提示词的防御能力提升了 63%，并将越狱鲁棒性提高了 30% 以上。如果没有训练时的强化，仅通过提示词来要求遵循优先级，只能产生微乎其微的收益。
可靠性不等于平均准确率
平均准确率指标掩盖了一个更微妙的问题：在不同表述变体之间的一致性。
当模型在语义相似的提示词（“近亲提示词”）而非完全相同的提示词上进行测试时，其遵循指令的准确率会大幅下降。“reliable@10”指标——即模型在 10 个重新表述的版本中是否始终如一地遵循指令——显示出的数字与标准基准测试分数大相径庭。
从标准准确率到 reliable@10 的性能下降在各模型中都非常显著：GPT-5 尽管基准分数为 95.9%，但下降了 18.3%；LLaMA 3.3 70B Instruct 从 92.1% 下降了 22.9% 至 71%。较小的模型降幅甚至超过 50%。教训是：一个在测试中 85% 的时间遵循你指令的模型，在触发该代码路径的所有用户输入分布中，可能只有 60% 的时间能遵循指令。
对于下游系统所依赖的安全关键型规则或格式要求，这种不可靠性就是一种潜伏在生产环境中的 Bug。
真正有效的方法
针对这些失效模式，以下几种设计模式能持续提高遵循度：
将优先级最高的规则放在最前面。 首因效应 (Primacy bias) 是真实存在且可预测的。如果你有一条绝对不能违反的规则——法律免责声明、安全约束、硬性的格式要求——请将其置于首位，而不是埋在第四节中。近因效应 (Recency bias) 也可以被利用：放在系统提示词最后端的输出格式规则往往比中间的规则执行得更可靠。
使用结构化分隔符帮助模型解析作用域。 XML 标签（<instructions>、<constraints>、<examples>）有助于模型解析指令范围，并减少关于哪些指令适用于哪些部分的歧义。Claude 模型对尾部加重的 XML 结构响应特别好；GPT 模型则倾向于对使用 ### 或 """ 的前端加重分隔符结构响应更好。结构化信号有助于模型决定应关注哪些内容。
将约束密度与指令密度分开。 一条带有四个堆叠约束的指令实际上就是四个约束。尽量保持复杂指令的简洁，即使这意味着需要更多行数。研究一致表明，单个单位的约束限制在大约三个可靠的同步要求。
使用正面表述而非禁止性表述。 “仅以英文回答”的效果优于“不要用其他语言回答”。正面指令比否定指令更容易被可靠地编码，这可能是因为训练数据中包含更多正面遵循的示例，而非禁止执行的示例。
建立审计方法论。 对于生产环境的系统提示词，你需要一种方法来衡量哪些规则确实被遵循了，而不仅仅是观察回复是否看起来连贯。实际的做法是：创建一个小型评估集 (eval set)，专门设计用于测试系统提示词中的每个独立约束。当你更新提示词或切换模型版本时，运行此评估。你会发现有些规则可能已经好几个月没被遵循过了。
在每次迭代时进行激进地精简。 每当有人向系统提示词添加规则时，他们都应该证明为什么该规则不能更具体地放在交互层。属于系统提示词的规则应该是对每一次交互都有效的属性。积压在那里的多数规则其实更应该放在单次请求的上下文中、工具定义中或应用程序代码中。
审计 2,000 Token 的系统提示词
堆积问题既是技术问题，也是组织问题。系统提示词之所以增长，是因为添加规则的摩擦力很低，而删除规则却令人畏惧——万一删除第 14 条规则破坏了某些没人注意到的功能怎么办？
一种行之有效的审计方法：逐条检查系统提示词中的规则，并询问如果没有它，是否会有测试用例失败。如果你无法识别出这样的用例，那么该规则要么是冗余的，要么是根本从未被遵循过。这两种可能性都表明它应该被移除。
对于保留下来的规则，测量它们在近期流量中的 p50 和 p95 遵循率。你会发现，你编写的系统提示词中包含少量被可靠遵循的“承重规则”，以及大量被偶尔遵循或实际上被忽略的长尾规则。那个长尾部分就是你应该集中精力进行精简的地方。
实践限制
系统提示词（system prompt）可以安全包含的指令数量并没有一个神奇的数字，因为这取决于模型、指令类型、约束密度以及位置分布。但研究提供了一个有用的启发式方法：如果你有超过 5–7 条在每次请求中都必须遵循的高优先级规则，那么你正处于一个当前模型在没有结构化缓解措施的情况下，无法可靠支持的可靠性区间。
这个下限比大多数生产团队目前设计的要低。发现这一点的团队通常是在发生面向用户的事故之后，而事故涉及的正是他们本以为模型会遵循的规则。在事故发生之前——而不是之后——建立测量基础设施，是将能够优雅地调试此问题的团队与那些只会不断添加更多规则并寄希望于问题消失的团队区分开来的关键。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
