OpenAI 使用 GPT-5.5

<a id="introduction"></a>

简介

GPT-5.5 面向复杂生产工作流，包括编程、工具密集型智能体、基于资料回答的助手、长上下文检索、从产品需求形成计划，以及重视执行质量与表达完成度的客户流程。

迁移时应把它视为需要重新评测的模型家族。先建立保持产品合同的最小提示基线，再用代表性任务调整推理力度、详细程度、工具说明与输出格式。不要把较早系统中的全部补偿性指令原样搬入。

GPT-5.5 延续 GPT-5.4 的提示词缓存、托管工具、工具搜索、上下文压缩，以及手动重放assistant项时的phase处理。

<a id="whats-new"></a>

新能力

同一推理力度下，相较较早模型，GPT-5.5可能用更少推理词元完成任务；多步与工具任务中的节省可以累积，但实际费用需测量。它也更擅长依据目标、约束、成功标准、允许的副作用、证据规则和输出形状执行任务，不必在非必要时指定每个步骤。

工具选择和参数使用更精确，尤其适合大型工具集合、多步骤服务流程和长任务。默认表达通常较成熟、温暖和可读，但也可能更直接，应按产品体验调整。

行为变化

1. 推理默认medium：作为质量、可靠性、延迟与成本的均衡起点。需要工具、规划、搜索或多步决策时，低延迟流程先试low，再比较none；none适合不需推理的轻量语音、快速检索、分类。只有评测收益足以覆盖延迟与费用时才提高至high／xhigh。指令冲突、停止条件弱、工具无限开放时，提高力度可能反而导致过度思考和搜索。
2. 默认保留更多图像细节：未设置或auto时采用original行为，在不超10,240,000像素、单边6,000像素限制内保留尺寸；显式high的对应限制为2,500,000像素、单边2,048像素；low更积极缩放超过512像素边长的图像以节约上下文。这些是5.5指南中的规格，不能套到5.6或其他家族。
3. 更细致地遵循指令：对长任务、工具和取证任务明确成功标准及停止规则。
4. 更简洁直接：面向客户的产品可能仍需说明个性、温度、理由和格式。text.verbosity默认medium，偏简洁可比较low。
5. 编程编排更重要：明确复用、子智能体、测试、验收、继续工作或求助的条件。

<a id="migration-quickstart"></a>

快速迁移

使用Codex自动迁移

可使用OpenAI Docs技能：

迁移请求示例的中文译文

$openai-docs 将此项目迁移到 gpt-5.5

其他编程智能体可从同一仓库获取技能。模型与提示词迁移的具体范围见升级到GPT-5.5。

API与模型参数

模型设为gpt-5.5；推理、工具和多轮任务优先Responses。力度从旧有效值建立基线，low用于高效推理，medium均衡，high用于较难且容忍延迟的智能体任务，xhigh用于最困难的异步任务或边界评测。简洁输出可设text.verbosity为low，它可能比5.4同名设置更简洁。

工具和长任务检查phase、开场进度与assistant项重放。对照准确性、词元和端到端延迟，不只比较单次可见回答长度。

提示词

明确结果与成功标准，移除不必要的逐步流程限制。可用结构化输出约束Schema，而不是只在提示中描述JSON形状。缓存采用稳定内容在前、动态内容在后。模型知道当前UTC日期，通常无需重复加入；业务时区、政策生效日期或用户本地日期仍需明确提供。

使用推理模型的配套能力

迁移不仅涉及提示词，还涉及API配置与编排：

• Responses与状态：多轮可用previous_response_id；无状态或ZDR流程按需回传相关输出项。
• 推理与详细度：将reasoning.effort与最终长度分开。用text.verbosity设置默认详细度，再明确字数、小节、表宽或仅JSON等合同。
• 结构化输出：优先用Schema机制约束和验证格式。
• 提示词缓存：符合条件的长提示自动缓存；保持前缀稳定，将用户动态信息放后面，统计usage中的cached_tokens，字段路径按端点返回结构确定。共享前缀使用稳定prompt_cache_key；高流量时按官方缓存指南分散键。
• 工具调用：延续5.4模式。工具自身说明应覆盖用途、时机、输入、副作用、重试安全和常见错误；跨工具的运行政策再放入system指令。
• 托管工具与工具搜索：合适时使用搜索、文件搜索、代码解释器、图像生成和计算机操作等托管能力；内部系统或专用副作用使用自定义函数。工具很多时，可通过工具搜索延后加载相关子集。
• 开场进度：用户先看到即将检查的内容，工具返回后继续同一assistant状态，有助于理解执行过程。
• phase：手动回放时原样保留；previous_response_id则由API保持旧状态。
• 上下文压缩：有意保留已完成动作、当前假设、ID、工具结果、阻塞和下一具体目标。
• Agents SDK：新智能体可参考当前SDK的编排、追踪、交接和状态模式。

<a id="prompting-best-practices"></a>

提示词最佳实践

定义目标、质量标准、约束、可用证据和最终输出，让模型选择有效路径。以下模式需结合产品、工具与评测调整。

个性与合作方式

个性说明声音、温度、直接程度、正式性、幽默、同理心与润色；合作方式说明何时提问、何时作假设、主动程度、提供多少背景、怎样验证和处理不确定性。两者都应短，不替代目标、工具规则与停止条件。

稳重、任务导向助手的个性提示词译文

## 个性
你是有能力的合作者：易于接近、稳重、直接。假定用户有能力且出于善意，以耐心、尊重和务实帮助回应。

请求已经足够清楚、可以尝试时，优先推进，不停下来澄清。结合上下文和合理假设行动。只有缺失信息会实质改变答案或产生明显风险时才澄清，问题保持聚焦。

简洁而不生硬。提供足够上下文，让用户理解并信任答案，然后结束。有助于理解时用例子、比较或简单类比。纠正或不同意用户时，坦诚且有建设性。别人指出错误时，直接承认，专注修正。

在专业边界内配合用户语气。默认不用表情或粗口，除非用户明确要求这种风格，或已明确表明它适合此对话。

表达较鲜明的合作助手提示词译文

## 个性
展现鲜活的对话存在感：聪明、好奇、适当俏皮，关注用户思路。问题不清楚时提好问题；上下文足够后果断行动。

温暖、合作、表达成熟。对话应轻松、有生气，但不为聊天而闲聊。给出自己的实际观点，而非只是附和，同时回应用户目标和约束。

需要综合或建议时，周到、务实。上下文足够时给明确推荐，解释重要取舍，指出不确定性而不回避。

用开场说明缩短首次可见等待

流式应用中，模型可能先规划或准备工具。长任务可要求一两句可见更新，回应请求并说明第一步，不改变实际任务。

多步骤工具任务的开场提示词

多步任务调用任何工具前，先发送用户可见的简短更新，回应请求并说明第一步，限一两句话。

支持不同消息阶段的编程智能体提示词

任务需要调用工具时，必须在任何 analysis 通道内容之前先发送中间更新，回应请求并解释第一步。

结果优先与停止条件

明确目的地，避免不必要地固定搜索和工具路径：

以最终结果定义客户问题的成功标准

从头到尾解决客户问题。

成功意味着：
- 依据可用政策与账户数据作出资格决定；
- 回复前完成任何获准动作；
- 最终答案包含 completed_actions、customer_message 和 blockers；
- 缺证据时，只询问最小缺失字段。

ALWAYS、NEVER、must、only等绝对措辞应留给真正不变量，如必填字段、禁止动作和安全约束。搜索、提问、调用和迭代这类判断，更适合给决策规则。以下是应避免机械套用的反例：

过度规定每一步的反例，不建议直接作为默认工作流

先检查 A，再检查 B，再比较每个字段，再思考所有可能例外，然后决定调用哪个工具，再调用工具，最后向用户解释整个过程。

将正确性与充分证据优先于压缩工具循环的停止规则

用最少的有效工具循环解决问题，但不能让减少循环优先于正确性、可获得的后备证据、计算或事实说法所需的引用标签。

每次得到结果后问：“现在能否用有用证据，以及事实说法所需的引用，回答用户核心请求？”如果可以，就回答。

证据足够时停止的规则

使用足以正确回答的最少证据，准确引用，然后停止。

格式

让结构服务理解，使用text.verbosity与明确的输出形状；确实需要稳定交付物时再加较重结构。

普通对话的格式提示词译文

让格式服务理解。普通对话、解释、报告、文档和技术文章默认用普通段落，呈现干净、易读，不让结构比内容更沉重。

少用标题、加粗、要点和有序列表。用户要求、需要明确比较或排名、或连贯文字较难浏览时才使用，否则优先短段落和自然衔接。

尊重用户格式偏好。要求简短、少排版、无要点、无标题或特定结构时，除非有充分理由，否则遵循。

指定受众与长度的提示词译文；400词为原示例预算

面向资深商业读者写作，答案少于 400 个词。用短段落，仅在便于浏览时加要点。先结论，再理由，再限制。

编辑和摘要时，先说明保留内容，再改风格，避免为润色而扩写：

保持交付物、结构与事实边界的编辑提示词

优先保留要求的交付形式、长度、结构和体裁。自然改善清晰度、流畅度、正确性。未经明确要求，不增加新说法、额外小节或更宣传化的语气。

依据、引用与检索预算

明确哪些主张需要证据、怎样算足够、缺失证据时如何处理。没有找到证据不自动意味着事实不存在。引用格式可参考引用指南。检索预算属于停止规则：

限定检索次数与再次检索条件的提示词

普通问答先用简短、有区分度的关键词做一次广泛搜索。最佳结果已有足够可引用依据支持核心请求时，直接据此回答，不再搜索。

仅在以下情况再次检索：
- 最佳结果未回答核心问题。
- 缺少必需事实、参数、负责人、日期、ID 或来源。
- 用户要求穷尽覆盖、比较或完整列表。
- 必须读取特定文档、URL、邮件、会议、记录或代码产物。
- 否则答案会含有重要但无依据的事实说法。

不为润色、添加例子、引用非必要细节，或支持可安全改为一般表述的措辞而再次搜索。

创意写作边界

幻灯片、发布文案、客户摘要、演讲和叙事应区分来源事实与可创意表达部分：

不编造具体产品、客户、指标和路线图的提示词

对幻灯片、领导发言短文、对外文案、分享摘要、讲稿要点或叙事框架等创作/生成请求，区分有来源支持的事实与创作措辞。

- 具体产品、客户、指标、路线图、日期、能力及竞争说法采用已检索或用户提供的事实，并引用。
- 不为增强文稿而编造具体名称、第一方数据说法、指标、路线图状态、客户成果或产品能力。
- 可引用支持很少或没有时，写有用的一般性稿件，用占位符或明确标注的假设，不给无依据的具体内容。

前端工程与视觉质量

前端提示示例涉及产品与用户背景、设计系统、首屏可用性、熟悉控件、交互状态和响应式布局，并说明应避免通用宣传首屏、嵌套卡片、装饰渐变、可见实现说明及破损布局等常见问题。

要求验证工作

提供实际可检查输出的工具，并明确验证层级：

编程修改后的具体验证要求

修改后运行最相关且可用的验证：
- 对变化行为运行定向单元测试；
- 适用时检查类型或 lint；
- 对受影响的包进行构建检查；
- 完整验证成本过高时，做最小冒烟测试。

无法运行验证时，解释原因并说明次优检查方式。

视觉交付物渲染后检查的要求

结束前渲染交付物，检查排版、裁切、间距、缺失内容和视觉一致性。反复修订，直到渲染结果符合要求。

让工程实施计划可追踪的要求

实现计划应包含：
- 需求及各自在哪满足；
- 涉及的具体资源、文件、API 或系统；
- 相关时说明状态转换或数据流；
- 验证命令或检查；
- 失败行为；
- 隐私和安全考虑；
- 实质影响实现的待解问题。

<a id="phase-parameter"></a>

phase参数

GPT-5.4起，长任务可通过assistant项phase区分中间更新与最终答案，GPT-5.5沿用该方式。previous_response_id自动保留旧状态；手动回放则必须原样保留，尤其存在开场说明、连续工具调用和最后总结时。

手动回放assistant项的phase规则

手动回放助手条目时：
- 完全保留助手 phase 值。
- 用户可见的中间更新用 phase: "commentary"。
- 完成的答案用 phase: "final_answer"。
- 不给用户消息添加 phase。

建议的提示词结构

每部分保持简短，只加入会改变行为的细节：

角色、个性、目标、成功标准、约束、输出和停止规则模板

角色：[用 1—2 句话定义模型职能、上下文与工作]

## 个性
[语气、举止与协作风格]

## 目标
[用户可见的结果]

## 成功标准
[最终答案前必须满足的条件]

## 约束
[政策、安全、业务、证据和副作用限制]

## 输出
[小节、长度和语气]

## 停止规则
[何时重试、回退、弃答、询问或停止]