一个客服 Agent 的系统提示里同时写着"回答要简短"与"必须完整列出所有步骤"，于是它的输出时短时长——因为在简单问题上也列了七步，而在复杂问题上又只给了一句结论。两条规则都"被遵守"了一部分，这个"从未被发现"是这类问题的核心特征：冲突不出现在日志里、不出现在错误率里，只出现在"输出看起来不对劲"里——而它容易被归因为"模型水平"。
而冲突从未被人发现。
多规则提示的冲突是"规范里没有优先级"的直接后果。而它不报错，只表现为"输出质量不稳定"——于是团队会去"调提示"，而不是"解决冲突"。
1. 三种冲突形态
| 形态 | 例子 |
|---|---|
| 直接矛盾 | "要简短" vs "要完整" |
| 资源竞争 | "多举例" vs "控制长度" |
| 条件重叠 | "涉及金额必须给依据" vs "不要输出额外内容" |
第二项最隐蔽：**两条规则各自都要求"占用同一种资源"（token、步骤数、时间）**第二项的"判定"很简单：问"两条规则能否同时被满足"。"多举例"与"控制长度"不能（长度有限），"给依据"与"要简短"通常能（依据可以一句）。
，于是它们"必然互相挤压"。
第三项的"交叉"常被忽略："涉及金额必须给依据"与"不要输出额外内容"在"金额问题"上必然交叉——于是模型在"给依据"与"不输出额外"之间折中，结果"依据时有时无"。
第三项要看"适用条件是否交叉"：当两条规则的触发条件重叠时，模型必须自己选一个——而它的选择取决于排列顺序与措辞强度，不可控。
2. 为什么模型"两边都遵守一点"
| 机制 | 结果 |
|---|---|
| 无优先级 | 折中 |
| 措辞强度接近 | 随机或按位置 |
| 上下文位置 | 靠前的更容易被遵循 |
| 训练偏好 | 倾向"更保险"的那条 |
第一项是根因：模型没有"冲突检测"能力，它不会说"这两条要求矛盾，请澄清"——它会默默地做一个折中。这个"默默折中"在设计上有其合理性：它的任务是"完成请求"，而不是"审查规范"。所以"要求它检测冲突"是错位的期望——规范必须先自洽。
第四项的"后果"是系统性的："简短"这条在"简单问题"上被牺牲得最厉害——因为"多说一点"在简单问题上不会被惩罚（看起来更完整），而在复杂问题上会被长度限制拉回来。
第四项让表现更不可控："保险"通常等于"多说一点"，于是"简短"这条被系统性牺牲。
3. 三种消除冲突的方式
| 方式 | 效果 |
|---|---|
| 给优先级（"若有冲突，以 X 为准"） | 直接有效 |
| 合并成一条带条件的规则 | 最干净 |
| 拆成两个阶段/两个 Agent | 结构上消除 |
第一项最省事：一句"如与前述要求冲突，以本段为准"第一项的"写法"要具体到"哪条优先"："输出长度以本节限制为准，优先于前面的详略要求"——而不是笼统的"以本节为准"。
就能把"多条规则的仲裁"变成"明确的覆盖关系"。
第二项的"额外收益"是"可判定"：合并后的规则能写出断言（行数、步骤数、是否含"可选"字样），于是它进入"自动验收"，而不再是"看感觉"。
第二项更好："回答要简短"与"完整列步骤"可以合并成"用编号列出必要步骤，每步一行"——于是它们不再是两条规则，而是一条可执行的要求。
// 冲突 → 合并的示例
冲突：① 回答要简短 ② 必须完整列出所有步骤
合并：③ 用编号列出必要步骤（不含可选步骤），每步一行，总长不超过 8 行
// 收益：一条规则、可判定（行数 ≤ 8）、无冲突
4. 资源竞争的三种处理
| 处理 | 说明 |
|---|---|
| 明确预算（字数/步骤数） | 让"竞争"变成"分配" |
| 分级（重要时才完整） | 让条件决定详略 |
| 删掉低价值那条 | 承认它不重要 |
第一项是把"感觉"变成"数"："8 行以内"比"简短"可执行得多。
第二项在"场景差异大"时最实用：简单问题 3 行、复杂问题 8 行——于是"简短"与"完整"按复杂度分配，而不是全局冲突。
"规则清单"值得做成一张表，一眼看出重叠：
// 规则对照表（每行一条规则，标出"占用的资源"与"适用条件"）
规则 资源 条件
R1 回答简短 长度 全部问题
R2 完整列出步骤 步骤数 多步流程
R3 金额必须给依据 长度 涉及金额
R4 不输出额外内容 长度 全部问题
// 冲突：R1×R2（长度 vs 步骤）、R1×R3（都占长度）、R4×R3（额外内容 vs 依据）
// 处理：R1 与 R4 合并成"除结论/依据/步骤外不输出其它内容"，并给 R2 定行数上限
5. 检测冲突的三个手段
| 手段 | 得到 |
|---|---|
| 规则清单互相对照 | 人工发现矛盾 |
| 抽样对比输出 | 同一问题两次输出的详略差异 |
| "边界用例"测试 | 复杂/简单问题各测 |
第二项最实用：同一问题跑 10 次，若"长度与结构"波动很大，说明存在冲突或模糊。第二项的"量化"方式是"同一问题 10 次的长度标准差"：若标准差超过均值的 25%，说明"详略要求"没有定死——而它可能是冲突，也可能是"没写清"。
第三项是针对性的：用"该简短"与"该完整"的两类问题各测一遍，看是否有一类系统性违反。
// 冲突检测的四个用例（每类 3 条，共 12 条）
简单事实问题 → 应简短（≤3 行）
多步流程问题 → 应完整（编号，≥4 步）
含金额问题 → 应给依据（引用来源）
闲聊兜底问题 → 应短且不给步骤
// 若"简单问题"经常给出 7 步，说明"完整"压过了"简短"
"优先级"要写成"可执行的形式"，否则它本身也会被稀释：
// 三种写法（从弱到强）
弱："如冲突以本节为准"
中："输出长度上限为 8 行；该限制优先于任何详略要求"
强："输出长度上限 8 行。若与'完整列出步骤'冲突，删减步骤细节而不是删减结论"
// 判据：能否写出断言（行数 ≤ 8 / 必含结论）
6. 排错：五种"提示冲突"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 输出长短不定 | 两条规则竞争 | 合并或给预算 |
| 简单问题答得过详 | "完整"压倒"简短" | 分级条件 |
| 复杂问题答得太略 | 相反 | 明确"多步时要完整" |
| 规则莫名被忽略 | 位置稀释/冲突 | 结尾重申 + 去冲突 |
| 改一条规则另一条失效 | 二者耦合 | 合并成一条 |
第五项的"排查动作"是"每次只改一条，测全量用例"：若"改 A"让"B 类用例"变差，就说明 A 与 B 在竞争同一资源——此时不应当"再调 A"，而应当"合并两条"。
第五项是"冲突"的强信号：改 A 之后 B 的表现变了，说明它们共享同一条路径（资源或条件）。
最后一个"验收"实践：把冲突用例做成回归集（12 条，四类各 3 条），每次改提示都跑一遍。于是"改 A 让 B 变差"能在发布前被发现，而不是在用户投诉里。
// 冲突回归集（四类，各 3 条，共 12 条）
简单事实：答案应是 1–3 行
多步流程：应含编号步骤，且 ≤ 8 行
金额问题：应含来源引用
闲聊兜底：应短且不给步骤
// 断言：每条都写"行数/是否含编号/是否含引用"，于是可自动判
7. 边界：什么情况不必消除冲突
| 场景 | 为什么 | 做法 |
|---|---|---|
| 规则很少（≤3 条） | 冲突概率低 | 保留 |
| 输出不用于决策 | 波动可接受 | 保留 |
| 有人工复核 | 会被发现 | 保留 |
| 一次性任务 | 不长期 | 保留 |
判断口径一句话："两条规则是否在同一类问题上同时生效"。最后一条与"演进"有关的边界：规则数量增加时，冲突概率是"组合级"增长。所以"每加一条规则就对照现有规则检查一次"，比"事后统一梳理"便宜得多——而前者通常没人做。
同时生效（都要遵守），就必须给优先级或合并；只在各自场景生效（互不重叠），它们不构成冲突。
8. 自测
- 三种冲突形态里，哪一种最隐蔽？为什么"资源竞争"必然互相挤压？
- 为什么模型会"两边都遵守一点"？它为什么不会说"请澄清"？
- 为什么"保险"的选择通常等于"多说一点"？它系统性地牺牲了哪条规则？
- "给优先级"与"合并成一条"分别怎么做？为什么合并更干净？
- "改一条规则另一条失效"为什么是冲突的强信号？
- 判断"是否需要消除冲突"的那个问题是什么？