指令位置问题：你在提示词中放置内容的位置，就是一个架构决策

你写了一个清晰的系统提示词。在测试环境中验证通过后，你将它部署上线了。三周后，一名用户发现你的安全约束并不能稳定触发——不是因为什么精妙的越狱手段，而是因为你在上个迭代中新增了一个400 token的上下文块，恰好把那条约束顶到了后面。模型就这样……忘了它的存在。

这就是指令位置问题——它不是你提示词里的一个bug，而是基于Transformer的模型处理序列的结构性属性。你提示词中的每一个token，并非获得相同的注意力权重。你放置指令的位置，以一种可量化的方式，决定着模型是否会遵从它。

大多数团队是通过莫名其妙的功能退化才发现这一点的。一个原本表现良好的提示词，在一次"只是增加了更多上下文"的常规更新后开始出问题。真正的原因——指令位置偏移——很少出现在事后复盘中，因为工程师们根本没有这样的心智模型去寻找它。

U形注意力曲线

长上下文LLM的研究已经持续揭示了一种被称为"中间丢失"（lost in the middle）的现象：当相关信息位于提示词的开头或结尾时，模型能正确使用它；而当它位于中间时，性能会显著下降。

在多文档问答任务中，将包含答案的文档从20个文档组的第1位移到中间位置，准确率会下降30%甚至更多。这一发现并非个例，它在GPT-3.5、GPT-4以及专为长上下文设计的模型上都得到了验证。扩大上下文窗口并不能解决这个问题——只是把悬崖推得更远而已。

根本原因在于位置编码的工作方式。现代LLM普遍采用的旋转位置编码（RoPE）引入了距离衰减机制：两个token之间的注意力会随着它们之间的距离增加而减弱。这是一个有意为之的设计选择——它让局部上下文比远端上下文更显著，这对语言建模很有用。但它有一个结构性的副作用：长序列中间的token所获得的聚合注意力，弱于序列端点的token。

结果就形成了一条U形的性能曲线。开头和结尾是可靠的，中间则不是。

指令遵从率随位置下降

"中间丢失"效应适用于检索任务。那么指令遵从呢？

同样的位置偏差在指令遵从基准测试中也有所体现。针对细微提示变体可靠性的研究发现，即使语义意图保持不变，现代模型在指令被改写或重新定位时，性能方差高达61.8%。行为约束类指令——也就是那些规定模型绝对不能做什么的指令——退化最为严重。

与放在开头的相同规则相比，被埋在长系统提示中间的关键规则，其遵从率会下降30–50%。模型并不是有意无视它们，而是其注意力机制在结构上给予这些内容的权重，远低于序列端点附近的内容。

这为那些有机生长的系统提示制造了一种特有的失效模式。一个最初150 token、运行良好的提示词，随着功能迭代不断积累特定功能指令、角色描述、领域知识和格式规范，逐渐膨胀到800 token。原本排在第一位的安全约束，现在处于800 token中的第200个位置——恰好在中间。没有人动过它，但它的遵从率已经悄然下降。

首因效应胜于近因效应，但两者都胜过中间

跨多项研究测量LLM中序列位置效应的结论一致显示，首因效应占主导：提示词开头的信息，在可检测到位置偏差的测试案例中，约73%能被正确使用。近因效应同样重要，但一致性较差——模型确实会稳定地关注最后几百个token，但这也更容易被出现在用户输入末尾的对抗性内容所利用。

这在实践中意味着：

• 将最严格的约束放在最前面。 行为护栏、不可违反的规则、输出格式要求——这些内容应位于系统提示的顶部，在任何上下文或示例之前。
• 利用近因效应进行任务框架设定。 紧接在用户输入之前的最后一条指令会获得充分的注意力。利用这个位置放置能塑造即时响应的、任务特定的提示。
• 系统提示的中间部分用于存放模型需要知道的内容，而非必须遵守的规则。 领域知识、角色描述和少样本示例可以放在中间。具有遵从后果的指令则不行。

指令层级问题

这个问题还有一个更微妙的变体：当你在同一个提示词中有多条指令，并且它们之间存在隐式冲突时。关于指令层级遵从的研究发现，GPT-4o-mini在47.5%的情况下未能正确解决冲突约束；Claude的表现更好，错误率约为23.6%，但依然远称不上可靠。

失效模式通常不是模型拒绝冲突——而是模型悄悄选择遵从其中一条指令，丢弃另一条。它选择哪条，部分取决于位置（通常是较早的指令获胜），部分取决于措辞。

"指令三明治"模式正是应对这一问题而生的。对于必须在任何用户输入下都成立的安全约束，可以将其同时放在系统提示的开头和结尾——用户输入夹在中间——从而同时利用首因效应和近因效应。开头的版本建立约束，结尾的版本在处理用户请求前再次强化它。这种冗余是有意为之的。

这不是一个完整的解决方案。它无法抵御来自检索内容的提示注入攻击，因为这些内容出现在最后一个安全块之后。但对于在非对抗性环境下有明确定义的行为约束，它能切实提升遵从率。

"提示架构"真正的含义

一旦你接受位置是一个设计变量，问题就变成了：如何组织一个系统提示？

对大多数应用来说，一个可行的顺序如下：

1. 核心身份与角色（简短，约20 token）——在一切之前确立系统是什么
2. 不可违反的行为约束——安全规则、隐私要求、绝对禁止事项
3. 输出格式与结构要求——JSON schema、语气、长度限制
4. 领域上下文与知识——模型需要了解但无需优先遵从的背景信息
5. 少样本示例——期望行为的演示
6. 本次请求的任务特定指令（如果关键，在结尾处重复）

前三类包含遵从敏感型指令，属于顶部内容。第4、5类包含模型应当使用但无需作为规则遵从的内容——中间位置适合它们。

第二条原则：保持基础系统提示的精简。冗长的单体系统提示会撑大KV缓存，减少用户输入的有效上下文空间，并在更大的范围内分散注意力，使中间位置效应不断叠加。推荐做法是将基础提示控制在200–300 token，并按条件加载特定功能的指令块。如果用户在执行任务A，就追加指令块A；如果他们在B流程，就追加B。这种方式能让关键指令始终靠近序列端点，避免被无关上下文所淹没。

测量你的提示词对位置的敏感性

大多数团队是在生产环境中发现提示词位置问题的，但那时已为时太晚。解决方案是在部署前，将敏感性测试纳入评估流程。

一个基本的位置敏感性测试，会将同一组指令在多个提示变体中重新排列，并测量遵从一致性。取你的关键指令，分别放置在总提示长度的0–20%、40–60%和80–100%位置，比较在每种配置下模型的遵从频率。如果某条安全约束在前四分之一时遵从率为95%，而在中间四分之一时降至65%，那么这条约束就是位置敏感的，需要被固定在顶部附近。

对于RAG管道，类似的测试是：检索多个文档，在不同的运行中将包含答案的文档放在不同位置，按位置测量检索准确率。U形性能曲线在几乎所有足够长的上下文场景中都会出现。曲线的形状告诉你准确率悬崖在哪里。

ACL 2025的LIFBench基准测试将这类评估正式化，涵盖2766条指令，跨越长上下文场景，分别测量开头、中间和结尾位置的遵从情况。其中对系统设计最直接适用的发现是：当约束按从难到易排序时，模型的表现往往优于直觉相反的顺序。与人类文档惯例相悖，以最难的规则开头，往往能改善所有约束的整体遵从率。

为你自己的系统构建基准测试其实很简单。挑出你最关键的五条遵从指令，在一个有代表性的提示词中分别在三个位置测试每一条。如果任何一条指令在不同位置之间的遵从率差异超过15%，就将其视为需要提示架构调整的结构性问题，而非提示措辞问题。

位置敏感性是一种CI失效模式

最后需要铭记于心的是：提示词更新可能在无声无息中引入位置回归。

一次为系统提示新增200 token上下文的更改，会改变其后所有指令的位置。指令本身没有变。它们的位置变了。如果你的遵从关键规则原本在第二个四分之一区间，现在可能已经到了第三个。你不会从标准的输出对比中发现这一点，因为模型仍然生成合理的响应——只是对那条被埋深的约束变得不那么可靠了。

这就是为什么提示词测试不能只检查输出质量，还必须包含位置检查。像对待代码一样对待提示词，意味着追踪位置变化如何影响遵从率，而不仅仅是输出是否看起来合理。提示词CI套件应该包含一个位置敏感性回归测试，当某次更改将关键指令推过某个位置阈值时，自动触发告警。

指令位置问题不会消失。位置注意力偏差是Transformer架构的结构性属性，解决方法不是等待模型更新——而是在设计提示词时就清楚位置很重要，测试不能失败的约束，并将每一次提示词更新视为潜在的遵从回归，直到验证证明无误为止。

---

"中间丢失"这一发现源自斯坦福大学的一项研究；指令可靠性方差数据来自ICLR 2025关于细微指令遵从的研究；序列位置效应的量化使用了2024年一项涵盖104个模型-任务组合的arXiv研究的SPEM方法论。