--- id: 2026-03-08-gpt-5-4-prompt-patterns title: 我读完 GPT-5.4 官方指南：别急着加钱调参数，先把这 6 个模块写对 slug: gpt-5-4-prompt-patterns status: polish content_type: article channels: - wechat - x language: zh-CN source_urls: - https://developers.openai.com/api/docs/guides/latest-model assets: - 05-assets/gpt-5-4-prompt-patterns/cover.png cover_image: 05-assets/gpt-5-4-prompt-patterns/cover.png template: article owner: content-forge created_at: 2026-03-08T00:00:00+08:00 updated_at: 2026-03-08T11:51:04+08:00 style: tech_blog audience: 泛 AI 从业者 tags: - prompt-engineering - gpt-5 - openai - llm - agent source_notes: - 00-inbox/2026-03-08-gpt-5-4-prompt-engineering-guide.md review_status: passed review_passed_at: 2026-03-08T11:44:21+08:00 polish_status: done polish_version: "1" polished_at: 2026-03-08T11:51:03+08:00 --- # 我读完 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） 控制模型"说什么、怎么说、说多少"。 ```xml - 只返回要求的章节，按要求的顺序。 - 如果 prompt 定义了前言、分析块或工作区，不要把它当额外输出。 - 长度限制只应用于指定的章节。 - 如果要求特定格式（JSON/Markdown/SQL/XML），只输出那种格式。 - 简洁、信息密集。 - 不要重复用户的请求。 - 进度更新保持简短。 - 不要为了短而省掉必要的证据、推理或完成检查。 ``` **什么时候用**：几乎所有 production prompt 都该加。它解决的是"模型废话太多"和"格式乱飘"这两个最高频的问题。 ### 模块 2：跟进策略（Follow-Through Policy） 告诉模型什么时候该自己干、什么时候该问你。 ```xml - 如果用户意图清晰且下一步可逆、低风险，直接执行不要问。 - 只在以下情况问： (a) 不可逆操作， (b) 有外部副作用（发送、购买、删除、写入生产环境）， (c) 需要缺失的敏感信息或会显著改变结果的选择。 - 如果直接执行了，简要说明做了什么。 ``` **什么时候用**：Agent 场景必备。你有没有遇到过 Agent 每走一步都来问你"可以继续吗？"让你想砸键盘？这个模块就是解药。 ### 模块 3：工具持久化（Tool Persistence） 防止模型"觉得差不多了就停手"——Agent 场景最常见的翻车模式。 ```xml - 只要工具调用能实质性提升正确性或完整性，就调用。 - 当再调一次工具很可能提升质量时，不要提前停止。 - 持续调用工具直到：(1) 任务完成，且 (2) 验证通过。 - 如果工具返回空或部分结果，换策略重试。 - 执行操作前，检查是否需要前置的发现、查找或记忆检索步骤。 - 不要因为最终操作看起来很明显就跳过前置步骤。 - 如果任务依赖前一步的输出，先解决那个依赖。 ``` 多少次你让 AI 搜个东西，它搜不到就直接告诉你"没有相关结果"？这就是缺了 tool persistence。 还有一个配套模块值得加： ```xml - 多个检索步骤相互独立时，优先并行调用以减少等待时间。 - 有前置依赖的步骤不要并行。 - 并行检索后暂停，合成结果再决定下一步。 ``` RAG、多工具 Agent、批量处理——这三个块组合使用效果最好。 ### 模块 4：完整性保障（Completeness Contract） 防止模型"做到一半就交差"。 ```xml - 所有请求项都覆盖或标记 [blocked] 之前，任务就是未完成。 - 维护内部交付物检查清单。 - 对列表或分页结果：确定预期范围，跟踪已处理项，确认覆盖率。 - 因缺失数据阻塞的项标记 [blocked]，说明具体缺什么。 如果查找返回空或可疑地窄的结果： - 不要立即断定"没有结果"。 - 至少尝试 1-2 个回退策略：换关键词、放宽过滤、前置查找、换工具。 - 然后才报告未找到，并说明尝试了什么。 ``` `empty_result_recovery` 这个块特别实用。它本质上是在教模型一个人类常识：**搜不到 ≠ 不存在，可能是你搜的方式不对。** 但如果你以为写对这些模块就万事大吉，那就太乐观了。 ### 模块 5：验证循环（Verification Loop） 最终交付或执行不可逆操作之前，强制自检。 ```xml 最终交付前： - 正确性：输出是否满足每一个要求？ - 可验证性：事实声明是否有上下文或工具输出支撑？ - 格式：是否符合要求的 schema 或风格？ - 安全：下一步有外部副作用的话，先请求确认。 - 缺少必要上下文时不要猜。 - 优先用工具查找；查不到时才问用户，且问题要最小化。 - 如果必须继续，明确标注假设并选择可逆操作。 ``` 代码部署、数据修改、对外发送——都该过这一关。别等到线上出了事故才想起来加自检，那时候成本是现在的 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 没告诉它什么叫"做完了"。 如果加了这三个模块还差点意思，再加： ```xml - 不要停在第一个看似合理的答案。 - 寻找二阶问题、边界情况和遗漏的约束。 - 如果任务涉及安全或准确性，至少做一次验证步骤。 ``` --- ## 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 个模块速查： 1. **输出契约** — 控制说什么、怎么说 2. **跟进策略** — 什么时候自主执行、什么时候问用户 3. **工具持久化** — 防止"差不多就行" 4. **完整性保障** — 防止"做到一半交差" 5. **验证循环** — 最终交付前自检 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