---
layout: post.njk
source: https://blog.qiaomu.ai/openai-prompt-5-5
speaker: 向阳乔木
title: GPT-5.5 提示词指南：OpenAI 在悄悄改写规则 · 乔木博客
date: '2026-05-01'
summary: 文章回顾了OpenAI发布的GPT-5.5提示词指南，核心观点是提示词工程正从精细化指令转向目标导向的协作。指南强调描述期望结果而非具体步骤，定义模型个性和协作风格，并引入了明确的停止条件、检索预算及模型自检机制。文章指出，AI应用的关键在于对业务问题的理解和对‘好结果’的定义，而非过度依赖复杂的提示词技巧，提示词正成为与强大协作者沟通的接口。
area: tech-engineering
category: ai-application
tags:
- prompt-engineering
- gpt-5.5
- ai-guidance
- llm-usage
people: []
companies_orgs:
- OpenAI
products_models:
- GPT-5.5
media_books: []
draft: true
status: evergreen
---
乔木博客
全部
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
## 十一、建议的提示词结构
指南给出了一个完整框架，适合复杂任务，可以直接拿来用：
```
Role: [1-2句话，定义模型的角色、背景和职责]
# Personality
[语气、态度和协作风格]
# Goal
[用户可见的目标]
# Success criteria
[最终答案前必须满足的条件]
# Constraints
[政策、安全、业务、证据和副作用限制]
# Output
[章节、长度和语气]
# Stop rules
[什么时候重试、回退、拒绝、追问或停止]
```
每个部分保持简短，只在真正影响行为的地方加细节。
## 十二、自动迁移工具
指南还提到，可以用 Codex（OpenAI 的编程智能体）配合 OpenAI Docs Skill（一个专门读取 OpenAI 文档的技能插件）来自动把旧项目迁移到 GPT-5.5。
命令很简单：
```
$openai-docs migrate this project to gpt-5.5
```
这个 Skill 可以从 OpenAI 的技能仓库下载，也可以在其他编程智能体里使用。
## 最后：一个更深的观察
这份指南有一个隐含的信号，OpenAI 在把"提示词工程"这件事往更高层次推。
早期的提示词工程，更像是在"驯服"一个不稳定的系统，需要各种技巧和绕路方法。
现在的方向，越来越像是在和一个有能力的协作者沟通，你只需要说清楚你要什么，它会自己找方法。
这对用 AI 做产品的人来说意味着，那些靠精细化提示词堆出来的护城河，可能会越来越浅。
真正的差异化，还是在于你对业务问题的理解，和你对"好结果"的定义能力。
提示词只是个接口，接口背后的判断力，才是核心。
© 2026
·
向阳乔木