不是AI不行，是你给了它互相冲突的目标：Agent提示词冲突诊断

给Agent加规则是个累积过程：上线后发现一个问题，加一条规则；再发现一个问题，再加一条。半年后系统提示词变成两千字、三十条规则。

然后Agent开始表现得很奇怪：有时很啰嗦，有时又太简略；有时擅自行动，有时又反复请示。

这不是模型的问题。是规则本身自相矛盾，模型在冲突的指令之间随机选边。

一、五种常见的指令冲突

冲突一：详尽 vs 简洁

• 第3行：“回答要全面、完整、覆盖所有相关情况。”
• 第17行：“回答要简洁，不超过150字。”

模型的表现：不稳定。有时输出四百字，有时输出80字。因为它无法同时满足，只能概率性地偏向某一边。

而且这种冲突会污染整个系统——模型会把”指令不可靠”这个推断带到其他决策上。

冲突二：自主 vs 请示

• “遇到需要修改数据的情况，先确认再执行。”
• “你是自主Agent，应尽量减少对用户的打扰，独立完成任务。”

这两条在”要不要改数据”这个具体场景下直接对立。模型可能时而问你，时而直接改。

这类冲突最危险，因为它涉及副作用操作。今天它请示，明天它自作主张，你永远不知道下一次是哪种。

冲突三：严格格式 vs 有帮助

• “必须严格输出JSON，不要任何额外文字。”
• “如果发现用户问题有歧义，请提问澄清。”

模型遇到歧义时，要么违背第一条（输出文字），要么违背第二条（在JSON里瞎猜）。大多数时候它选前者，导致下游解析失败。

修法：明确优先级。“格式优先。遇到歧义时，在JSON的 clarification_needed 字段里说明，不要输出额外文字。“

冲突四：角色 vs 任务

• “你是一名严谨的法律顾问，措辞必须专业、保守，避免任何未经证实的陈述。”
• “你的任务是帮用户快速草拟合同条款，用户很急。”

角色设定要求保守，任务要求快速出结果。模型会两边摇摆——要么给一堆免责声明，要么给出没有依据的条款。

冲突五：通用规则 vs 特例

• “所有对外回复都必须经过审核。”
• “客户投诉必须在5分钟内响应。”

这两条在”投诉需要立即回复”的场景下冲突。如果没有写好例外条款，模型会在规则之间打转。

二、为什么冲突会持续存在

因为大部分人不会重读整个提示词。

每次加规则，都是针对一个具体case打的补丁。加的时候看的是”这条能不能解决这个问题”，不看”它和已有什么冲突”。

而且提示词里规则没有优先级标注。所有规则平铺在一起，模型只能自己判断哪条重要。模型判断的依据是什么？位置和措辞的强度——通常是靠后的、语气更重的赢。

所以提示词的”实际生效顺序”是反的：越晚加的越容易生效。这意味着早期的核心规则会被后来的补丁覆盖。

三、诊断方法

方法一：让模型自己指出冲突

把完整提示词丢给模型（另一个厂商的模型更好），问：

请找出这段系统提示词中互相矛盾或可能在实际执行时冲突的指令对。对每一对，说明在什么场景下会冲突，以及按什么优先级解决会更合理。

这个办法出奇地有效。模型在读”别人的”提示词时，对矛盾的敏感度远高于执行时。

注意：别用同一个模型，别用同一个会话（会带上下文）。

方法二：场景矩阵测试

列出你的Agent需要处理的所有场景类型，做成表格。对每个场景，检查每条相关规则是否指向同一个方向。

场景	适用规则	是否冲突
用户问简单问题	简洁规则、全面规则	✅ 冲突
用户要求改数据	请示规则、自主规则	✅ 冲突
用户输入有歧义	格式规则、澄清规则	✅ 冲突

任何一行出现两个✅，就是一个待修点。

方法三：记录矛盾行为

上线后，把系统表现不一致的case记下来：同一个输入、同样的上下文、两次不同结果。

这些case大概率对应一处规则冲突。收集十个，通常能定位到两三个根本冲突。

四、分层重写

修冲突最有效的方法不是删规则，是分层。

第一层：身份（不超过3句）

你是谁、为谁服务、边界在哪。

你是XX公司的客服助手，为已购客户服务。不处理售前咨询、不处理退款审批、不提供法律或医疗建议。

这一层只放”不可协商”的东西。

第二层：优先级声明（关键）

明确写出冲突时的解决顺序：

当以下原则冲突时，按此顺序优先：

1. 安全与合规
2. 数据正确性
3. 输出格式
4. 简洁性
5. 主动性

这一段是整个提示词最有价值的部分。 它让模型在遇到未预见的冲突时有确定的裁决依据，而不是随机选。

第三层：任务与流程

具体怎么做：步骤、工具使用条件、分支判断。

流程应该用编号步骤或伪代码表达，而不是一段散文。结构化表达能显著降低歧义。

第四层：风格与格式

输出格式、语气、长度。放最后，因为这一层最常改。

第五层：示例

few-shot示例。注意——示例是最强的指令。如果示例和上面的规则冲突，模型会跟着示例走。

所以每加一个示例，都要检查它是否违背了前三层。

五、几条具体原则

1. 一条规则只表达一个要求。 “回答要简洁清晰、避免术语、给出参考来源”——这是三条规则塞进一句。拆开写。

2. 用否定句要谨慎。 “不要输出任何额外文字”很明确，但”不要过于啰嗦”就模糊。模糊的否定会让模型过度反应，变得极度简略。

3. 给”例外”明确的触发条件。 “一般不超过150字，除非用户明确要求详细说明，或问题涉及多步骤流程。“——有例外条款的规则才可执行。

4. 规则数控制在15条以内。 超过这个数，模型的遵守率会明显下降。抽象出共性原则，替代罗列具体case。

5. 用”如果…那么…”表达分支。 自然语言里的条件句比”同时要…又要…”更容易被正确执行。

六、改完之后怎么验证

准备冲突敏感测试集：专门测那些曾经冲突的场景。

比如针对”简洁 vs 详尽”，测试：

• 简单问题 → 应简短
• 复杂问题 → 应详细
• 用户说”详细说说” → 应详细
• 用户说”一句话” → 应极简

四个场景都通过，说明这个冲突修好了。

这类测试比通用测试集更有针对性，也更容易发现回归。

七、一个更深的问题

提示词冲突的本质，是产品决策没有被明确。

“要不要请示用户”不是一个提示词问题，是一个产品设计问题——你希望这个Agent的行为模式是什么？

写提示词时遇到的每一个冲突，都对应一个没想清楚的产品决策。 把这些决策显式地写出来（写进优先级声明），比在提示词里打补丁有效得多。

这也是为什么好的Agent提示词看起来像一份规格说明书，而不是一堆叮嘱。

结语

提示词不是越长越好，是越一致越好。

三十条互相打架的规则，不如十条有明确优先级的规则。

当你发现Agent行为不稳定时，先别换模型——先读一遍你的提示词，找找里面有几个自己在跟自己做对。