---
title: "GPT-5.6 Sol 提示词指南"
author: "OpenAI"
source_url: "https://developers.openai.com/api/docs/guides/prompt-guidance-gpt-5p6"
fetched_at: "2026-07-16T14:26:35Z"
updated_at: "2026-07-16T14:30:31Z"
language: "zh"
review_status: "draft"
---
# GPT-5.6 Sol 提示词指南
当你要把提示词、工具描述、Agent 指令或提示词栈迁移到 GPT-5.6 Sol 或 GPT-5.6 系列时，可以参考这份指南。API 细节、限制、价格和功能可用性，请结合当前的 [GPT-5.6 模型指南](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6) 一起查看。
GPT-5.6 的最佳效果通常来自这样的提示词：清楚定义目标结果、重要约束、可用证据和完成标准，同时给模型留出空间，让它选择高效的执行路径。
删除重复指令和示例、简化工具描述，可以提升任务表现和 token 效率。在一组内部 coding-agent eval 运行样本中，使用更精简 system prompt 的配置，评估分数大约提升了 10–15%，同时总 token 降低了 41–66%，成本降低了 33–67%。具体结果会随工作负载变化，因此应把这些范围视为方向性参考，并用你自己应用中的代表性任务来验证改动。
## 先简化提示词
从一个已经能正常工作的提示词和工具集开始。每次只移除一组指令、示例或工具，然后重新运行同一组 eval。
可以裁剪：
- 对同一规则的重复表述；
- 不改变行为的重复风格或流程指令；
- 不改变行为的示例；
- 模型已经能可靠执行的行为对应的流程指令；
- 与任务无关的工具和工具描述。
应保留：
- 用户可见的目标结果；
- 成功标准和停止条件；
- 安全、业务、证据和权限约束；
- 当工具路径取决于上下文时的工具路由规则；
- 必需的输出形态和验证要求。
检查剩余指令是否存在矛盾。GPT-5 级别的模型会紧密遵循提示词契约，因此相互冲突的规则可能比细节缺失更容易造成不稳定。
## 目标优先的提示词与停止条件
描述要到达的结果，而不是规定每一步怎么走。当提示词说明了“好的结果是什么”时，GPT-5.6 通常可以自行选择高效的搜索、工具或推理路径。
推荐：
```
Resolve the customer's issue end to end.
Success means:
- make the eligibility decision from available policy and account evidence
- complete any allowed action before responding
- return completed_actions, customer_message, and blockers
- if required evidence is missing, ask for the smallest missing field
```
避免不必要的绝对规则。`ALWAYS`、`NEVER`、`must` 和 `only` 只用于真正的不变量，例如安全规则、必填字段，或绝不应该发生的动作。对于需要判断的情况，例如何时搜索、何时提问、何时使用工具或继续迭代，优先使用决策规则。
保留明确的用户取值。当正确取值是隐含的，应提供决策标准，让模型根据上下文或 schema 推理。避免通用默认值、关键词映射和宽泛的语义捷径。
添加停止条件：
```
Resolve the request in the fewest useful tool loops, but do not let loop
minimization outrank correctness, required evidence, calculations, or
required citations.
After each result, ask whether the core request can now be answered with
useful evidence. If yes, answer. If required evidence is still missing,
name the missing fact and use the smallest useful fallback.
```
## 个性、协作方式和回答长度
GPT-5.6 默认往往比 GPT-5.5 更简洁。迁移时，检查“Be concise”或“Keep it short”这类宽泛的简短指令是否仍然有用。对某些任务来说，它们可能已经不必要，有时还会让回答过短。只有当它们能稳定产出你的应用所需的输出时，才保留这些指令。
为了在不同请求之间获得更一致的控制，可以用 `text.verbosity` 设置默认详细程度，再用提示词说明任务特定要求。请求的默认详细程度可选 `low`、`medium` 或 `high`。在提示词中，指定任务特定的长度、结构或必需内容。API 示例见[设置 `text.verbosity`](https://developers.openai.com/api/docs/guides/deployment-checklist#set-up-textverbosity)。
对于面向客户的助手和协作型产品，应同时定义个性和协作方式。
- 个性控制语气、温度、直接程度、正式程度、幽默、同理心和文字打磨程度。
- 协作方式控制模型何时提问、何时做假设、何时主动推进、何时解释取舍、何时检查工作，以及如何处理不确定性。
两者都应保持简短。个性应塑造用户体验；协作指令应塑造任务行为。二者都不应替代清晰的目标、成功标准、工具规则或停止条件。
当任务要求更短回答时，要指出模型必须保留哪些信息、可以省略哪些细节。例如：
```
Lead with the conclusion. Include the evidence needed to support it, any material
caveat, and the next action. Omit secondary detail and repetition.
Keep all required facts, decisions, caveats, and next steps. Trim introductions,
repetition, generic reassurance, and optional background first.
```
这会给模型一个清晰的优先级：先保留完成任务所需的内容，再删除价值较低的细节。
“friendly”或“empathetic”这类宽泛标签可能含义模糊。应描述定义产品语气的具体写法，例如回答要多直接、何时承认问题，以及是否需要安抚或结束语。
```
State the answer directly. If the user reports a problem, acknowledge the
specific issue before giving the next step. Use reassurance only when it is
relevant. Omit generic praise and unnecessary sign-offs.
```
除非这确实是产品要求，否则避免使用“always respond in the user’s language”这类一刀切的语言规则。应指定预期输出语言，以及何时应该切换语言。
对于编辑、改写、摘要和面向客户的草稿，应告诉模型要保留什么：
```
Preserve the requested artifact, length, structure, genre, and factual claims
first. Improve clarity, flow, and correctness without adding new claims,
sections, or a more promotional tone unless requested.
```
## 定义自主性和审批边界
GPT-5.6 在执行多步骤任务时可以更主动、更持久。应定义每类请求授权了什么程度的行动，让模型可以在安全、范围内的工作上继续推进，避免不必要的暂停，同时在外部写入、破坏性、昂贵或扩大范围的动作之前停下来。
通常，一个简洁的策略就足够：
```
For requests to answer, explain, review, diagnose, or plan, inspect the
relevant materials and report the result. Do not implement changes unless
the request also asks for them.
For requests to change, build, or fix, make the requested in-scope local
changes and run relevant non-destructive validation without asking first.
Require confirmation for external writes, destructive actions, purchases,
or a material expansion of scope.
```
明确列出安全的本地动作，例如读取文件、检查日志、编辑范围内代码和运行测试。把策略集中放在一个地方，每条规则只写一次。反复写“ask first”“do not mutate”或“wait for approval”等指令，可能会导致模型对安全且预期内的动作也不断请求批准。
对于长时间运行的工作，应定义当前处于哪一层工作。区分研究、设计、实现、评审和外部协调，避免模型在没有说明的情况下从一层工作默默移动到另一层。
## 工具路由
只暴露与任务相关的工具。工具描述应说明工具做什么、何时使用、重要返回字段和错误行为。
当正确性依赖前置检索或查找时，要明确说明：
```
Before taking an action, resolve required discovery, retrieval, and
validation steps. Do not skip a prerequisite because the intended final
state seems obvious.
```
如果多个读取动作彼此独立，就并行执行。若一个结果决定下一步动作，就保持串行。并行检索之后，先综合结果再行动。
如果工具返回空结果、部分结果，或范围可疑地狭窄，在得出“没有结果”之前，应尝试一两个有意义的备选方案。
## Programmatic Tool Calling
Programmatic Tool Calling（PTC）最适合有边界的工作流：代码可以处理多个工具结果或大型中间输出，并返回更小的结构化结果。
仅仅存在多次调用、并行调用或依赖调用，并不足以说明应该使用 Programmatic Tool Calling。
适合用于：
- 过滤、关联、排序、排名、去重和聚合；
- 对大量相似记录进行批处理；
- 重复的确定性验证；
- 可以压缩成紧凑 schema 的大型结构化结果。
以下情况更适合直接工具调用：
- 一次调用就足够；
- 中间输出本来就很小；
- 每个结果都可能改变下一步决策；
- 动作需要审批；
- 最终回答必须保留引用或原生产物；
- 工作流需要在调用之间进行语义判断。
不要依赖“use Programmatic Tool Calling efficiently”这类泛泛的指令。应说明有边界的阶段、可用工具、输出 schema、重试次数上限、停止条件，以及何时交回直接模型判断。
```
Use Programmatic Tool Calling only for the bounded record-reduction stage.
Call only the documented read-only tools. Filter and deduplicate the
intermediate results, then emit exactly the required compact schema with
evidence fields. Retry transient failures at most twice. Use direct tool
calls for approval, semantic judgment, citations, and final validation.
```
如果两条路径都需要，应定义一个清晰的交接点，并告诉模型不要切换路线或重复已经完成的工作。
`program_output` 条目和最终 assistant `message` 是两个独立输出；务必都测试。理论上，程序可能返回了正确记录，但 message 里遗漏了必需字段、引用或限制说明。
在同一组代表性任务上比较直接调用和 programmatic calling。检查最终回答是否正确、完整，并且包含必需证据。然后比较总 token、延迟、成本、调用次数、轮次和重试次数。只有当回答仍通过现有 eval 时，资源使用降低才算改进。
## 依据、引用和检索预算
对于有依据的回答，引用行为应该成为提示词的一部分。定义哪些内容需要支持、什么算足够证据，以及证据缺失时如何处理。没有证据不应自动变成事实上的“否”。
```
For ordinary Q&A, start with one broad search using short, discriminative
keywords. If the top results contain enough support for the core request,
answer from those results.
Make another retrieval call only when a required fact, owner, date, ID, or
source is missing; the user asked for exhaustive coverage or comparison; a
specific artifact must be read; or an important claim would otherwise be
unsupported.
Do not search again only to improve phrasing, add examples, or support
nonessential detail.
```
对于研究和综合：
- 只引用检索到的来源；
- 把引用附在它们支持的主张上；
- 将推断与直接支持的事实分开标注；
- 说明来源之间的冲突；
- 缩小回答范围，或报告缺失证据，而不是猜测。
对于创意写作，应区分有来源支持的事实和创造性措辞。不要为了让草稿听起来更有说服力而编造姓名、指标、日期、路线图状态、客户结果或产品能力。
## 长时间运行的工作流和状态
对于多步骤或工具密集型任务，应在第一次工具调用之前提示模型给出一小段用户可见的开场说明，然后只在主要阶段变化时给出稀疏的、基于结果的更新。不要要求模型叙述日常工具调用。
```
Before tool calls for a multi-step task, send a one- or two-sentence
user-visible update that states the first step. During the task, update only
when a major phase begins or a finding changes the plan. Each update should
state one concrete outcome and the next step.
```
回放历史时，应保留 assistant phase 的值，让模型能区分 commentary 和最终回答。如果使用 `previous_response_id`，之前的 assistant 状态会自动保留。如果手动回放历史，应原样保留每个原始 phase 值。
在主要里程碑之后再压缩，而不是每一轮都压缩。压缩后应保持提示词在功能上一致，并把压缩后的条目当作不透明状态处理。
当目标、假设和优先级在多轮之间保持稳定时，持久化 reasoning 很有用。当早先的 reasoning 不再相关时，应使用当前轮行为。不要把持久化 reasoning 当成始终开启的优化：过期 reasoning 可能增加 token、提高延迟，并把模型锚定在过时的方法上。
提示词缓存也会影响提示词构造。保持可复用前缀稳定，避免大型 system prompt 出现不必要的频繁变动。只有当显式缓存断点能改善该工作负载下测得的缓存行为和成本时，才使用它。
## Reasoning effort
在改变 reasoning effort 之前，先用当前 reasoning effort 建立基线。
- 保留当前 GPT-5.5 或 GPT-5.4 的 reasoning effort 作为基线。
- 在代表性任务上测试相同设置和低一级设置。
- 对延迟敏感的工作，如果质量能保持，使用 low。
- 以 medium 作为均衡起点。
- 只有当 eval 显示有显著收益时，才使用 high 或 xhigh。
- 将 max 留给最困难、质量优先的工作负载；不要全局推荐。
在提高 reasoning effort 之前，先检查提示词是否缺少成功标准、依赖规则、工具路由规则或验证循环。
## 前端和视觉任务
GPT-5.6 在布局、视觉层级和设计判断上更强。即便如此，仍应提供产品上下文，保留现有设计系统，并说明重要的状态和约束。
对于增量前端改动：
- 检查并保留现有设计 token、组件和模式；
- 除非用户要求，不要添加额外功能或装饰性 UI；
- 保留响应式行为和预期状态；
- 在最终完成前渲染并检查结果。
对于视觉、computer use、本地化或 OCR 这类空间精度很重要的任务，应有意识地选择图像 `detail`。当图像很大、内容密集或对坐标敏感，并且额外输入成本和延迟是合理的，使用 `original detail`。
## 完成前检查工作
给 GPT-5.6 可以验证输出的工具，并说明哪些验证重要。
对于编码：
```
After making changes, run the most relevant validation available:
- targeted tests for changed behavior
- type checks or lint checks when applicable
- build checks for affected packages
- a minimal smoke test when full validation is too expensive
If validation cannot be run, explain why and describe the next best check.
```
对于视觉产物：
```
Render the artifact before finalizing. Inspect layout, clipping, spacing,
missing content, and visual consistency. Revise until the rendered output
matches the requirements.
```
对于实现计划，应包含需求、命名资源或文件、状态转换或数据流、验证检查、失败行为、隐私或安全考虑，以及会实质影响实现的开放问题。
## 建议的提示词结构
将这个结构作为复杂提示词的起点。每一节都保持简短。只有在细节会改变行为时，才添加细节。
```
Role: [the model's function and context]
Personality: [tone and collaboration style]
Goal: [user-visible outcome]
Success criteria: [what must be true before the final answer]
Constraints: [policy, safety, business, evidence, and side-effect limits]
Tools: [which tools to use, when, and what not to use]
Output: [sections, length, format, and tone]
Stop rules: [when to retry, fallback, abstain, ask, or stop]
```
## 提示词迁移工作流
当把现有应用迁移到 GPT-5.6 时：
1. 切换模型，并保留当前 reasoning effort。
2. 在改提示词之前，先运行代表性 eval。
3. 删除过时的脚手架、重复指令和无关工具。
4. 只添加能修复已测得退化的最小定向指令。
5. 每次修改提示词或 reasoning 后，都重新运行 eval。
不要一次性重写一个正在工作的提示词栈。否则你无法判断行为变化来自模型、reasoning 设置、提示词、工具集还是运行时。
当提示词发生退化时，用一小组真实 traces 调试。识别失败模式，找出可能导致问题的指令或矛盾，做一次外科手术式编辑，然后用同一批案例重新运行。