负向提示的失效

Failure of Negative Prompting

PE-A-05内容已写满G06安全与鲁棒性第 17 层

负向提示指令遵循改写

一句话结论

「不要做 X」不是可靠的控制手段：禁令会把被禁内容带进上下文，又缺少可判定的判定标准。处置办法是做一次负向指令清查，把每条约束改写成期望行为的正向描述并核对原意覆盖，无法正向化的改写为可判定的处置规则并配输出校验。不靠加强语气来补救，因为强调式措辞在新代模型上常反而降低遵循度。

本页结构（可跳转）

改写对照图：负向提示「不要做 X」反而激活 X 的机制、改写成期望行为的前后对照，以及无法正向化时的可判定处置规则。（本站自制）

01为什么需要它

「不要做某件事」这类约束在行为控制上不可靠：提示里出现的否定短语会把被禁的内容一并写进上下文，官方口径因此要求把约束改写成期望行为的描述。

掌握这一点，是为了在写提示词时就把大量的负向清单换成可执行、可校验的正向指令，而不是等到出错之后反复加禁止语。

适用边界

负向表述在提示里仍有一席位置：它可以作为兜底的负面清单，或作为正向描述之外的第二次提醒；它不该承担主要的行为控制职责，也不该成为唯一防线。另有一处须标注：把负向指令改写为正向指令有明确的厂商一手依据，但这不等于业界已经给出统一口径，其他厂商未必逐字表述同一命题；把这条结论推广到所有模型、所有任务之前，应先在自己的评测集上复测。

02机制说明

负向提示的失效可以从两条线索看懂。

第一条是内容浮现：禁止语本身带有被禁对象的名字，模型读到的既有禁令也有那个对象；厂商给出的改法是把话说成期望的样子——不要写「不要使用某种格式」，而要写「回答应当由怎样的结构组成」。
第二条是可判定性：一条「不要做 X」没有说清什么时候算违规、违规时该输出什么，人读得懂，机器却验不了，因而无法进入自动化校验。
工程上的处置是把提示与规则文件里的负向指令做一次系统清查，逐条改写为正向描述，再逐条核对改写是否仍覆盖原意：原句想拦住的每一种情形，改写后都要有对应的正句覆盖。
确有一些约束无法正向化，例如必须拒绝某一类请求；这类约束不应继续以一句禁止语承担主要职责，而应改写为可判定的处置规则——写明触发条件、判定依据与输出形态——并由校验环节兜底。
改写的副产品是提示变短：分散的禁止语被合并成少数几条正向要求，复查与评测都更容易。

03何时该用 / 何时不该用

按场景对照：先看条件，再看该怎么做。
类别	场景 / 条件（总结）	具体做法（细节）
该用	提示或规则文件里出现「不要做 X」类约束时	把它改写成期望行为的正向描述，并逐条核对是否仍覆盖原意。
该用	约束无法正向化时	改写为可判定的处置规则，写明触发条件与输出形态，并加输出校验。
该用	同一份提示里负向指令成堆时	先做一次清查与归并，把重复的禁止语收成少数几条正向要求。
不该用	把负向清单当作主要控制手段	它的可靠性低于正向描述，且无法被机检覆盖。
不该用	只堆强调词来加固指令	全大写与严厉措辞在新一代模型上反而可能降低遵循度。

04实验台

shellbash
查看代码
```
grep -nE "不要|禁止|不可|严禁|切勿" prompts/*.md
```
预期观察：输出提示文件里全部负向指令的文件名与行号，作为改写清单的起点；无输出表示这些文件里已没有负向指令。

filepython

查看代码

import re
neg = re.compile("不要|禁止|不可|严禁|切勿")
total = hits = 0
for ln in open("prompts/system.md", encoding="utf-8"):
    if neg.search(ln):
        total += 1
        if re.search("应当|必须输出|格式为", ln):
            hits += 1
print("负向指令 %d 条，已配正向改写 %d 条" % (total, hits))

预期观察：打印负向指令总条数与其中已同时给出正向写法的条数；已配稿数等于总条数说明改写清查完成，否则差额须逐条处理。

05证据

主张厂商给出的改法是描述期望行为、而不是禁止行为：把「不要做」换成「应该做什么」的表述。

分级official

来源S-0001 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices

原文

展开原文关键句

Tell Claude what to do instead of what not to do

主张同一份官方最佳实践还要求回调攻击性措辞：把全大写的强制语气换成平常的提示写法，说明强调式表达不是可靠的控制手段。

分级official

来源S-0001 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices

原文

展开原文关键句

The fix is to dial back any aggressive language.

主张厂商的生产案例显示，含矛盾或含糊指令的提示对新代模型的伤害可能大于对旧模型，措辞粗糙本身就是风险来源。

分级official

来源S-0015 https://raw.githubusercontent.com/openai/openai-cookbook/main/examples/gpt-5/gpt-5_prompting_guide.ipynb

原文

展开原文关键句

poorly-constructed prompts containing contradictory or vague instructions can be more damaging to GPT-5 than to other models

主张另一家厂商的官方提示指南同样以「精确直接、避免不必要的说服性语言」表达相近方向，可作旁证但非同一命题。

分级official

来源S-0018 https://ai.google.dev/gemini-api/docs/prompting-strategies

原文

展开原文关键句

Be precise and direct ... Avoid unnecessary or overly persuasive language.

06术语

术语负向提示的失效　Failure of Negative Prompting

界定「不要做 X」形式的指令在行为控制上不可靠，因为否定词在后续 token 预测中会提高而非降低相关内容的出现概率；应改写为正向指令。

07失效模式

写了「不要提到 X」就以为已经把 X 排除X 反而随禁令进入上下文，模型对它的可及性上升，违规出现得更频繁。
只替换措辞而不核对覆盖把「不要用列表」改成「用段落作答」却漏掉原有的例外条款，静默丢掉一半原意，评测也看不出来。
用全大写、CRITICAL、MUST 之类的强调来加固指令官方口径已把这类措辞列为应回调的对象，压力式表达在新代模型上常与预期相反。
对无法正向化的约束只写一句禁止没有触发条件、没有处置动作、没有校验，等于把责任推给模型的临场判断。

08在本站知识结构中的位置

所属分组: G06安全与鲁棒性
依赖深度: 第 17 层（同层节点彼此无先后约束）

前置PE-A-04→PE-A-05 本节点→后继PE-A-06

在交互全景图中定位本节点。