一个客服助手在提示里写了七条"不要"：不要编造、不要承诺、不要猜测、不要说不知道、不要用感慨号、不要提竞品、不要超过 80 字。上线后它依然偶尔编造——而那七条"不要"里，有四条互相冲突（"不要猜测"与"不要说不知道"）。
否定指令有两个问题：它没说"该做什么"（于是模型只能猜），以及多条否定会互相冲突（于是它只能"折中"）。这个"可执行"的差别在于"目标状态"：肯定句给出"输出应该长什么样"，否定句只给出"输出不该长什么样"——而"穷举不该"是不可能的。
而"改成肯定句"往往能让同样的意图"可执行"。
1. 为什么"不要"弱于"要"
| 原因 | 说明 |
|---|---|
| 否定句"没有目标行为" | 只能"避免"，而"避免"不可执行 |
| 训练里"否定"常被忽略 | 语料里"不要"后面跟的仍是"那个行为" |
| 多条否定互相冲突 | 只能折中 |
第二项最"反直觉"："不要提竞品"这句话本身提到了竞品第二项的"机制"是"激活"：读到"竞品"，概念就被点亮，于是"提及"的概率上升——这与"不要想一只白熊"是同一个现象。
——于是模型"激活"的是"竞品"这个概念。
2. "三条否定"的改写对照
| 否定 | 改写（可执行） |
|---|---|
| 不要编造 | 只依据检索到的原文回答；无依据时写"资料中没有" |
| 不要承诺 | 涉及时间/金额只引用政策原文的表述 |
| 不要超过 80 字 | 输出不超过 3 句，每句一个信息点 |
第三项的"额外收益"是"可测试"："不超过 3 句"能写进断言，"简洁"只能靠人看——于是"验收"从"抽样"变成"每次"。
第三项是"把约束数字化"："80 字"可数，"简洁"不可数——于是"可判定"的约束才会被执行。
3. "否定冲突"的三种组合
| 组合 | 结果 |
|---|---|
| 不要猜测 + 不要说不知道 | 只能编（最坏） |
| 不要啰嗦 + 要完整 | 折中（都不满足） |
| 不要提竞品 + 要客观对比 | 自相矛盾 |
第一项是"开头那个事故"的根因：两条一起，等于"要求它猜得很好"第一项的"解法"只有一个：删掉其中一条——"无依据就说没有"再配"不给猜测"是重复的，因为"说没有"已经堵住了"猜"。
——而"编造"正是这个组合的必然产物。
"冲突检测"可以做成"两两对照"的清单，成本十分钟：
// 一份"否定清单的冲突检查"（逐对看）
对 A：不要猜测 × 不要说不知道 → 冲突（只能编）→ 合并
对 B：不要啰嗦 × 要完整 → 冲突（折中） → 分场景定
对 C：不要提竞品 × 要客观对比 → 冲突（矛盾） → 删一条
// 判据：任一"对"里，两条能否"同时被满足"
4. "改成肯定句"的三步
| 步骤 | 动作 |
|---|---|
| 1 找出"禁止的行为" | 它在做什么 |
| 2 写出"替代行为" | 该做什么 |
| 3 给"可判定标准" | 怎么算做到 |
第二步的"难点"在"要想到替代"："不要迟到"的替代不是"按时"，而是"提前 5 分钟出发"——于是"替代"要具体到"一个可做的动作"。
第二步是关键："不要编造"的替代行为是"无依据时明确说没有"——于是"编造"被"一个具体的动作"取代。
// 一次改写（同一意图）
原：不要编造，不要猜测，也不要说不知道
改：只引用检索到的原文；若检索结果为空，回答"资料中没有相关内容，可咨询 X"
// 判据：改后"读一遍就知道该做什么"，而不是"知道不该做什么"
"改写"可以按"一张表"批量做，而不必"逐条想":
// 一张"否定 → 肯定"的对照表（示例四行）
不要编造 → 只引用检索原文；无依据时回答"资料中没有"
不要承诺时间 → 时间只引用政策原文的表述（"7 个工作日"）
不要啰嗦 → 输出 ≤ 3 句；每句一个信息点
不要提竞品 → 只描述我方能力，不做"对比"
// 用法：把这张表当成"提示的骨架"，而不是"补充说明"
5. "数字化约束"的三种写法
| 写法 | 可判定 |
|---|---|
| 简洁 | 否 |
| 不超过 3 句 | 是 |
| 每句 ≤ 25 字 | 是（更严） |
第二项与第三项"可被程序检查"——于是它们能进"自动验收"，而不只是"提示里的一句话"。这个"能进验收"的价值常被低估："提示里写十遍"不如"每天跑一遍断言"——因为前者依赖"模型每次都注意"，后者依赖"程序每次都检查"。
"遵守率"可以用"抽检 + 断言"两条腿，而后者更便宜：
// 两种"验收"
1 人工抽检 20 条：看"有没有编造/超长/提竞品"（每周一次）
2 程序断言：输出句数 ≤ 3；含"资料中没有"时必须无引用；含金额必须有出处
// 判据：能写进断言的，就别靠抽检；抽检只留给"主观项"
6. 排错：五种"否定指令问题"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 仍然编造 | 只有"不要" | 改肯定 + 给替代 |
| 时而遵守时而不 | 约束不可判定 | 数字化 |
| 输出互相矛盾 | 否定冲突 | 合并成一条 |
| 越加越多 | 每次事故加一条 | 定期合并 |
| 换了模型就失效 | 依赖"隐含理解" | 显式规则 + 示例 |
"示例"是最强的"肯定指令"，而它比"规则描述"更省字数：
// 一个"少而有效"的示例块（两行）
好例：据《售后政策 2024》第 2 条，签收后 7 天内可退货；拆封后不支持。
坏例：肯定可以退的，您放心！（无出处、含承诺、含语气词）
// 判据：示例里"该做什么"与"不该做什么"同时出现，且都短
7. 边界：什么情况"不要"是可以的
| 场景 | 为什么 | 做法 |
|---|---|---|
| 硬红线（法律/安全） | 必须明文禁止 | 保留"不要"，但配"替代动作" |
| 极短的负面清单（1–2 条） | 无冲突风险 | 可保留 |
| 有"示例"辅助 | 示例承载"该做什么" | 可保留 |
| 已有"程序化校验"兜底 | 不依赖模型自觉 | 可保留 |
最后一条与"演进"有关的边界："否定清单"只会增不会减（每次事故加一条），于是"半年后 60 条，互相冲突"——所以它需要"季度合并"，把"相关几条"合成"一条肯定规则"。
判断口径一句话："这条约束，能不能写成"一个具体动作 + 一个可判定标准"。能（"无依据就说没有"+"输出里必须出现'资料中没有'"），就改写；不能（"不要有攻击性"这类主观判断），就配"示例 + 人工抽检"。
再补一个"改写后的验收"细节：改写不等于"一次到位"——把新规则上线后，需要"重跑那批失败用例"，看"编造率/超长率"是否下降。因为"肯定句"也可能"被模型忽略"，只是"忽略的方式不同"（比如"输出 4 句"而不是"编造"）。所以"改写"要配"同一批用例的前后对比"，否则你只是"换了一种失败的形状"。
还有一条"文化"上的观察："不要"清单往往是"事故的墓碑"——每次出事加一条，于是它记录的是"我们踩过什么坑"，而不是"我们要什么"。而"肯定规则"天然是"面向未来"的：它描述"好回答长什么样"。这个视角的转变，比"改措辞"更根本。
这条转变，通常一次就够了。
而它只在"写规则的人"换位思考时才发生。
8. 自测
- "不要"为什么弱于"要"？"不要提竞品"这句话激活了什么？
- 三条否定改写的共同点是什么？为什么"数字化"能提升遵守率？
- "不要猜测 + 不要说不知道"为什么"只能编"？
- "改写成肯定句"的三步分别做什么？哪一步最关键？
- "可判定"的约束为什么能进"自动验收"？
- 判断"能否改写"的那个问题是什么？