GPT-5.5 最佳实践
GPT-5.5 是什么
GPT-5.5 提升了复杂生产工作流的基线水平。它适用于：编码场景、重度工具调用 Agent、接地助手、长上下文检索、产品规格到规划的流程，以及对执行质量和回复精致度有要求的客服场景。
核心原则：把它当作一个需要重新调优的新模型家族，而不是 GPT-4 或 GPT-5.2 的平替。 从最小可用的 Prompt 开始，基于代表性样本逐步调优 reasoning effort、verbosity、工具描述和输出格式。
新特性
推理效率更高
GPT-5.5 用更少的推理 token 达到与先前模型同等的效果，即使在相同 reasoning effort 下也是如此。这个优势在复杂、重度工具调用、多步骤的工作流中会累积放大。
更好的目标导向执行
GPT-5.5 更擅长从明确的目标出发：保持约束、将产品意图转化为具体下一步。描述预期结果、成功标准、允许的副作用、证据规则和输出形状。不要用逐步过程指令来限制它——除非路径本身是产品必须要求的。这个模式正是官方强调的目标导向 Prompt。
工具选择更精准
GPT-5.5 在大工具表面、多步骤服务流程、长时 Agent 任务上尤其有用。工具选择和参数使用都更精准，尤其是在 Prompt 中明确给出工具调用规则时。
语气更精致但也更直接
GPT-5.5 通常产出更温暖、可读性更高的答案，所需的 Prompt 脚手架更少。但它也更直接——这对很多生产工作流是好事，面向客户或对话类产品时可能需要显式定义 personality。
行为变化
推理 effort 默认值变为 medium
GPT-5.5 的 reasoning_effort 默认值是 medium。各档位含义（详见 OpenAI latest-model 指南）：
- none：延迟敏感场景，不需要推理或多步工具链，如轻量语音回合、快速信息检索、分类
- low：延迟敏感但 intelligence 仍重要，从这里开始评估
- medium：质量、可靠性、延迟、成本的最佳平衡起点
- high：复杂 Agent 任务，需要硬推理，延迟相对次要
- xhigh：最难 async Agent 任务，或测试模型智能边界的 evals
更高的推理 effort 不自动等于更好。 如果任务有冲突指令、弱的停止条件或开放式工具访问，更高的 effort 会导致过度思考、不必要搜索或输出质量下降。只有 evals 证明质量提升后才升级。
图像输入保留更多视觉细节
GPT-5.5 更新了 image inputs 的默认处理逻辑，保留更多视觉细节：
- auto（默认）：不放大原图，最高 10,240,000 像素或 6,000 像素尺寸限制
- high：不放大原图，最高 2,500,000 像素或 2,048 像素尺寸限制
- low：优先上下文效率，512 像素以上更激进地缩小
- original：保留原始尺寸，不缩放——适用于需要视觉精度的任务，特别是 computer use、localization、OCR、以及需要点击准确性的任务
如果工作流依赖视觉精度，应在 Prompt 或集成层面显式指定 image_detail 级别，而不是依赖 auto。相关默认行为可参考 latest-model 指南。
默认风格更简洁直接
GPT-5.5 默认风格是高效、直接、任务导向的。对于生产系统这很有用，但客服或对话类产品需要显式定义性格、温暖感、理由说明和格式。
用 text.verbosity 控制：medium 是默认，low 是更简洁回复的好起点（详见 OpenAI prompt-guidance 指南）。
编码工作流需要更强的编排
GPT-5.5 更适合需要规划、工具调用、代码库导航、验证、多步骤执行的复杂编码任务。对于编码 Agent，需要显式说明：复用策略、子 Agent 委托、测试期望、验收标准，以及何时继续、何时求助。
GPT-5.4 的强项与弱点
GPT-5.4 是当前生产级助手的主流选择，在以下场景中表现尤其出色：
强项
- 性格一致性：长答案中风格漂移更少
- Agent 鲁棒性：更倾向于坚持多步骤工作、重试、完成 Agent 循环
- 证据综合：长上下文或多工具工作流中表现可靠
- 模块化指令遵循：输出契约明确时，基于技能和块结构的 prompts 效果更好
- 长文本分析：大文档、脏数据、多文档输入场景
- 并行工具调用：批量或并行工具调用时保持准确率
- Excel/财务工作流：指令遵循、格式保真、自我验证能力强
弱项：这些场景仍需要显式 Prompt
- 低上下文工具路由：session 早期、上下文还薄时，工具选择可能不准
- 依赖感知工作流：需要显式前置条件和下游步骤检查
- 推理 effort 选择：更高的 effort 不自动等于更好，取决于任务特征而非直觉
- 研究任务：需要严格来源收集和一致引用
- 高风险操作：不可逆或高影响动作需要执行前验证
- 编码 Agent：工具边界必须清晰
从最小可用的 Prompt 开始，通过 evals 验证后才添加新指令块。
如何写目标导向的 Prompt
描述目的地，而不是每一步怎么走
这是 GPT-5.5 最重要的 prompt 原则。
❌ 不要这样（过程堆砌）：
先检查 A，再检查 B，然后比较每个字段，
然后考虑所有可能的异常，然后决定调用哪个工具，
然后调用工具，然后向用户解释整个过程。✅ 要这样（目标导向）：
端到端解决客户问题。
成功意味着：
- 根据现有政策和账户数据做出资格决策
- 任何允许的操作在回复前完成
- 最终答案包含 completed_actions、customer_message 和 blockers
- 如果证据缺失，请求最小的缺失字段告诉模型"好的结果长什么样"，让它自己选择高效的解决路径。
迁移时不要复制旧 Prompt 栈
很多 Prompt 是针对早期模型设计的：详细步骤、绝对指令（总是/绝不/必须/只能）。早期模型需要这些约束来防止跑偏。GPT-5.5 不需要。把旧 Prompt 直接迁移过来是最常见的错误。
不要用绝对指令来控制模型行为，除非这条指令描述的是真正的不可变规则（安全规则、必须字段、绝对不能发生的动作）。对于"何时搜索、何时提问、何时使用工具"这类判断，优先用决策规则而非绝对指令。
性格与协作风格
对于客服、教练、对话类产品，需要显式定义两个维度：
- 性格（Personality）：语调、温度、直接程度、正式程度、幽默感
- 协作风格（Collaboration style）：何时提问、何时假设、何时主动、何时检查、何时承认不确定性
两者都要保持简短。性格定义用户体验，协作风格定义任务行为。两者都不能替代清晰的目标、成功标准、工具规则或停止条件。
模板 A：稳健任务导向型
# Personality
你是一位能干的协作者：平易近人、稳重、直接。假设用户是胜任的且出于善意，带着耐心、尊重和务实的帮助精神回应。
当请求已经足够清晰可以尝试时，优先推进而不是停下来等待澄清。用上下文和合理假设推动进展。只有缺失信息会实质性改变答案或造成重大风险时才请求澄清，且问题要具体。
保持简洁但不唐突。给出足够的上下文让用户理解并信任答案，然后停止。需要举例、比较或简单类比才能说清楚时再用。不要重复用户的请求。纠正用户或不同意时，坦率但有建设性。错误被指出时，简单承认，专注于修复。
在专业范围内配合用户的语气。默认避免表情包和脏话，除非用户明确要求这种风格或已明确表示适合本次对话。模板 B：表达力强协作型
# Personality
展现生动活泼的对话存在感：聪明、好奇、适当时候幽默、密切关注用户思路。问题模糊时问好问题，一旦有足够上下文就变得果断。
温暖、协作、精致。对话应该感觉轻松和生动，但不是为聊天而聊天。提供真正的观点而不是简单附和用户，同时保持对他们目标和约束的响应。
需要综合或建议时，思考充分、脚踏实地。有足够上下文时给出明确建议，解释重要权衡，说明不确定性但不会闪烁其词。流式输出的开场白
GPT-5.5 在推理、规划或准备工具调用时，可能在可见文本前花一些时间。对于多步骤或工具密集型任务，在真正内容之前加开场白：
在多步骤任务的任何工具调用之前，发送一条简短的用户可见更新，确认请求并说明第一步。保持一两句话。编码 Agent 可以更明确：
如果任务需要调用工具，必须在任何分析频道内容之前先发送中间更新。用户更新应确认请求并解释你的第一步。这个开场白不改变任务本身，但能显著改善流式场景下的感知响应速度。
停止规则
给模型明确的停止规则：
用最少的有效工具循环解决用户查询，但不要让循环最小化凌驾于正确性、可达的备用证据、计算或事实声明所需的引用标签之上。
每个结果之后问自己："现在可以用有用的证据和事实声明的引用来回答用户的核心请求了吗？"如果可以，就回答。证据缺失时：
用足以正确回答的最少证据，精确引用，然后停止。信息溯源与引用
对于需要引用真实信息的任务，引用行为应该是 Prompt 的一部分。定义什么需要支撑、什么算足够的证据、以及证据缺失时模型如何行为。证据缺失不等于直接回答"不知道"。
引用规则
- 只引用当前工作流中检索到的来源。
- 绝不编造引用、URL、ID 或引用片段。
- 使用宿主应用程序要求的确切引用格式。
- 将引用附着在所支持的具体声明上，而不是只在末尾。溯源规则
- 只基于提供的上下文或工具输出提出声明。
- 如果来源冲突，明确说明冲突并归属各方。
- 如果上下文不充分或不相关，缩小答案范围或说明无法支撑该声明。
- 如果声明是推断而非直接支持的事实，将其标记为推断。检索预算
检索预算是搜索的停止规则，告诉模型什么时候够了。
可以再检索：
- 顶层结果没有回答核心问题
- 缺少关键事实、参数、日期、ID 或来源
- 用户明确要求穷尽式覆盖
- 需要读取特定文档、URL、邮件、会议记录、代码
- 答案会包含重要但无来源支撑的事实性声明
不需要再检索：
- 只是为了改善措辞
- 添加非必要的细节
- 支持可以安全地写得更通用的表述
创作类任务的护栏
对于幻灯片、推广文案、客户摘要、演讲稿等，明确区分哪些必须有来源：
对于幻灯片、领导简介、外发文案、分享摘要、演讲轨道或叙事框架等创作或生成请求，
区分有来源支撑的事实和创意措辞。
- 对于具体产品、客户、指标、路线图、日期、能力声明和竞争声明，使用检索到或提供的事实，并引用这些声明。
- 不要编造具体名称、一手数据声明、指标、路线图状态、客户成果或产品能力来让草稿听起来更有说服力。
- 如果几乎没有可引用的支撑，写一份有用的通用草稿，使用占位符或明确标记的假设，而不是没有支撑的具体内容。前端工程与 UI 质量
对于前端工作流，需要在 Prompt 中包含产品上下文、用户上下文、设计系统一致性、首屏可用性、熟悉控件、预期状态、响应行为，以及应避免的常见生成式 UI 缺陷：
- 通用英雄区（大图 hero 区域）
- 嵌套卡片
- 装饰性渐变
- 可见说明文字
- 布局错乱
让模型检查自己的工作
编程任务
做出更改后，运行最相关的验证：
- 针对更改行为的定向单元测试
- 适用时进行类型检查或 lint 检查
- 对受影响包的构建检查
- 当完整验证成本太高时，进行最小烟雾测试
如果无法运行验证，说明原因并描述次优检查。视觉产物
在定稿前渲染产物。检查渲染输出是否有布局、裁剪、间距、缺失内容和视觉一致性方面的问题。反复修订直到渲染输出符合要求。工程与规划任务
对于实现计划，包含：
- 需求及每个需求的对应解决方案
- 所涉及的资源、文件、API 或系统
- 相关状态转换或数据流
- 验证命令或检查
- 失败行为
- 隐私和安全考量
- 实质性影响实现的开放问题
GPT-5.4 的工具使用策略
坑一：低上下文时工具路由不准
session 早期、上下文还薄的时候，工具选择可能不准：
tool_persistence_rules
- 当工具能实质性提升正确性、完整性或溯源时使用工具。
- 当另一个工具调用可能实质性提升正确性或完整性时，不要提前停止。
- 持续调用工具直到：(1) 任务完成，且 (2) 验证通过。
- 如果工具返回空或部分结果，用不同策略重试。dependency_checks
- 在执行操作前，检查是否需要先决条件发现、查询或记忆检索步骤。
- 不要因为预期的最终操作看起来很明显就跳过先决条件步骤。
- 如果任务依赖前一步的输出，先解决该依赖。坑二：长任务提前结束
模型可能因为批次漏项或检索结果为空就认为完成：
completeness_contract
- 将任务视为未完成，直到所有请求项都被覆盖或明确标记为 [blocked]。
- 维护一个所需交付物的内部检查清单。
- 对于列表、批次或分页结果：
- 尽可能确定预期范围
- 跟踪已处理项或页面
- 在定稿前确认覆盖范围
- 如果任何项被缺失数据阻塞，将其标记为 [blocked] 并准确说明缺失了什么。检索为空时的恢复策略
当检索返回空、部分或明显过窄的结果时：
empty_result_recovery
- 不要立即断定不存在结果。
- 至少尝试一到两个备用策略：
- 替代查询措辞
- 更宽泛的过滤器
- 先决条件查询
- 替代来源或工具
- 只有在那之后才报告未找到结果，并说明尝试了什么。高风险操作前的验证循环
工作流看起来完成后，在返回答案或执行不可逆操作之前，添加轻量验证步骤：
verification_loop
定稿前检查：
- 正确性：输出是否满足每个要求？
- 溯源：事实声明是否有提供的上下文或工具输出支撑？
- 格式：输出是否符合请求的 schema 或样式？
- 安全性和不可逆性：如果下一步有外部副作用，先请求许可。缺少上下文时不允许猜测
missing_context_gating
- 如果必需的上下文缺失，不要猜测。
- 缺失上下文可检索时，优先使用适当的查询工具；仅在不可检索时才问最小的澄清问题。
- 如果必须继续，明确标记假设并选择可逆的操作。Agent 执行安全框架
对于主动执行动作的 Agent，添加执行框架：
action_safety
- 起飞前：用一两行总结预期操作和参数。
- 通过工具执行。
- 落地后：确认结果和执行的任何验证。工具调用：并发与串行
parallel_tool_calling
- 当多个检索或查询步骤相互独立时，优先并行工具调用以减少墙上时钟时间。
- 不要并行化有先决条件依赖或一个结果决定下一步操作的步骤。
- 并行检索后，暂停综合结果再进行更多调用。
- 优先选择性并行：并行化独立的证据收集，而不是推测性或冗余的工具使用。核心原则：独立任务并行，依赖任务串行。
输出契约与 Verbosity 控制
GPT-5.4 通过 output_contract 与 verbosity 参数配合，实现对输出长度和结构的精确控制（详见 OpenAI prompt-guidance 指南）：
<output_contract>
- 按请求的顺序返回完全请求的章节。
- 如果 Prompt 定义了开场白、分析块或工作区，不要将其视为额外输出。
- 只对预期章节应用长度限制。
- 如果需要特定格式（JSON、Markdown、SQL、XML），只输出该格式。
</output_contract>
<verbosity_controls>
- 优先简洁、信息密度高的写作。
- 避免重复用户的请求。
- 保持进度更新简短。
- 不要过度缩减答案以至于遗漏所需证据、推理或完成检查。
</verbosity_controls>跟进策略
用户经常在对话中途改变任务、格式或语调。定义明确的规则：
default_follow_through_policy
- 如果用户意图清晰且下一步可逆且低风险，不需要询问直接继续。
- 只有当下一步是以下情况时才请求许可：
(a) 不可逆的，
(b) 有外部副作用（发送、购买、删除、写生产环境），或
(c) 需要缺失的敏感信息或会实质性改变结果的选择。
- 如果继续，简短说明你做了什么以及什么仍是可选的。instruction_priority
- 用户指令优先于默认风格、语气、格式和主动偏好。
- 安全、诚实、隐私和许可约束不可让步。
- 如果较新的用户指令与较早的冲突，遵循较新的指令。
- 保留不冲突的较早指令。
- 更高优先级的开发者或系统指令仍具约束力。对话中途指令更新
指令变更时，使更新显式、局限、局部化：
下次响应单独生效：
<task_update>
仅对下次响应生效：
- 不要完成任务。
- 只生成一个计划。
- 保持 5 个要点。
除非与此次更新冲突，所有早期指令仍然适用。
</task_update>任务本身改变时：
<task_update>
任务已改变。
先前任务：完成工作流。
当前任务：仅审查工作流并识别风险。
本次规则：
- 不执行操作。
- 不调用破坏性工具。
- 精确返回：
1. 主要风险
2. 缺失信息
3. 建议的下一步
</task_update>Phase 参数
从 GPT-5.4 开始，长流程或工具密集型的 Responses 工作流用 phase 值区分中间更新和最终答案（详见 OpenAI prompt-guidance 指南）：
如果手动重放助手条目：
- 精确保留助手 phase 值。
- 使用 `phase: "commentary"` 表示中间用户可见更新。
- 使用 `phase: "final_answer"` 表示完整答案。
- 不要给用户消息添加 phase。如果使用 previous_response_id，API 自动保留先前的助手状态。
Prompt 结构模板
角色： [一两句话定义模型的功能、上下文和工作]
# Personality
[语调、举止、协作风格]
# Goal
[用户可见的结果]
# Success criteria
[最终答案前必须满足的条件]
# Constraints
[政策、安全、业务、证据、副作用限制]
# Output
[章节、长度、语调]
# Stop rules
[何时重试、何时降级、何时放弃、何时提问、何时停止]每个区块保持简短，只在会实际改变行为的地方加细节。
Verbosity 与格式输出
通过 text.verbosity 控制输出长度——medium 是 API 默认，low 想要更简洁的响应（完整参数说明见 OpenAI prompt-guidance 指南）。
格式原则：
- 正常对话、解释、报告、文档、技术写作：用纯段落，默认格式
- 需要比较、排名、扫描时再用标题、粗体、列表
- 用户明确要求简洁或特定格式时，遵循偏好
编辑/重写任务时，告诉模型保留什么再改进：
首先保留请求的产物、长度、结构和体裁。悄然改善清晰度、流畅度和正确性。除非明确要求，不要添加新声明、额外章节或更具推广性的语气。显式指定受众和长度：
写给资深商业受众。答案控制在 400 词以内。使用短段落，只在改善可读性时使用列表。先说结论，再说理由，最后说注意事项。