你加了”不要太通用”，因为上次输出很通用。新输出确实没出现”通用”这个词，改用了”普适”。它依然通用。你又加”不要写大段文字”，模型给了 bullet，把同样的大段文字拆成了 8 行。
最快的修法： 删掉光秃秃的”不要”，换成一条可量化的”要”。把 不要太通用 改成 每段至少包含 2 个具体数字和 1 个具体工具名。正向指令给了模型一个能命中、也能自检的靶子；负向只给了它一个可以绕开的词。
纯负向约束失败是机制问题，不是态度问题。要执行”不要写 X”，模型得先把 X 表示出来，这反而抬高了那个 token 的激活，而不是压低它。prompt 圈把这叫 Pink Elephant Problem（粉色大象问题），跟”别想粉色大象”会对人适得其反是同一套 Ironic Process Theory（讽刺过程理论）。Anthropic 官方 prompt 指南也直说：告诉模型该做什么，而不是不该做什么（Claude prompting best practices，截至 2026 年 6 月）。2026 年针对负向约束失败的实证研究发现：禁词之所以在绝大多数违规里重新冒出来，恰恰是因为”点名”它就等于”激活”它；而且同一意图下，负向指令对目标 token 的压制，远弱于等价正向指令对想要内容的引导。
本文讲为什么”只负向”约束必败，以及怎么把每条翻成模型能执行、也能验证的正向引导。
先对号入座
| 输出里的症状 | 大概率原因 | 跳到 |
|---|---|---|
| 禁词没了，同样的味道又回来 | 负向写的是价值，不是行为 | Step 1 |
| 输出很平、说不清哪里错 | 没有正向目标可去 | Step 1、Step 4 |
| 换了近义词或稍微变形 | 表面禁，没行为锚 | Step 2、Step 4 |
| 禁令好像被整个无视 | 禁词单太长，被当噪音 | Step 3 |
| 模型无声地、悄悄违反规则 | 禁令和任务本身矛盾 | 见”常见原因”#5 |
常见原因
1. 负向写成价值判断而不是行为
“不要通用”是价值判断。“通用”在评审脑子里，不对应任何模型能测量的具体输出特征。模型没法拿来自检，于是抠掉那个字面词、照样交同样的内容。
如何判断： 你的负向是形容词或价值词（通用、无聊、企业腔、不专业），不是具体的 token、结构或模式。
2. 没有正向目标
只禁止时模型没方向可去。它退回下一个最可能的续写，对写作任务来说，那往往就是下一个最通用的东西。
如何判断： 你的 prompt 有 不要 X 但没配 要 Y。
3. 模型换说法绕开
禁一个词，它用近义词。禁一个模式，它用稍微变形。表面禁、没行为锚，就会被钻空子。
如何判断： 禁词没了，底层行为没变。
4. 禁词单太长
20 条”不要”会稀释注意力，模型当成背景噪音，几乎一条都不遵守。短而具体的清单会被照办；长清单不会。
如何判断： 你的”不要”清单 15+ 项。
5. 禁令和其他 prompt 内容矛盾
不要用行话 加上一个没有术语表的技术任务，会逼模型在”不准确”和”违反规则”之间二选一。它通常无声违反，因为准确性赢了这场权衡。
如何判断： 禁令在该任务下根本不可行。该修的是这个冲突（允许一份界定好的术语表，或放宽禁令），而不是把禁令喊得更响。
动手前先确认
- 列出 prompt 里每一条”不要”。
- 每条都写下你真正想要的行为（配对的”要”）。
- 给每条禁令标注：具体（可测）还是含糊（要解读）。
- 决定哪些禁令值得保留、哪些砍掉。
- 给每条留下来的禁令规划一个正向锚（示例、schema 或规则）。
需要收集的信息
- 当前 prompt 里全部负向约束清单。
- 绕开了禁令的那次输出。
- 你实际想要的行为。
- 模型是换说法绕开，还是真的漏了禁令。
- 模型 + temperature（temperature 越高，可绕开的空间越大）。
最短修复路径
Step 1：每条”不要”配一条”要”
差： 不要通用。
好： 每段至少包含 2 个具体数字和 1 个具体工具名。
差： 不要写大段文字。
好： 最多 4 句、每句不超过 20 字。用编号列表。写清”要”之后，“不要”通常可以整条删掉，因为它会从正向规则里自然成立。如果两条都留，把”要”放前面。
Step 2：模糊负向翻成具体禁词
差： 不要用企业语言。
好： 禁词：leverage、utilize、synergize、going forward、
归根到底、整体、稳健、可扩展。具体 token 禁可以强制执行，因为模型能逐个扫描。模糊的 vibe 禁不能。
Step 3：限制禁词单长度
封顶 5-10 条高度具体的项。再长就稀释注意力。条目多了就拆成多个 prompt，或用多轮工作流（先出稿，再用完整清单跑一遍专门的修订轮）。
Step 4：给正例
替代”不要”最强的方式，是把你想要的输出展示出来，并和你不想要的做对比：
像这样：
我们上了 Stripe Connect 处理 marketplace 结算。日交易额 4.2 万美元，
T+2 到账。替换了之前的 PayPal 集成，那套有 18% 的拒付处理摩擦。
不要这样：
我们采用了稳健的支付方案来优化结算流程。对比让两个方向都变具体。一组 before/after 往往比一整段规则更管用。
Step 5：末尾加自检
写完后核对：
- 用过禁词吗？列出来。
- 每段是否至少 2 个具体数字或具体工具名？
- 任何一项不过就先重写那部分，再交答案。这通过强制模型拿正向标准（而不是负向）去审自己的草稿，来抓住绕开行为。
Step 6：常用禁令锁进 project / system prompt
如果”不用企业行话”是你全工作流的长期规则，就把清单挪进 project 指令或 system prompt（Claude Projects、ChatGPT 自定义 GPT，或 Cursor 的 project rule）。这样它就不再占用每条消息的空间，也躲开了”近期漂移”——长对话里靠近 prompt 顶部的规则会逐渐失效。
怎么确认已经修好
- 新输出不含任何禁词（逐个 Ctrl+F 查一遍）。
- 新输出也包含你要求的具体正向特征（那些数字、那些工具名、那个长度上限）。
- 故意喂一段很差的输入再跑一次，也不回到旧行为。
- 同事看输出说不出你用了哪些禁令，只看到好输出。
如果还是没修好
- “要”配得太软。把正向改成可测的（一个计数、一个长度、一个具体元素），而不是又一个形容词。
- 再加 1-2 个 pass/fail 示例，正好覆盖你看到的那种绕开。
- 切到结构化输出（JSON 或 schema）。结构让部分禁令变得多余——一个要求填数字的字段，装不下水词。
- 复杂禁令让模型先规划再写。在还没有任何正文之前，你就能在规划阶段挡掉绕开。
FAQ
为什么模型无视”不要”却听”要”？ 要执行”不要 X”，模型得先把 X 表示出来，这反而抬高了那个 token 的概率，而不是压低（粉色大象问题）。正向指令直接指向靶子，没有什么需要去压制。
那负向约束到底该不该用？ 该用——用在外科手术式、字面化的禁令上，也就是不想要的东西就是一个具体 token 或模式，比如 禁词：leverage、utilize。保持简短，并配一条正向规则。出问题的是模糊负向（不要太通用），不是所有负向。
多堆几条”不要”是不是更保险？ 不是。长禁词单会稀释注意力，模型当噪音处理。封顶在 5-10 条左右，所有要解读的东西都靠正例顶上。
禁词没了，但文字还是平淡，为什么？ 删掉一个词不等于加进实质。你禁了症状，却没指定解药。补一条正向要求（具体数字、具体工具名、一个具体示例），让模型有个好地方可去。
GPT-5.5、Claude、Gemini 之间有区别吗？ 没有。这是语言模型处理”否定”的固有特性，不是某一家的怪癖。截至 2026 年 6 月，把负向改成正向这招在 GPT-5.5、Claude Opus 4.7 / Sonnet 4.6、Gemini 3.1 Pro 上表现一致。
预防建议
- 默认规则：永远不写孤立的”不要”。
- 每个工作流保留一份稳定的短禁词单（最多 5-10 条）。
- 解读性禁令一律配一组 before/after 示例做正向锚。
- 每季度审一次累积下来的、没有配对正向的”不要”。
- 团队工作流把禁词单当配置文件，不当临时 message 文本。
- 自己先写一段故意差的输出来测禁令。模型产出像你那段差例时，就说明禁令没打中。