完整文档索引，请参阅 llms.txt。在页面 URL 后追加 .md 即可获取文档页面的 Markdown 版本。

GPT-5.6 Sol 的提示词编写指南

本指南适用于将提示词、工具描述、智能体指令或提示词堆栈适配到 GPT-5.6 Sol 或 GPT-5.6 系列模型时参考。请配合当前的 GPT-5.6 模型指南 一同使用，以了解 API 详情、限制、定价及功能可用性。

GPT-5.6 在提示词明确定义预期结果、重要约束、可用证据以及完成标准，同时留有空间让模型自主选择高效路径时，表现最佳。

删除重复的指令和示例、简化工具描述，有助于提升任务性能和令牌效率。在一组内部编码智能体评估运行样本中，使用更精简系统提示词的配置将评估得分提高了约 10–15%，同时将总令牌数减少了 41–66%，成本降低了 33–67%。实际结果因工作负载而异，请将这些范围视为方向性参考，并在您自己应用程序的代表性任务上验证更改效果。

首先简化提示词

从一个已经有效的提示词和工具集开始。每次移除一组指令、示例或工具，然后重新运行相同的评估。

可以删减：

• 重复陈述同一规则的内容；
• 不改变行为的重复风格或流程指令；
• 不改变行为的示例；
• 针对模型已能可靠执行的行为所设置的流程指令；
• 与任务无关的工具及工具描述。

需要保留：

• 用户可见的预期结果；
• 成功标准和停止条件；
• 安全、业务、证据和权限约束；
• 当路由取决于上下文时的工具路由规则；
• 必需的输出格式和验证要求。

检查剩余指令中是否存在矛盾。GPT-5-class 模型会严格遵守提示词约定，因此相互冲突的规则可能比缺少细节造成更多不稳定性。

以结果为先的提示词与停止条件

描述目标，而非规定每一个步骤。当提示词说明了"好的结果是什么样的"，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 用于真正的不变量，例如安全规则、必填字段或绝对不应发生的操作。对于需要判断的情况，例如何时搜索、询问、使用工具或继续迭代，优先使用决策规则。

明确保留用户的价值观。当正确值是隐式的，请提供决策标准，让模型从上下文或模式中进行推断。避免使用通用默认值、关键词映射和宽泛的语义快捷方式。

添加停止条件：

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 更为简洁。在迁移时，请检查"请简洁"或"保持简短"等宽泛的简洁指令是否仍然有用。对于某些任务，这些指令可能已无必要，有时甚至会使响应过于简短。若这些指令能稳定地产生应用程序所需的输出，则予以保留。

为了在请求间实现更一致的控制，使用 text.verbosity 设置默认的详细程度，然后在提示词中指定特定任务的要求。选择 low、medium 或 high 作为请求的默认详细级别。在提示词中，指定任何特定任务的长度、结构或必需内容。有关 API 示例，请参阅设置 text.verbosity。

对于面向客户的助手和协作产品，请同时定义个性和协作风格。

• 个性控制语气、亲切感、直接性、正式程度、幽默感、同理心和精练程度。
• 协作风格控制模型何时提问、做出假设、主动采取行动、解释权衡、核查工作以及处理不确定性。

两者均应保持简短。个性应塑造用户体验；协作指令应塑造任务行为。两者都不应替代明确的目标、成功标准、工具规则或停止条件。

当任务需要较短的回答时，明确指出模型必须保留的信息以及可以省略的细节。例如：

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.

这为模型提供了清晰的优先级顺序：先保留完成任务所需的内容，再删除价值较低的细节。

"友好"或"有同理心"等宽泛标签可能存在歧义。请描述定义您产品语气的具体写作选择，例如回答的直接程度、何时承认问题，以及是否适合给出安慰或结束语。

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.

避免使用"始终用用户的语言回复"等笼统的语言规则，除非这确实是产品需求。请明确指定预期的输出语言以及何时应切换语言。

对于编辑、改写、摘要和面向客户的草稿，请告诉模型需要保留的内容：

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.

明确列出安全的本地操作，例如读取文件、检查日志、编辑范围内的代码以及运行测试。将策略集中在一处，每条规则只陈述一次。重复"先询问"、"不要修改"或"等待审批"等指令，可能会导致对安全、预期操作产生不必要的审批请求。

对于长时间运行的工作，请定义当前的工作层级。区分研究、设计、实现、审查和外部协调，以防模型在不知不觉中从一个层级转移到另一个层级。

工具路由

仅暴露与任务相关的工具。工具描述应说明该工具的功能、使用时机、重要的返回字段以及错误行为。

当正确性依赖于先决条件的检索或查询时，请明确说明：

Before taking an action, resolve required discovery, retrieval, and
validation steps. Do not skip a prerequisite because the intended final
state seems obvious.

当多个读取操作相互独立时，应并行执行。当某一结果决定下一步操作时，应保持顺序执行。并行检索完成后，先进行综合分析，再采取行动。

如果工具返回空结果、部分结果或可疑的狭窄结果，请在得出"无结果"的结论之前尝试一两次有意义的备选方案。

程序化工具调用

程序化工具调用（PTC）最适用于有明确边界的工作流——代码可以处理多个工具结果或大型中间输出，并返回更小的结构化结果。

仅仅是多次调用、并行调用或依赖调用本身，并不足以证明需要使用程序化工具调用。

适用场景：

• 过滤、连接、排序、排名、去重和聚合；
• 对大量相似记录进行批处理；
• 重复性确定性验证；
• 可压缩为紧凑模式的大型结构化结果。

以下情况优先使用直接工具调用：

• 一次调用即可满足需求；
• 中间输出已经很小；
• 每个结果都可能影响下一步决策；
• 某个操作需要审批；
• 最终答案必须保留引用或原生构件；
• 工作流在调用之间需要语义判断。

不要依赖诸如"高效使用程序化工具调用"之类的笼统指令。请明确说明有边界的阶段、可用工具、输出模式、重试上限、停止条件，以及如何将控制权交回直接模型判断。

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 条目和最终的助手 message 是独立的输出；务必对两者都进行测试。理论上，程序可能返回了正确的记录，而消息却遗漏了某个必填字段、引用或注意事项。

在相同的代表性任务上对比直接调用与程序化调用。检查最终响应是否正确、完整，并包含所需的证据。然后比较总 token 数、延迟、成本、调用次数、轮次和重试次数。只有当响应仍通过现有评估时，才将较少的资源消耗视为改进。

溯源、引用与检索预算

对于需要溯源的答案，引用行为应纳入提示中。定义哪些内容需要支撑、什么程度的证据足够，以及在证据缺失时应如何处理。证据缺失不应自动等同于事实上的"否"。

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.

在重放历史记录时，保留助手的阶段值，以便模型能够区分注释与最终答案。如果使用 previous_response_id，之前的助手状态会自动保留。如果手动重放历史记录，则保持每个原始阶段值不变。

在主要里程碑之后进行压缩，而不是每轮都压缩。压缩后保持提示功能上的一致性，并将已压缩的条目视为不透明状态。

当目标、假设和优先级在多个轮次中保持稳定时，持久化推理是有用的。当早期推理不再相关时，使用当前轮次的行为。不要将持久化推理视为始终开启的优化手段：过时的推理可能增加 token 消耗、提高延迟，并使模型锚定于过时的方法。

提示缓存也会影响提示的构建方式。保持可复用前缀的稳定性，避免在大型系统提示中进行不必要的变动。仅当显式缓存断点能改善工作负载的实测缓存行为和成本时，才使用它们。

推理力度

在调整推理力度之前，先以当前推理力度建立基准。

• 将当前的 GPT-5.5 或 GPT-5.4 推理力度保留为基准。
• 在代表性任务上测试相同设置和低一级的设置。
• 在低延迟敏感型工作中，若质量不受影响，则使用低推理力度。
• 将中等推理力度作为均衡的起点。
• 仅当评估结果显示有显著提升时，才使用高或超高推理力度。
• 将最高推理力度保留给最难的质量优先型工作负载；不建议全局使用。

在提高推理力度之前，检查提示是否缺少成功标准、依赖规则、工具路由规则或验证循环。

前端与视觉任务

GPT-5.6 在布局、视觉层次和设计判断方面更为出色。仍需提供产品背景，保留现有设计系统，并明确说明重要的状态和约束条件。

对于增量式前端变更：

• 检查并保留现有的设计令牌、组件和模式；
• 除非有明确要求，否则不要添加额外功能或装饰性 UI；
• 保留响应式行为和预期状态；
• 在最终确定之前渲染并检查结果。

对于视觉、计算机使用、本地化或 OCR 任务（这些任务对空间精度有要求），请有意识地选择图像细节级别。当额外的输入成本和延迟是合理的时，对大型、密集或坐标敏感的图像使用原始细节级别。

完成前检查工作

为 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. 切换模型并保留当前推理力度。
2. 在修改提示之前运行代表性评估。
3. 删除过时的脚手架、重复指令和不相关的工具。
4. 仅添加能修复已测量到的回归问题的最小针对性指令。
5. 在每次提示或推理变更后重新运行评估。

不要一次性全面重写一个运行正常的提示词栈。否则，你将无法判断行为变化究竟源于模型、推理设置、提示词、工具集，还是运行时环境。

当某个提示词出现退步时，使用一小组真实的追踪记录来调试它。识别失败模式，找出可能导致问题的指令或矛盾之处，进行针对性的精确修改，然后用相同的用例重新运行。