OpenAI 官方给出的完整方法论,GPT-5.6 提示词指南:少写一点,反而更强?

🧭 先说结论：别再把 Prompt 写成操作手册

这份指南用于把现有的提示词、工具描述、Agent 指令或整套 Prompt Stack 迁移到 GPT-5.6 Sol 或 GPT-5.6 系列模型。OpenAI 建议同时参考当前的 GPT-5.6 模型指南，以了解 API 细节、限制、定价和功能可用性。

官方给出的总原则是：

让提示词定义结果、重要约束、可用证据和完成标准，然后给模型足够空间，让它自己选择高效路径。

这与很多人熟悉的 Prompt 写法正好相反。过去，模型能力较弱时，我们会在系统提示词里写一长串操作流程：先做什么，再做什么；遇到某个词就调用某个工具；每一步都必须输出什么；任何情况都不能跳过某个步骤。

GPT-5.6 的建议是：不要把每一条可能的行为都写成硬编码流程。 如果这些规则不改变最终行为，就应该删掉，让模型围绕目标自行规划。

OpenAI 在一组内部编码 Agent 评测中观察到，精简系统提示词后，评测分数大约提升了 10%—15%，总 Token 量减少 41%—66%，成本减少 33%—67%。

但官方也明确提醒：这些结果取决于工作负载，只能作为方向性参考。不要把它们理解成所有应用都能复制的性能承诺，最终还是要用自己的代表性任务验证。

✂️ 第一原则：先把提示词瘦身

开始时，应该保留一份已经能够工作的 Prompt 和工具集合。然后一次只删除一组指令、示例或工具，再重新运行同一套评测。

可以优先删掉什么？

• 重复表达同一条规则的句子；
• 不会改变模型行为的重复风格或流程指令；
• 不会改变行为的示例；
• 模型已经能够稳定执行的过程性指令；
• 与当前任务无关的工具及工具描述。

哪些内容必须留下？

• 用户最终能看到的结果；
• 成功标准和停止条件；
• 安全、业务、证据和权限约束；
• 依赖上下文才能决定的工具路由规则；
• 必须遵守的输出结构和验证要求。

删完以后，还要检查剩余指令之间是否相互矛盾。

GPT-5 级别的模型会非常认真地执行 Prompt 合同。也就是说，矛盾的规则可能比缺少细节更容易造成不稳定。你以为自己增加了安全网，模型看到的却可能是一组互相冲突的优先级。

一个典型误区

比如同时写下：

• “尽可能少调用工具”；
• “任何结论都必须有外部证据”；
• “不要向用户追问”；
• “缺少信息时必须确认”；
• “不要做任何假设”；
• “即使信息不全也要给出完整答案”。

这些句子单独看都合理，放在一起却没有告诉模型，在它们发生冲突时谁优先。

更好的写法不是继续添加第七条、第八条例外规则，而是明确成功标准、证据要求和停止条件。

🎯 结果优先：描述终点，不要规定每一步

OpenAI 建议，复杂任务的 Prompt 应该先告诉模型“什么叫做好”，而不是事无巨细地规定所有过程。

例如，不要写成：

先检查账户，再调用资格查询工具，然后读取政策文档，接着计算折扣，最后输出三段话。

可以改成：

端到端解决客户问题。

成功标准：
- 根据现有政策和账户证据做出资格判断
- 在回复前完成所有被允许的操作
- 返回 completed_actions、customer_message 和 blockers
- 如果缺少必要证据，只询问最小的缺失字段

这段 Prompt 规定了终点、完成标准、输出结构和缺失信息的处理方式，却没有强迫模型沿着唯一的路径执行。

模型可以根据当前任务决定：什么时候查资料，什么时候调用工具，什么时候直接回答，什么时候需要补充检索。

少用“永远”“绝对”“必须”

ALWAYS、NEVER、must 和 only 应该只用于真正不允许变化的规则，例如：

• 安全边界；
• 必填字段；
• 绝对不能执行的外部操作；
• 强制的权限条件。

对于“什么时候搜索”“什么时候提问”“什么时候使用工具”“是否继续迭代”这类判断问题，不要一律写成绝对命令，而应使用决策规则。

例如：

用尽可能少的有效工具循环解决请求，但不能为了减少循环而牺牲正确性、必要证据、计算结果或必需引用。

每次获得结果后，判断现在是否已经可以用足够证据回答核心请求。如果可以，就回答。如果仍缺少必要证据，指出缺少的事实，并采用最小的有效补救方式。

这比“最多调用一次工具”更可靠，因为它给模型的是优先级，而不是脱离上下文的硬限制。

尊重用户明确提供的值

当用户已经明确给出了一个值、偏好或参数，Prompt 不应该用宽泛的默认值覆盖它。

如果正确值需要从上下文或 Schema 中推断，就提供判断标准，让模型根据上下文推理，而不是建立一张庞大的关键词映射表或语义捷径。

🗣️ 简洁、个性与协作方式

OpenAI 观察到，GPT-5.6 默认往往比 GPT-5.5 更简洁。因此在迁移时，要重新检查“保持简洁”“尽量短”这类宽泛指令是否仍然有用。

它们有时可以帮助控制输出，但也可能让答案变得过短，遗漏证据、限定条件或下一步行动。

对于更稳定的细节控制，可以使用 text.verbosity 设置默认详细程度：

• low：偏简洁；
• medium：平衡；
• high：更完整。

然后在 Prompt 中描述当前任务所需的具体长度、结构和必需内容。

Personality 不等于任务指令

面向客户的助手或协作型产品，应该同时定义：

• Personality：语气、温度、直接程度、正式程度、幽默、共情和润色程度；
• Collaboration style：什么时候提问、什么时候做假设、什么时候主动推进、什么时候解释权衡、什么时候检查工作，以及如何处理不确定性。

两者都应该简短。个性控制用户体验，协作风格控制任务行为；它们不能替代清晰的目标、成功标准、工具规则和停止条件。

比如，“友好一点”“更有共情”都太模糊。可以改成：

直接给出答案。如果用户报告了问题，先承认具体问题，再给出下一步。
只有在确实相关时才进行安抚。省略泛泛的夸奖和不必要的结束语。

这种写法把抽象形容词转换成了可观察的写作行为。

输出较短时，先定义什么不能丢

如果任务需要短答案，应该明确哪些信息必须保留，哪些细节可以删除：

先给结论。包含支撑结论所需的证据、重要限定条件和下一步行动。
优先删除次要细节和重复内容。

保留所有必要事实、决定、限定条件和后续步骤。
先删掉开场白、重复说明、泛泛的安慰和可选背景。

这样，模型就知道“简洁”不是无差别删字，而是先保护完成任务所必需的信息。

对于编辑、改写、摘要和面向客户的草稿，还应该明确要求模型保留什么：

优先保留用户要求的产物、长度、结构、体裁和事实主张。
在不添加新主张、新章节或更强营销语气的前提下，改善清晰度、流畅度和正确性。

🛡️ 明确自主权和审批边界

GPT-5.6 在执行多步骤任务时可以更主动、更持久。因此，Prompt 必须定义每类请求授权了什么，让模型可以继续完成安全且范围内的工作，同时在外部写入、破坏性操作、付费或扩大范围之前停下来。

OpenAI 给出的紧凑政策示例是：

对于回答、解释、审查、诊断或规划请求，检查相关材料并报告结果。
除非请求同时要求实施，否则不要执行修改。

对于修改、构建或修复请求，直接完成请求范围内的本地修改，
并运行相关的非破坏性验证，不要事先询问。

对于外部写入、破坏性操作、购买行为或范围发生实质性扩大，必须先确认。

这里有一个很重要的区别：

• 读取文件、查看日志、编辑范围内代码、运行测试，通常可以定义为安全的本地操作；
• 发邮件、提交生产配置、删除数据、购买服务或扩大任务范围，则需要确认。

不要把“任何修改都要先问我”写成一条总规则，否则模型可能连运行测试、修复当前文件中的拼写错误都要反复请求批准。

对于长时间运行的工作，还要明确当前处于哪一层：

• 研究；
• 设计；
• 实施；
• 审查；
• 外部协调。

这样可以避免模型在没有明确授权的情况下，从研究阶段悄悄跳到外部执行阶段。

🔧 工具路由：工具越多，不一定越强

只暴露与任务有关的工具。工具描述应该说清楚四件事：

• 工具能做什么；
• 什么时候使用；
• 重要返回字段是什么；
• 发生错误时会怎样。

如果正确性依赖前置检索或发现步骤，应该明确写出来：

在采取行动之前，先完成所需的发现、检索和验证步骤。
不要因为最终状态看起来很明显，就跳过前置条件。

当多个读取操作彼此独立时，可以并行执行；当一个结果会决定下一步动作时，应保持顺序执行。并行检索完成后，要先综合结果，再采取行动。

如果工具返回空结果、部分结果或可疑的狭窄结果，不要立刻得出“没有结果”的结论。可以尝试一到两种有意义的备选方式，再判断是否真的不存在。

⚙️ Programmatic Tool Calling：适合做确定性的数据处理

程序化工具调用（Programmatic Tool Calling，简称 PTC）适合有边界的工作流：让代码处理多次工具返回的大量中间结果，再返回一个更小、更结构化的结果。

适合使用 PTC 的场景包括：

• 过滤、连接、排序、排名、去重和聚合；
• 对很多相似记录进行批处理；
• 重复性的确定性验证；
• 把大型结构化结果压缩成紧凑 Schema。

但“有多个调用”“调用可以并行”本身，并不足以证明应该使用 PTC。

以下情况更适合直接调用工具：

• 一个调用就够了；
• 中间结果本来就很小；
• 每个结果都可能改变下一步决策；
• 操作需要审批；
• 最终答案必须保留原生引用或完整产物；
• 调用之间需要语义判断。

不要只写一句“高效使用 PTC”。应该明确它的边界、可用工具、输出 Schema、重试上限、停止条件，以及什么时候把控制权交还给模型。

只在有限的记录压缩阶段使用 Programmatic Tool Calling。
只调用文档中列出的只读工具。过滤和去重中间结果，
然后严格输出带有 evidence 字段的指定紧凑 Schema。
瞬时失败最多重试两次。审批、语义判断、引用和最终验证使用直接工具调用。

如果同一工作流同时使用两种路径，要定义清晰的交接点，并告诉模型不要切换路线或重复已经完成的工作。

还要分别测试 program_output 和最终的 assistant message。理论上，程序可能返回了正确记录，但最终消息漏掉了必需字段、引用或限定条件。

评测时，不要只比较 Token 数量。应该在相同代表性任务上比较：

• 正确性；
• 完整性；
• 证据是否充分；
• 总 Token；
• 延迟；
• 成本；
• 调用次数；
• 对话轮数；
• 重试次数。

资源使用降低，只有在答案仍然通过现有评测时，才算真正的改进。

🔍 Grounding、引用与检索预算

对于需要事实支撑的回答，引用行为应该直接写进 Prompt。要定义：什么需要支持、多少证据才够，以及证据缺失时应该怎么做。

一个非常关键的原则是：没有证据，不应自动变成事实上的“没有”。

官方建议的普通问答检索策略是：

对于普通问答，先用简短且有区分度的关键词进行一次宽泛搜索。
如果顶部结果已经足以支持核心请求，就根据这些结果回答。

只有在以下情况才进行下一次检索：缺少必要事实、负责人、日期、ID 或来源；
用户要求穷尽覆盖或比较；必须阅读某个具体材料；
或者重要主张否则无法得到支持。

不要只是为了改善措辞、增加例子或支持非必要细节而再次搜索。

对于研究和综合任务：

• 只引用实际检索到的来源；
• 把引用贴在它支持的具体主张旁边；
• 将推断与直接支持的事实分开标注；
• 说明不同来源之间的冲突；
• 如果证据不够，就缩小回答范围或报告缺失证据，不要猜。

对于创意写作，也要区分“来源支持的事实”和“创意表达”。不要为了让草稿更有说服力而虚构姓名、指标、日期、路线图状态、客户结果或产品能力。

🔄 长流程、状态与上下文压缩

对于多步骤或工具密集型任务，Prompt 可以要求模型在第一次调用工具前给出一段简短可见的前言，然后只在重要阶段变化时更新。

不要让模型为每次常规工具调用都写一段过程旁白。

在多步骤任务第一次调用工具前，用一到两句话向用户说明第一步。
任务进行中，只在主要阶段开始或发现改变计划时更新。
每次更新只说一个具体结果和下一步。

如果你重放历史消息，要保留 assistant 的 phase 值，让模型能够区分 commentary 和最终回答。使用 previous_response_id 时，之前的 assistant 状态会自动保留；如果手动重放历史，就要原样保留每条消息的 phase。

不要每轮都压缩上下文，应该在重要里程碑之后压缩。压缩后，Prompt 的功能应保持一致，把已经压缩的内容当作不透明状态，而不是重新解释或随意改写。

持久化推理在目标、假设和优先级保持稳定时很有用。但不要把它当作永远开启的优化：过时的推理会增加 Token、延迟，并让模型被旧思路锚定。

Prompt Caching 也会影响 Prompt 结构。可复用的前缀要保持稳定，避免频繁修改大型系统 Prompt。只有在测量结果表明能改善缓存命中率和成本时，才使用明确的缓存断点。

🧠 Reasoning effort：先建立基线，再提高强度

不要一上来就把推理强度调到最高。

官方建议：

• 保留现有 GPT-5.5 或 GPT-5.4 的 reasoning effort，作为基线；
• 在代表性任务上测试相同设置，以及低一级设置；
• 延迟敏感的任务，如果低强度仍能保住质量，就使用低强度；
• medium 可以作为平衡起点；
• 只有评测显示有明显收益时，才使用 high 或 xhigh；
• max 留给最难、最重质量的工作，不要全局推荐。

在提高推理强度前，先检查 Prompt 是否缺少：

• 成功标准；
• 依赖规则；
• 工具路由规则；
• 验证闭环。

很多所谓“模型推理不够”，根本原因并不是推理预算太低，而是模型不知道什么叫完成、哪些证据必须拿到、什么时候应该停。

🎨 前端与视觉任务：更强的审美，不等于可以自由发挥

GPT-5.6 在布局、视觉层级和设计判断方面更强，但仍然需要产品上下文。你应该说明现有设计系统、重要状态和约束。

对于渐进式前端修改：

• 检查并保留现有设计 Token、组件和模式；
• 不要擅自增加额外功能或装饰性 UI；
• 保持响应式行为和已有状态；
• 在最终确定前渲染并检查结果。

对于视觉、电脑使用、本地化或 OCR 等空间精度重要的任务，要有意识地选择图片细节等级。面对大图、密集信息或坐标敏感任务时，可以使用原始细节，但要权衡额外输入成本与延迟。

换句话说，GPT-5.6 的视觉能力增强，不意味着 Prompt 可以少写产品背景；恰恰相反，越是需要它做设计判断，越要告诉它哪些部分是既有系统、哪些部分不能碰。

✅ 完成前必须检查工作

要给 GPT-5.6 提供可以验证输出的工具，并明确告诉它验证什么。

对于代码任务，官方建议使用类似这样的验证规则：

完成修改后，运行最相关的可用验证：
- 针对修改行为的测试
- 适用时运行类型检查或 lint
- 检查受影响包的构建
- 如果完整验证成本过高，至少运行最小冒烟测试

如果无法运行验证，说明原因，并描述下一项最佳检查。

对于视觉产物：

在最终确定前渲染产物。
检查布局、裁切、间距、缺失内容和视觉一致性。
持续修改，直到渲染结果符合要求。

对于实施计划，至少应包含：

• 需求；
• 指定资源或文件；
• 状态转换或数据流；
• 验证检查；
• 失败处理；
• 隐私和安全注意事项；
• 会实质性影响实施的开放问题。

这部分的核心不是“让模型多说一点”，而是把“完成”从一句主观判断，变成可以观察和复现的验证动作。

🧱 一套推荐的复杂 Prompt 结构

OpenAI 给出了一份可以作为起点的模板。每个部分都应该保持简短，只在会改变行为的地方增加细节：

Role: [模型的职能和上下文]

Personality: [语气和协作风格]

Goal: [用户可见的结果]

Success criteria: [最终回答前必须满足什么]

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

Tools: [使用哪些工具、什么时候使用、哪些不要使用]

Output: [章节、长度、格式和语气]

Stop rules: [什么时候重试、回退、拒答、提问或停止]

这个结构的好处，是把常常混在一起的内容拆开：角色不是目标，目标不是工具，工具不是成功标准，成功标准也不等于停止条件。

🛠️ GPT-5.6 迁移工作流：小步改，不要一次重写

把现有应用迁移到 GPT-5.6 时，官方建议按以下顺序：

1. 切换模型，同时保留当前的 reasoning effort；
2. 在修改 Prompt 之前，先运行代表性评测；
3. 删除过时的脚手架、重复指令和无关工具；
4. 只有在评测发现具体回归时，才添加最小的针对性指令；
5. 每次修改 Prompt 或推理设置后，都重新运行评测。

不要一次性重写一套本来能够工作的 Prompt Stack。否则当行为发生变化时，你无法判断到底是模型、推理设置、Prompt、工具集合还是运行时环境导致的。

当某个 Prompt 出现回归时，用一小组真实 Trace 调试：

• 找到具体失败模式；
• 判断可能触发问题的指令或矛盾；
• 做一次手术式修改；
• 用同一批案例重新运行。

🔬 这份指南真正改变了什么

表面上，这是一份 GPT-5.6 的 Prompt 调优手册；更深一层，它提出的是一种 Agent 系统设计哲学：

1. 从流程控制转向结果控制

弱模型需要你告诉它每一步怎么走。更强的模型可以自己选择路径，你应该把 Prompt 的重点放在目标、约束、证据和完成标准上。

2. 从“增加指令”转向“减少冲突”

Prompt 不是越长越专业。重复、模糊和相互矛盾的规则，会让模型在多个局部目标之间摇摆。

3. 从“多调用工具”转向“合理分配检索预算”

检索不是越多越好。一次检索已经支持核心请求时，继续搜索往往只是在增加延迟和成本；但缺少关键事实时，又不能为了省调用而强行回答。

4. 从“提高推理等级”转向“补足验证闭环”

在调高 reasoning effort 之前，先检查是否定义了成功标准、依赖条件、路由和验证动作。更多推理时间不能补救一个没有完成定义的任务。

5. 从“自动执行”转向“边界清楚的自主性”

好的 Agent 不是每一步都询问，也不是未经许可地做所有事情，而是在安全范围内主动推进，在外部写入、破坏性操作、购买和范围扩大之前停下来。

📌 给开发者的最终清单

如果你今天要把一个现有 Prompt 迁移到 GPT-5.6，可以先检查这 10 项：

• 是否删掉了重复规则？
• 是否定义了用户最终想要的结果？
• 是否写清楚成功标准？
• 是否写清楚什么时候停止？
• 是否只把真正不可违反的规则写成 must 或 never？
• 是否区分了安全本地操作和需要审批的外部操作？
• 是否只暴露了任务需要的工具？
• 是否定义了证据、引用和缺失信息的处理方式？
• 是否在提高 reasoning effort 前建立了基线？
• 是否给模型提供了真实的验证闭环？

如果答案大部分是否定的，继续堆 Prompt 可能不是正确方向。先删掉噪声，补上完成标准，再用代表性任务评测。

GPT-5.6 的提示词工程，最终不是一场“谁能写出最长系统 Prompt”的比赛，而是一次系统设计：你能否把目标、边界、证据、工具和验证组织成一份清晰的工作契约。

🦞 龙虾之心 | OpenClaw Heart | AI 智能体成长伙伴