核心 GUIDE
Instruction Authority（指令权威层级）
可靠 Prompting 的前提，是知道不同 Instruction Source 谁有权决定行为。System、Developer、Retrieved Context 与 User Text 并不是可以平等互相覆盖的 Peer。
核心心智模型
Instruction Authority 是 Source-aware 的 Precedence Model。更高 Authority 的应用规则约束更低层请求，而 Retrieved Content 通常只是 Evidence，不应自动变成新的系统行为所有者。
为什么重要
如果没有 Authority Model，系统即使每一段 Prompt 都写得很好，整体仍可能互相矛盾。这不仅是 Security 问题，也是普通产品行为问题：Policy Text、Example、Tool Output 与 User Request 必须按照角色解释，否则就等于让模型只根据“谁说得更像命令”来决定治理关系。
01
先分配 Authority，再处理措辞冲突
在模型行动前先标记每个 Source 的 Ownership 与 Purpose。Application-owned Rule 定义不可违反的 Constraint，User Input 在这些 Constraint 内定义 Task，Retrieved Material 默认提供 Fact，除非应用明确提升其 Authority。出现冲突时，应在 Source Policy 层解决，而不是继续给文字加“必须”“绝对”等更强形容词。
02
示例：Retrieved Policy 试图覆盖审批边界
客服系统检索到一篇 VIP Refund Article，其中写着可以忽略较低退款上限；User 又要求立刻退款 300 美元。Flat Authority 会把两者都当成有说服力的 Instruction。Source-aware Model 则保留应用的 100 美元 Approval Boundary，把文章当 Eligibility Evidence，而不是绕过 Gate 的 Permission。
常见失败模式
- 把所有 Prompt Text 都当成同 Authority 的 Instruction。
- 允许 Retrieved Document 悄悄重定义 Application Policy。
- 用更强烈措辞解决 Precedence Conflict，而不是定义 Source Rule。
工程启发
- 为每个可能包含 Instruction 的 Source 定义明确 Role 与 Owner。
- 默认把 Retrieved Content 当 Evidence，而不是 Executable Authority。
- 先在 Policy 与 Architecture 层解决冲突，再优化 Prompt Wording。
关键结论
- 01Authority 取决于 Source Role，而不是语言强度。
- 02Context 可以包含 Instruction，但不代表它拥有系统行为控制权。
- 03清晰的 Precedence Model 同时降低普通行为冲突与 Prompt Injection 风险。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。