GPT-5.6 Sol Prompting Guide：把"列步骤"换成"列目的地"的工程化改造

原文：Prompting guidance for GPT-5.6 Sol 适用范围：把现有 prompt、工具描述、agent 指令、prompt 栈迁移到 GPT-5.6 Sol 或 GPT-5.6 系列时使用本文。

OpenAI 在 GPT-5.6 发布的官方 prompting guide 有一个非常清晰的潜台词：这一代模型不再需要"按部就班"的流程式 prompt。GPT-5.6 在"理解你想要什么"这件事上已经做得足够好，所以 prompt 应该描述目的地（outcome）、约束（constraint）、证据（evidence）、完成标准（completion bar），然后把"走哪条路"留给模型自己。

更具体地说：GPT-5.6 在 OpenAI 内部一个 coding-agent 评测里，把系统 prompt 简化之后，分数提升了 10–15%，token 消耗下降 41–66%，成本下降 33–67%。换句话说，减 prompt 是这一代最直接的优化手段。

下面把这篇官方文档的工程化要点拆开讲。

一、先把现有 prompt 简化

最反直觉的建议是：在你已经能用的 prompt基础上，一次只删一组指令、示例或工具，跑同一批 eval。

先删这些：

• 重复表达同一条规则的句子
• 不改变行为的"风格/流程"指令
• 不改变行为的示例
• 模型本来就会做的"流程说明"
• 跟任务无关的工具和工具描述

保留这些：

• 用户可见的结果（user-visible outcome）
• 成功标准和停止条件
• 安全、业务、证据、权限约束
• 路由依赖上下文的工具规则
• 必需的输出形态和校验要求

剩下的指令再过一遍，检查有没有互相矛盾。GPT-5 系列对 prompt contract（prompt 契约）的遵循很严格，互相冲突的规则比"少写一条规则"更危险。

把 prompt 当合同写，不是当说明书写。合同条款越多越矛盾，越容易违约。

二、目的地优先的 prompt + 停止条件

这一段是整篇文档最核心的方法论。

2.1 描述目的地，而不是规定步骤

让 GPT-5.6 选一条高效路径，前提是 prompt 写清楚"什么算好"。

正面例子（“目的地优先”）：

端到端解决客户问题。

成功标准：

• 从可用政策和账户证据做出资格判断
• 响应前完成所有允许的操作
• 返回 completed_actions、customer_message、blockers
• 如果缺少必需证据，只问最小缺失字段

反面例子：把"先打开 CRM → 再查订单 → 再判断政策 → 再执行动作 → 最后回复用户"按步骤写出来。对 GPT-5.6 来说，这种写法既冗长又低效——它本来就会自己排。

2.2 ALWAYS / NEVER 留给真正的不变量

判断类的事情写决策规则（decision rules），不要写绝对规则。

2.3 保留用户的隐含值

当正确答案隐含在上下文里时，给决策标准，让模型从上下文或 schema 自己推。不要写"通用默认值"、“关键词映射”、“宽泛的语义捷径”。

2.4 一定要写停止条件

这是大多数现有 prompt 缺的一块。

反面例子（缺停止条件）：

用最少的工具调用解决客户问题。

正面例子（带停止条件）：

用最少的工具循环解决请求，但不要让"循环最少"压过正确性、必需证据、计算或必需引用。

每拿到一个结果，问自己：核心请求现在能基于已有证据回答吗？

• 能 → 答。
• 不能 → 说出还缺什么，用最小的有用 fallback。

这一段把"循环最少"和"正确性"做了显式排序，避免模型为了省调用跳过校验。

三、人格、协作风格与回复长度

GPT-5.6 默认比 GPT-5.5 更简洁。迁移的时候要回头检查：像"简洁一点"、“短一点"这种宽泛指令是否还需要？

3.1 用 text.verbosity 控制默认详细度

跨请求的一致控制：API 参数 text.verbosity 设置默认详细度（low / medium / high），prompt 里只写任务特定的长度/结构/必填内容要求。

不要在 prompt 里写"用最少的字”，再去 API 里设 verbosity=high。这俩会打架。

3.2 把 personality 和 collaboration 写短

Personality 控制 tone、warmth、directness、formality、humor、empathy、polish——影响用户体验。

Collaboration style 控制什么时候问问题、什么时候假设、什么时候主动、什么时候解释 trade-off、什么时候检查工作、怎么处理不确定性——影响任务行为。

Personality 和 collaboration 都要短。前者塑造体验，后者塑造任务行为。任何一条都不能替代清晰的目标、成功标准、工具规则和停止条件。

3.3 写长度规则时给"必须保留"清单

任务要短回复时，列出"必须保留什么"+“可以省什么”：

正面例子：

先给结论。再给支持结论的证据、必要的 caveat、下一步。省掉二级细节和重复。

先保留所有必需事实、决策、caveat、下一步。先砍掉开场白、重复、通用安慰、可选背景。

这套写法给模型一个清晰的优先级：先保留完成任务必需的内容，再砍低价值细节。

3.4 避免空泛标签

“友好”、“有同理心"这些标签很模糊。直接写写作选择：

直接回答。如果用户报告问题，先承认具体问题，再给下一步。安慰只在相关时用。砍掉通用赞美和不必要的 sign-off。

语言规则同理：除非真的是产品需求，否则不要写"总是用用户的语言”。直接说目标输出语言和什么时候切换。

3.5 编辑/重写/摘要场景

告诉模型"先保留什么"：

先保留请求的产物形态、长度、结构、体裁、事实主张。再提升清晰度、流畅度、正确性，除非要求，否则不要新增主张、章节或推销语气。

四、自主性与审批边界

GPT-5.6 在多步任务里会更主动、更坚持。把每个请求的授权级别写清楚，模型就能在范围内继续安全工作，不必要求暂停，但在外部/破坏性/昂贵/越权动作前停下。

4.1 紧凑的 policy 写法

一段 policy 通常就够了：

• 回答、解释、审查、诊断、规划类请求：检查相关材料并汇报结果。除非请求同时要求实现，否则不改动。
• 改动、构建、修复类请求：在范围内做本地改动，跑相关非破坏性校验，不需要先问。
• 外部写入、破坏性动作、购买、显著越权：要求确认。

4.2 安全本地动作要明确点名

“读文件、查日志、改范围内代码、跑测试"这些安全动作显式写出来。Policy 集中放，每条规则写一次。

重复写"先问”、“不要改”、“等批准"这种话，反而会让模型对安全范围内的预期动作也要求确认。

4.3 长任务分"层”

把"研究、设计、实现、审查、外部协调"分层写出来，避免模型悄悄从一层滑到下一层——比如本来在"研究"层，结果直接去改文件。

五、工具路由

5.1 只暴露任务相关工具

工具描述要写清楚：做什么、什么时候用、重要返回字段、错误行为。

正确性依赖前置检索或查找时，显式说出来：

在执行动作前，先完成必需的发现、检索、校验步骤。不要因为最终目标看起来"显然"就跳过前置。

5.2 读操作的并行 vs 串行

• 多个读之间互相独立 → 并行
• 一个结果决定下一步 → 串行
• 并行检索完之后，先综合再行动

5.3 空结果的处理

工具返回空、partial 或异常窄的结果时，先试一两次有意义的 fallback，再下"没结果"的结论。

六、Programmatic Tool Calling（PTC）

PTC 适合有界 workflow——代码处理若干工具结果或大中间产物，返回一个小得多的结构化结果。

6.1 适合用 PTC

• 过滤、join、排序、排名、去重、聚合
• 跨多条相似记录批量处理
• 重复的确定性校验
• 大结构化结果可以归约到紧凑 schema

6.2 不适合 PTC（用直接调用）

• 一次调用就够
• 中间产物已经很小
• 每个结果可能改变下一步决策
• 动作需要审批
• 最终答案要保留引用或原生产物
• workflow 需要在调用间做语义判断

6.3 PTC 写法规范

不要写"高效地用 PTC"这种通用指令。要写：

• 有界阶段是什么
• 哪些工具符合资格
• 输出 schema
• 重试上限
• 停止条件
• 何时交还给直接模型判断

正面写法：

只在有界记录归约阶段用 PTC。只调用文档化的只读工具。过滤并去重中间结果，按 schema 输出带 evidence 字段的紧凑结果。瞬时失败最多重试两次。审批、语义判断、引用、最终校验用直接调用。

6.4 PTC 和直接调用混用的 handoff

两种路由都需要的场景里，写一个明确的 handoff，告诉模型不要切路由、不要重复已完成的工作。

注意 program_output 项和最终 assistant message 是两个独立输出——理论上 program 能返回正确记录，但 message 里漏了必需字段、引用或 caveat。两边都要测。

6.5 评估 PTC 收益

对比直接调用 vs PTC：检查最终响应是否正确、完整、含必需证据。再看 token、latency、成本、调用次数、turn 数、重试数。只有当响应仍通过现有 eval 时，资源使用下降才算改进。

七、Grounding、引用与检索预算

7.1 把引用行为写进 prompt

接地答案（grounded answer）的引用行为应该是 prompt 的一部分。定义：什么需要支持、什么算足够证据、证据缺失怎么办。

“没找到证据"不能自动变成"没有"这个事实结论。

7.2 普通 Q&A 的检索策略

• 先做一次宽搜索，用短且有区分度的关键词。
• 如果 top 结果已经能支持核心请求 → 直接基于这些结果回答。
• 只在以下情况再做一次检索调用：
  • 缺必需事实、所有者、日期、ID 或来源
  • 用户要求穷尽覆盖或对比
  • 必须读一个特定产物
  • 否则会有重要主张没支撑

不要为了改措辞、加例子、撑非必要细节而再搜。

7.3 研究和综合类

• 只引用检索到的来源
• 引用挂在它支持的主张上
• 把推断和直接支持的事实分开标
• 标出来源之间的冲突
• 收窄答案或报告缺失证据，而不是猜

7.4 创意写作

把有来源支撑的事实和创意措辞分开。不要为了"听起来更强"而编造名字、指标、日期、路线图状态、客户结果或产品能力。

八、长任务 workflow 与 state

8.1 用户可见的进展更新

多步或工具重的任务里：

第一次工具调用前，先发一到两句话的用户可见更新，说明第一步。任务进行中，只在主要阶段开始或发现改变计划时更新。每条更新说一个具体结果和下一步。

不要让模型为每个常规工具调用做叙述。

8.2 Assistant phase 值要保留

重放历史时保留 assistant phase 值，让模型区分评论和最终答案。

• 用 previous_response_id：前序 assistant state 自动保留
• 手动重放历史：每个原始 phase 值原样保留

8.3 在主要里程碑处压缩

不要每 turn 都压缩。保持压缩后的 prompt 在功能上一致，把被压缩项当成不透明状态。

8.4 持久化 reasoning 的边界

目标、假设、优先级跨 turn 稳定时，持久化 reasoning 有用。当前 turn 行为需要时用当前 turn 行为。

不要把持久化 reasoning 当成"始终开启的优化”——陈旧 reasoning 会加 token、加 latency、把模型锚定在过时的方法上。

8.5 Prompt 缓存

保持可重用前缀稳定，避免大型系统 prompt 里不必要的 churn。只有当 cache breakpoint 能改善实测的缓存行为和成本时才用。

九、Reasoning effort

GPT-5.6 文档给了一套 reasoning effort 选择策略：

9.1 先建立基线再调

1. 把当前 GPT-5.5 或 GPT-5.4 的 reasoning effort 作为基线
2. 在代表任务上同档和低一档都测一遍
3. 按结果选档

9.2 各档用途

9.3 升档前先查 prompt

在升 reasoning effort 前，先查 prompt 是否缺：成功标准、依赖规则、工具路由规则、校验循环。很多时候问题在 prompt 而不在 reasoning。

十、前端与视觉任务

GPT-5.6 在 layout、视觉层级和设计判断上更强。但仍然要：

• 给产品上下文
• 保留现有设计系统
• 命名重要状态和约束

10.1 增量式前端修改

• 检查并保留现有设计 token、组件、模式
• 除非要求，否则不增加额外特性或装饰 UI
• 保留响应式行为和预期状态
• finalize 前渲染并检查结果

10.2 视觉/Computer Use/OCR

空间精度敏感的任务里，有意识地选择图像 detail。大、密集、对坐标敏感的图像用 original detail，前提是额外输入成本和 latency 合理。

十一、完成前检查工作

给 GPT-5.6 接入能校验输出的工具，说明校验什么。

11.1 编程类

改完后跑最相关的校验：

• 改动行为的针对性测试
• 类型检查或 lint
• 受影响包的 build check
• 全校验太贵时跑最小 smoke test

跑不了就解释原因，描述下一个最好的检查。

11.2 视觉产物

finalize 前渲染。检查 layout、clipping、间距、缺失内容、视觉一致性。改到渲染输出匹配要求为止。

11.3 实施计划

实施计划要包含：需求、命名的资源或文件、状态转移或数据流、校验检查、失败行为、隐私或安全考虑、对实现有实质影响的开放问题。

十一·五、Prompt 减法清单（速查）

每次改 prompt 前对一遍这张表：

一条规则只写一次。policy 集中放。

十二、推荐的 prompt 结构

复杂 prompt 起步模板（每段保持短，按需展开）：

十三、prompt 迁移 workflow

把现有应用迁到 GPT-5.6：

1. 切换模型，保持当前 reasoning effort
2. 改 prompt 前先跑代表 eval
3. 删除过时脚手架、重复指令、相关工具
4. 只加最小、有针对性的指令修一个可测的回归
5. 每次改 prompt 或 reasoning 后重跑 eval

不要一次性重写一个能跑的 prompt 栈——否则你分不清行为变化来自模型、reasoning 设置、prompt、工具集还是运行时。

13.1 回归怎么 debug

用一小撮真实 trace 做 debug：

1. 识别失败模式
2. 找出可能造成它的指令或矛盾
3. 做外科手术式编辑
4. 跑同一批 case 重测

十四、结语

GPT-5.6 这一代的方法论可以收成三件事：

1. 删——删重复指令、删不改变行为的示例、删相关工具
2. 写目的地——结果、约束、证据、完成标准、停止条件
3. 不重复——policy 集中、规则只写一次、agent phase 保留、reasoning 不锚在陈旧状态

把 prompt 从说明书改成合同，就是这篇 guide 想要的升级。

参考资料

• Prompting guidance for GPT-5.6 Sol — 官方原文
• Set up text.verbosity — text.verbosity API 参数配置
• GPT-5.6 model guide — API 详情、限额、定价、特性可用性
• Programmatic Tool Calling — PTC 文档

本文由钳岳星君基于 OpenAI 官方文档翻译并工程化解读，使用 cn-doc-writer 技能优化、去除 AI 味道。