负面提示词是代码异味:为什么系统提示词中的每个 “不要” 都是技术债
打开任何已经上线超过三个月的生产环境 AI 功能的系统提示词(system prompt)。数一数其中的负向条款——“不要”、“绝不说”、“避免”、“在任何情况下都不”、“你绝不能”。如果计数达到了两位数,你看到的就不是一个系统提示词。你看到的是一个坟场。每一块墓碑都标志着一个特定的用户投诉、一个特定的事故报告,或者一条来自利益相关者的 Slack 消息,因为他们看到模型做出了一些令人尴尬的事情。团队在表面打了补丁后就继续前进了,现在这个提示词读起来就像一份被强行嫁接了人格的法律免责声明。
负向提示词是代码异味(code smells)。并非隐喻意义上的,而是字面意义上的。它们在提示词工程中相当于吞掉异常的 try/except 块、没有文档的配置标志,或者是 2022 年留下的 // TODO: refactor this。它们在某种程度上有效,直到它们失效。而且它们所掩盖的失败模式,几乎总是比它们被添加用来压制的那个失败更有趣。
粉象问题是结构性的,而非风格性的
负向指令失败的原因在提示词工程文献中有一个名字:粉象问题(pink elephant problem)。告诉某人不要去想一只粉色的象,他们脑子里浮现的第一件事就是粉色的象。LLM 患有这种疾病的更严重版本。为了处理“不要提及竞争对手 X”,模型必须在工作上下文中表示出竞争对手 X,将其与指令进行权衡,然后对其进行压制。表示是自动发生的;而压制才是失败的部分。
最近的研究正式确认了从业者多年来观察到的现象。关于否定处理的研究表明,LLM 在需要反转指令的任务中表现出系统性的欠佳,而且——与直觉相反——这种差距并没有随着模型规模的扩大而缩小。经过 RLHF 训练的 InstructGPT 风格模型在变得更大时,在某些否定任务上的表现反而变差了,因为底层的训练信号奖励了与提示词试图压制的话题相关的流畅度。自回归 Transformer 的结构使得“做什么”比“避免什么”具有清晰得多的梯度。
这意味着负向指令不仅冗长。在机械层面上,它也比对同一意图的正向规范更不可靠。“不要提供法律建议”在边缘情况下就像抛硬币一样不确定。“如果用户提出法律问题,请回答:‘我无法提供法律方面的帮助——请咨询执业律师’”是模型真正可以执行的行为。前者是祈祷。后者是代码。
没人追踪的密度指标
如果你这个季度要为你的提示词测量一个指标,那就测量负向条款占总指令的比例。称之为负向提示词密度(negative-prompt density)。这是你能从提示词中提取出的最有用的单一数字,但几乎没人追踪它。
以下是密度告诉你的信息,按严重程度大致递增:
- 低于 10%:健康。对于硬性政策红线(个人身份信息 PII、越狱、受管制言论),少量“不要”条款是不可避免的。提示词的其余部分规定了好的行为是什么样的。
- 10–25%:偏移中。团队已经开始用修改提示词而不是从上游修复来处理事故。值得进行一次重构。
- 25–50%:不健康。提示词正在承担本应由微调(fine-tuning)、检索(retrieval)或工具边界(tool boundary)完成的工作。模型对抗提示词的程度与其遵循提示词的程度相当。
- 超过 50%:确诊。基础模型不适合该任务,或者任务定义不清晰,抑或两者兼有。添加更多的“不要”也无济于事。
密度也会随着时间推移而变化。从版本控制中的提示词历史记录中提取它并绘制图表。斜率会告诉你,你的团队是在趋向于一个稳定的行为契约,还是仅仅在积累疤痕组织。单调上升的曲线是一个先行指标,预示着故障或质量倒退即将到来,因为在某个时刻,其中两个负向条款会在团队未预料到的上下文中发生冲突,模型将选择其中任何一个符合其训练先验的选项。你将无法确定性地复现这种失败,而那是后果最严重的 Bug。
为什么“不要”会堆积起来
这种积累有一个可辨认的模式。失败发生了——智能体推荐了错误的产品,使用了听起来带有居高临下意味的语气,幻觉出了一个功能,或者说了一些法务团队标记的内容。有人提交了工单。值班工程师有两个选择:在上游修复(更好的检索、工具边界、不同的模型、微调)或者在提示词中修复。上游修复需要一个冲刺(sprint)。提示词修复只需要一小时。提示词修复发布了,工单结案了,站会继续。
将此乘以每个拥有提示词编辑权限的产品经理、支持工程师和利益相关者,再乘以 12 个月,你就会得到一个读起来像政策手册的系统提示词。Microsoft Azure SRE 团队的智能体在上线两周内就积累了超过一百个工具,系统提示词的大小堪比一份法律文件。它在团队已经编码好的场景中表现完美,但在其他任何地方都会崩溃。这种模式是普遍存在的:提示词变成了过去失败的纪念碑,而不是对预期行为的描述。
更糟糕的是,没有人拥有删除“不要”的政治权威。每条负向指令背后都有一个故事,而那个故事通常涉及一个不开心的人。删除这一行感觉就像删除了修复方案,即使该方案从未真正奏效过。因此,提示词只会增长,从不收缩,而下一任接手的工程师也不敢触碰它。这与功能开关(feature flag)坟场或没人敢重构的 CSS 文件有着相同的动态特征。
- https://eval.16x.engineer/blog/the-pink-elephant-negative-instructions-llms-effectiveness-analysis
- https://arxiv.org/abs/2503.22395
- https://arxiv.org/abs/2402.07896
- https://gadlet.com/posts/negative-prompting/
- https://community.openai.com/t/prompt-anti-patterns-when-more-instructions-may-harm-model-performance/1372460
- https://arxiv.org/html/2505.13360v1
- https://www.dbreunig.com/2025/03/16/overcoming-bad-prompts-with-help-from-llms.html
- https://hackernoon.com/llms-dont-understand-negation
- https://swimm.io/blog/understanding-llms-and-negation
- https://www.palantir.com/docs/foundry/aip/best-practices-prompt-engineering
