乔木博客

全部

AI工具

AI教程

AI生成

AI资讯

健脑房

播客解读

论文学习

GPT-5.5 提示词指南：OpenAI 在悄悄改写规则

AI教程

·

2026年5月1日

·

282 次阅读

·

约 12 分钟

OpenAI 最近更新了 GPT-5.5 的官方提示词指南。

读完之后有一种感觉，这份文档本身就是在告诉你，之前那套写提示词的方法，可以扔掉一大半了。

https://developers.openai.com/api/docs/guides/prompt-guidance?model=gpt-5.5

先说背景：GPT-5.5 和之前有什么不同

GPT-5.5 的默认风格是高效、直接、任务导向。

不绕弯子，不会加没用的客套话，响应更聚焦，行为也更容易被引导。

这对做生产系统的人来说是好事，但对做对话产品的人来说，意味着你需要主动去定义它的"个性"，否则它就是一台冷静的机器。

一、核心转变：别再手把手教模型干活

GPT-5.5 之前，大家写提示词有个习惯，把每一步都写清楚。

先做什么，再做什么，遇到什么情况怎么处理，像在给新员工写操作手册。

GPT-5.5 的指南直接说，这种做法会带来问题。

过度规定流程，反而会压缩模型的搜索空间，导致答案机械化。

新的思路是：描述目标，而不是路径。

告诉模型"好的结果长什么样"，告诉它有哪些约束，告诉它最终答案需要包含什么字段，然后让它自己决定怎么走到那里。

指南给了一个对比，很直白：

避免这种写法：

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

推荐这种写法：

端到端解决客户的问题。成功标准是：资格决策来自可用的政策和账户数据，所有允许的操作在回复前完成，最终答案包含 completed_actions（已完成操作）、customer_message（客户消息）和 blockers（阻碍项）三个字段，如果缺少证据，询问最少的缺失字段。

早期模型需要更多引导才能保持在轨道上，所以大家养成了写详细步骤的习惯。

但现在模型的推理能力强了，那些"保姆式"指令反而成了噪音。

二、个性设定：两种产品，两种写法

GPT-5.5 的默认风格偏冷静专业，适合后台系统。

但如果你做的是面向用户的产品，比如客服助手、教练类应用、对话产品，就需要主动定义两件事：

个性（Personality），控制助手听起来怎么样，包括语气、温度、直接程度、正式程度、幽默感、共情能力、表达的精致程度。

协作风格（Collaboration style），控制助手怎么工作，包括什么时候追问、什么时候直接假设推进、主动程度、给多少背景信息、什么时候自检、遇到不确定或风险时怎么处理。

指南给了两个例子，分别对应两种产品场景：

稳定任务型助手的个性设定示例：

你是一个有能力的协作者，平易近人、稳定、直接。假设用户有能力且出于善意，以耐心、尊重和实用的方式回应。倾向于推进而不是停下来要求澄清，当请求已经足够清晰时。用上下文和合理假设向前推进。只有当缺失信息会实质性改变答案或产生有意义的风险时，才寻求澄清，并保持问题简短。保持简洁但不冷漠。给用户足够的背景来理解和信任答案，然后停止。纠正用户或不同意时，坦诚但有建设性。被指出错误时，坦然承认并专注于修复。

表达型协作助手的个性设定示例：

采用生动的对话存在感：智慧、好奇、适时幽默，关注用户的思维。当问题模糊时提好问题，一旦有足够背景就变得果断。温暖、协作、有质感。对话应该感觉轻松而有活力，但不是为了聊天而聊天。提供真实的观点，而不仅仅是镜像用户，同时对他们的目标和约束保持响应。在需要综合或建议的任务中，保持深思熟虑和有根基。当有足够背景时，给出清晰的建议，解释重要的权衡，并在不回避的情况下说明不确定性。

两个例子都很短，这是刻意的。

个性设定的目的是塑造用户体验，不是用来补偿模糊的任务指令或缺失的目标定义。

三、流式输出的"开场白"技巧

流式输出（Streaming）是指模型一边生成一边把文字推送给用户，而不是等全部生成完再显示，常见于 ChatGPT 这类产品的打字机效果。

对于需要工具调用或多步骤的任务，模型在开始真正干活之前，可能会有一段沉默期，用户看不到任何输出，体验很差。

指南建议加一条指令，让模型先发一两句话，说明它在做什么，然后再去调用工具。

通用写法：

对于多步骤任务，在任何工具调用之前，发送一个简短的用户可见更新，确认请求并说明第一步。保持在一两句话以内。

针对有独立消息阶段的编程智能体，可以更明确：

如果任务需要调用工具，必须始终在分析频道的任何内容之前，先发一个中间更新。用户更新应确认请求并解释你的第一步。

这不改变任何逻辑，只是让用户感觉响应更快。

感知速度有时候比实际速度更重要。

四、推理力度要重新评估

GPT-5.5 的推理效率更高了，指南明确说，low（低）和 medium（中）推理力度应该重新测试，再决定要不要升级到 high（高）。

这里解释一下推理力度，这是 OpenAI API 里的一个参数，控制模型在回答之前花多少"内部思考时间"。

力度越高，质量可能越好，但速度越慢，成本越高。

意思是，以前需要拉满推理力度才能解决的问题，现在可能中档就够了，不用浪费。

在用 GPT-5.5 之前，建议重新跑一遍评估，而不是直接把旧设置搬过来。

五、ALWAYS、NEVER 这类词要省着用

以前很多提示词里充满了"必须"、"绝对不能"、"只能"，用来控制模型行为。

指南的建议是，这些词留给真正的硬性约束，比如安全规则、必填输出字段、绝对不能发生的操作。

对于判断类的场景，比如什么时候搜索、什么时候追问用户、要不要调用某个工具，改用"决策规则"，给模型一定的判断空间，而不是用绝对指令把它锁死。

六、停止条件：告诉模型什么时候可以停了

这是很多提示词里缺失的一块。

指南建议加上明确的停止规则，例如：

用最少的有用工具循环解决用户查询，但不要让减少循环次数的优先级高于正确性、可访问的备用证据、计算，或事实性声明所需的引用标签。每次得到结果后，问自己："我现在能用有用的证据和引用回答用户的核心请求了吗？"如果是，就回答。

这个设计防止模型陷入"无限优化"的循环，为了显得更全面而反复调用工具，浪费时间和成本。

七、检索要设"预算"

检索预算（Retrieval budget）是一个新概念，本质上是给搜索行为设停止规则，告诉模型什么时候已有的结果够用了，直接回答就行。

指南给出的示例逻辑是：

对于普通问答，先用简短的关键词做一次宽泛搜索。

如果前几条结果已经包含足够的可引用支持，就直接回答，不要再搜了。

只在以下情况才再次检索：

前几条结果没有回答核心问题

缺少必要的事实、参数、负责人、日期、ID 或来源

用户要求全面覆盖、对比或完整列表

必须读取特定文档、URL、邮件、会议记录、代码文件

答案中会出现重要的无支撑事实性声明

不要为了这些原因再次搜索：

改善措辞

添加例子

引用非必要细节

支持可以安全泛化的表达

防止模型为了"显得更全面"而反复搜索，浪费 token，也浪费时间。

八、创意写作的护栏

对于做幻灯片、产品发布文案、客户摘要、演讲稿、领导力简介这类任务，指南建议明确区分哪些内容必须有来源支撑，哪些可以创意发挥。

示例指令：

对于创意或生成类请求，区分有来源支撑的事实和创意措辞。对于具体的产品、客户、指标、路线图、日期、能力和竞争性声明，使用检索到的或提供的事实，并引用这些声明。不要为了让草稿听起来更有力而编造具体名称、第一方数据声明、指标、路线图状态、客户结果或产品能力。如果几乎没有可引用的支持，写一个有用的通用草稿，用占位符或明确标注的假设，而不是无支撑的具体内容。

九、让模型自检

指南建议，在条件允许的情况下，给模型访问可以验证输出的工具，并在提示词里要求它主动检查自己的工作。

对于编程智能体：

做出更改后，运行最相关的可用验证：针对已更改行为的单元测试，适用时进行类型检查或代码风格检查，受影响包的构建检查，当完整验证太昂贵时进行最小冒烟测试（即最基本的功能验证）。如果无法运行验证，解释原因并描述下一个最佳检查方式。

对于视觉产物：

在最终确定前渲染产物。检查渲染输出的布局、裁剪、间距、缺失内容和视觉一致性。修改直到渲染输出符合要求。

对于工程和规划任务：

实施计划应包含：需求及每项需求的处理位置、涉及的命名资源或文件或 API 或系统、相关的状态转换或数据流、验证命令或检查、失败行为、隐私和安全考虑、会实质性影响实施的开放问题。

十、Phase 参数：区分"过程"和"答案"

从 GPT-5.4 开始，长时间运行或工具密集型的工作流可以使用 phase（阶段）参数，来区分中间更新和最终答案。GPT-5.5 沿用了这个机制。

phase 是 OpenAI Responses API（响应接口）里的一个字段，用来标记某条助手消息属于哪个阶段。

如果你用 previous_response_id（上一次响应的 ID）来串联对话，API 会自动保留之前的助手状态。

但如果你的应用是手动把上一次的助手输出塞回下一次请求，就需要原样保留每条消息的 phase 值，不能改动。

规则是：

中间的用户可见更新，用 phase: "commentary"（评论阶段）

最终完成的答案，用 phase: "final_answer"（最终答案阶段）

用户消息不加 phase

十一、建议的提示词结构

指南给出了一个完整框架，适合复杂任务，可以直接拿来用：

<code>Role: [1-2句话，定义模型的角色、背景和职责]

# Personality
[语气、态度和协作风格]

# Goal
[用户可见的目标]

# Success criteria
[最终答案前必须满足的条件]

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

# Output
[章节、长度和语气]

# Stop rules
[什么时候重试、回退、拒绝、追问或停止]</code>

每个部分保持简短，只在真正影响行为的地方加细节。

十二、自动迁移工具

指南还提到，可以用 Codex（OpenAI 的编程智能体）配合 OpenAI Docs Skill（一个专门读取 OpenAI 文档的技能插件）来自动把旧项目迁移到 GPT-5.5。

命令很简单：

<code>$openai-docs migrate this project to gpt-5.5</code>

这个 Skill 可以从 OpenAI 的技能仓库下载，也可以在其他编程智能体里使用。

最后：一个更深的观察

这份指南有一个隐含的信号，OpenAI 在把"提示词工程"这件事往更高层次推。

早期的提示词工程，更像是在"驯服"一个不稳定的系统，需要各种技巧和绕路方法。

现在的方向，越来越像是在和一个有能力的协作者沟通，你只需要说清楚你要什么，它会自己找方法。

这对用 AI 做产品的人来说意味着，那些靠精细化提示词堆出来的护城河，可能会越来越浅。

真正的差异化，还是在于你对业务问题的理解，和你对"好结果"的定义能力。

提示词只是个接口，接口背后的判断力，才是核心。

© 2026

·

向阳乔木