272 lines
11 KiB
Markdown
272 lines
11 KiB
Markdown
---
|
||
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
|
||
<output_contract>
|
||
- 只返回要求的章节，按要求的顺序。
|
||
- 如果 prompt 定义了前言、分析块或工作区，不要把它当额外输出。
|
||
- 长度限制只应用于指定的章节。
|
||
- 如果要求特定格式（JSON/Markdown/SQL/XML），只输出那种格式。
|
||
</output_contract>
|
||
|
||
<verbosity_controls>
|
||
- 简洁、信息密集。
|
||
- 不要重复用户的请求。
|
||
- 进度更新保持简短。
|
||
- 不要为了短而省掉必要的证据、推理或完成检查。
|
||
</verbosity_controls>
|
||
```
|
||
|
||
**什么时候用**：几乎所有 production prompt 都该加。它解决的是"模型废话太多"和"格式乱飘"这两个最高频的问题。
|
||
|
||
### 模块 2：跟进策略（Follow-Through Policy）
|
||
|
||
告诉模型什么时候该自己干、什么时候该问你。
|
||
|
||
```xml
|
||
<default_follow_through_policy>
|
||
- 如果用户意图清晰且下一步可逆、低风险，直接执行不要问。
|
||
- 只在以下情况问：
|
||
(a) 不可逆操作，
|
||
(b) 有外部副作用（发送、购买、删除、写入生产环境），
|
||
(c) 需要缺失的敏感信息或会显著改变结果的选择。
|
||
- 如果直接执行了，简要说明做了什么。
|
||
</default_follow_through_policy>
|
||
```
|
||
|
||
**什么时候用**：Agent 场景必备。你有没有遇到过 Agent 每走一步都来问你"可以继续吗？"让你想砸键盘？这个模块就是解药。
|
||
|
||
### 模块 3：工具持久化（Tool Persistence）
|
||
|
||
防止模型"觉得差不多了就停手"——Agent 场景最常见的翻车模式。
|
||
|
||
```xml
|
||
<tool_persistence_rules>
|
||
- 只要工具调用能实质性提升正确性或完整性，就调用。
|
||
- 当再调一次工具很可能提升质量时，不要提前停止。
|
||
- 持续调用工具直到：(1) 任务完成，且 (2) 验证通过。
|
||
- 如果工具返回空或部分结果，换策略重试。
|
||
</tool_persistence_rules>
|
||
|
||
<dependency_checks>
|
||
- 执行操作前，检查是否需要前置的发现、查找或记忆检索步骤。
|
||
- 不要因为最终操作看起来很明显就跳过前置步骤。
|
||
- 如果任务依赖前一步的输出，先解决那个依赖。
|
||
</dependency_checks>
|
||
```
|
||
|
||
多少次你让 AI 搜个东西，它搜不到就直接告诉你"没有相关结果"？这就是缺了 tool persistence。
|
||
|
||
还有一个配套模块值得加：
|
||
|
||
```xml
|
||
<parallel_tool_calling>
|
||
- 多个检索步骤相互独立时，优先并行调用以减少等待时间。
|
||
- 有前置依赖的步骤不要并行。
|
||
- 并行检索后暂停，合成结果再决定下一步。
|
||
</parallel_tool_calling>
|
||
```
|
||
|
||
RAG、多工具 Agent、批量处理——这三个块组合使用效果最好。
|
||
|
||
### 模块 4：完整性保障（Completeness Contract）
|
||
|
||
防止模型"做到一半就交差"。
|
||
|
||
```xml
|
||
<completeness_contract>
|
||
- 所有请求项都覆盖或标记 [blocked] 之前，任务就是未完成。
|
||
- 维护内部交付物检查清单。
|
||
- 对列表或分页结果：确定预期范围，跟踪已处理项，确认覆盖率。
|
||
- 因缺失数据阻塞的项标记 [blocked]，说明具体缺什么。
|
||
</completeness_contract>
|
||
|
||
<empty_result_recovery>
|
||
如果查找返回空或可疑地窄的结果：
|
||
- 不要立即断定"没有结果"。
|
||
- 至少尝试 1-2 个回退策略：换关键词、放宽过滤、前置查找、换工具。
|
||
- 然后才报告未找到，并说明尝试了什么。
|
||
</empty_result_recovery>
|
||
```
|
||
|
||
`empty_result_recovery` 这个块特别实用。它本质上是在教模型一个人类常识：**搜不到 ≠ 不存在，可能是你搜的方式不对。**
|
||
|
||
但如果你以为写对这些模块就万事大吉，那就太乐观了。
|
||
|
||
### 模块 5：验证循环（Verification Loop）
|
||
|
||
最终交付或执行不可逆操作之前，强制自检。
|
||
|
||
```xml
|
||
<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 没告诉它什么叫"做完了"。
|
||
|
||
如果加了这三个模块还差点意思，再加：
|
||
|
||
```xml
|
||
<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 个模块速查：
|
||
|
||
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
|