我读完 GPT-5.4 官方指南：别急着加钱调参数，先把这 6 个模块写对
OpenAI 刚放出了 GPT-5.4 的官方 Prompt Engineering 指南。说实话，我原以为又是那种"清晰指令+角色扮演+few-shot"的老三篇。
结果不是。
这份指南的核心论点让我愣了一下：别急着调 reasoning effort，先把你的 prompt 结构写对。 在大多数场景下，none 或 low 就够了——前提是你的 prompt 里有完整的"输出契约"和"验证循环"。
这篇文章把这份 4000+ 词的英文指南拆成 6 个可直接复用的 prompt 模块。每个模块给出中文版模板，复制过去就能用。
01 GPT-5.4 变了什么
GPT-5.4 相比前代的核心变化不在"更聪明"，而在更可控：
- 人格和语气在长回复中漂移更少
- Agentic 工作流更鲁棒——更倾向于坚持多步任务、自动重试、端到端完成
- 批量/并行 tool calling 准确率提升
- 长上下文分析能力增强
但它也暴露了几个必须靠 prompt 补救的短板：
| 短板 | 具体表现 | 解法 |
|---|---|---|
| 低上下文 tool routing | 会话初期工具选择不靠谱 | 加前置条件检查 |
| 依赖感知弱 | 跳过前置步骤直奔终态 | 加 dependency_checks |
| reasoning effort 误区 | 开发者默认拉满，但更高 ≠ 更好 | 按任务类型选档位 |
| 不可逆操作 | 高影响操作缺少确认 | 加 verification_loop |
关键洞察：这些短板的解法不是换模型或加预算，是写更好的 prompt 结构。
但光知道"要写好 prompt"没用，得知道具体写什么。接下来拆解的 6 个模块就是答案。
02 六个核心 Prompt 模块
整份指南的精华浓缩为 6 个 XML 模块。它们像乐高积木——你的 system prompt 按需组装就行。
模块 1：输出契约（Output Contract）
控制模型"说什么、怎么说、说多少"。
<output_contract>
- 只返回要求的章节，按要求的顺序。
- 如果 prompt 定义了前言、分析块或工作区，不要把它当额外输出。
- 长度限制只应用于指定的章节。
- 如果要求特定格式（JSON/Markdown/SQL/XML），只输出那种格式。
</output_contract>
<verbosity_controls>
- 简洁、信息密集。
- 不要重复用户的请求。
- 进度更新保持简短。
- 不要为了短而省掉必要的证据、推理或完成检查。
</verbosity_controls>
什么时候用：几乎所有 production prompt 都该加。它解决的是"模型废话太多"和"格式乱飘"这两个最高频的问题。
模块 2：跟进策略（Follow-Through Policy）
告诉模型什么时候该自己干、什么时候该问你。
<default_follow_through_policy>
- 如果用户意图清晰且下一步可逆、低风险，直接执行不要问。
- 只在以下情况问：
(a) 不可逆操作，
(b) 有外部副作用（发送、购买、删除、写入生产环境），
(c) 需要缺失的敏感信息或会显著改变结果的选择。
- 如果直接执行了，简要说明做了什么。
</default_follow_through_policy>
什么时候用：Agent 场景必备。你有没有遇到过 Agent 每走一步都来问你"可以继续吗？"让你想砸键盘？这个模块就是解药。
模块 3：工具持久化（Tool Persistence）
防止模型"觉得差不多了就停手"——Agent 场景最常见的翻车模式。
<tool_persistence_rules>
- 只要工具调用能实质性提升正确性或完整性，就调用。
- 当再调一次工具很可能提升质量时，不要提前停止。
- 持续调用工具直到：(1) 任务完成，且 (2) 验证通过。
- 如果工具返回空或部分结果，换策略重试。
</tool_persistence_rules>
<dependency_checks>
- 执行操作前，检查是否需要前置的发现、查找或记忆检索步骤。
- 不要因为最终操作看起来很明显就跳过前置步骤。
- 如果任务依赖前一步的输出，先解决那个依赖。
</dependency_checks>
多少次你让 AI 搜个东西，它搜不到就直接告诉你"没有相关结果"？这就是缺了 tool persistence。
还有一个配套模块值得加：
<parallel_tool_calling>
- 多个检索步骤相互独立时，优先并行调用以减少等待时间。
- 有前置依赖的步骤不要并行。
- 并行检索后暂停，合成结果再决定下一步。
</parallel_tool_calling>
RAG、多工具 Agent、批量处理——这三个块组合使用效果最好。
模块 4：完整性保障（Completeness Contract）
防止模型"做到一半就交差"。
<completeness_contract>
- 所有请求项都覆盖或标记 [blocked] 之前，任务就是未完成。
- 维护内部交付物检查清单。
- 对列表或分页结果：确定预期范围，跟踪已处理项，确认覆盖率。
- 因缺失数据阻塞的项标记 [blocked]，说明具体缺什么。
</completeness_contract>
<empty_result_recovery>
如果查找返回空或可疑地窄的结果：
- 不要立即断定"没有结果"。
- 至少尝试 1-2 个回退策略：换关键词、放宽过滤、前置查找、换工具。
- 然后才报告未找到，并说明尝试了什么。
</empty_result_recovery>
empty_result_recovery 这个块特别实用。它本质上是在教模型一个人类常识：搜不到 ≠ 不存在，可能是你搜的方式不对。
但如果你以为写对这些模块就万事大吉，那就太乐观了。
模块 5：验证循环（Verification Loop）
最终交付或执行不可逆操作之前，强制自检。
<verification_loop>
最终交付前：
- 正确性：输出是否满足每一个要求？
- 可验证性：事实声明是否有上下文或工具输出支撑？
- 格式：是否符合要求的 schema 或风格？
- 安全：下一步有外部副作用的话，先请求确认。
</verification_loop>
<missing_context_gating>
- 缺少必要上下文时不要猜。
- 优先用工具查找；查不到时才问用户，且问题要最小化。
- 如果必须继续，明确标注假设并选择可逆操作。
</missing_context_gating>
代码部署、数据修改、对外发送——都该过这一关。别等到线上出了事故才想起来加自检，那时候成本是现在的 100 倍。
模块 6：推理力度调优（Reasoning Effort）
这是整份指南最反直觉的部分。
原文说得很直白：reasoning effort 是 last-mile knob（最后一公里的旋钮），不是 primary lever（主杠杆）。 大多数团队应该默认在 none、low 或 medium 范围内。
reasoning effort 是 OpenAI API 的一个参数，控制模型在回答前"思考多久"——档位越高，延迟越大、成本越高，但不一定效果更好。
| 档位 | 适用场景 | 典型任务 |
|---|---|---|
none | 执行型、延迟敏感 | 工作流步骤、字段提取、工单分类 |
low | 需少量思考 | 复杂指令遵循 |
medium | 需较强推理 | 长上下文综合、多文档审查 |
high | 重度推理 | 冲突解决、策略撰写 |
xhigh | 慎用，需 eval 验证 | 超长 Agent 任务 |
关键原则：在加 reasoning effort 之前，先加模块 3（工具持久化）+ 模块 4（完整性保障）+ 模块 5（验证循环）。 这三个 prompt 模块能解决大部分"模型不够认真"的问题。你以为是模型不够聪明，其实是你的 prompt 没告诉它什么叫"做完了"。
如果加了这三个模块还差点意思，再加：
<dig_deeper_nudge>
- 不要停在第一个看似合理的答案。
- 寻找二阶问题、边界情况和遗漏的约束。
- 如果任务涉及安全或准确性，至少做一次验证步骤。
</dig_deeper_nudge>
03 迁移策略：一次只改一个变量
从旧模型迁移到 GPT-5.4，最容易犯的错是同时换模型+改 prompt+调参数，出了问题根本不知道谁的锅。正确姿势：先换模型、保持 reasoning_effort 不变、跑 eval、一次只调一个参数。
| 你的现状 | GPT-5.4 起步建议 |
|---|---|
| GPT-5.2 | 保持当前 reasoning effort |
| GPT-5.3-Codex | 保持当前 reasoning effort |
| GPT-4.1 / GPT-4o | 从 none 开始，不够再加 |
| 研究类 Agent | medium 或 high |
| 长流程 Agent | medium 或 high |
04 适用边界（别无脑照搬）
这些模块不只适用于 GPT-5.4。输出契约、验证循环、工具持久化都是模型无关的 prompt 工程模式。我在 Claude 的 system prompt 里也用了类似结构，效果同样显著。
但也不要照搬。
每个模型有不同的默认行为。GPT-5.4 在 agentic 工作流上比 4o 鲁棒很多，所以指南里的"验证一切"实际上比以前宽松了。Claude 的 tool use 和 GPT 的 tool use 语义有差异，复制模板没问题，但别跳过在你的场景下跑 eval。
还有一点可能让你不安：reasoning effort 设成 none？真的够用？
指南说得很清楚：GPT-5.4 在 none 下就能胜任 action-selection 和 tool-discipline 任务。只有任务涉及细微理解——隐含需求、歧义处理、取消的 tool call 恢复——才需要 low 或 medium。
05 你的 Prompt 体检清单
这份指南传递了一个信号：LLM 应用的质量瓶颈正在从"模型能力"转移到"prompt 结构"。
6 个模块速查：
- 输出契约 — 控制说什么、怎么说
- 跟进策略 — 什么时候自主执行、什么时候问用户
- 工具持久化 — 防止"差不多就行"
- 完整性保障 — 防止"做到一半交差"
- 验证循环 — 最终交付前自检
- 推理力度 — 不是越高越好，prompt 结构先行
现在就打开你的 system prompt，对照这 6 个模块逐项查缺补漏。跑一遍 eval，有效的保留，没用的删掉——别堆模块，够用就好。
"Start with the smallest prompt that passes your evals, and add blocks only when they fix a measured failure mode." （从能通过 eval 的最小 prompt 开始，只在修复了实测到的失败模式时才加新模块。）
— OpenAI GPT-5.4 Prompt Guide developers.openai.com/api/docs/gu…
