Prompt Engineering 知识架构
来源：42 个一手数据文件 + Claude Code 系统提示词深度分析，303 + 30 条原始编码，87 条核心原则
方法论：深度知识体系构建（Grounded Knowledge Architecture）
一致性检验：通过（发现 2 处需补充说明，已在正文中解决）
收敛自：evidence/phase2-3-merged-analysis.md
一致性声明
Phase 4 检验结果
4.1 两两对比检验（重点对 5 组）：
| 对比对 | 结论 | 说明 |
|---|
| P020（直接要求）vs P024（模糊时澄清/覆盖） | 一致 | P020 解决”已知想要什么”的场景——直接说出来；P024 解决”指令本身不清晰”的场景——先消歧再执行。二者是顺序关系：先判断是否模糊（P024），若不模糊则直接要求（P020）。 |
| P021（做什么 > 不做什么）vs P023（约束范围） | 一致，互补 | P021 指导指令的表述方式（正面表达优于否定）；P023 指导指令的覆盖范围（显式划定边界）。一个管”怎么说”，一个管”说多宽”，不冲突。 |
| P029（通用指令优于步骤）vs P042（明确拼出思考步骤） | 条件一致 | 已在关系网络中标注为条件分支：推理模型用 P029，基础模型用 P042。补充说明：即使使用 P029，也可以用 P042 的 XML 标签隔离思考区域——二者可组合为”给出高层目标 + 用标签隔离思考区域，但不规定具体步骤”。 |
| P014（末尾重申任务）vs P009（数据顶部、查询底部） | 一致 | P009 说的是数据/文档放顶部、查询放底部；P014 说的是在长 prompt 末尾重申任务。两条指向同一个结论：任务指令应靠近 prompt 末尾。P009 管数据位置，P014 管任务重申，完全兼容。 |
| P053（降温减幻觉）vs M002 裁决 | 自洽 | P053 的通用原则”低温度 = 更确定性”成立，M002 裁决正确标注了 Gemini 3 是例外。P053 适用条件中已标注”另见矛盾 M002”，读者可追溯。 |
补充发现的 2 处需说明：
-
P006（模型对模式敏感）与 P031（角色提示）的关系：P006 说你的表达模式会传染给模型，P031 说角色提示改变风格。二者一致且互补——角色提示正是利用”模式传染”机制来引导输出风格。在下方架构中已标注为互补关系。
-
P015（高频内容放开头利用缓存）与 P014（末尾重申任务）的潜在张力：P015 建议把不变的内容放开头以命中 prompt cache；P014 建议在末尾重申任务。二者实际不冲突——P015 管的是”系统提示的稳定部分”放最前面，P014 管的是”用户的即时任务”在末尾重申。一个是 cache 优化策略，一个是注意力引导策略，层面不同。
4.2 矛盾裁决审核：6 处矛盾（M001-M006）裁决均合理，详见附录。
4.3 结论：72 条原则体系内部一致，无未解决的逻辑冲突。所有表面矛盾均为条件分支或平台差异，已通过适用条件标注消歧。
Tier 1: 通用原则（Universal Principles）
所有 LLM、所有场景都适用的基石原则。无论你用什么模型写什么 prompt，这些都成立。
P001 — LLM 是概率预测引擎
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用，是所有 PE 的理论基础
原则：LLM 本质上是概率预测引擎，不是知识库。没有 prompt 锚定时模型会随机采样训练数据。
为什么有效：理解这一本质才能明白为什么 prompt 的措辞、结构、示例都会影响输出——它们改变的是模型采样的概率分布。
怎么做：设计 prompt 时想的不是”问模型一个问题”，而是”给模型足够的上下文让它朝正确方向采样”。
证据：C027, C028, C029, A036
相关原则：→ P006（模式敏感是概率本质的直接推论）→ P041（CoT 通过改变 token 序列条件概率生效）
P002 — PE 是迭代的科学过程
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用
原则：Prompt Engineering 不是”写一次就好”，而是 Plan → Draft → Evaluate → Refine → Deploy 的完整生命周期。
为什么有效：第一版 prompt 几乎不可能完美。系统性迭代比灵感式修改更高效。
怎么做：每次修改只变一个因素，用固定测试集验证效果，记录每个版本的表现。
证据：A056, A067, A109, B003, B048
相关原则：前置依赖 P070（先有评估标准才能迭代）；互补 P071（单变量迭代方法论）
P006 — 模型对模式敏感
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用
原则：你犯错它犯错，你聪明它聪明。prompt 中的拼写、语法、格式质量会直接传染给输出。
为什么有效：P001 的直接推论——模型按条件概率采样，你提供的模式就是条件。
怎么做：prompt 中保持专业的拼写和语法；如果希望输出用正式语言，prompt 就用正式语言。
证据：A018, A019, A083, C052
相关原则：依赖 P001；互补 P031（角色提示利用模式传染机制）
P019 — 像对新员工一样清晰
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用
原则：模型除了你告诉的内容之外没有任何上下文——像对一个聪明但完全不了解背景的新员工解释任务。
为什么有效：消除”模型应该知道”的假设，迫使你把隐含的背景知识显式化。
怎么做：写完 prompt 后自问：如果一个没有上下文的人读到这段话，能否准确完成任务？
证据：A005, A006, C032
相关原则：→ P020（直接要求）→ P022（解释原因）
P020 — 直接要求你想要的
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用
原则：想让它做选择就明确说，想跳过前言就直接说，想要 JSON 就直接说。不要暗示，直接要求。
为什么有效：模型擅长遵从明确指令，不擅长猜测言外之意。
怎么做：把期望的行为写成祈使句。“列出 5 个方案并推荐最优”比”能不能帮我想想有什么方案”好得多。
证据：A007, A008, A009, A069, A086, B052
相关原则：前置依赖 P019；互补 P022（解释为什么要这样做）
P021 — 正面指令优于否定约束
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用（默认推荐）；但安全约束、边界定义、破坏性操作限制等场景，否定指令（NEVER/Do not）更直接有效——详见 P079
原则：告诉模型”做什么”比”不做什么”更有效。避免过于宽泛的否定如”do not infer”。
为什么有效：否定指令定义的是无限大的禁止空间，模型仍不知道应该做什么。正面指令直接指向目标。
怎么做：把”不要编造数据”改为”仅使用提供的数据，缺失字段标记为 null”。
证据：A082, B063, C039
相关原则：互补 P023（约束范围）——一个管表述方式，一个管覆盖范围；Agent 场景修正见 P079（否定约束的精确使用）——Anthropic 在 Claude Code 中使用了 25+ 条否定指令，证明安全/边界场景下否定指令更有效
P022 — 解释指令背后的原因
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用
原则：解释”为什么”能让模型更好地泛化到边缘情况，比单纯禁止更有效。
为什么有效：原因提供了推理的锚点——遇到指令未覆盖的情况时，模型可以从原因推断应有的行为。
怎么做：在关键指令后加一句原因。“回答限制在 200 字以内，因为这会显示在移动端通知中。”
证据：A071, A072, B063
相关原则：互补 P020
P026 — 直奔主题
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用
原则：不要复述用户请求；跳过填充词、前言和不必要的过渡，直接给出实质内容。
为什么有效：减少无意义 token 消耗，提高信息密度，让输出更实用。
怎么做：在 prompt 中加入”Skip preamble. Start with the answer directly.”
证据：B018, B052, A127
相关原则：互补 P025（长度/格式约束）
P027 — 定义退出机制
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用，减少幻觉的关键手段
原则：告诉模型可以说”不知道”、可以拒绝、可以保持原答案不修改。
为什么有效：没有退出机制时，模型被迫在所有情况下生成答案，即使它实际上不确定——这是幻觉的主要来源之一。
怎么做：加入 “If you cannot determine the answer from the provided context, say ‘I don’t have enough information to answer this.’”
证据：A037, A060, A115, B054, A121
相关原则：互补 P049（先引用再回答）→ 系统性减少幻觉；互补 P051（不确定时避免编造）
P035 — Few-shot 示例是最有效的 PE 工具
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用（受 token 预算约束）
原则：示例既能得到正确答案，又能得到正确格式。示例比冗长的文字描述更有效。
为什么有效：示例直接展示了期望的输入-输出映射，消除了文字描述的歧义。
怎么做：用 <example> 标签包裹 2-5 个示例，涵盖典型和边缘情况。
证据：A032, A033, A034, A046, A048, B010, C067
相关原则：→ P036（示例质量要求）→ P037（3-5 个最佳）→ P038（格式比内容重要）→ P039（展示思维链）→ P040（用困难用例）
P041 — 给模型”思考时间”（Chain of Thought）
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：复杂推理/数学/逻辑任务；简单提取/分类任务无需
原则：让模型展示推理过程能显著提升复杂任务的准确性。
为什么有效：显式输出推理步骤改变了 token 序列的条件概率——每一步正确的推理都为下一步提供更好的上下文。
怎么做：简单任务用 “Think step by step”（P044）；复杂任务明确拼出步骤 + 用 <thinking> 标签隔离（P042）。
证据：A026, A027, A030, C055, C071
相关原则：依赖 P001；→ P042, P044, P045, P046（特化技术）；互补 P039（示例中展示思维链）
P051 — 不确定时避免编造
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用
原则：用”Based on the provided context…”替代绝对断言；缺失字段设为 null 而非猜测。
为什么有效：与 P027（退出机制）协同——模型知道有”不知道”的出口时，更倾向于诚实回答。
怎么做：指令中加入 “If a field is not present in the source, set it to null. Do not guess or infer values.”
证据：B026, B027, B043, B044
相关原则：互补 P027, P049, P050
P061 — 上下文是有限资源
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用
原则：找到”最大化预期结果概率的最小高信号 token 集合”。
为什么有效：无关信息会稀释模型的注意力，增加成本和延迟，甚至引入噪音。
怎么做：每加一段内容都问：这对完成任务是否必要？如果删掉会影响结果吗？
证据：A142, A147, C034
相关原则：上位概念 P004；→ P062（截断策略）→ P065（JIT 上下文）
P070 — 先定义成功标准
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用，尤其是生产环境
原则：先定义成功标准和评估方法，再开始写 prompt。没有评估体系的 prompt 优化是盲人摸象。
为什么有效：没有标准就无法判断修改是改进还是退步。
怎么做：准备 10-20 个测试用例，定义预期输出，建立自动化评估流水线。
证据：A067, B003, B048
相关原则：→ P002（迭代循环的前提）；互补 P071
Tier 2: 核心技巧（Core Techniques）
经过充分验证的实操技巧，按任务类型组织。
2A. Prompt 结构与组织
P007 — 系统提示词是行为锚点
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：所有 API 场景
原则：系统提示在 user turn 之前提供上下文、指令和指南，精心编写能显著提升表现。
为什么有效：系统提示设定了整个对话的基调和行为边界，模型会持续参考它。
怎么做：始终使用系统提示，哪怕只是一句角色定义 + 核心约束。
证据：A001, A002, B006, C031
相关原则：→ P008（推荐结构）
P008 — 推荐的系统提示结构
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：中等以上复杂度的 prompt
原则：Identity/角色 → Instructions/规则 → Examples/示例 → Context/数据。复杂 prompt 可包含多达 10 个标准元素。
为什么有效：结构化的信息组织让模型更容易解析和遵循，减少遗漏。
怎么做：按 Identity → Instructions → Examples → Context 顺序组织；用 XML 标签或 Markdown 标题分隔各部分。
证据：A041, A043-A054, B006, C001, C004-C009
相关原则：上位概念，包含 P007, P009, P017
P009 — 数据顶部，查询底部
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：含长文档的场景
原则：长文档/数据放在 prompt 顶部，查询/指令放在底部——查询在末尾可提升响应质量达 30%。
为什么有效：模型对最近处理的 token（prompt 末尾）注意力最强（recency bias）。
怎么做：[系统指令] → [参考文档/数据] → [用户查询]
证据：A078, A079, A050, A051, A113, B068（三方共识，见 M005 裁决）
相关原则：与 P014（末尾重申）一致；与 P015（缓存优化）兼容
P010 — 用 XML 标签分隔内容边界
置信度：★★★★★ (95%+)
适用范围：通用（Claude 专门训练过 XML 识别，但所有模型都受益）
适用条件：始终适用
原则：将变量数据与指令分离，用一致的描述性标签名，支持嵌套反映层级。
为什么有效：明确的边界让模型精确区分”这是指令”和”这是数据”，减少混淆。
怎么做：<instructions>...</instructions> <context>...</context> <user_query>...</user_query>
证据：A015, A016, A021, A049, A076, A077, B008, C051
相关原则：互补 P011（XML 管边界，Markdown 管层级）
P011 — 用 Markdown 传达层级
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用
原则：用 Markdown 标题和列表传达层级关系；编号列表用于顺序和完整性重要时。
怎么做：# 用于大分区，- 用于并列项，1. 2. 3. 用于顺序步骤。
证据：A070, B007, C047
相关原则：互补 P010
P014 — 关键指令散布重复
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：长 prompt（>1000 tokens）；Agent 场景尤其重要
原则：在长 prompt 末尾重申即时任务，比放在开头效果更好。在 Agent 场景（超长 prompt）中，应进一步采用”散布重复”策略：关键约束不仅在首尾出现，还应在 prompt 中间的相关段落处（如工具描述、SOP 步骤中）重复出现，确保无论模型注意到哪段文本，关键约束都在近距离可见。
为什么有效：利用 recency bias——模型对 prompt 末尾的注意力最强。在超长上下文中，LLM 注意力不均匀，散布重复确保关键约束在任何相关位置都”可见”。
怎么做：短 prompt→末尾重申即可。长 prompt/Agent 场景→识别关键约束→系统提示开头完整声明→每个相关工具描述中重复→相关 SOP 步骤中引用→末尾简短重申。
证据：A050, A057, B022；AP-009（Claude Code 安全约束在 L36 和 L187 逐字重复；文件操作偏好在 4+ 位置出现）
相关原则：与 P009 一致（任务靠近末尾）；Agent 场景详见 P080
P017 — 明确指定输出格式
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：需要程序化消费输出时必须
原则：语言、语法、结构化格式（JSON/XML/Markdown）和样式偏好，放在 prompt 末尾。
怎么做：提供输出 schema 示例；对 JSON 输出指定字段名和类型。
证据：A022, A053, A107, B041, B051, C019, C025, C054
相关原则：P008 的组成部分；互补 P025（长度约束）
2B. 指令编写
P023 — 明确约束范围
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：编码和生产环境尤其重要
原则：只做直接要求的，不加额外功能和”改进”。明确划定模型应做和不应做的边界。
为什么有效：模型倾向于”过度帮忙”，没有边界约束时会添加不必要的功能或信息。
怎么做：加入 “Only perform the specific task described. Do not add features, improvements, or information beyond what is requested.”
证据：B019, B035, A130, A131, A132
相关原则：互补 P021
P030 — 不同模型需要不同策略
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：模型选择/迁移时
原则：推理模型给高层目标，基础模型给精确指令。不能用同一个 prompt 套所有模型。
为什么有效：模型架构和训练方式不同，指令遵从能力和推理能力差异巨大。
怎么做：迁移 prompt 时先不改内容只换模型，观察差异后再针对性调整。
证据：B001, A089, A090, B046
相关原则：互补 P071（迁移方法论）；条件分支：推理模型 → P029，基础模型 → P042
2C. 角色与人格
P031 — 角色提示改变风格和深度
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用
原则：角色提示改变风格、语气和回答深度，可以放在系统提示或 user turn 中。
为什么有效：角色设定激活了模型训练数据中对应领域的知识分布（P001 → P006 的应用）。
怎么做：在系统提示开头用 “You are [角色]” 设定；复杂角色加入世界观、动机、价值体系（P032）。
证据：A010, A011, A012, A013, C003
相关原则：→ P032（人格画像设计）→ P034（显式列举能力和局限）
2D. 示例与 Few-shot
P036 — 示例要相关、多样、结构化
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：始终适用
原则：示例要展示多样化的输入范围，覆盖边缘案例，用 <example> 标签包裹。对于容易误用的行为，应同时提供正面示例和反面示例（正反对比），每个示例附 <reasoning> 标签解释为什么。示例数量应与误用风险成正比——高误用风险的工具/行为需要更多正反对比示例。
怎么做：确保示例覆盖：典型情况、边缘情况、预期拒绝情况。高风险行为增加正反对比示例（good-example / bad-example + When to Use / When NOT to Use）。
证据：A073, A074, A047, A106, A116, B010, C017；AP-006（Claude Code TodoWrite 4正4反共8示例 vs Glob 0示例——误用风险决定示例数量）
相关原则：依赖 P035；Agent 场景详见 P077（描述详细度与误用风险成正比）
P039 — 在示例中展示思维链
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：需要推理的任务
原则：在 few-shot 示例中展示推理过程/内心独白，让模型学会如何思考。
怎么做：示例中加入 <thinking> 或 <rationale> 部分，展示从输入到输出的推理链。
证据：C018, A093, A047
相关原则：互补 P035 + P041
2E. 推理技术
P042 — 明确拼出思考步骤
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：需要精确控制推理过程时；基础模型优先使用；Agent 场景中思考可通过任务管理工具外化
原则：明确拼出思考步骤比笼统说 “think step by step” 更有效；用 XML 标签（<thinking> <scratchpad>）隔离思考区域。在 Agent 场景中，思考步骤可通过 TodoWrite / TaskCreate 等任务管理工具外化为可见的任务列表，替代传统的文本推理——用户看到的不是推理文本，而是结构化的进度条。
为什么有效：具体步骤消除了模型自行决定推理路径的不确定性。Agent 场景中，外化为任务列表同时解决了规划（防止遗漏步骤）和可见性（用户看到进展）两个问题。
怎么做：文本生成场景→Step 1: Identify... Step 2: Analyze... 配合 <thinking> 标签隔离。Agent 场景→通过任务管理工具创建任务列表=分解问题=“思考”；标记完成=跟踪进度=“展示工作”。
证据：A030, A031, A114, C057；AP-022（Claude Code 用 TodoWrite 替代 CoT）
相关原则：互补 P041；条件分支见 P029（推理模型可能不需要具体步骤）；Agent 场景外化见 P083（用户可见性三段式）
P044 — Zero-shot CoT
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：大参数模型
原则：仅需 “Let’s think step-by-step” 即可触发推理能力。
怎么做：在查询末尾加 “Let’s think step by step.” 或 “Think through this carefully.”
证据：C056, C072, C070
相关原则：依赖 P041；简化版的 P042
2F. 减少幻觉
P049 — 先提取引用再回答
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：长文档/多文档场景
原则：让模型先提取相关引用，再基于引用生成答案——显著减少长文档场景下的幻觉。
为什么有效：强制模型”有据可依”，阻断”凭记忆编造”的路径。
怎么做：Step 1: Extract all relevant quotes from the document. Step 2: Based only on these quotes, answer the question.
证据：A038, A039, A081, B024, C053
相关原则：互补 P027（退出机制）→ 系统性减少幻觉
P050 — 断言锚定到具体章节
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：事实密集型任务
原则：引用关键细节（日期、阈值、条款编号），而非泛泛而谈。
怎么做：要求模型在每个断言后标注来源章节或段落编号。
证据：B023, B024
相关原则：互补 P049
2G. 工具与 Agent
P054 — 工具描述本身就是 PE
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：所有工具使用场景
原则：简洁 1-2 句说明工具做什么和何时使用，描述必须精确。在多工具 Agent 中，还需定义工具间偏好层级和多工具协作 SOP。
为什么有效：模型根据工具描述决定是否调用——描述不准确直接导致工具误用或漏用。多工具场景中，缺少偏好层级导致随机选择工具，缺少 SOP 导致工具协作混乱。
怎么做：每个工具的 description 包含：功能（做什么）、触发条件（何时用）、不适用场景（何时不用）。多工具 Agent 还需：1) 定义工具间偏好层级（P076）；2) 为关键工作流编写多工具协作 SOP（P078）。
证据：A139, B036, A065；AP-005, AP-006, AP-007（Claude Code 的工具偏好和 SOP 设计）
相关原则：互补 P058（抽象层级）；Agent 场景扩展见 P076（工具偏好层级）、P077（描述详细度与误用风险成正比）、P078（多工具协作 SOP）
P055 — 鼓励并行工具调用
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：多工具场景
原则：鼓励并行工具调用以降低延迟。
怎么做：在系统提示中加入 “When multiple independent tool calls are needed, make them in parallel.”
证据：A091, B037
P056 — 需要新鲜数据时优先用工具
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：agent 场景
原则：需要新鲜或用户特定数据时优先使用工具而非内部知识。
证据：B039, C040, C041
2H. 模板化与复用
P012 — 结构化模板比散乱技巧更高效
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：生产环境/重复任务
原则：像代码模块一样设计 prompt，一次创建、无限适配。
证据：A020, C001, C002, C021
相关原则：互补 P013
P013 — Prompt 模板化
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：生产环境
原则：固定骨架 + 可替换变量（{{variable}} 或 <Variable>），实现重复任务的标准化。
证据：A020, B014, C010
相关原则：互补 P012
2I. 评估与迭代
P071 — 模型迁移时单变量迭代
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：模型升级/迁移
原则：先不改 prompt 只换模型——一次只变一个因素，每次小改动后重跑 eval。
证据：B046, B048, A089
相关原则：互补 P070
Tier 3: 场景策略（Scenario Strategies）
按场景分支的具体指导，标注适用条件。
3A. 上下文管理策略
P004 — 上下文工程 > Prompt 工程
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：agent/长对话场景尤其重要
原则：管理整个上下文状态（token 预算、信息新鲜度、上下文腐烂），而非只写好指令。
为什么有效：prompt 只是上下文的一部分，对话历史、工具返回、外部数据同样影响输出质量。
怎么做：监控 token 使用率；定期清理过时信息；用摘要替代完整历史。
证据：A140, A141, A142, A147
相关原则：上位概念，包含 P061
P062 — 上下文截断策略
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：长对话
原则：滑动窗口、优先保留 bot 回复、LLM 摘要替代历史消息。
怎么做：设定 token 上限；超限时用 LLM 生成前序对话摘要替代原文。
证据：C035, A146
相关原则：依赖 P061
P063 — 动态上下文修改
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：需要外部知识的场景
原则：根据用户意图实时更换隐藏提示中的数据（RAG/语义搜索），这是好体验的关键。
证据：C042, C043, C044, B012, A145
相关原则：互补 P065（JIT 上下文）
P064 — Reminder 机制
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：长多轮对话
原则：强制模型在每次回复前回顾关键设定，对抗长对话中的上下文丢失。
证据：C013, B031
P065 — Just-in-time 上下文
置信度：★★★★☆ (85%+)
适用范围：场景特定
适用条件：agent/工具使用场景
原则：保持轻量级标识符，动态加载相关信息，避免一次性塞入所有上下文。
证据：A145, C042
相关原则：互补 P063
3B. 模糊性处理
P024 — 模糊指令的处理策略
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：按交互模式选择（见 M001 裁决）
原则：遇到模糊指令时选择最简单的合理解释，或主动问澄清问题。
为什么有效：避免模型在歧义上浪费 token 或选择错误的解释。
怎么做：
- 交互式场景（聊天）→ 问 1-3 个精确澄清问题
- 单次调用场景（API/批处理）→ 覆盖所有合理解释
证据：B020, B025, C012
相关原则：与 P020 是顺序关系——先消歧，再直接要求
3C. 长度与格式控制
P025 — 提供明确的长度/格式约束
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：需要一致性输出时
原则：默认多长、简单问题多长、复杂问题用什么结构——都要明确指定。
怎么做：Default: 2-3 sentences. For complex topics: use bullet points, max 200 words.
证据：B015, B016, B017, A118, A126
P018 — Prompt 格式选择
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：根据数据结构选择
原则：Markdown（默认推荐）、JSON、YAML。Markdown 表格适合同类数据，JSON 适合嵌套数据。
怎么做：
- 同类多条数据 → Markdown 表格
- 嵌套复杂数据 → JSON
- Token 紧张的嵌套数据 → 关系型 Markdown 表格
证据：C014, C047, C048, C049
3D. 安全约束
P066 — 假设用户可看到所有 prompt 内容
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：所有生产环境
原则：永远不要在 prompt 中放不能让用户看到的信息。
证据：C030, C038
P067 — 约束针对正常用户设计
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：面向公众的应用
原则：假设恶意用户可绕过所有约束；防越狱最佳实践是将最重要约束放在末尾。
证据：C036, C037
P068 — 破坏性操作执行前确认
置信度：★★★★★ (95%+)
适用范围：通用
适用条件：有副作用的操作
原则：用户批准一次不代表所有上下文都批准。
证据：A136, A137
3E. 自检与验证
P028 — 高风险场景做自检
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：法律/财务/合规/医疗场景
原则：重新扫描未声明假设、不实数字、过强措辞。
怎么做：加入 After generating your response, review it for: unverified claims, unsupported numbers, and overly strong assertions.
证据：B028, A094, B026, B027
P048 — 先验证再生成（Split-Step Verification）
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：减少幻觉
原则：先验证信息/能力是否存在，再生成答案。
怎么做：Step 1: Check if the requested information exists in the context. Step 2: If yes, generate the answer. If no, state that the information is not available.
证据：B064, A038
P047 — 先列正反论点再判断
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：需要平衡分析的场景
原则：让模型先列出正反论点再作判断，可改善复杂判断质量。
证据：A028, A112
3F. Agent 场景策略
P057 — 写操作后简短重述
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：有副作用的操作
原则：写操作后简短重述改了什么；高影响操作需要验证步骤。
证据：B040, B038
P059 — Agent 更新应简短（含用户可见性设计）
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：agent 场景
原则：只在新阶段或计划变更时发送状态更新（1-2 句），避免叙述常规工具调用过程。更完整的设计是 ack→work→result 三段式：收到任务先一行确认（消除等待焦虑）→执行时仅在有信息价值的检查点更新→最终简洁呈现结果。跳过纯过程描述（“正在运行测试…”）。
证据：B032, B033, B034, A128；AP-021（Claude Code v2.1.81 的用户可见性设计）
相关原则：Agent 场景详见 P083（用户可见性三段式）
P060 — 子代理架构
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：复杂/长对话 agent
原则：专门化代理处理聚焦任务，用干净的上下文窗口，返回压缩摘要。
证据：A138, A146
P016 — 多文档结构化包裹
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：多文档/多源处理
原则：<document index="n"> + 唯一 ID，便于引用和追踪。
证据：A080, C053, B045
P015 — 高频内容放开头利用缓存
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：API 生产环境
原则：高频复用内容放在 prompt 开头以利用缓存降低成本和延迟。
证据：B009, A078
P052 — 声明上下文是唯一事实来源
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：与模型训练知识冲突的场景
原则：假设场景中明确声明”提供的上下文是唯一事实来源”。
证据：B067, A123
3G. Agent 架构设计
在 Agent 场景中，60% 的 prompt 工程是工具描述设计，20% 是行为约束，20% 是示例演示。传统”一问一答”的 PE 原则只覆盖了中间那 20%。
来源：Claude Code 完整系统提示词（v2.0.0 + v2.1.81）深度分析，30 个 Agent PE 模式
详细展开 → 3-Agent提示词工程.md
P073 — Agent 主动性光谱校准
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：所有有工具调用能力的 Agent
原则：Agent 被允许主动行动，但仅限于用户已经要求做某事的上下文中。“问”和”做”是两种不同的响应模式，不能混为一谈。
为什么有效：解决 Agent 场景的核心张力——过度主动让用户失控（“我的文件怎么被改了？”），过度被动让 Agent 无用。区分询问意图和执行意图是关键。
怎么做：构建决策树——用户在提问？先回答不行动。用户要求做事？执行并合理跟进。不确定？默认为提问。
证据：AP-001（Claude Code v2.0.0 + v2.1.81 双版本一致）
相关原则：→ P074（授权范围）
P074 — 一次授权不等于全局授权
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：有副作用操作的 Agent
原则：用户对某操作的一次性批准不构成全局授权。授权范围精确匹配被请求的范围。区分一次性口头授权和持久化配置授权。
为什么有效：防止长会话中的”隐式授权蔓延”——用户同意一次 git push，Agent 后续自动 push。
怎么做：一次性授权仅适用于当次请求；持久化配置（如 CLAUDE.md）可跨会话生效；高风险操作在不同上下文中仍需确认。
证据：AP-002（Claude Code v2.0.0），与 P068 互补
相关原则：扩展 P068（破坏性操作确认）；→ P075（风险矩阵）
P075 — 可逆性 × 影响范围决策矩阵
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：所有有工具调用能力的 Agent
原则：操作风险由可逆性和影响范围两个正交维度决定。本地+可逆→自由执行；任一维度为高→确认后执行；两个维度都高→谨慎确认并说明风险。
为什么有效：将”安全/危险”的模糊二分法转化为可操作的二维矩阵，同时给出默认许可（编辑文件、运行测试）避免 Agent 过度保守。
怎么做：为每类操作评估可逆性和影响范围，建立四象限决策表。附带 4 类高风险操作的具体列表（破坏性、难逆转、影响他人、信息泄露）。
证据：AP-003（Claude Code v2.0.0）
相关原则：扩展 P068；互补 P074
P076 — 工具偏好层级
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：多工具 Agent
原则：当多个工具都能完成同一任务时，定义明确的偏好层级：专用工具优先于通用工具。在每个相关工具的描述中都重复这一偏好。
为什么有效：没有明确偏好时模型随机选择工具，导致体验不一致和潜在问题。
怎么做：列出功能重叠的工具对→定义优先级→在每个工具描述中散布重复这一偏好→给出偏好理由。
证据：AP-005（Claude Code v2.0.0 + v2.1.81，后者拆为独立注入片段进一步强化）
相关原则：扩展 P054；互补 P077
P077 — 工具描述详细度与误用风险成正比
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：自定义工具设计
原则：工具描述的标准结构为：功能概述→使用场景→不适用场景→用法→示例。详细程度（尤其是正反对比示例数量）应与该工具的误用风险成正比。
为什么有效：高误用风险的工具需要更多正反示例来划清边界；低误用风险的工具只需简短描述，避免占用上下文。
怎么做：评估每个工具的误用风险→低风险：1-2 句说明→中风险：功能+场景+排除→高风险：完整结构+多个正反对比示例+推理标签。
证据：AP-006（Claude Code TodoWrite 8 示例 vs Glob 5 行描述）
相关原则：扩展 P054；互补 P036（正反对比示例）
P078 — 多工具协作 SOP
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：涉及多工具协作的关键工作流
原则：为关键的多工具工作流提供完整 SOP：编号步骤→标注并行机会→标注依赖关系→内联错误恢复策略。
为什么有效：单个工具描述再好也不能解决工具间协作问题。步骤编号确保顺序，并行标注优化效率，错误恢复内联在 SOP 中确保不遗漏。
怎么做：识别关键多工具工作流（高频+高风险）→拆为编号步骤→标注并行/串行→内联错误恢复。
证据：AP-007（Claude Code git commit SOP 和 PR 创建 SOP）
相关原则：新增维度，补充 P054
P079 — 否定约束的精确使用
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：安全约束、边界定义、破坏性操作限制
原则：安全/边界场景下，否定指令（NEVER/Do not）比正面指令更直接有效。但否定指令必须具体到操作级别，每个 NEVER 映射到一个具体的失败场景，并附带例外条件。
为什么有效：“不要 force push” 比 “使用安全的 git 操作” 更难被误解。否定约束的覆盖面有限但边界清晰，适合高风险操作。
怎么做：高风险操作→NEVER+具体操作+例外条件；行为偏好→仍用正面指令；安全边界→NEVER不带例外。
证据：AP-008（Claude Code 15+ NEVER，每条映射真实失败场景）
相关原则：修正 P021（增加适用条件）
P080 — 关键指令散布重复
置信度：★★★★★ (95%+)
适用范围：Agent 场景（长 prompt 尤其适用）
适用条件：prompt 超过 500 行
原则：关键约束应在 prompt 中多个相关位置重复出现——系统提示开头、相关工具描述中、相关 SOP 步骤中、系统提示末尾。确保无论模型注意到哪段文本，关键约束都在近距离可见。
为什么有效：LLM 在超长上下文中注意力不均匀。散布重复比”首尾重申”更有效，它确保模型执行到任何相关段落时都能”看到”关键约束。
怎么做：识别关键约束→在系统提示开头完整声明→每个相关工具描述中重复→相关 SOP 步骤中引用→末尾简短重申。重复方式可以是逐字重复、换角度重述或局部引用。
证据：AP-009（Claude Code 安全约束 L36 和 L187 逐字重复；文件操作偏好在 4+ 位置出现）
相关原则：扩展 P014
P081 — 输出通道分离
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：有工具调用能力的 Agent
原则：文本输出和工具调用是两个独立通道。文本用于与用户交流，工具用于执行操作。禁止在工具调用中向用户传递信息，禁止在文本输出中描述操作而不调用工具。
为什么有效：混用通道导致用户在 CLI 中看到混乱的工具输出，或 Agent 描述了操作但实际未执行。
怎么做：明确定义每个通道的职责；如果有专门的用户消息工具，所有用户可见回复都必须通过该工具。
证据：AP-011（Claude Code v2.0.0 + v2.1.81 SendUserMessage 进一步强化）
相关原则：互补 P082
P082 — 输出极简主义
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：CLI/工具型 Agent
原则：默认极简回复。做完了说”完成”不解释；用户问问题直接给答案不加铺垫；只在用户要求解释、出错需说明、有决策需输入时展开。提供极简锚点示例（“2+2”→“4”）。
为什么有效：CLI 环境中冗长文本是噪音；减少 token 消耗；极端示例设定”最简”锚点，模型在此和”适当详细”之间找平衡。
怎么做：在 prompt 中加入极简示例设定锚点 + 明确列出应该输出什么（决策、状态更新、错误）。
证据：AP-012（Claude Code 双版本一致，v2.1.81 增加了”Focus text output on…”正面清单）
相关原则：扩展 P026；互补 P081
P083 — 用户可见性三段式
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：需要后台执行的 Agent
原则：用户可见性采用 ack→work→result 三段式：1) 确认收到（一行，消除等待焦虑）→ 2) 关键检查点（仅在有信息价值时更新）→ 3) 最终结果（简洁呈现）。跳过纯过程描述。
为什么有效：解决了”盯着转圈焦虑”和”事事汇报噪音”之间的平衡。检查点必须”carrying information”才值得发送。
怎么做：短任务直接给结果；需要时间的任务先 ack 一行→工作→给结果；长任务在 ack 和结果之间加有信息价值的检查点。
证据：AP-021（Claude Code v2.1.81 的 SendUserMessage 进展更新设计）
相关原则：扩展 P059；互补 P082
P084 — 子代理上下文隔离
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：使用子代理的 Agent
原则：子代理有两种模式：继承上下文（fork）和独立启动（fresh）。Fork 模式直接下达指令不重复背景，但禁止偷看中间结果和预测结果。Fresh 模式像给刚进入会议室的同事做简报，包含尝试过什么、排除了什么。
为什么有效：继承上下文避免重复传递信息但需防止上下文窗口污染；独立启动保持干净视角但需要充分的简报。
怎么做：需要主 Agent 已有知识→fork（不重复背景、不偷看、不预测）；需要独立视角→fresh（完整简报、描述已知和未知）。
证据：AP-013（Claude Code v2.1.81 fork 和 subagent_type 两种完整模式）
相关原则：扩展 P060；互补 P085
P085 — 不委托理解
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：使用子代理的 Agent
原则：理解和综合是主 Agent 的职责，不能委托给子代理。给子代理的 Prompt 必须包含具体的文件路径、行号、明确的修改内容——证明主 Agent 已经理解了问题。
为什么有效：防止”子代理链条”——A 委托 B，B 委托 C，信息在传递中不断丢失。要求主 Agent 写出细节迫使它先理解再委托。
怎么做：禁止 “based on your findings, …”、“implement what you think is best” 等委托理解的用语。Prompt 中必须有具体的文件、行号、修改内容。
证据：AP-014（Claude Code v2.1.81 明确禁止此模式）
相关原则：互补 P084
P086 — 上下文压缩与持久化
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：长会话 Agent
原则：通过结构化总结协议将长会话压缩为可恢复摘要。摘要必须覆盖 5 个维度：任务概述+成功标准、当前状态+已修改文件、关键发现（含失败经验）、下一步+优先级、需保留的上下文（用户偏好和承诺）。
为什么有效：设计假设是”未来的我可能不记得任何东西”。保留失败经验避免重复踩坑，保留承诺避免因压缩而食言。
怎么做：压缩前用 <analysis> 标签做全面回顾→压缩后按 5 维度输出摘要。目标：让”失忆”的新实例能无缝接续。
证据：AP-017（Claude Code v2.1.81 的 compaction 总结模板）
相关原则：互补 P062（上下文截断）
P087 — 模式切换机制
置信度：★★★★★ (95%+)
适用范围：Agent 场景
适用条件：需要在规划/执行等不同模式间切换的 Agent
原则：通过显式模式定义，在不同模式下注入完全不同的行为约束。每种模式定义三件事：权限边界（什么可做/不可做）、默认行为（模糊时如何选择）、退出条件（如何切换）。模式的权限约束高于其他所有指令。
为什么有效：Plan 模式和 Auto 模式的行为完全相反——Plan 默认不执行，Auto 默认不询问。没有显式模式切换，Agent 会在两种行为间随机摇摆。
怎么做：定义模式枚举→每种模式写明权限/默认行为/退出条件→用显式工具切换模式→模式约束声明为最高优先级（“this supercedes…”）。
证据：AP-015（Claude Code Plan 模式 + Auto 模式 + 5 阶段 Plan 工作流）
相关原则：新增维度
Tier 4: 模型专属（Model-Specific）
特定模型或平台的专属技巧。
P029 — 通用指令优于规定性步骤（推理模型）
置信度：★★★★☆ (85%+)
适用范围：推理模型（o1/o3/Gemini thinking/Claude extended thinking）
适用条件：新一代推理模型；基础模型应使用 P042
原则：“think thoroughly” 往往比手写步骤更好——推理模型的推理能力可能超过人类预设的步骤。
为什么有效：推理模型内部已有强大的思维链机制，过细的步骤限制反而会约束其能力发挥。
怎么做：给高层目标和约束，让模型自行规划推理路径。可配合 P042 的 <thinking> 标签隔离思考区域，但不规定具体步骤。
证据：A092, A095
相关原则：与 P042 是条件分支关系（一致性检验已确认）
P033 — Persona 可能优先于其他指令（Gemini）
置信度：★★★☆☆ (65%+)
适用范围：Gemini 专属
适用条件：需跨模型验证
原则：Persona 会被 Gemini 严肃对待，可能优先于其他指令——需仔细审查避免歧义。
证据：B066
相关原则：参考 P031
P053 — 降低温度减少幻觉
置信度：★★★★☆ (85%+)
适用范围：通用（Gemini 3 例外）
适用条件：需要确定性输出时；Gemini 3 必须保持默认 1.0
原则：temperature 0 最接近确定性输出。但 Gemini 3 的采样架构不同，降低温度会导致循环或退化。
为什么有效：低温度减少随机采样，使输出更确定性。
怎么做：Claude/GPT：降低 temperature 到 0-0.3 获取更确定性输出。Gemini 3：保持默认 1.0，查阅官方文档确认。
证据：A040, B055
相关原则：见矛盾 M002 裁决
P072 — 生产环境锁定模型快照版本
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：生产环境
原则：锁定模型快照版本以保证行为一致性。
怎么做：使用带日期戳的模型 ID（如 gpt-4-0613），而非 gpt-4。
证据：B002
Tier 5: 进阶/实验性（Advanced/Experimental）
新兴趋势或置信度较低的信号，有参考价值但需谨慎使用。
P003 — 不是所有问题都适合 PE 解决
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：评估阶段决策
原则：延迟和成本有时换模型更有效；简单任务不需要复杂 prompt。
证据：A068, A103
P005 — PE 是技能组合
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：始终适用
原则：需要混合搭配多种策略，包括安全、工具集成、领域知识注入等全栈能力。
证据：C065, C066
P032 — 像写人格画像而非流程手册
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：复杂角色/长对话场景
原则：赋予世界观、动机、价值体系比列步骤更有效。
证据：C020, A010
P034 — 显式列举能力和局限
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：复杂角色设定
原则：显式列举 Skills 和 Limitations，而非隐含期望模型推断。
证据：C006, C015, C016
P037 — 3-5 个示例最佳
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：取决于 token 预算
原则：建议 3-5 个示例获取最佳效果；更多通常更好。
证据：A074, A048
P038 — Few-shot 的格式比内容重要
置信度：★★★★☆ (85%+)
适用范围：通用（学术发现）
适用条件：理解 few-shot 工作机制时
原则：即使用随机标签，有格式也比没格式好得多；标签空间和输入分布比标签正确性更重要。
为什么有效：few-shot 的核心作用是校准输出格式和任务理解，而非提供知识。
证据：C068, C069
P040 — 用困难用例作为示例
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：有已知边缘案例时
原则：用困难用例训练模型处理边缘情况。
证据：C017, A047
P043 — 思考必须”大声”输出
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：无 extended thinking 的模型
原则：不能要求只输出答案不输出思考过程——思考只有输出时才影响后续 token 概率。
证据：A027, C058
P045 — Self-Consistency（多路径投票）
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：可多次采样的场景
原则：采样多条推理路径，选最一致的答案——适用于算术和常识推理。
怎么做：同一问题采样 5-10 次（temperature > 0），取多数票答案。
证据：C074, C075
P046 — Tree of Thoughts (ToT)
置信度：★★★☆☆ (65%+)
适用范围：通用（学术）
适用条件：复杂探索任务
原则：维护思维树 + 搜索算法（BFS/DFS）进行系统性探索，适用于需要前瞻的复杂任务。
证据：C076, C077, C078, C079
P058 — 工具命令的抽象层级
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：自定义工具设计
原则：太具体不灵活，太底层模型会幻觉；用大量描述和示例对抗幻觉。
证据：C045, C046
P069 — Fine-tuning 安全红线
置信度：★★★★☆ (85%+)
适用范围：通用
适用条件：fine-tuning 场景
原则：永远不要用真实客户数据做微调——模型会记住并泄露。
证据：C061
附录 A：关系网络图
前置依赖
P001 → P006（概率本质 → 模式敏感）
P001 → P041（概率本质 → CoT 有效性）
P007 → P008（系统提示作用 → 推荐结构）
P019 → P020（无上下文假设 → 直接要求）
P035 → P036, P037, P038, P039, P040（few-shot 有效 → 各项最佳实践）
P041 → P044, P045, P046（CoT → 特化推理技术）
P070 → P002（评估标准 → 迭代循环）
互补组合
P010 + P011 = 完整的 prompt 组织（XML 边界 + Markdown 层级）
P020 + P022 = 更好的指令效果（直接要求 + 解释为什么）
P021 + P023 = 精准控制行为（正面指令 + 约束范围）
P027 + P049 = 系统性减少幻觉（退出机制 + 先引用再回答）
P035 + P039 = 教会推理（示例 + 展示思维链）
P041 + P042 = 可控推理（要求思考 + 隔离思考区域）
P054 + P058 = 可靠工具使用（精确描述 + 适中抽象层级）
P012 + P013 = 可规模化 prompt（结构化模板 + 变量化）
P063 + P065 = 高效上下文管理（动态上下文 + JIT 加载）
P070 + P071 = 科学 prompt 优化（评估体系 + 单变量迭代）
P006 + P031 = 风格引导（模式传染 + 角色设定）
# Agent PE 互补组合（Tier 3G）
P073 + P074 = 主动性管理（行动校准 + 授权范围）
P075 + P074 = 安全决策（风险矩阵 + 授权限制）
P076 + P078 = 工具生态（偏好层级 + 协作 SOP）
P077 + P036 = 示例策略（误用风险成正比 + 正反对比）
P081 + P082 = 输出管理（通道分离 + 极简主义）
P084 + P085 = 子代理管理（上下文隔离 + 不委托理解）
P080 + P079 = 约束执行（散布重复 + 精确否定）
上下位关系
P004 ⊃ P061（上下文工程 ⊃ 上下文有限）
P041 ⊃ P044, P045, P046（CoT ⊃ Zero-shot CoT, Self-Consistency, ToT）
P008 ⊃ P007, P009, P017（推荐结构 ⊃ 系统提示, 数据位置, 输出格式）
P035 ⊃ P036, P037, P038, P039, P040（Few-shot ⊃ 各项最佳实践）
条件分支
| 场景 | 条件 | 适用原则 |
|---|
| 模型类型 | 推理模型（o1/o3/Claude extended thinking） | P029（通用指令优于步骤） |
| 基础模型（GPT-4.1/Claude Sonnet） | P042（明确拼出步骤） |
| 任务复杂度 | 简单提取/分类 | P020（直接要求） |
| 复杂推理/多步逻辑 | P041 + P042（CoT + 结构化思考） |
| 极复杂探索 | P046（ToT） |
| 交互模式 | 聊天/对话 | P024-A（问澄清问题） |
| API/批处理 | P024-B（覆盖所有意图） |
| 输出用途 | 程序消费 | P017（严格格式）+ P025 |
| 人类阅读 | P025（长度约束）+ P026（直奔主题） |
| 上下文长度 | 短对话（<4k tokens） | 标准 prompt |
| 长对话（>10k tokens） | P062 + P064（截断 + Reminder） |
| Agent 超长会话 | P060 + P065（子代理 + JIT） |
| 温度设置 | Claude / GPT | 低温度减少幻觉（P053） |
| Gemini 3 | 保持默认 1.0（M002 裁决） |
附录 B：矛盾裁决记录
M001：模糊指令——澄清还是覆盖？
矛盾：Claude/Anthropic 建议主动问澄清问题（B025, A037）；GPT-5.2 指南建议覆盖所有可能意图（B050）。
裁决：条件消歧。交互式场景 → 澄清；单次调用场景 → 覆盖。GPT-5.2 指南明确标注这是”深度研究”场景下的建议。
一致性审核：裁决合理，与 P020（直接要求）一致——P020 处理”已知想要什么”，P024 处理”指令不清晰”，是顺序关系。
M002：温度——降低 vs 保持 1.0
矛盾：Anthropic/OpenAI 建议降低温度减少幻觉（A040）；Gemini 3 必须保持默认 1.0，降低会退化（B055）。
裁决：模型专属差异。通用原则”低温度 = 更确定性”成立（P053），Gemini 3 是明确例外。
一致性审核：裁决合理且自洽。P053 适用条件中已标注例外。
M003：关键指令位置——开头还是末尾？
矛盾：Anthropic 习惯在开头用 XML 标签强调（A043, A078）；Gemini/Brex 建议关键约束放末尾（B065, C037）。
裁决：两种策略组合——约束在开头完整声明，在末尾简短重申。P009 + P014 组合覆盖。
一致性审核：裁决充分。三方对”查询放末尾”有共识；分歧仅在约束位置，组合策略是最优解。
M004：消息角色层级——显式 vs 隐式
矛盾：OpenAI 区分 developer > user > assistant 优先级（B004）；Claude/Gemini 无显式层级。
裁决：平台差异，概念相通。P007 只保留”系统提示优先于用户输入”的通用原则。
一致性审核：裁决合理，避免了平台 API 细节侵入通用原则。
M005：数据与问题顺序——数据在前还是在后？
矛盾：表面矛盾——Anthropic 和 Gemini 实际上都建议”数据在前、问题在后”（A078-A079, B068）。
裁决：三方共识，非真矛盾。源于 Phase 1 编码时的误判。P009 已正确反映。
一致性审核：裁决正确。经复查，三方在此点上完全一致。
M006：激进语言——需要还是不需要？
矛盾：旧实践用 “CRITICAL: You MUST…” 强调；新模型（A089, A090）认为激进语言导致过度触发。
裁决：时效性差异。P030（不同模型不同策略）覆盖。对新模型使用正常语气，不遵从时才逐步加强。
一致性审核：裁决合理，与 P030 一致。C022（惩罚机制/strike rule）也归类为”旧模型技巧，新模型慎用”。
附录 C：置信度方法论
评分标准
| 置信度 | 含义 | 来源要求 |
|---|
| ★★★★★ (95%+) | 多方共识，经过充分验证 | 3+ 独立来源一致；或 2 个来源 + 官方文档 |
| ★★★★☆ (85%+) | 经过验证，有较强证据 | 2+ 独立来源一致 |
| ★★★☆☆ (65%+) | 有证据但需进一步验证 | 仅 1 个来源，或来源间有分歧 |
| ★★☆☆☆ (40%+) | 信号级，仅供参考 | 单一来源 + 未经验证 |
来源体系
- A 系列（147 条）：Anthropic 官方文档 + 教程
- B 系列（68 条）：OpenAI/Google 官方文档
- C 系列（88 条）：Brex 指南 + 学术论文 + 社区整理
独立来源判定
- Anthropic、OpenAI、Google 各算一个独立来源
- 学术论文算独立来源
- 社区整理（如 Brex 指南）如有独立见解算独立来源，如仅转述官方则不算
降级规则
- 仅单一来源 → 最高 ★★★★☆
- 仅中文二手来源 → 降一级
- 学术但未在生产验证 → 最高 ★★★☆☆
- 模型版本特定 → 标注适用版本而非降级