系统提示中的冲突指令：无人负责的隐性故障模式

你的 AI 功能在上线时运行良好。六个月后，它有时给出简短的一两句话，有时写出五段长文，偶尔还会拒绝回答上个季度毫无障碍地处理过的问题。代码库中没有任何变化——至少你是这么认为的。实际上，系统提示在悄然改变，经过四名工程师跨两个团队提交的十一个拉取请求，逐步演变。每次改动单独来看都合情合理，但合在一起，却将你的提示变成了一台矛盾制造机。

这就是指令冲突问题。它不会抛出异常，不会出现在错误日志中，而是以行为漂移的形式表现出来——模型在细微不同的情境下做出细微不同的事，难以复现，更难溯源。等到用户提交 bug 报告时，提示可能已经被再次打过两个补丁了。

系统提示如何积累矛盾

想想提示在生产代码库中实际是如何变化的。产品经理要求更详细的解释，开发者追加了"始终逐步解释你的推理过程"。两周后，一起关于冗长回复的支持升级促使另一位开发者在前面插入"简洁直接地回答"。没有人删除旧的指令；它们分布在一个 600 token 提示的不同部分，代码审查早已合并。

这并非疏忽——这是将系统提示当作只追加配置文件的自然结果。每位贡献者只关注自己的改动，提示没有强制结构使冲突在代码差异中显而易见，矛盾只在推理时才会浮现，此时模型必须调和两条从未被训练过要分优先级的指令。

同样的积累模式在每个提示关注点上反复出现：

• 语气：一月份添加了"友好随意"，三月份又添加了"始终保持专业语气"
• 格式：一处要求"列表使用项目符号"，另一处却要求"倾向流畅散文而非碎片化列表"
• 范围：开头要求"有帮助地回答任何用户问题"，第 40 行才埋着"只回答关于我们产品的问题"
• 安全与功能：一个团队写道"绝不拒绝用户请求"，另一个团队写道"拒绝可能被滥用的请求"

对开源 LLM 项目中提示债务的研究发现，指令块式提示是失败率最高的类别之一，原因正是它们在没有任何结构机制来显示冲突的情况下不断积累。提示越长，潜在矛盾的密度就越高。

模型如何解决你未曾解决的问题

当模型遇到冲突指令时，它不会报错，而是做出选择——而那个选择未必是你期望的。

几种有据可查的偏差决定了模型如何处理冲突：

近因偏差。 出现在提示后部的指令权重更高，在长上下文中尤为明显。这意味着矛盾中的"赢家"往往是最近追加指令的工程师——一套你从未设计过的隐性优先级系统。

位置效应。 模型对上下文的开头和结尾关注度高，对中间部分关注度低。埋在 1000 token 提示中间的指令，与处于两端的指令竞争时，可能在功能上被忽视。多指令遵循研究发现，位于上下文窗口中间的指令准确率下降超过 30%。

指令干扰。 当用户输入本身带有指令性质时（例如以指令方式提出的问题），它可能无视位置而覆盖系统级指令。这意味着你的系统提示权威并不像系统/用户提示分离所暗示的那样绝对。

不可预测的仲裁。 当上述偏差都无法产生明确赢家时，模型会依赖预训练中的模式。结果行为单独看可能合理，但与任何一条指令的规定都有出入。没有可依赖的"平局裁决规则"；行为实际上是涌现出来的。

其后果是，系统提示中的矛盾会产生一个不确定性行为包络。不同的输入、温度设置，甚至模型版本的静默更新，都会改变哪条指令占优。一个看似能优雅处理冲突的生产模型，可能在一次无声的模型版本升级后开始偏向另一条指令。

生产故障的真实面貌

指令矛盾导致的行为漂移很少以清晰的 bug 形式出现，它看起来像：

• 客服机器人时而简洁时而冗长，找不到明显规律，导致客户满意度分数波动
• 代码助手在被要求解释时会写注释，但在被要求生成时却跳过注释，因为两条指令对文档风格的规定相互矛盾
• 内容审核功能对某些类别的标记不一致，因为安全指令与帮助性指令在边缘情况下发生冲突
• 智能体在单轮评估中表现正常，但在多轮对话中逐渐退化，因为状态积累改变了模型将哪条指令视为权威

加载中…