GPT-5 提示指南

GPT-5，我们最新的旗舰模型，在代理任务性能、编码、原始智能和可控性方面实现了重大飞跃。

虽然我们相信它在各种领域都能“开箱即用”地表现出色，但在本指南中，我们将介绍一些提示技巧，以最大化模型输出的质量，这些技巧源于我们训练模型并将其应用于实际任务的经验。我们讨论的概念包括提高代理任务性能、确保指令遵守、利用新的 API 功能以及优化前端和软件工程任务的编码——并深入探讨了 AI 代码编辑器 Cursor 与 GPT-5 的提示调整工作。

我们已经看到，通过应用这些最佳实践并尽可能采用我们的规范工具，我们取得了显著的进步，我们希望本指南以及我们构建的提示优化器工具能成为您使用 GPT-5 的起点。但是，请永远记住，提示并非一刀切的练习——我们鼓励您在本文提供的基础上进行实验和迭代，以找到解决您问题的最佳方案。

代理工作流的可预测性

我们为开发者量身打造了 GPT-5：我们专注于改进工具调用、指令遵循和长上下文理解，使其成为代理应用程序的最佳基础模型。如果将 GPT-5 用于代理和工具调用流程，我们建议升级到 Responses API，其中推理在工具调用之间保持持久，从而实现更高效、更智能的输出。

控制代理的主动性

代理支架可以涵盖广泛的控制范围——一些系统将绝大多数决策委托给底层模型，而另一些系统则通过繁重的程序化逻辑分支将模型置于严格的控制之下。GPT-5 经过训练，可以在这个范围内的任何地方运行，从在模棱两可的情况下做出高级决策到处理专注、明确定义的任务。在本节中，我们将介绍如何最好地校准 GPT-5 的代理主动性：换句话说，它在主动性和等待明确指导之间的平衡。

提示以减少主动性

默认情况下，GPT-5 在代理环境中尝试收集上下文时是彻底和全面的，以确保它会产生正确的答案。要减少 GPT-5 代理行为的范围——包括限制切题的工具调用操作和最小化获得最终答案的延迟——请尝试以下方法：

• 切换到较低的 reasoning_effort。这会降低探索深度，但能提高效率和延迟。许多工作流可以在 medium 甚至 low 的 reasoning_effort 下以一致的结果完成。
• 在您的提示中为模型如何探索问题空间定义明确的标准。这减少了模型探索和推理过多想法的需要：

<context_gathering>
目标：快速获取足够的上下文。并行化发现并在可以行动时立即停止。
方法：
- 从广泛开始，然后扩展到集中的子查询。
- 并行启动各种查询；读取每个查询的最高匹配项。对路径进行去重和缓存；不要重复查询。
- 避免过度搜索上下文。如果需要，在一个并行批次中运行有针对性的搜索。
提前停止标准：
- 您可以命名要更改的确切内容。
- 最高匹配项在一个区域/路径上收敛（约 70%）。
升级一次：
- 如果信号冲突或范围模糊，则运行一个精炼的并行批次，然后继续。
深度：
- 仅跟踪您将要修改或依赖其契约的符号；除非必要，否则避免传递性扩展。
循环：
- 批量搜索 → 最小计划 → 完成任务。
- 仅在验证失败或出现新的未知情况时再次搜索。优先选择行动而不是更多搜索。
</context_gathering>

如果您愿意进行最大程度的规定，您甚至可以设置固定的工具调用预算，如下所示。预算可以根据您期望的搜索深度自然变化。

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

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

提示以增加主动性

另一方面，如果您想鼓励模型的自主性，增加工具调用的持久性，并减少澄清问题或以其他方式将控制权交还给用户的情况，我们建议增加 reasoning_effort，并使用如下提示来鼓励持久性和彻底的任务完成：

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

通常，明确说明代理任务的停止条件、概述安全与不安全的操作，并定义模型何时（如果可以的话）可以将控制权交还给用户会很有帮助。例如，在一组购物工具中，结账和支付工具对于需要用户澄清的不确定性阈值应明确较低，而搜索工具的阈值应极高；同样，在编码设置中，删除文件工具的阈值应远低于 grep 搜索工具。

工具前导

我们认识到，在由用户监控的代理轨迹上，模型关于其工具调用正在做什么以及为什么做的间歇性更新可以提供更好的交互式用户体验——部署时间越长，这些更新带来的差异就越大。为此，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 参数来控制模型的思考深度和调用工具的意愿；默认为 medium，但您应根据任务的难度进行上调或下调。对于复杂的多步骤任务，我们建议使用更高的推理力度以确保获得最佳输出。此外，我们观察到，当将不同的、可分离的任务分解到多个代理回合中，每个任务一个回合时，性能达到峰值。

使用 Responses API 重用推理上下文

我们强烈建议在使用 GPT-5 时使用 Responses API，以解锁改进的代理流程、降低成本并在您的应用程序中更有效地使用令牌。

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

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

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

前端应用开发

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 模式分解为组件来避免重复。
- 一致性：用户界面必须遵守一致的设计系统——颜色标记、排版、间距和组件必须统一。
- 简单性：倾向于使用小型、专注的组件，并避免样式或逻辑中不必要的复杂性。
- 面向演示：结构应允许快速原型制作，展示流式传输、多轮对话和工具集成等功能。
- 视觉质量：遵循 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/ # 实用程序（获取器、帮助程序） /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 改进的可控性特别有影响力，为他们的用户提供了更定制的体验。

优化智能和指令遵循

引导

作为我们迄今为止最易于引导的模型，GPT-5 对围绕详细程度、语气和工具调用行为的提示指令非常敏感。

详细程度

除了能够像以前的推理模型一样控制 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 性能。我们建议在我们的提示优化器工具中测试您的提示，以帮助识别这些类型的问题。

最小推理

在 GPT-5 中，我们首次引入了最小推理力度：我们最快的选项，但仍能 reaping the benefits of the reasoning model paradigm。我们认为这是对延迟敏感的用户以及 GPT-4.1 当前用户的最佳升级。

也许不足为奇，我们建议使用类似于 GPT-4.1 的提示模式以获得最佳结果。最小推理性能可能会比更高推理级别更剧烈地因提示而异，因此需要强调的关键点包括：

• 提示模型在最终答案的开头给出一个简短的解释，总结其思维过程，例如通过项目符号列表，可以提高需要更高智能的任务的性能。
• 请求详尽且描述性的工具调用前导，不断向用户更新任务进度，可以提高代理工作流的性能。
• 最大程度地消除工具指令的歧义，并插入如上所述的代理持久性提醒，对于在最小推理下最大化长时间运行的部署中的代理能力并防止过早终止至关重要。
• 提示规划同样更重要，因为模型用于内部规划的推理令牌更少。下面，您可以在代理任务的开头找到一个示例规划提示片段：第二段尤其确保代理在将控制权交还给用户之前完全完成任务和所有子任务。

请记住，您是一个代理 - 请继续，直到用户的查询完全解决，然后再结束您的回合并将控制权交还给用户。将用户的查询分解为所有必需的子请求，并确认每个子请求都已完成。不要仅在完成部分请求后就停止。只有当你确定问题已解决时才终止你的回合。您必须准备好回答多个查询，并且只有在用户确认他们完成后才能结束通话。在进行后续函数调用之前，您必须根据工作流步骤进行广泛的规划，并广泛反思每个函数调用的结果，确保用户的查询和相关的子请求都已完全解决。

Markdown 格式

默认情况下，API 中的 GPT-5 不会将其最终答案格式化为 Markdown，以保持与可能不支持 Markdown 呈现的开发人员应用程序的最大兼容性。但是，像下面这样的提示在很大程度上成功地诱导了分层的 Markdown 最终答案。

- **仅在语义正确的情况下**使用 Markdown（例如，`内联代码`、```代码围栏```、列表、表格）。
- 在助手消息中使用 markdown 时，使用反引号格式化文件、目录、函数和类名。对内联数学使用 \\( 和 \\)，对块数学使用 \\\\[ 和 \\\\]。

有时，在长时间的对话过程中，对系统提示中指定的 Markdown 指令的遵守程度可能会下降。如果您遇到这种情况，我们看到每 3-5 条用户消息附加一条 Markdown 指令可以保持一致的遵守。

元提示

最后，以一个元点结束，早期测试人员发现使用 GPT-5 作为其自身的元提示器取得了巨大成功。已经有几个用户将提示修订部署到生产中，这些修订只是通过询问 GPT-5 可以向不成功的提示中添加哪些元素以引出期望的行为，或者可以删除哪些元素以防止不期望的行为而生成的。

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

当被要求优化提示时，请从您自己的角度给出答案——解释可以向此提示中添加或删除哪些特定短语，以更一致地引出期望的行为或防止不期望的行为。这是一个提示：[提示] 此提示的期望行为是让代理 [执行期望的行为]，但它却 [执行不期望的行为]。在尽可能保持现有提示完整的同时，您可以进行哪些最小的编辑/添加来鼓励代理更一致地解决这些缺点？