你在 prompt 里加了”不要太通用”，因为上次输出很通用。新输出确实没出现”通用”这个字，改用了”普适”。它依然通用。你又加”不要写大段文字”——模型给了 bullet，把大段文字拆成了 8 行。光靠负向约束不管用，因为它只说不做什么，没说要做什么。模型回避字面短语，用别的措辞重现底层行为。修法不是加更多”不要”，是给每条”不要”配一个具体的”要”。
本文讲为什么”只负向”约束必败，以及怎么把它们翻成模型能执行的正向引导。
常见原因
1. 负向写成价值判断而不是行为
“不要通用”是价值判断。“通用”在评审眼里，不对应任何具体输出特征。模型没法对照检查。
如何判断：你的负向是形容词或价值词，不是具体 token/结构/模式。
2. 没正向目标
只禁止时模型没方向可去。它选下一个最可能的产物，常常就是下一个最通用的。
如何判断：你的 prompt 有”不要 X”但没配”要 Y”。
3. 模型换说法绕开
禁词它就用近义词。禁模式它用稍微变形。表面禁不挡行为，会被钻空子。
如何判断：禁词没了，底层行为没变。
4. 禁词单太长
20 个禁词稀释注意力。模型当背景噪音处理。短而具体的清单会被遵守；长清单不会。
如何判断：你的”不要”清单 15+ 项。
5. 禁令和其他 prompt 内容矛盾
“不要用行话” + 技术任务无术语表 = 模型只能选”不准确”或”违反规则”。它通常无声违反。
如何判断：禁令在任务下不可行。
动手前先确认
- 列出 prompt 里每条”不要”。
- 每条对应你真正想要的行为（配对的”要”）。
- 每条禁令是具体（可测）还是含糊（要解读）。
- 决定哪些禁令值得保留、哪些砍掉。
- 给每条留下来的禁令规划一个正向锚（示例、schema 或规则）。
需要收集的信息
- 当前 prompt 里全部负向约束清单。
- 绕开禁令的输出。
- 你实际想要的行为。
- 模型是换说法绕开还是真的漏了禁令。
- 模型 + 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% 的拒付处理摩擦。"
不要这样：
"我们利用了稳健的支付方案优化结算流程。"对比让两个方向都清晰。
Step 5：末尾加自检
写完后核对：
- 用过禁词吗？列出来。
- 每段是否至少 2 个具体数字或命名工具？
- 任何一项失败就重写。强制模型自审来抓绕开。
Step 6：常用禁令锁进 project / system prompt
如果”不用企业行话”是全工作流的长期规则，挪到 project 指令，不占每个 prompt 空间，也躲开近期漂移。
怎么确认已经修好
- 新输出无禁词。
- 新输出包含你要求的具体正向特征。
- 故意输入差的内容也不回到旧行为。
- 同事看输出说不出你用了哪些禁令——只看到好输出。
如果还是没修好
- “要”配得太软——把正向变可测。
- 加 1-2 个 pass/fail 示例。
- 切到结构化输出（JSON、schema）——结构让部分禁令不必要。
- 复杂禁令让模型先规划再写；在规划阶段就能挡掉问题。
预防建议
- 默认规则：永远不写孤立”不要”。
- 每个工作流保留稳定的短禁词单（最多 5-10 条）。
- 解读性禁令一定配示例做正向锚。
- 每季度审一次累积的无配对”不要”。
- 团队工作流把禁词单当配置文件，不当临时 message 文本。
- 自己写一段故意差的输出测禁令；模型产出像你的差例时就说明禁令没打中。