核心 GUIDE
Instruction Conflict（指令冲突）
Instruction Conflict 指多个看起来都合理的 Source 要求系统采取彼此不兼容的行为。可靠系统需要显式识别冲突，而不是让模型临场“折中”。
核心心智模型
Conflict 不只是“文字有点乱”，而是两个 Instruction 在同一 State 下无法同时满足的 Decision Point，因此系统必须依靠 Precedence、Clarification 或 Safe Refusal 来处理。
为什么重要
多 Source AI Application 同时组合 System Rule、Developer Workflow、User、Retrieved Policy 与 Tool Feedback，因此 Conflict 是常态而不是例外。如果系统没有把它建模成 First-class State，模型可能只选择当前最显眼的措辞，导致行为不一致，也难以 Debug 与 Audit。
01
检测、分类并解决 Conflict
先定义哪些 Source 有资格发出 Instruction，再检查它们要求的 Action 是否能够同时满足。可以把冲突分类为 Authority Conflict、Policy Ambiguity、Stale State 或 User-goal Tension。不同类型分别使用 Precedence、Clarification、Evidence Refresh、Refusal 或 Escalation，而不是统一交给模型猜。
02
示例：User Goal 与 Compliance Rule 分叉
User 希望为了加快客服处理，把完整 Customer Record 发给合作方。用户目标本身合理，但 Application Policy 禁止导出敏感字段。系统应识别两者不可同时满足，保留用户真正想解决的问题，并提供允许的 Workflow，而不是各执行一半。
常见失败模式
- 用“Use Best Judgment”掩盖真实 Conflict。
- 把所有 Conflict 都当成 Security Attack，忽略普通 Policy Ambiguity。
- 只解决当前 Turn，却不记录底层冲突 Rule 或 Stale State。
工程启发
- 在 Trace 或 Structured State 中让 Conflict Detection 可观察。
- 根据 Conflict Type 选择 Resolver，而不是使用一个通用 Prompt。
- 拒绝冲突 Action 时尽量保留 User 的真实目标并提供可行路径。
关键结论
- 01多 Source System 中 Instruction Conflict 是正常现象。
- 02Conflict 应触发显式 Resolver，而不是模型即兴决定。
- 03好的解决方式会把 User Goal 与不安全或不可执行的 Requested Action 分开。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。