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

这些故障尤其难以诊断，因为它们在统计上是分散的。任何单一响应看起来都可能是正确的，只有在大量响应中或对比提示变更前后的行为时，问题才会变得可见。由于提示变更很少像代码变更那样附带评估门控，回归往往在数周内未被察觉。

一项多智能体系统研究发现，行为退化在长时间交互中会累积——在早期轮次表现稳定的智能体，随着对话进展，对系统提示约束的偏离越来越大。同样的动态适用于具有长上下文的单智能体系统：在短会话中潜伏的矛盾，随着上下文增长而被激活，模型有更多表面积来调解冲突。

程序化检测矛盾​

最简单的方法是在部署前用 LLM 作为提示本身的矛盾检测器。提示一个能力较强的模型阅读系统提示，并识别在合理用户输入下可能产生冲突的指令对。这对表面级矛盾（明显的语气冲突、格式冲突、范围冲突）效果良好，可以接入 CI 流水线作为提示 lint 步骤。

对于更深层的语义矛盾，自然语言推理（NLI）提供了更有原则的方法。将系统提示分割为单独的指令单元（通常每句话或每个分句为一个），然后使用经过微调的 NLI 模型进行逐对蕴含检验。如果两条指令互不蕴含，且都可能适用于同一类输入，则将该对标记供人工审查。

更有针对性的方法是行为测试：生成一组多样化的合成提示，合理地激活每条指令，运行模型，并按行为特征对输出进行聚类。对相似输入产生不一致输出特征的指令，是矛盾的候选者。这种方法较慢，但能捕获经过语义分析仍能存活的矛盾，因为它们只在上下文中才显现。

这些方法都不是万无一失的。基于 LLM 的检测受到与被测模型相同的位置和近因偏差影响。NLI 模型经常会遗漏需要对下游行为进行推理的隐式矛盾。行为测试需要维护测试套件，且规模扩展成本高昂。在实践中，最好的保护是架构层面的——设计提示，使矛盾在结构上无法被静默引入。

分层提示架构：结构化解决方案​

积累问题的根源在于扁平架构。扁平提示是单一文本块，关注点之间没有强制分离。任何指令可以放在任何位置，任何贡献者都可以追加任何内容，没有任何模式能在审查中使冲突显而易见。

分层提示架构将系统提示分为具有明确语义和修改规则的显式部分：

不可变约束是最内层。它们编码从不能被覆盖的硬性要求：安全规则、范围限制、输出格式契约。这些内容一次设定，只能通过明确的审查流程更改，并需要 AI 功能可靠性契约所有者的明确签字。它们位于提示顶部，被视为承重基础设施。

角色与语气定义模型的声音和交互风格。这些内容稳定但可协商——新的产品方向可能改变语气，但不应与约束层发生无声冲突。语气指令应放在约束之后，约束改变时需审查其兼容性。

功能级覆盖是最外层。这是修改最频繁的部分——"针对此特定任务，将输出格式化为 JSON"、"在此上下文中，优先考虑简洁性"。由于明确限定在功能级关注点，它们不会隐式与不可变约束竞争。每个覆盖应包含范围注释——适用于哪些用户意图或上下文——以便审查者能够推理重叠情况。

使这一切奏效的机制纪律是差异审查。当分层提示被更改时，差异是可读的：你可以看到哪一层被修改，以及更改是否可能与相邻层中的现有指令冲突。追加到功能覆盖层的约束在视觉上是异常的。与现有约束相矛盾的语气指令，无需阅读整个提示，就可以对照约束层进行审查。

版本控制增加了第二层结构执行。提示的语义化版本控制——约束变更为主版本，语气或范围变更为次版本，措辞澄清为补丁版本——创建了将提示版本与行为观察关联起来的审计追踪。当检测到回归时，可以像对代码变更日志进行二分查找一样，对提示历史进行二分查找。

所有权问题​

即使架构良好的提示，在没有明确所有权的情况下也会退化。指令冲突问题在一定程度上是社会问题：没有人像代码所有者对 API 契约负责那样，对提示的全局一致性负责。

实际所有权意味着一个人或团队拥有修改约束层的权力，所有其他层的修改都需要他们的审查。意味着提示更改在合并前根据行为基线进行评估，而不仅仅是审查语法正确性。意味着提示有一份活的规范——它应该做什么，在哪些上下文中，以什么语气——审查者对照它检查更改。

没有这些，拉取请求驱动的积累模式必然导致最终矛盾。每位贡献者局部优化；没有人全局优化。提示变成无人设计、人人头疼的问题。

将提示视为契约​

解决大多数问题的思维模式转变，是将系统提示视为行为契约，而非配置字符串。契约有层次（不可协商条款、可协商条款、实现细节），有变更流程（双方必须同意修改不可协商条款），有审计机制（可以检查历史并推理当前状态）。

这不需要新工具，只需要将同样的工程纪律应用于任何外部行为所依赖的接口：模式、版本控制、所有权和审查。使系统提示陷入矛盾与保持一致的区别不在于 LLM——而在于工程团队是否像对待任何其他用户所依赖的生产产物一样，以同等的严格性对待提示。

模型不会感到困惑，是提示让它困惑的。