策略文件：为什么你不应该把拒绝规则写在系统提示词里

上个季度，一家金融科技初创公司的安全审核员在系统提示词（system prompt）中添加了四行内容。这次修改包含一条拒绝规则，旨在防止助手为公司未获得运营许可的司法管辖区提供具体的税务建议。这听起来很合理、范围明确且符合审计要求。该规则在周二上线。到周五时，评估套件显示在与税务完全无关的客户入职流程中出现了 7 个点的下降——模型开始对任何提及国家的提问都模棱两可，甚至包括“这个账户持有哪种货币”。产品团队撤回了修改。安全团队在下周以略有不同的措辞重新发布了它。三周后，同样的退化以不同的形式再次出现，而接下来的安全修改又破坏了另一个无关的流程。

这里的 bug 不在于措辞，而在于拒绝规则放错了位置。它被挤进了一个 2,400 token 的构件中，该构件还包含助手的对话语气、格式契约、任务指令以及其他六项策略条款——对其中任何一项的修改都是对所有内容的行为修改，因为模型无法分辨哪句话是策略，哪句话是风格。生产环境中的系统提示词之所以变成了一坨乱麻的单体，是因为三个正交的关注点伪装成了一个整体。没有将它们解耦的团队在每次修改时都在支付“集成税”。

三种关注点，三类审核员，三种频率

打开任何足够成熟的 LLM 产品的系统提示词，你会发现三类文本挤在一起，除了空行之外没有任何有意义的分隔。

第一种是对话指令——助手的语气、人格、默认基调、如何询问澄清问题、如何 handle 歧义。（“你是一家电子商务商店的得力助手。表现得热情且简洁。当用户不高兴时，先表示同理心。”）这是产品文案的关注点。审核员是产品负责人或设计师。当品牌调性改变时它才会改变，而这很少见。

第二种是输出格式——对响应的结构化契约。Markdown 还是纯文本、代码块格式、列表规则、除非要求否则不包含表情符号。（“使用 Markdown 回复。产品类别使用 H3 标题。引用价格时带上本地货币符号。”）这是工程关注点。审核员是负责模型下游渲染器的任何人。当渲染器更改时它才会更改，这也很少见，但原因完全不同。

第三种是策略——拒绝规则、司法管辖限制、禁止提及竞争对手、升级触发条件，以及无论用户如何表述，模型必须做或不能做的任何事情。（“绝不直接点名推荐竞争对手的产品。拒绝提供医疗或法律建议。如果用户提到自残，请引导至危机资源流程。”）这是合规与信任安全（T&S）的关注点。审核员是法务、合规或 T&S 团队。每当监管或风险环境发生变化时它都会改变，而这种情况经常发生——有时甚至是为了应对单一恶性事件而紧急修改。

三种关注点，三类不同的审核员，三种截然不同的修改理由。但在大多数生产系统中，这三者都存在于同一个字符串中，由同一个工具对比差异，由同一个人审核，并在同一个发布周期中上线。团队会在第一次“单行策略修改导致无关功能出现行为退化”时学到这个教训，然后一遍又一遍地重复教训，直到终于有人提出进行解耦。

为什么单体架构总是会退化

单体之所以失败，并不是因为单次修改有误。它失败是因为修改之间会产生交互作用，而这些交互在修改时是不可见的。

长系统提示词存在位置偏差 (position bias)——靠近顶部和底部的指令比中间的指令权重更高。放在前面的拒绝规则被解读为身份（“你是那种不做 X 的助手”）；放在后面的规则被解读为模型看到的最新指令。同样的文字，不同的行为。因此，当安全团队为了整洁而将第五个拒绝条款与现有的四个放在一起时，他们改变了其他每个条款的相对位置——导致在没人触碰的任务上出现了行为波动。

更糟糕的是，拒绝性语言具有生成性。告诉模型“不要对美国以外的司法管辖区提供税务建议”不仅仅是拦截了税务建议。它还改变了涉及非美国司法管辖区的每个回复的条件分布，因为模型现在在那个语义邻近区域被启动了“谨慎”模式。这种回避会蔓延。模型开始在货币转换、时区问题、原产地查询中添加免责声明——任何触及到该激活概念的内容都未能幸免。

这就是为什么进行量化衡量的团队会看到同样的模式：一个干净、精确、初衷良好的策略修改，在无关的评估中产生了弥散且难以归因的退化。修复的方法不是更好的措辞，而是从一开始就不应该将策略拼接到提示词中。它应该是一个独立的构件，拥有自己的评估器、自己的分类法和自己的编译时注入点。

拆分后的形态

拆分包含三个部分，每个部分对应一个关注点，并成为你代码库中不同类型的对象。

加载中…