提示词位置即政策：当三个团队共同拥有一个系统提示词时发生的无声合并冲突

你 Prompt 仓库中的 diff 显示有三行发生了变化。生产环境中的行为差异却显示一切都变了。安全团队将一条拒绝规则从第 14 行移动到了第 87 行，目的是为了“将其与相关的防护栏归类”；产品团队没有注意到这一点，因为措辞完全相同；一周后，评估套件显示在对抗性输入上的得分下降了 9 个百分点。没有人修改这条规则，只是有人移动了它。在一个拥有 2,400 token 的系统 Prompt 中，由于对防护栏存在首因效应（Primacy Bias），对指令遵循存在近因效应（Recency Bias），移动一条规则所带来的行为改变与重写它一样具有承重性——而你的工具对这两者都无法感知。

这是 AI 团队在回归评审结束时，而非开始时才会发现的合并冲突模式。系统 Prompt 在 2025 年底的某个时候增长到了 2K token 以上。安全团队负责顶部，产品团队负责中间，智能体（Agent）团队负责底部。三个月的“小幅编辑”在无声无息中重新排列了每个人的意图，因为原本适用于代码的基于行的 diff 工具无法告诉你一条指令已经跨越了区域边界。Bug 不在任何一次单一的编辑中。Bug 在于位置现在即策略，而你对位置却没有任何策略。

为什么位置在 2025 年变得具有承重性

在 2023 年和 2024 年的大部分时间里，典型的生产环境系统 Prompt 只有 200 到 800 token。在这种规模下，位置效应确实存在，但很微弱，模型对指令的遵循足以覆盖这些效应。你在顶部写下 拒绝以下请求...，在中间写下 使用友好且简洁的语气，在底部写下 调用工具时，首选 X 而非 Y，模型基本上会照你说的做。关于位置的争论听起来就像是 Prompt 工程中的民间传说。

但有两件事发生了变化。首先，对于任何运行具有非琐碎工具目录、RAG 上下文塑形、输出格式契约和多语言角色规则的智能体的团队来说，系统 Prompt 已经突破了 2K token。其次，长上下文的相关文献赶上了从业者们一直在回避的问题：《迷失在中间》（Lost in the Middle）论文展示了一条 U 型性能曲线，即即便是在明确的长上下文模型中，位于上下文两端的信息被召回和执行的概率也远高于中间部分。2025 年的后续研究——《大语言模型的序列位置效应》（Serial Position Effects of Large Language Models）论文是对此最清晰的引用——专门针对指令遵循将这一现象正式化。麻省理工学院在 2025 年的一项机械性研究将其追溯到因果掩码注意力机制（Causal-masked attention）的一个结构性属性：前面的 token 会累积来自后续每个 token 的注意力权重，而位于 2,000 token Prompt 中第 500 个位置的 token 只能被第 501 到 2,000 个 token 关注，并退化到 U 型曲线的中间。

实际后果是，在 2K+ token 的系统 Prompt 中，一条指令的位置与其内容具有同等的影响力。一条防护栏从第 100 个 token 移动到第 1,200 个 token，即使措辞完全相同，其强制执行力度也不再相同。一条工具使用规则从 Prompt 底部移动到中间，会变得更像建议而非指令，因为底部的槽位实际上承担了近因效应的重要工作。

对于那些系统 Prompt 已经蔓延到 4K 或 8K token 的团队（这在拥有大量工具文档或详细输出 Schema 的智能体产品中很常见）来说，U 型曲线变得更陡峭，中间部分变得更沉默。2026 年一篇关于 Transformer 位置偏见的机械性论文指出，U 型曲线部分源于解码器的几何特性，而非训练伪影，这意味着扩大模型规模并不能消除这个问题。

三团队失效模式

失效的形式通常是这样的。安全团队负责拒绝、内容策略和 PII 规则——他们希望把内容放在顶部，因为首因效应是防护栏的好帮手。产品团队负责人设、语气、品牌声音和示例输出——他们希望内容放在显眼的地方，因为语气是用户感知的核心。智能体团队负责工具使用规则、输出格式契约和结构化输出 Schema——他们希望把内容放在底部，因为近因效应是紧接其后的动作执行指令的好帮手。

在 200–800 token 的体制下，三个团队都可以把内容放在任何地方，模型大多表现正常。但在 2K+ token 的体制下，这三种偏好变成了结构性要求。防护栏必须在顶部。工具规则必须在底部。人设是唯一可以吸收中间位置影响而不产生太大负面效果的内容。一旦 Prompt 跨越了这个阈值，隐含的顺序就变得具有承重性——但没有人把这个顺序写下来。

于是，安全团队增加了一条新的拒绝规则。他们把它放在第 14 行，因为那是他们其他规则所在地。产品团队正在编辑人设部分，注意到文件变长了，于是他们通过将新的拒绝规则“与其他安全项放在一起”来进行整合——他们把这个部分放在了第 80 行，因为这种分组在叙述逻辑上对他们更有意义。智能体团队在底部增加了一条工具规则。系统 Prompt 变长了，拒绝规则从首因位置移动到了中间位置，三个月的评估之后，有人注意到模型比以前更容易被诱导产生边缘情况的违规。

没有人改变任何词句。从模型的体验来看，Prompt 的语义发生了实质性的变化。而 PR 评审中的基于行的 diff 却显示这是一次整洁的重构。

位置感知的 diff 是什么样的

一个位置感知的 diff 会将系统提示词（system prompt）视为一系列带有“位置”的“部分（sections）”，而不是一行行的内容。一个最简可行版本应该能回答关于每个 PR 的四个问题：

是否有任何指令跨越了区域边界？ 一个护栏从“安全”区域移动到“工具”区域是一个重大变化，即使措辞完全相同。Diff 应该像代码审查中标记函数在模块间移动一样，突出显示这种变化。

任何受归属保护的区域的相对位置是否发生了偏移？ 如果安全区域在 main 分支中位于第 0–400 个 token，而在 PR 中位于第 400–800 个 token，这种变化可能会导致在对抗性输入下的评估指标下降 9 个点。Diff 应该显示“位置占总长度的百分比”，并对超过某个阈值（总长度的 10% 是一个合理的起点）的偏移发出警示。

提示词总长度是否跨越了位置偏见阈值？ 跨越 2K token 线、4K token 线或模型声明的上下文饱和点，都会改变位置偏见（position bias）的影响程度。一个显示“提示词从 1.8K 增长到 2.3K token”的 diff 应该被标记，因为它跨越了一个模式转变点，而不不仅仅是因为它变长了。

护栏是否仍处于首因（primacy）位置，工具规则是否仍处于近因（recency）位置？ 这是一个简单的不变性检查：枚举标记为“护栏”和“工具”的规则，并验证它们的位置百分位是否处于预期区域。这可以捕捉到由于好心的合并操作而将护栏挤到中间的情况。

这个工具的第一版不需要任何机器学习。一个声明区域范围和归属的 YAML 清单，一个通过区域标记（XML 标签或注释分隔符）拆分提示词的解析器，以及一个对比区域位置并标记移动的 CI 检查，就是一个周末的项目。难点在于让三个团队对清单达成一致。

将分段式系统提示词作为重构目标

到 2026 年，大多数生产环境的系统提示词仍然被写成一个扁平的长字符串。必须完成的重构是将提示词切分为命名的、归属明确且顺序显式的区域。对大多数团队行之有效的结构如下：

顶部的护栏区域（guardrails section），归安全团队所有，包含拒绝触发、内容策略、PII（个人隐私信息）处理和特定司法管辖区的规则。该区域是不变量：其他人都不能编辑它，安全团队承诺对其进行追加而非重新排序。

中上部的角色和背景区域（persona and context section），归产品团队所有，包含品牌语调、语气校准、受众假设和高层级能力框架。这个区域占据了 U 形曲线的中间位置，因为语气违规是可以补救的，不像护栏违规那样致命。

中下部的任务和输出区域（task and output section），由产品和 Agent 团队共同拥有，包含面向用户的任务框架和输出契约。这个区域是大多数编辑实际发生的地方，也是最需要协同的地方。

底部的工具使用和即时动作区域（tool-use and immediate-action section），归 Agent 团队所有，包含工具选择规则、结构化输出模式以及模型在下一轮对话中应该发出的格式。这是近因槽位，必须保持指令性（imperative）。

每个区域都以显式标记开始和结束——如 XML 标签、注释分隔符或任何你的评估套件（eval harness）可以解析的内容。每个区域在清单文件中都有一个 owner: 注解。修改某个区域的 PR 需要该区域所有者的审查。将规则跨越区域边界移动的 PR 需要两个所有者的审查，并且要在 PR 描述中加入标记，说明这一位置变化是关键的（load-bearing）。

这比大多数团队今天的纪律性要强。但比起一般的代码库对模块所有权的纪律性来说，这其实还算宽松，毕竟 CODEOWNERS 文件在过去十年里一直是代码库的顶梁柱。

在你的评估套件中加入什么

分段式提示词和位置感知的 diff 是必要条件，但还不够。评估套件必须验证位置不变量是否真的起到了你预想的作用。在现有的评估集中增加三项内容：

位置排列评估（position-permutation eval）。 针对每个主要的失败模式类别——护栏违规、语气偏移、工具误用——运行两次套件：一次让规则处于规范位置，一次将规则移动到提示词中间。两者的差异（delta）会告诉你行为在多大程度上取决于位置而非内容。如果差异很小，你可以容忍较松散的排序纪律；如果差异很大，你的 CI 必须对此严格把关。大多数团队会对护栏规则受位置影响之大感到惊讶。

长度阈值评估（length-threshold eval）。 在当前提示词长度、1.5 倍长度和 2 倍长度下分别运行套件——通过在中间放置中性填充内容来合成额外的长度。这会告诉你提示词对长度增长的鲁棒性，而无论你是否计划，长度增长总会发生。一个在 2K 时通过但在 4K 时失败的提示词，随着三个团队不断往里塞东西，在接下来的两个季度里会发生隐性退化。

跨区域评估（cross-section eval）。 专门测试区域之间的相互作用——例如一个拒绝规则、一个角色规则和一个涉及相同边缘案例的工具规则。你要寻找的失败模式是“角色区域软化了拒绝规则，因为模型正在对所有指令进行近因加权平均（recency-weighted averaging）”。这在单区域级别的评估中是看不出来的。

架构层面的实现

系统提示词（System Prompt）是共享的基础设施。三个或更多的团队会对其进行编写。各团队对提示词位置存在合理的、结构性的偏好，且这些偏好彼此冲突。当提示词超过一定长度后，模型认为位置的重要性与内容大致相等。然而，现有的工具链——diff 工具、审核流程、版本控制系统——只能体现行级的变化，而对位置级的变化视而不见。

这与 monorepo 通过 CODEOWNERS 文件解决代码问题、微服务通过架构注册表（schema registries）解决 API 问题、以及 Kubernetes 通过准入控制器（admission controllers）解决配置问题的逻辑是一样的。提示词仓库尚未经历这种成熟化过程，原因在于它们还很新，且此前大多数提示词都足够短，以至于这个问题尚未爆发。到了 2026 年，提示词不再简短。合并冲突是真实存在的，工具无法识别它们，而评估套件在导致问题的更改发生数周后才能捕捉到性能回归。

如果一个团队能开发出位置感知的 diff 工具、分段式提示词清单（manifest）以及位置排列评估，并将其作为一套“铺好的路”（paved-road）式的内部工具交付，那么他们虽然花了一个季度的时间，却能节省一年的神秘回归排查。如果不这样做，团队将持续支付这种“税费”——评估指标一次下降 9 个点，而原因却被归咎于模型升级、配置漂移或任何其他因素，唯独不是那个隐藏了实际变更的基于行的 diff。

位置即策略。请写下策略。