GPT-5.5 Prompt 迁移指南：旧提示词为什么要先删再改

OpenAI 在 API 文档里更新了 GPT-5.5 prompting guide。这份文档最有价值的地方，不是又给了一套更长的提示词模板，而是提醒开发者：迁移到 GPT-5.5 时，很多旧 prompt 反而应该变短。

官方文档地址：https://developers.openai.com/api/docs/guides/prompt-guidance

如果只看一句话，GPT-5.5 的提示词方向是：少写过程，多写结果；少堆规则，多定义验收；少用“永远必须”，多写清楚什么时候停止、什么时候验证、什么时候补证据。

旧 prompt 为什么需要重写

很多生产系统里的 prompt 是一层层堆出来的。模型不稳定时，加一条规则；工具调用出错时，再加一条禁止；输出啰嗦时，再加一段格式要求。时间久了，系统 prompt 会变成一份厚重的操作手册。

这种写法在旧模型上有时有用，因为模型需要更多步骤约束才能不跑偏。但到了 GPT-5.5，OpenAI 的建议很明确：不要把旧 prompt stack 原样搬过来。

原因很简单。过度指定过程会带来几类副作用：

噪声变多，模型要在大量旧规则里找真正重要的约束。
搜索空间变窄，模型不敢选择更高效的解法。
输出变机械，看起来像在执行脚本，而不是解决问题。
旧规则之间可能互相冲突，导致工具调用和最终回答都变笨。

GPT-5.5 更适合让 prompt 描述目标状态、约束、可用证据和最终输出，而不是把每一步都写死。

outcome-first：先定义什么叫完成

官方文档反复强调一个方向：GPT-5.5 最适合 outcome-first prompt。

也就是说，提示词里应该优先写：

目标结果是什么。
什么条件算成功。
哪些约束不能突破。
当前可用上下文是什么。
最终答案需要包含哪些字段或部分。
证据不足时怎么处理。

不太推荐的写法是：

1

先检查 A，再检查 B，然后比较所有字段，再思考全部异常情况，再决定调用哪个工具，再调用工具，最后解释完整过程。

更适合 GPT-5.5 的写法是：

1
2
3
4
5


解决用户的问题。成功标准：
- 基于可用政策和账户数据完成判断
- 如果允许执行操作，先完成操作再回复
- 最终输出包含 completed_actions、customer_message、blockers
- 如果缺少关键证据，只询问最小必要字段

这不是让 prompt 变得含糊，而是把控制点从“过程顺序”移到“结果和边界”。模型可以自己选择搜索、推理和工具调用路径，但必须对成功标准负责。

少用绝对规则，多写决策规则

旧 prompt 里常见大量 ALWAYS、NEVER、must、only。这些词不是不能用，但应该只留给真正不可违反的约束，比如安全规则、必填字段、禁止执行的动作。

对于“什么时候搜索”“什么时候问用户”“什么时候继续迭代”“什么时候停止”这类判断，GPT-5.5 更适合使用决策规则。

例如，不要只写：

1

永远先搜索三次。

可以改成：

1

先做一次覆盖核心问题的检索。如果前几个结果已经能支持关键事实，就停止检索并作答。只有当证据冲突、缺失或不足以支撑结论时，才继续搜索。

这种写法给了模型判断空间，也给了它停止条件。对需要联网、检索、文件搜索或数据库查询的产品来说，这一点很关键，因为每多一轮工具调用都会带来延迟和成本。

给检索设置 retrieval budget

GPT-5.5 prompt 里值得单独加的一类规则是 retrieval budget。

它不是预算金额，而是检索停止规则。它告诉模型：什么时候证据已经足够，什么时候应该继续找，什么时候该承认缺证据。

一个实用写法是：

1

普通问答先做一次宽检索，关键词要短且有区分度。如果前几个结果已经能支持核心请求，就基于这些结果回答，不再继续搜索。只有当结果冲突、缺失关键事实或不能支持结论时，才追加检索。

这类规则能减少两种常见问题：

搜索不够，答案没有证据。
搜索过头，模型在工具循环里浪费时间。

更重要的是，文档还提醒：没有搜到证据，不应该自动变成事实上的“否”。有时正确行为是说明证据不足，或者换一个更小的问题继续查。

reasoning effort 不要一上来拉高

GPT-5.5 的推理效率更高，所以 OpenAI 建议重新评估 low 和 medium，不要一遇到质量问题就直接把 reasoning effort 往上加。

更稳的顺序是：

先确认 prompt 是否写清楚了目标、输出格式和停止条件。
加上验证循环，比如测试、引用、复核或渲染检查。
为工具调用补上持久性规则和完成标准。
仍然不够时，再提高 reasoning effort。

换句话说，reasoning.effort 更像最后的调参旋钮，不应该替代清晰的 prompt 设计。

如果任务是短分类、字段抽取、支持工单分流、格式转换，可以先从低推理成本开始。如果是长文档综合、多源冲突判断、策略写作、复杂研究，再考虑 medium 或更高。

text.verbosity 控制输出，不等于控制思考

GPT-5.5 对输出格式很可控。官方文档建议使用 text.verbosity 配合 prompt 里的输出要求。

默认 text.verbosity 是 medium。如果产品需要更短、更干净的回复，可以使用 low。但这不意味着所有内容都要变短。

一个典型做法是：

面向用户的状态更新和最终总结保持简短。
代码、配置、结构化结果需要清楚时，仍然要求可读性。
不要为了“简短”牺牲字段完整性、引用和必要 caveat。

这对代码类产品尤其有用。可以让聊天回复短一点，但要求生成的代码保持可读变量名、清楚结构和必要注释。

preamble 和 phase：让长任务更可感知

GPT-5.5 在复杂任务中可能先做推理、计划或准备工具调用，然后才输出可见文字。对流式产品来说，用户会明显感知首 token 等待时间。

官方建议是：对多步骤、工具密集或长时间运行的任务，让模型先发一个短 preamble。它不需要解释完整计划，只要告诉用户“我会先做什么”。

例如：

1

我会先检查相关文件和现有配置，然后再给出修改方案。

在 Responses API 的长任务或工具密集工作流里，还要注意 assistant item 的 phase。如果应用使用 previous_response_id，API 会自动保留前序 assistant 状态；如果应用手动回放 assistant 输出，就要保留原来的 phase 值。

常见约定是：

phase: "commentary"：中间状态更新。
phase: "final_answer"：最终答案。
不要给 user message 添加 phase。

这部分看起来像底层实现细节，但对有工具调用、状态更新和最终回答的产品很重要。手动回放时弄丢 phase，容易让模型分不清中间进度和最终结论。

提示模型检查自己的工作

GPT-5.5 guide 里还有一条非常实用：在可以验证的任务里，给模型验证工具和验证规则。

对代码 Agent，可以明确要求：

修改后运行相关单元测试。
必要时运行 type check 或 lint。
影响包较大时跑 build。
全量验证太贵时，至少做最小 smoke test。
如果验证无法运行，要解释原因和下一个最好检查方式。

对视觉或页面产物，可以要求先渲染再检查布局、裁切、间距、缺失内容和视觉一致性。

对工程方案，可以要求计划里包含需求对应关系、涉及文件/API/系统、状态流转、验证命令、失败行为、隐私和安全考虑，以及真正影响实现的开放问题。

这类规则比“请认真一点”有效得多。它把“认真”落到了可执行检查上。

一个更适合 GPT-5.5 的 prompt 骨架

OpenAI 文档给出的结构可以简化成这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


Role:
你是什么角色，要在什么上下文里工作。

# Personality
语气、协作方式、是否需要温度或观点。

# Goal
用户可见的目标结果。

# Success criteria
最终回答前必须满足的条件。

# Constraints
安全、业务、证据、权限、成本和副作用边界。

# Output
输出结构、长度、语气、字段要求。

# Stop rules
什么时候继续、什么时候重试、什么时候降级、什么时候询问、什么时候停止。

这个骨架的重点不是“每个 prompt 都要写这么多标题”。它真正想表达的是：复杂任务的 prompt 应该让模型知道目的地、边界和交付物，而不是把每一步都硬编码进去。

迁移旧 prompt 的实际顺序

如果你现在有一套 GPT-4.1、GPT-4o、GPT-5.2 或 GPT-5.4 的旧 prompt，不建议一次性大改。

更稳的迁移顺序是：

先切模型，固定当前 reasoning effort 和输出参数。
跑已有 eval 或真实样例，找出行为变化。
删除明显过时、重复、互相冲突的过程规则。
把“步骤要求”改成“成功标准”和“停止条件”。
补上检索预算、引用规则和缺证据行为。
为工具任务加验证循环。
最后再调 reasoning.effort 和 text.verbosity。

如果没有 eval，至少准备一组典型任务：简单问答、复杂检索、工具调用、格式化输出、拒答/降级、长任务完成。不要只用一个 demo case 判断 prompt 好坏。

一张旧 prompt 迁移清单

真正迁移旧 prompt 时，可以先按这张清单过一遍。它的目标不是把 prompt 改得更短，而是把无效约束删掉，把关键约束改成更可验证的形式。

检查项	常见问题	建议处理
重复规则	同一件事在不同段落反复出现，甚至措辞不一致	合并成一条清晰规则，只保留最终版本
绝对词	到处都是 `ALWAYS`、`NEVER`、`must`、`only`	只给安全、合规、权限、必填字段保留绝对约束
无停止条件	要求模型持续搜索、持续分析、持续修复，但没写什么时候停	增加 stop rules，例如证据足够、验证通过、达到轮次或成本上限
无验证命令	只写“确保正确”，没有测试、lint、引用或检查方式	改成具体检查：运行测试、类型检查、构建、引用来源或 smoke test
过程太细	把每一步都写死，模型只能照流程走	改成目标、成功标准、边界和输出要求
旧模型补丁	为旧模型弱点写的限制仍然保留	先删除，再用 eval 判断是否真的还需要
工具规则模糊	只写“必要时使用工具”	写清楚何时调用、何时停止、失败时怎么降级
输出格式漂移	有格式要求，但没有字段完整性要求	明确必填字段、可选字段、缺证据时的占位或说明

如果你只能做一件事，优先检查“无停止条件”和“无验证命令”。这两项最容易让 GPT-5.5 在长任务里变成无限工具循环，或者在没有证据时给出看似完整但不可验证的答案。

GPT-5.5 prompt 示例对比

下面这几组不是完整系统 prompt，而是迁移时常见的局部改写方式。

例子 1：检索问答

旧写法：

1

回答前必须搜索至少 3 次。必须阅读所有相关结果。必须给出完整解释。

新写法：

1

先做一次覆盖核心问题的检索。若前几个结果已经能支持关键事实，停止检索并回答。若结果冲突或缺少关键事实，再追加检索。最终回答说明依据；证据不足时明确说证据不足。

区别在于，新写法把“搜索次数”改成了“证据是否足够”。它给模型继续查的理由，也给模型停下来的理由。

例子 2：代码修改

旧写法：

1

仔细修改代码。不要破坏现有逻辑。完成后告诉我改了什么。

新写法：

1
2
3
4
5


完成用户要求的最小必要代码修改。成功标准：
- 只修改与任务相关的文件
- 保持现有公开接口兼容，除非用户明确要求变更
- 修改后运行相关单元测试；如果无法运行，说明原因和下一个最好验证方式
- 最终总结改动、验证结果和剩余风险

区别在于，新写法没有泛泛要求“仔细”，而是把谨慎落到文件范围、接口兼容、测试命令和风险说明上。

例子 3：结构化输出

旧写法：

1

请输出 JSON。不要输出多余内容。字段要完整。

新写法：

1
2
3
4
5
6


输出严格 JSON，不要添加 Markdown。必须包含：
- status: "ok" | "needs_more_info" | "blocked"
- answer: string
- evidence: string[]
- missing_info: string[]
如果证据不足，status 使用 "needs_more_info"，不要编造 evidence。

区别在于，新写法不仅要求 JSON，还定义了缺证据时的合法输出路径。这样模型不用在“必须完整”和“证据不足”之间硬编。

参数怎么配

reasoning.effort 和 text.verbosity 不应该孤立看。前者影响模型投入多少推理，后者影响输出有多详细。一个常见误区是：质量不够就先把 reasoning.effort 拉高，输出太长就把 prompt 写得更凶。更稳的做法是按任务类型配。

场景	reasoning.effort	text.verbosity	说明
字段抽取、分类、短格式转换	`none` 或 `low`	`low`	追求低延迟，重点是输出 schema 清楚
客服分流、简单工具路由	`low`	`low` 或 `medium`	规则明确时不需要高推理，保留必要解释即可
普通问答、轻量检索总结	`low` 或 `medium`	`medium`	需要一点判断，但不必默认高推理
多文档综合、冲突判断	`medium`	`medium`	先保证证据规则和引用，再考虑提高 effort
复杂代码修改、长任务 Agent	`medium` 或 `high`	用户回复 `low`，代码输出要求清晰	聊天更新可以短，代码和 diff 要可读
策略、方案、风险分析	`medium` 或 `high`	`medium` 或 `high`	需要解释取舍、风险和假设

对大多数应用来说，可以先从 low 或 medium 开始。只有当 prompt 已经写清楚成功标准、停止条件和验证规则，模型仍然遗漏关键约束时，再提高 reasoning.effort。

text.verbosity 也不是越低越好。低 verbosity 适合状态更新、客服短答、操作结果摘要；但对于代码、配置、迁移方案、审计说明，过低的输出会让结果难以审查。

哪些规则适合保留

迁移到 GPT-5.5 不是把旧 prompt 全部删掉。下面这些规则通常应该保留，而且要写得更明确。

安全规则：不能执行的动作、不能生成的内容、需要拒绝或降级的场景。
合规规则：行业政策、地区限制、年龄限制、审计要求、审批要求。
隐私规则：个人信息处理、敏感数据脱敏、日志记录限制、数据不得外传。
输出字段：API 响应、JSON schema、表格字段、前端组件需要的固定结构。
业务边界：退款规则、账号权限、服务等级、合同范围、人工客服升级条件。
工具权限边界：哪些工具能调用、哪些工具必须先确认、哪些工具禁止调用。
引用和证据规则：什么时候必须引用来源，证据冲突时怎么处理。

这些规则不是旧包袱，而是产品契约。区别只在于，迁移时要把它们从长篇口号改成可执行约束。

例如：

1

不要泄露用户隐私。

可以改成：

1

不要在最终回答中输出完整手机号、身份证号、访问 token、API key 或内部用户 ID。需要引用时只显示脱敏版本，例如手机号保留后 4 位。

哪些内容不要误删

删 prompt 时最危险的不是删掉废话，而是把真正的系统边界一起删掉。下面这些内容即使看起来“很老”，也不应该轻易删除。

隐私与数据处理要求：尤其是日志、导出、跨系统传输、第三方工具调用相关规则。
安全和权限限制：删除数据、转账、发邮件、改权限、执行 shell 命令等高风险动作的确认规则。
引用格式：如果产品依赖 citation、脚注、来源列表或审计链路，不要只因为它占空间就删掉。
工具调用边界：哪些工具只读、哪些工具可写、哪些工具必须用户确认。
失败行为：API 超时、数据缺失、检索失败、权限不足时应该怎么降级。
业务硬规则：价格、退款、封禁、风控、合规审核这类不能由模型自由发挥的规则。

一个简单判断方法是：如果删掉某条规则只会让输出风格变一点，可以考虑删；如果删掉后可能导致越权、泄露、误操作、错误承诺或审计断链，就应该保留，并改写得更精确。

总结

GPT-5.5 prompting guide 的核心不是“写更高级的提示词”，而是把旧 prompt 里过度指定过程的部分删掉。

更适合 GPT-5.5 的提示词应该做到：

目标优先，而不是步骤优先。
成功标准明确，而不是泛泛要求“做好”。
有停止条件，而不是无限搜索或无限工具循环。
有证据预算，而不是查不到就乱答或一直查。
有验证规则，而不是只靠模型自觉。
参数调优靠后，而不是一上来拉高 reasoning effort。

如果你的旧系统 prompt 已经很长，迁移到 GPT-5.5 的第一步可能不是加内容，而是删内容。把真正不可违反的规则留下，把过程细节改成结果、边界和检查项，通常比继续堆提示词更有效。

参考资料

OpenAI Prompt guidance：https://developers.openai.com/api/docs/guides/prompt-guidance
OpenAI Using GPT-5.5：https://developers.openai.com/api/docs/guides/latest-model