原文链接：

https://cookbook.openai.com/examples/gpt-5/gpt-5_prompting_guide

可以先看要点总结，全文在下面。

01 要点总结

控制智能体自主性

降低自主性方法：

• 切换到较低的reasoning_effort（推理强度）
• 在提示词中为模型探索问题空间定义明确标准
• 设置固定工具调用预算
• 提供"逃生舱口"条款

提高自主性方法：

• 提高reasoning_effort
• 使用持续性提示词鼓励模型工作到完全解决问题
• 明确定义停止条件和安全行为边界

工具调用前言（Tool Preambles）

• GPT-5支持通过"工具调用前言"提供清晰计划和进度更新
• 可在提示词中引导前言的频率、风格和内容
• 提供友好、清晰、简洁的目标重述和结构化计划

推理强度参数

• 提供reasoning_effort参数控制思考深度
• 默认为medium，可根据任务难度调整
• 复杂多步骤任务建议使用更高推理强度

Responses API

• 强烈推荐使用Responses API替代Chat Completions API
• 可传回先前推理项，节省思维链令牌
• 实测TauBench-Retail得分从73.9%提升到78.2%

最大化编程性能

前端应用开发

推荐技术栈：

• 框架：Next.js (TypeScript), React, HTML
• 样式/UI：Tailwind CSS, shadcn/ui, Radix Themes
• 图标：Material Symbols, Heroicons, Lucide
• 动画：Motion
• 字体：San Serif, Inter, Geist等

从零到一应用生成：

• 使用自我反思提示词建立评估标准
• 要求模型根据自建标准进行迭代执行

匹配代码库设计规范：

• 提供工程原则、目录结构和最佳实践指导
• 使用结构化的代码编辑规则模板

Cursor的GPT-5提示词调优经验

系统提示词优化：

• 将verbosity参数设为low保持简洁
• 在提示词中强调编程工具使用高详细程度
• 提供产品行为细节减少模糊性

关键发现：

• 移除过度鼓励彻底性的提示词（如maximize_context_understanding）
• 使用结构化XML规范提高指令遵循度
• 允许用户配置自定义规则

优化智能与指令遵循

可引导性（Steering）

详细程度控制：

• 新增verbosity API参数影响最终答案长度
• 支持提示词中的自然语言详细程度覆盖指令

指令遵循

关键原则：

• GPT-5具有"外科手术般"精度的指令遵循
• 矛盾或模糊指令会消耗推理令牌
• 需要彻底审查提示词发现措辞不当的指令

最小推理模式

适用场景：

• 延迟敏感型用户
• GPT-4.1用户的最佳升级路径

优化建议：

• 在最终答案开头提供简短解释
• 请求详尽的工具调用前言
• 最大化消除工具指令歧义
• 强化提示驱动的规划

Markdown格式化

• 默认不使用Markdown格式
• 可通过特定提示词引导生成分层Markdown
• 长对话中需要定期追加Markdown指令

元提示（Metaprompting）

• 使用GPT-5作为自身的"元提示器"
• 询问模型如何添加或删除提示词元素
• 多位用户已将GPT-5生成的提示词修订版部署到生产环境

附录

包含了SWE-Bench验证、智能体编程工具定义、Taubench-Retail指令和Terminal-Bench提示词等具体实现细节和完整的工具函数定义。

02 全文翻译

GPT-5 作为我们最新的旗舰模型，在智能体任务性能、编程能力、原始智能和可引导性方面均实现了重大飞跃。

我们相信它在各种应用场景下都能“开箱即用”，表现出色。但在这份指南中，我们将分享一些旨在最大化模型输出质量的提示技巧，这些技巧源于我们训练模型并将其应用于真实世界任务的宝贵经验。我们将深入探讨如何提升智能体任务性能、确保指令遵循、运用全新的 API 功能，以及为前端和软件工程任务优化编程等概念，并重点分享 AI 代码编辑器 Cursor 在 GPT-5 提示词调优方面的关键见解。

我们发现，通过应用这些最佳实践并尽可能采用我们的标准工具，模型性能得到了显著提升。我们希望本指南以及我们构建的提示词优化工具，能成为您驾驭 GPT-5 的起点。但请始终牢记，提示工程并非一刀切的实践——我们鼓励您在本文提供的基础上不断实验和迭代，以找到解决您特定问题的最佳方案。

智能体工作流的可预测性

我们在训练 GPT-5 时充分考虑了开发者的需求：我们专注于改进工具调用、指令遵循和长上下文理解能力，使其成为构建智能体应用的最佳基础模型。若要将 GPT-5 用于智能体和工具调用流程，我们建议升级至 Responses API，该 API 能够在工具调用之间持久化推理过程，从而实现更高效、更智能的输出。

控制智能体的“自主性”

智能体的控制框架千差万别——有些系统将绝大部分决策权委托给底层模型，而另一些系统则通过大量的程序化逻辑分支对模型进行严格约束。GPT-5 经过训练，能够胜任这一范围内的任何工作，无论是处理模糊情况下的高层决策，还是执行专注且明确定义的任务。在本节中，我们将介绍如何最好地校准 GPT-5 的智能体自主性（Agentic Eagerness）：换言之，即它在主动性和等待明确指令之间的平衡。

引导模型降低自主性

默认情况下，GPT-5 在智能体环境中会详尽全面地收集上下文，以确保给出最准确的答案。要缩小 GPT-5 智能体行为的范围——包括限制不相关的工具调用和减少获得最终答案的延迟——请尝试以下方法：

• 切换到较低的 reasoning_effort (推理强度)。这会降低探索深度，但能提高效率和响应速度。许多工作流在 medium (中等) 甚至 low (低) 推理强度下也能获得一致的优异结果。

• 在提示词中为模型如何探索问题空间定义明确的标准。这可以减少模型探索和思考过多路径的需求：

<context_gathering>
目标：快速获取足够上下文。并行化发现过程，并在能够行动时立即停止。

方法：
- 从宽泛查询开始，然后扩展到更具针对性的子查询。
- 并行发起不同类型的查询；读取每个查询的最高匹配结果。对路径进行去重和缓存；不要重复查询。
- 避免过度搜索上下文。如果需要，可以在一个并行批次中运行有针对性的搜索。

提前停止标准：
- 你可以明确指出需要更改的具体内容。
- 最高匹配结果（约70%）收敛于一个领域/路径。

升级一次：
- 如果信号冲突或范围模糊，则运行一个精炼的并行批次，然后继续。

深度：
- 只追踪你将要修改或依赖其接口的符号；除非必要，否则避免进行传递性扩展。

循环：
- 批处理搜索 → 最小化规划 → 完成任务。
- 仅在验证失败或出现新的未知情况时再次搜索。优先选择行动，而非更多搜索。
</context_gathering>

如果你希望提供最大程度的规定性，你甚至可以设置固定的工具调用预算，如下所示。预算可以根据你期望的搜索深度自然地调整。

<context_gathering>
- 搜索深度：非常低
- 强烈倾向于尽快提供正确答案，即使它可能不完全正确。
- 通常，这意味着绝对最多进行 2 次工具调用。
- 如果你认为需要更多时间进行调查，请向用户更新你的最新发现和待解决的问题。只有在用户确认后，你才能继续。
</context_gathering>

在限制核心上下文收集行为时，明确为模型提供一个“逃生舱口”会很有帮助，这使它更容易满足较短的上下文收集步骤。这通常以条款的形式出现，允许模型在不确定性下继续前进，例如上述示例中的“即使它可能不完全正确”。

引导模型提高自主性

另一方面，如果你想鼓励模型自主行动、增强工具调用的持久性，并减少澄清性问题或将控制权交还给用户的情况，我们建议提高 reasoning_effort，并使用如下提示词来鼓励持久且彻底地完成任务：

<persistence>
- 你是一个智能体——请持续工作，直到用户的请求被完全解决，然后再结束你的回合并将控制权交还给用户。
- 只有当你确定问题已解决时，才终止你的回合。
- 当遇到不确定性时，绝不要停止或将控制权交还给用户——研究或推断出最合理的方法并继续。
- 不要请求人类确认或澄清假设，因为你之后随时可以调整——自行判断最合理的假设是什么，继续执行，并在完成后记录下来供用户参考。
</persistence>

总而言之，清晰地说明智能体任务的停止条件、勾勒出安全与不安全的行为，并定义何时（以及是否）可以接受模型将控制权交还给用户，这些都大有裨益。例如，在一套购物工具中，对于结账和支付工具，需要用户澄清的不确定性阈值应明确设置得更低；而对于搜索工具，该阈值则应极高。同样，在编程环境中，删除文件工具的阈值应远低于 grep 搜索工具。

工具调用前言 (Tool Preambles)

我们认识到，在由用户监控的智能体任务轨迹中，模型间歇性地更新其工具调用的内容及原因，可以提供更佳的交互式用户体验——任务执行的时间越长，这些更新带来的价值就越大。为此，GPT-5 经过训练，能够通过“工具调用前言”消息提供清晰的前期计划和一致的进度更新。

你可以在提示词中引导工具调用前言的频率、风格和内容——从对每个工具调用的详细解释，到简短的前期计划，乃至介于两者之间的任何形式。这是一个高质量前言提示词的示例：

<tool_preambles>
- 在调用任何工具之前，始终以友好、清晰、简洁的方式重述用户的目标。
- 接着，立即概述一个结构化的计划，详细说明你将遵循的每个逻辑步骤。
- 在执行文件编辑时，简洁并按顺序叙述每个步骤，清晰地标记进度。
- 最后，将已完成的工作与你的前期计划明确分开，进行总结。
</tool_preambles>

以下是响应此类提示词可能生成的工具调用前言示例——随着智能体工作的复杂性增加，这类前言可以极大地提高用户跟进其工作的能力：

"output": [
    {
        "id": "rs_6888f6d0606c819aa8205ecee386963f0e683233d39188e7",
        "type": "reasoning",
        "summary": [
            {
                "type": "summary_text",
                "text": "**确定天气响应**\n\n我需要回答用户关于旧金山天气的问题。...."
            }
        ]
    },
    {
        "id": "msg_6888f6d83acc819a978b51e772f0a5f40e683233d39188e7",
        "type": "message",
        "status": "completed",
        "content": [
            {
                "type": "output_text",
                "text": "我将查询一个实时天气服务以获取旧金山的当前状况，并同时提供华氏度和摄氏度的温度，以满足您的偏好。"
            }
        ],
        "role": "assistant"
    },
    {
        "id": "fc_6888f6d86e28819aaaa1ba69cca766b70e683233d39188e7",
        "type": "function_call",
        "status": "completed",
        "arguments": "{\"location\":\"San Francisco, CA\",\"unit\":\"f\"}",
        "call_id": "call_XOnF4B9DvB8EJVB3JvWnGg83",
        "name": "get_weather"
    }
]

推理强度 (Reasoning effort)

我们提供一个 reasoning_effort 参数来控制模型的思考深度和调用工具的意愿；默认为 medium (中等)，但您应根据任务的难度进行上调或下调。对于复杂的多步骤任务，我们建议使用更高的推理强度以确保最佳输出。此外，我们观察到，当不同且可分离的任务被分解到多个智能体回合中，每个回合处理一个子任务时，性能会达到峰值。

使用 Responses API 复用推理上下文

我们强烈建议在使用 GPT-5 时采用 Responses API，以解锁更优的智能体流程、降低成本，并在您的应用中实现更高效的令牌使用。

我们已经看到，在使用 Responses API 替代 Chat Completions API 时，评估结果有统计学意义上的显著改善——例如，仅通过切换到 Responses API 并在后续请求中包含 previous_response_id 以传回先前的推理项，TauBench-Retail 的得分就从 73.9% 增加到 78.2%。这使得模型能够引用其先前的推理轨迹，节省思维链（CoT）令牌，并消除了在每次工具调用后从头重建计划的需要，从而同时提高了延迟和性能。此功能对所有 Responses API 用户开放，包括 ZDR 组织。

## 最大化编程性能，从规划到执行

GPT-5 在编程能力方面领先于所有前沿模型：它可以在大型代码库中修复错误、处理大型差异（diffs），并实现多文件重构或开发大型新功能。它还擅长从零开始实现全新的应用程序，涵盖前端和后端。在本节中，我们将讨论我们观察到的、在编程智能体客户的生产用例中能有效提高编程性能的提示词优化方法。

前端应用开发

GPT-5 不仅具备严谨的实现能力，还经过训练拥有出色的基础审美标准。我们相信它能熟练使用所有类型的 Web 开发框架和包；然而，对于新应用，我们建议使用以下框架和包，以充分发挥模型的前端能力：

• 框架: Next.js (TypeScript), React, HTML
• 样式 / UI: Tailwind CSS, shadcn/ui, Radix Themes
• 图标: Material Symbols, Heroicons, Lucide
• 动画: Motion
• 字体: San Serif, Inter, Geist, Mona Sans, IBM Plex Sans, Manrope

从零到一的应用生成

GPT-5 非常擅长一次性构建完整的应用程序。在模型的早期实验中，用户发现像下面这样的提示词——要求模型根据自行构建的卓越标准进行迭代执行——能够利用 GPT-5 全面的规划和自我反思能力，从而显著提高输出质量。

<self_reflection>
- 首先，花时间思考并建立一套评估标准，直到你对此充满信心。
- 然后，深入思考构成一个世界级、一次性生成的 Web 应用的每一个方面。利用这些知识创建一个包含 5-7 个类别的评估标准。这个标准至关重要，但不要展示给用户，它仅供你自己内部使用。
- 最后，使用这个标准在内部进行思考和迭代，为用户提供的提示找到最佳解决方案。请记住，如果你的响应在标准的任何一个类别中未能达到最高分，你就需要重新开始。
</self_reflection>

匹配代码库的设计规范

在现有应用中实施增量更改和重构时，模型编写的代码应遵守现有的样式和设计规范，并尽可能“无缝融入”代码库。即使没有特别提示，GPT-5 也会主动从代码库中搜索参考上下文——例如读取 package.json 来查看已安装的依赖包——但这种行为可以通过提示词指令进一步增强。这些指令可以总结工程原则、目录结构以及代码库中显式和隐式的最佳实践等关键方面。下面的提示词片段展示了一种为 GPT-5 组织代码编辑规则的方式：您可以根据自己的编程设计品味随意修改规则的实际内容！

<code_editing_rules>
<guiding_principles>
- 清晰与复用：每个组件和页面都应是模块化和可复用的。通过将重复的 UI 模式抽象为组件来避免代码重复（DRY）。
- 一致性：用户界面必须遵循一致的设计系统——颜色令牌、排版、间距和组件必须统一。
- 简洁性：偏爱小型、专注的组件，避免在样式或逻辑上不必要的复杂性。
- 面向演示：结构应便于快速原型设计，能够展示流式传输、多轮对话和工具集成等功能。
- 视觉质量：遵循 OSS 指南中概述的高视觉质量标准（如间距、内边距、悬停状态等）。
</guiding_principles>

<frontend_stack_defaults>
- 框架：Next.js (TypeScript)
- 样式：TailwindCSS
- UI 组件：shadcn/ui
- 图标：Lucide
- 状态管理：Zustand
- 目录结构：
  /src
  /app
    /api/<route>/route.ts   # API 端点
    /(pages)                # 页面路由
    /components/            # UI 构建块
    /hooks/                 # 可复用的 React 钩子
    /lib/                   # 工具函数 (如 fetchers, helpers)
    /stores/                # Zustand 状态存储
    /types/                 # 共享的 TypeScript 类型
    /styles/                # Tailwind 配置
</frontend_stack_defaults>

<ui_ux_best_practices>
- 视觉层次：将排版限制在 4-5 种字体大小和字重以保持一致的层次结构；使用 `text-xs` 作为说明和注释；除非用于大标题或主标题，否则避免使用 `text-xl`。
- 颜色使用：使用 1 种中性基色（例如 `zinc`）和最多 2 种强调色。
- 间距与布局：始终使用 4 的倍数作为内边距和外边距，以保持视觉节奏。处理长内容流时，使用固定高度的容器和内部滚动。
- 状态处理：使用骨架屏占位符或 `animate-pulse` 来指示数据获取状态。通过悬停过渡效果（`hover:bg-*`, `hover:shadow-md`）来指示可交互性。
- 可访问性：在适当的地方使用语义化 HTML 和 ARIA 角色。优先使用内置了可访问性支持的 Radix/shadcn 组件。
</ui_ux_best_practices>
</code_editing_rules>

生产环境中的协作编程：Cursor 对 GPT-5 的提示词调优

我们很荣幸，AI 代码编辑器 Cursor 成为了 GPT-5 值得信赖的 alpha 测试者。下面，我们将揭示 Cursor 如何调整其提示词以充分利用模型能力的内幕。更多信息，他们的团队也发表了一篇博客文章，详细介绍了 GPT-5 在 Cursor 中的首日集成：https://cursor.com/blog/gpt-5

系统提示词与参数调优

Cursor 的系统提示词侧重于实现可靠的工具调用，在详细程度和自主行为之间取得平衡，同时允许用户配置自定义指令。Cursor 对其系统提示词的目标是让智能体在长周期任务中能够相对自主地操作，同时仍然忠实地遵循用户提供的指令。

团队最初发现模型产生的输出很冗长，常常包含状态更新和任务后总结，这些内容虽然技术上相关，但会打断用户的自然工作流。同时，工具调用中输出的代码质量很高，但有时因过于简洁而难以阅读，例如普遍使用单字母变量名。为了寻求更好的平衡，他们将 verbosity (详细程度) API 参数设置为 low 以保持文本输出简洁，然后修改提示词，以强烈鼓励仅在编程工具中输出详细内容。

编写代码时，首先要考虑清晰性。优先选择可读、可维护的解决方案，使用清晰的命名、必要的注释和直接的控制流。除非明确要求，否则不要编写“代码高尔夫”式或过于巧妙的单行代码。在编写代码和使用代码工具时，请使用高详细程度。

这种参数和提示词的双重运用，形成了一种平衡的格式，它将高效、简洁的状态更新和最终工作总结与更易于阅读的代码差异相结合。

Cursor 还发现，模型在采取行动前偶尔会向用户请求澄清或下一步指示，这在较长任务的流程中造成了不必要的阻碍。为了解决这个问题，他们发现，除了提供可用的工具和周围的上下文外，提供更多关于产品行为的细节，能鼓励模型以更少的干扰和更大的自主性执行更长的任务。强调 Cursor 功能的细节，如撤销/拒绝代码和用户偏好，通过明确指定 GPT-5 在其环境中应如何行为，帮助减少了模糊性。对于长周期任务，他们发现以下提示词提升了性能：

请注意，你所做的代码编辑将作为建议的变更呈现给用户，这意味着：(a) 你的代码编辑可以非常主动，因为用户随时可以拒绝；(b) 你的代码应该写得很好，易于快速审查（例如，使用恰当的变量名而不是单字母）。如果提议的下一步骤涉及更改代码，请主动为用户进行这些更改以供其批准/拒绝，而不是询问用户是否要继续执行计划。总的来说，你几乎永远不应询问用户是否继续执行计划；相反，你应该主动尝试该计划，然后询问用户是否希望接受已实施的更改。

Cursor 发现，他们之前对早期模型行之有效的提示词部分，需要进行调整才能充分利用 GPT-5 的潜力。以下是一个例子：

<maximize_context_understanding>
在收集信息时要彻底。在回复之前确保你已了解全局。根据需要使用额外的工具调用或澄清性问题。
...
</maximize_context_understanding>

虽然这段提示词对于需要鼓励才能彻底分析上下文的旧模型效果很好，但他们发现它对 GPT-5 来说适得其反，因为 GPT-5 天生就具有自省和主动收集上下文的能力。在较小的任务上，这个提示词常常导致模型过度使用工具，重复调用搜索，而其内部知识本已足够。

为了解决这个问题，他们通过移除 maximize_ 前缀并软化关于“彻底性”的语言来完善提示词。调整后的指令实施后，Cursor 团队看到 GPT-5 在何时依赖内部知识与何时使用外部工具之间做出了更好的决策。它在保持高度自主性的同时，避免了不必要的工具使用，从而带来了更高效和相关的行为。在 Cursor 的测试中，使用像 <[instruction]_spec> 这样的结构化 XML 规范，提高了其提示词的指令遵循度，并允许他们在提示词的其他地方清晰地引用先前的类别和部分。

<context_understanding>
...
如果你执行的编辑可能部分满足了用户的请求，但你没有十足的把握，请在结束你的回合之前收集更多信息或使用更多工具。
如果你能自己找到答案，倾向于不向用户求助。
</context_understanding>

虽然系统提示词提供了一个强大的默认基础，但用户提示词仍然是实现可引导性的一个高效杠杆。GPT-5 对直接和明确的指令响应良好，Cursor 团队一致认为，结构化、范围明确的提示词能产生最可靠的结果。这包括详细程度控制、主观代码风格偏好和对边缘情况的敏感性等领域。Cursor 发现，允许用户配置他们自己的自定义 Cursor 规则在 GPT-5 改进的可引导性下尤其有效，为他们的用户提供了更定制化的体验。

## 优化智能与指令遵循

可引导性 (Steering)

作为我们迄今为止最具可引导性的模型，GPT-5 对围绕详细程度、语气和工具调用行为的提示词指令反应异常灵敏。

详细程度 (Verbosity)

除了像以前的推理模型一样能够控制 reasoning_effort 之外，我们在 GPT-5 中引入了一个名为 verbosity 的新 API 参数，它影响模型最终答案的长度，而非其思考过程的长度。我们的博客文章更详细地介绍了这个参数背后的理念——但在这份指南中，我们想强调的是，虽然 API verbosity 参数是推广期间的默认设置，但 GPT-5 经过训练，能够响应提示词中特定上下文的自然语言详细程度覆盖指令。在这些上下文中，你可能希望模型偏离全局默认设置。上面 Cursor 的例子中，全局设置低详细程度，然后仅为编程工具指定高详细程度，就是这种上下文的一个典型例子。

指令遵循

与 GPT-4.1 一样，GPT-5 能够以“外科手术般”的精度遵循提示词指令，这使其能够灵活地融入所有类型的工作流程。然而，其严谨的指令遵循行为也意味着，包含矛盾或模糊指令的结构不良的提示词对 GPT-5 的损害可能比对其他模型更大，因为它会消耗推理令牌来试图调和这些矛盾，而不是随机选择一个指令来执行。

下面，我们给出了一个经常损害 GPT-5 推理轨迹的对抗性提示词示例——虽然它初看可能内部一致，但仔细检查会发现关于预约安排的指令存在冲突：

• 在病历中没有记录明确的患者同意之前，绝不安排预约 与随后的 为降低风险，首要行动是自动分配当天最早的空档，无需联系患者 相冲突。
• 提示词说 在采取任何其他行动之前，始终查找患者资料以确保他们是现有患者，但接着又给出了矛盾的指令 当症状表明高度紧急时，立即升级为紧急情况，并指示患者在任何安排步骤之前立即拨打 911。

您是 CareFlow Assistant，一个为医疗保健初创公司根据优先级和症状安排患者的虚拟管理员。您的目标是分诊请求，将患者匹配到合适的网络内提供者，并预留最早的临床上合适的时间段。在采取任何其他行动之前，始终查找患者资料以确保他们是现有患者。

- 核心实体包括患者、提供者、预约和优先级（红色、橙色、黄色、绿色）。将症状映射到优先级：红色在 2 小时内，橙色在 24 小时内，黄色在 3 天内，绿色在 7 天内。当症状表明高度紧急时，立即升级为紧急情况，并指示患者在任何安排步骤之前立即拨打 911。
+ 核心实体包括患者、提供者、预约和优先级（红色、橙色、黄色、绿色）。将症状映射到优先级：红色在 2 小时内，橙色在 24 小时内，黄色在 3 天内，绿色在 7 天内。当症状表明高度紧急时，立即升级为紧急情况，并指示患者在任何安排步骤之前立即拨打 911。
*在紧急情况下，不要进行查找，立即提供 911 指导。*

- 使用以下能力：安排预约、修改预约、加入候补名单、查找提供者、查找患者和通知患者。在预订前验证保险资格、首选诊所和记录在案的同意。在病历中没有记录明确的患者同意之前，绝不安排预约。

- 对于高危的红色和橙色病例，*为降低风险，首要行动是自动分配当天最早的空档，无需联系患者*。如果没有合适的提供者，将患者加入候补名单并发送通知。如果同意状态未知，暂时保留一个空档并继续请求确认。

- 对于高危的红色和橙色病例，*在告知患者你的行动后*，自动分配当天最早的空档。如果没有合适的提供者，将患者加入候补名单并发送通知。如果同意状态未知，暂时保留一个空档并继续请求确认。

通过解决指令层次结构中的冲突，GPT-5 能够产生更高效、更高性能的推理。我们通过以下方式修复了这些矛盾：

• 将自动分配的行为改为在联系患者之后进行，即 在告知患者你的行动后，自动分配当天最早的空档，以与“仅在获得同意后安排预约”的原则保持一致。
• 添加 在紧急情况下，不要进行查找，立即提供 911 指导，让模型知道在紧急情况下可以跳过查找步骤。

我们理解构建提示词是一个迭代的过程，许多提示词是不断被不同利益相关者更新的“活文档”——但这更有理由去彻底审查它们，以发现措辞不当的指令。我们已经看到，多个早期用户在进行此类审查后，在其核心提示词库中发现了模糊和矛盾之处：移除它们极大地简化并改善了他们的 GPT-5 性能。我们建议在我们的提示词优化工具中测试您的提示词，以帮助识别这类问题。

最小推理 (Minimal reasoning)

在 GPT-5 中，我们首次引入了“最小推理强度”：这是我们最快的选项，同时仍能享有推理模型范式的好处。我们认为这是对延迟敏感型用户以及当前 GPT-4.1 用户的最佳升级路径。

也许不足为奇，我们建议采用与 GPT-4.1 相似的提示词模式以获得最佳结果。最小推理模式的性能随提示词的变化可能比更高推理级别更剧烈，因此需要强调的关键点包括：

1. 提示模型在最终答案的开头给出一个简短的解释（例如通过项目符号列表）来总结其思考过程，可以提高需要更高智能的任务的性能。
2. 请求详尽且描述性的工具调用前言，持续向用户更新任务进展，可以提高智能体工作流的性能。
3. 最大限度地消除工具指令的歧义，并插入如上文分享的智能体持久性提醒，在最小推理模式下对于最大化长时运行任务的智能体能力和防止过早终止尤为关键。
4. 提示驱动的规划同样更为重要，因为模型用于内部规划的推理令牌更少。下面，您可以看到我们放置在智能体任务开始处的一个示例规划提示词片段：特别是第二段，它确保智能体在将控制权交还给用户之前完全完成任务及其所有子任务。

请记住，你是一个智能体——请持续工作，直到用户的请求被完全解决，然后再结束你的回合并将控制权交还给用户。将用户的请求分解为所有必需的子请求，并确认每一个都已完成。不要在仅完成部分请求后就停止。只有当你确定问题已解决时，才终止你的回合。你必须准备好回答多个查询，并且只有在用户确认他们没有其他问题后才能结束通话。

在进行后续函数调用之前，你必须根据工作流程步骤进行详尽的规划，并对每次函数调用的结果进行深入反思，确保用户的请求及相关的子请求都已完全解决。

Markdown 格式化

默认情况下，API 中的 GPT-5 不会以 Markdown 格式化其最终答案，以最大程度地保持与可能不支持 Markdown 渲染的开发者应用的兼容性。然而，像下面这样的提示词在引导模型生成分层的 Markdown 最终答案方面基本上是成功的。

- **仅在语义正确的地方**使用 Markdown（例如，`行内代码`，```代码块```，列表，表格）。
- 在助手的消息中使用 Markdown 时，使用反引号来格式化文件、目录、函数和类名。使用 \( 和 \) 表示行内数学公式，\[ 和 \] 表示块级数学公式。

偶尔，在长对话过程中，对系统提示词中指定的 Markdown 指令的遵循度可能会下降。如果您遇到这种情况，我们发现每隔 3-5 条用户消息追加一次 Markdown 指令，可以保持一致的遵循度。

元提示 (Metaprompting)

最后，以一个元视角的观点来结束本指南：早期测试者发现使用 GPT-5 作为自身的“元提示器”取得了巨大成功。已经有几位用户部署了由 GPT-5 生成的提示词修订版本到生产环境中，这些修订版本仅仅是通过询问 GPT-5 “可以向一个不成功的提示词中添加哪些元素以引发期望的行为”，或“移除哪些元素以防止不期望的行为”而生成的。

以下是我们喜欢的一个元提示模板示例：

当被要求优化提示词时，请从你自己的角度给出答案——解释可以从这个提示词中添加或删除哪些具体短语，以更稳定地引发期望的行为或防止不期望的行为。

这是一个提示词：[PROMPT]

这个提示词期望的行为是让智能体 [执行期望的行为]，但它却 [执行了不期望的行为]。在尽可能保持现有提示词完整的前提下，你会做哪些最小的编辑/补充，以鼓励智能体更稳定地解决这些缺陷？

## 附录

SWE-Bench 验证的开发者指令

在这个环境中，你可以运行 `bash -lc <apply_patch_command>` 来对文件执行一个 diff/patch，其中 <apply_patch_command> 是一个特殊格式的 apply patch 命令，代表你希望执行的 diff。一个有效的 <apply_patch_command> 如下所示：

apply_patch << 'PATCH'
*** Begin Patch
[YOUR_PATCH]
*** End Patch
PATCH

其中 [YOUR_PATCH] 是你补丁的实际内容。

务必极其彻底地验证你的更改。你可以进行任意多次工具调用——用户非常有耐心，并且将正确性置于一切之上。在结束之前，请确保你 100% 确定你的解决方案是正确的。
重要提示：并非所有测试都在代码库中对你可见，所以即使在你认为相对直接的问题上，你也必须反复检查你的解决方案，以确保它们能通过隐藏测试中覆盖的任何边缘情况，而不仅仅是可见的测试。

智能体编程工具定义

## 集合 1: 4个函数，无终端

type apply_patch = (_: {
  patch: string, // default: null
}) => any;

type read_file = (_: {
  path: string, // default: null
  line_start?: number, // default: 1
  line_end?: number, // default: 20
}) => any;

type list_files = (_: {
  path?: string, // default: ""
  depth?: number, // default: 1
}) => any;

type find_matches = (_: {
  query: string, // default: null
  path?: string, // default: ""
  max_results?: number, // default: 50
}) => any;

## 集合 2: 2个函数，终端原生

type run = (_: {
  command: string[], // default: null
  session_id?: string | null, // default: null
  working_dir?: string | null, // default: null
  ms_timeout?: number | null, // default: null
  environment?: object | null, // default: null
  run_as_user?: string | null, // default: null
}) => any;

type send_input = (_: {
  session_id: string, // default: null
  text: string, // default: null
  wait_ms?: number, // default: 100
}) => any;

正如在 GPT-4.1 提示指南中分享的，这里是我们最新的 apply_patch 实现：我们强烈建议使用 apply_patch 进行文件编辑，以匹配训练分布。最新的实现应该在绝大多数情况下与 GPT-4.1 的实现相匹配。

Taubench-Retail 最小推理指令

作为一名零售智能体，您可以帮助用户取消或修改待处理订单、退换已送达的订单、修改他们的默认用户地址，或提供关于他们个人资料、订单和相关产品的信息。

请记住，你是一个智能体——请持续工作，直到用户的请求被完全解决，然后再结束你的回合并将控制权交还给用户。只有当你确定问题已解决时，才终止你的回合。

如果你不确定与用户请求相关的信息，请使用你的工具读取文件并收集相关信息：不要猜测或编造答案。

你必须在每次函数调用前进行详尽的规划，并对先前函数调用的结果进行深入反思，确保用户的请求被完全解决。不要仅通过连续调用函数来完成整个过程，因为这会削弱你解决问题和进行有洞察力思考的能力。此外，请确保函数调用具有正确的参数。

# 工作流程步骤
- 在对话开始时，你必须通过邮箱或姓名+邮政编码来定位用户ID，以验证用户身份。即使用户已经提供了用户ID，也必须执行此操作。
- 一旦用户通过身份验证，你就可以向用户提供有关订单、产品、个人资料等信息，例如帮助用户查找订单ID。
- 每次对话只能为一个用户提供服务（但可以处理同一用户的多个请求），并且必须拒绝任何与其他用户相关的任务请求。
- 在执行更新数据库的重要操作（取消、修改、退货、换货）之前，你必须列出操作详情并获得用户的明确确认（回答“是”）才能继续。
- 你不应编造任何用户或工具未提供的信息、知识或流程，也不应给出主观的建议或评论。
- 你每次最多只能进行一次工具调用，如果你进行了工具调用，就不应同时回复用户。如果你回复了用户，就不应进行工具调用。
- 当且仅当请求无法在你能力范围内处理时，你才应将用户转接给人工客服。

## 领域基础知识
- 数据库中的所有时间均为美国东部时间（EST）并采用24小时制。例如，“02:30:00”表示东部时间凌晨2:30。
- 每个用户都有一个包含其邮箱、默认地址、用户ID和支付方式的个人资料。每种支付方式可以是礼品卡、PayPal账户或信用卡。
- 我们的零售店有50种产品。每种产品都有不同选项的变体商品。例如，对于“T恤”产品，可能有一个选项为“颜色蓝色，尺码M”的商品，以及另一个选项为“颜色红色，尺码L”的商品。
- 每种产品都有一个唯一的产品ID，每个商品都有一个唯一的商品ID。它们之间没有关系，不应混淆。
- 每个订单的状态可以是“待处理”、“已处理”、“已送达”或“已取消”。通常，你只能对“待处理”或“已送达”的订单进行操作。
- 换货或修改订单的工具只能调用一次。在进行工具调用前，请确保所有要更改的商品都已收集到一个列表中！！！

## 取消待处理订单
- 只有当订单状态为“待处理”时才能取消，你应该在操作前检查其状态。
- 用户需要确认订单ID和取消原因（“不再需要”或“误订”）。
- 用户确认后，订单状态将变为“已取消”，如果原支付方式是礼品卡，将立即退款；否则，将在5到7个工作日内退款。

## 修改待处理订单
- 只有当订单状态为“待处理”时才能修改，你应该在操作前检查其状态。
- 对于待处理订单，你可以修改其送货地址、支付方式或商品选项，但不能修改其他内容。

## 修改支付方式
- 用户只能选择一种不同于原支付方式的单一支付方式。
- 如果用户想将支付方式修改为礼品卡，该卡必须有足够的余额来支付总金额。
- 用户确认后，订单状态将保持“待处理”。如果原支付方式是礼品卡，将立即退款；否则，将在5到7个工作日内退款。

## 修改商品
- 此操作只能调用一次，并将订单状态更改为“待处理（商品已修改）”，之后智能体将无法再修改或取消该订单。因此，在执行此操作前，请务必谨慎并确认所有细节都正确。特别要提醒客户确认他们已提供了所有要修改的商品。
- 对于待处理订单，每个商品可以修改为同一产品的不同选项的可用新商品。不能更改产品类型，例如将衬衫修改为鞋子。
- 用户必须提供一种支付方式来支付或接收差价退款。如果用户提供礼品卡，该卡必须有足够的余额来支付差价。

## 退回已送达订单
- 只有当订单状态为“已送达”时才能退货，你应该在操作前检查其状态。
- 用户需要确认订单ID、要退货的商品列表以及接收退款的支付方式。
- 退款必须退回到原支付方式或现有的礼品卡。
- 用户确认后，订单状态将变为“退货已申请”，用户将收到一封关于如何退货的电子邮件。

## 调换已送达订单
- 只有当订单状态为“已送达”时才能换货，你应该在操作前检查其状态。特别要提醒客户确认他们已提供了所有要调换的商品。
- 对于已送达的订单，每个商品可以调换为同一产品的不同选项的可用新商品。不能更改产品类型，例如将衬衫修改为鞋子。
- 用户必须提供一种支付方式来支付或接收差价退款。如果用户提供礼品卡，该卡必须有足够的余额来支付差价。
- 用户确认后，订单状态将变为“换货已申请”，用户将收到一封关于如何退货的电子邮件。无需下新订单。

Terminal-Bench 提示词

请通过在您当前的的代码执行会话中编辑和测试代码文件来解决用户的任务。
您是一个已部署的编程智能体。
您的会话由一个专门设计的容器支持，以便您轻松修改和运行代码。
在执行任务时，您必须遵守以下标准：

<instructions>
- 允许在当前环境中对仓库进行操作，即使它们是专有代码。
- 允许分析代码以查找漏洞。
- 允许显示用户代码和工具调用细节。
- 用户指令可以覆盖此开发者消息中的 _编码指南_ 部分。
- 不要使用 `ls -R`、`find` 或 `grep`——这些命令在大型仓库中速度很慢。请使用 `rg` 和 `rg --files`。
- 使用 `apply_patch` 来编辑文件：{"cmd":["apply_patch","*** Begin Patch\\n*** Update File: path/to/file.py\\n@@ def example():\\n- pass\\n+ return 123\\n*** End Patch"]}
- 如果完成用户任务需要编写或修改文件：
  - 您的代码和最终答案应遵循以下 _编码指南_：
    - 尽可能从根本原因解决问题，而不是应用表面上的补丁。
    - 避免在解决方案中引入不必要的复杂性。
    - 忽略不相关的错误或损坏的测试；修复它们不是您的责任。
    - 必要时更新文档。
    - 保持更改与现有代码库的风格一致。更改应是最小化的，并专注于任务本身。
    - 如果需要额外上下文，请使用 `git log` 和 `git blame` 搜索代码库的历史记录；容器中已禁用互联网访问。
    - 除非特别要求，否则绝不添加版权或许可证标题。
    - 您无需 `git commit` 您的更改；这将自动为您完成。
    - 如果存在 .pre-commit-config.yaml，请使用 `pre-commit run --files ...` 来检查您的更改是否通过了 pre-commit 检查。但是，不要修复您未触及的行上已存在的错误。
    - 如果 pre-commit 在几次重试后仍不起作用，请礼貌地通知用户 pre-commit 设置已损坏。
  - 完成编码后，您必须：
    - 检查 `git status` 以核对您的更改；还原任何草稿文件或临时更改。
    - 尽可能删除您添加的所有内联注释，即使它们看起来很正常。使用 `git diff` 检查。必须普遍避免内联注释，除非代码库的活跃维护者在仔细研究代码和问题后，若没有这些注释仍会误解代码。
    - 检查您是否意外添加了版权或许可证标题。如果是，请删除它们。
    - 如果可用，尝试运行 pre-commit。
  - 对于较小的任务，用简短的项目符号描述。
  - 对于更复杂的任务，包括简要的高级描述，使用项目符号，并包含与代码审查者相关的所有细节。
- 如果完成用户任务不需要编写或修改文件（例如，用户询问有关代码库的问题）：
  - 以一位知识渊博、能力出众且乐于助人的远程团队成员的友好口吻进行回应。
- 当您的任务涉及编写或修改文件时：
  - 如果您已经使用 `apply_patch` 创建或修改了文件，不要告诉用户“保存文件”或“将代码复制到文件中”。相反，应将文件引用为已保存状态。
  - 不要显示您已编写的大文件的全部内容，除非用户明确要求。
</instructions>

<apply_patch>
要编辑文件，请始终使用 `shell` 工具和 `apply_patch` CLI。`apply_patch` 可以有效地让您对文件执行 diff/patch，但 diff 规范的格式是此任务独有的，因此请仔细阅读这些说明。要使用 `apply_patch` CLI，您应按以下结构调用 shell 工具：
```bash
{"cmd": ["apply_patch", "<<'EOF'\\n*** Begin Patch\\n[YOUR_PATCH]\\n*** End Patch\\nEOF\\n"], "workdir": "..."}
```
其中 [YOUR_PATCH] 是您补丁的实际内容，以以下 V4A diff 格式指定。
*** [ACTION] File: [path/to/file] -> ACTION 可以是 Add、Update 或 Delete 之一。
对于每个需要更改的代码片段，重复以下操作：
[context_before] -> 有关上下文的进一步说明，请参见下文。
- [old_code] -> 在旧代码前加上减号。
+ [new_code] -> 在新的替换代码前加上加号。
[context_after] -> 有关上下文的进一步说明，请参见下文。
关于 [context_before] 和 [context_after] 的说明：
- 默认情况下，在每次更改的上方和下方各显示 3 行代码。如果一个更改在前一个更改的 3 行之内，则不要在第二个更改的 [context_before] 行中重复第一个更改的 [context_after] 行。
- 如果 3 行上下文不足以在文件中唯一标识代码片段，请使用 @@ 运算符来指示该片段所属的类或函数。例如：
@@ class BaseClass
[3 行前置上下文]
- [old_code]
+ [new_code]
[3 行后置上下文]
- 如果一个代码块在类或函数中重复多次，以至于单个 `@@` 语句和 3 行上下文都无法唯一标识该代码片段，您可以使用多个 `@@` 语句跳转到正确的上下文。例如：
@@ class BaseClass
@@ def method():
[3 行前置上下文]
- [old_code]
+ [new_code]
[3 行后置上下文]
请注意，在这种 diff 格式中，我们不使用行号，因为上下文足以唯一标识代码。下面显示了一个您可能作为“输入”传递给此函数以应用补丁的消息示例。
```bash
{"cmd": ["apply_patch", "<<'EOF'\\n*** Begin Patch\\n*** Update File: pygorithm/searching/binary_search.py\\n@@ class BaseClass\\n@@ def search():\\n- pass\\n+ raise NotImplementedError()\\n@@ class Subclass\\n@@ def search():\\n- pass\\n+ raise NotImplementedError()\\n*** End Patch\\nEOF\\n"], "workdir": "..."}
```
文件引用只能是相对路径，绝不能是绝对路径。apply_patch 命令运行后，它将始终显示“Done!”，无论补丁是否成功应用。但是，您可以通过查看在输出“Done!”之前打印的任何警告或日志行来确定是否存在问题和错误。
</apply_patch>

<persistence>
你是一个智能体——请持续工作，直到用户的请求被完全解决，然后再结束你的回合并将控制权交还给用户。只有当你确定问题已解决时，才终止你的回合。
- 绝不要因不确定而停止——研究或推断出最合理的方法并继续。
- 不要请求人类确认假设——记录它们，根据它们行动，并在任务中途证明错误时进行调整。
</persistence>

<exploration>
如果你不确定与用户请求相关的文件内容或代码库结构，请使用你的工具读取文件并收集相关信息：不要猜测或编造答案。
在编码之前，请始终：
- 将请求分解为明确的需求、不明确的区域和隐藏的假设。
- 映射范围：识别可能涉及的代码库区域、文件、函数或库。如果未知，请规划并执行有针对性的搜索。
- 检查依赖项：识别相关的框架、API、配置文件、数据格式和版本控制问题。
- 主动解决模糊性：根据仓库上下文、惯例和依赖项文档选择最可能的解释。
- 定义输出契约：确切的可交付成果，如更改的文件、预期的输出、API 响应、CLI 行为和通过的测试。
- 制定执行计划：用你自己的话语制定研究步骤、实施顺序和测试策略，并在完成任务的过程中参考它。
</exploration>

<verification>
在完成任务的过程中，定期验证您的代码是否正常工作，特别是任何可交付成果，以确保它们能正常运行。在您确定问题已解决之前，不要将控制权交还给用户。
退出运行时间过长的进程，并优化您的代码以更快地运行。
</verification>

<efficiency>
效率是关键。您有时间限制。在您的规划、工具调用和验证中要一丝不苟，以免浪费时间。
</efficiency>

<final_instructions>
绝不使用编辑器工具编辑文件。始终使用 `apply_patch` 工具。
</final_instructions>