什么是负面提示词？在什么场景下使用？
- 标签：Prompt、负面提示词
🏛 业务架构师
负面提示词（Negative Prompt）指告诉模型"不要什么/避免什么"的指令——最初流行于图像生成（Stable Diffusion 里排除"模糊、多余手指、低质量"），在文本模型里则是"禁止项"：不要编造数据、不要使用英文、不要超过三段、不要给医疗诊断。
适用场景：
- 图像生成：排除不想出现的元素与质量缺陷（噪点、水印、畸形）——SD 类模型的标配字段，效果立竿见影；
- 文风与格式控制：营销文案"不要用夸张感叹号、不要陈词滥调"——压掉模型的"AI 味"；
- 安全与合规：客服机器人"不要承诺退款结果、不要讨论竞品、不要透露内部流程"——业务红线的提示词化；
- 抑制已知 badcase：模型总是加开场白"当然可以！"——明确"直接给答案，不要开场白和客套"。
使用要点（重要的实践智慧）：
- 正向指令优先：心理学与实测一致——"用简体中文回答"远好于"不要用英文"（负向表述反而"提醒"了模型）；负面提示用于"正向说不清"的场景（"不要陈词滥调"——你很难正向穷举什么是好文风）；
- 负面清单要短而具体：堆 20 条"不要"，模型的注意力被稀释，反而顾此失彼；
- 配 Few-shot 兜底：一个"正确示范"比五条"禁止"更有效；
- 文本场景的硬约束靠工程：格式类"不要"用输出校验+重试闭环，比提示词可靠。
我的总结：负面提示是"排除法调优"工具——在正向描述无力时补刀，而不是主力手段；用得好是精细打磨，用滥是提示词膨胀的开始。
🏗 系统架构师
负面提示词 = 显式声明"不要什么"的约束指令（不要出现的内容、风格、元素），在两类场景价值最大：
使用场景：
- 图像生成（术语起源地）：Midjourney/SD 的
--no参数、提示里的"no text, no watermark"——排除水印、文字、多余肢体等高频缺陷；负面 embedding（专门训练的负面条件）是工程化形态； - 文本生成的禁区声明：输出约束（"不要输出解释、只要 JSON"）、安全红线（"不要提竞品名称"）、风格排除（"不要用营销腔"）；
- 代码生成：排除已知坏模式（"不要用全局变量、不要引入新依赖"）——把团队的历史踩坑变成约束。
有效使用要点：
- 负面 + 正面成对出现：只说"不要长篇大论"不如"回答控制在 200 字内"——模型对正向指令的遵循率高于负向禁止；负面约束是补充不是替代；
- 具体可执行："不要啰嗦"是模糊的，"不要重复问题背景、直接给结论"是可执行的；
- 位置：负面约束放在接近输出的位置（尾部注意力高）——离输出越远越容易被"遗忘"；
- 对抗性测试：故意用诱导性输入验证负面约束的强度（约束是软的，高诱导下会被突破——安全级约束要配程序化校验兜底）。
架构师视角：负面提示词本质是把"已知失败模式"显式化为约束——它的来源应该是 badcase 分析（用户吐槽什么就禁什么），而不是拍脑袋列清单；约束清单要版本化管理，随 badcase 持续增补——这是把踩坑经验资产化的最小成本途径。
💻 全栈开发专家
负面提示词（Negative Prompt）：**告诉模型「不要什么」**的约束。两种主流用法：
1. 生成式约束（文本场景）：
- 禁止性内容：「不要提及竞品名称」「不要给出具体的收益承诺」；
- 禁止性行为：「不要编造数据来源」「不要输出免责声明之外的解释」；
- 风格禁区：「不要使用口语化表达」。
2. 图像生成（最出名的用法）：Stable Diffusion 等的 negative prompt 字段——「blurry, low quality, extra fingers」排除不想要的属性，对出图质量影响巨大。
什么时候用（判断标准）：出现以下信号时补负面约束：
- 输出反复出现同一类不想要的模式（复读、客套话、跑题元素）；
- 合规/安全红线（禁词、禁话题）；
- 图像生成的质量缺陷。
工程上的两个重要认知：
- 正向表述永远优先：模型对「做什么」的服从度高于「不做什么」（否定约束容易被忽略——尤其埋在长 prompt 中段时）。正确姿势是「负转正」：「不要冗长」→「回答限制在 3 条以内」；「不要编造」→「只使用给定资料，无依据时回答不知道」；
- 负面约束要具体可检测：「不要不专业」没法执行；「不得出现'保证''肯定'等词」可以执行且可程序校验——最好配输出侧的关键词过滤兜底（prompt 约束是概率性的，程序校验是确定性的）。
一句话：负面提示词是「补丁」不是「主药」——能用正向指令+结构化输出解决的，别靠否定句堆叠。