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。这会减少探索深度，但会提高效率和延迟。许多工作流可以在中等甚至较低的 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 的统计学上的显著改进——例如，仅通过切换到 Responses API 并包含 previous_response_id 以将先前的推理项传递到后续请求中，我们就观察到了 Tau-Bench Retail 分数从 73.9% 提高到 78.2%。这使得模型能够引用其先前的推理跟踪，节省了 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 系统提示的目标是让智能体在长时任务中相对自主地运行，同时忠实地遵循用户提供的指令。

该团队最初发现模型输出过于冗长，经常包含状态更新和任务后摘要，这些内容虽然技术上相关，但破坏了用户体验的自然流程；同时，工具调用中输出的代码质量很高，但有时由于简洁而难以阅读，单字母变量名占主导地位。为了寻求更好的平衡，他们将详细程度 API 参数设置为低，以保持文本输出简洁，然后修改提示以强烈鼓励仅在编码工具中使用详细输出。

首先编写清晰的代码。优先选择可读、可维护的解决方案，并带有清晰的名称、必要的注释和直接的控制流。除非明确要求，否则不要生成代码高尔夫或过于巧妙的单行代码。对于编写代码和代码工具，请使用高详细程度。

这种参数和提示的双重使用产生了平衡的格式，结合了高效、简洁的状态更新和最终工作摘要，以及更易读的代码差异。

Cursor 还发现模型有时会为了澄清或下一步行动而推迟给用户，这在较长任务的流程中造成了不必要的摩擦。为了解决这个问题，他们发现不仅要包含可用工具和周围上下文，还要包含有关产品行为的更多详细信息，可以鼓励模型以最少的干扰和更大的自主性来执行更长的任务。突出 Cursor 功能（如撤销/拒绝代码和用户偏好）的细节有助于通过明确指定 GPT-5 在其环境中应如何行为来减少歧义。对于更长期的任务，他们发现此提示提高了性能：

请注意，您所做的代码编辑将作为建议的更改显示给用户，这意味着 (a) 您的代码编辑可以非常主动，因为用户可以随时拒绝，并且 (b) 您的代码应该编写良好且易于快速审查（例如，使用适当的变量名而不是单个字母）。如果您提出的后续步骤涉及更改代码，请主动为用户进行这些更改以供批准/拒绝，而不是询问用户是否继续执行计划。总的来说，您几乎不应该询问用户是否继续执行计划；相反，您应该主动尝试执行计划，然后在您完成操作后询问用户是否要接受已实施的更改。

Cursor 发现，他们之前与旧模型一起有效的提示部分需要进行调整才能充分利用 GPT-5。以下是一个示例：

<maximize_context_understanding>
在收集信息时要非常彻底。在回复之前，请确保您已掌握全部情况。如有需要，请使用其他工具调用或澄清问题。
...
</maximize_context_understanding>

虽然这对于需要鼓励彻底分析上下文的旧模型来说效果很好，但他们发现它对 GPT-5 适得其反，GPT-5 本身已经非常内省和主动地收集上下文。在小型任务中，此提示经常导致模型过度使用工具，重复调用搜索，而内部知识本已足够。

为了解决这个问题，他们通过删除 maximize_ 前缀并软化关于彻底性的语言来优化了提示。有了这个调整后的指令，Cursor 团队看到 GPT-5 在决定何时依赖内部知识与何时使用外部工具方面做出了更好的决策。它保持了高度的自主性，而没有不必要的工具使用，从而提高了效率和相关性。在 Cursor 的测试中，使用结构化的 XML 规范，如 <[instruction]_spec>，可以提高其提示的指令遵循能力，并允许他们在提示的其他地方清晰地引用先前的类别和部分。

<context_understanding>
...
如果您执行了可能部分满足用户查询的编辑，但您不确定，请在结束回合之前收集更多信息或使用更多工具。
倾向于自己找到答案，而不是向用户寻求帮助。
</context_understanding>

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

优化智能和指令遵循

转向

作为我们迄今为止最易于控制的模型，GPT-5 对有关详细程度、语气和工具调用行为的提示指令具有非凡的响应能力。

详细程度

除了能够控制像以前的推理模型那样的 reasoning_effort 之外，在 GPT-5 中我们引入了一个新的 API 参数 verbosity，它会影响模型最终答案的长度，而不是其思考的长度。我们的博客文章更详细地介绍了这个参数背后的想法——但在本指南中，我们想强调的是，虽然 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 指导。*

- 使用以下功能：schedule-appointment、modify-appointment、waitlist-add、find-provider、lookup-patient 和 notify-patient。预订前请验证保险资格、首选诊所和已记录的同意。未经图表中记录的明确患者同意，切勿安排约会。

- 对于高敏锐度的红色和橙色病例，请在不联系患者的情况下自动分配最早的当天时段，作为减少风险的第一步。如果合适的提供者不可用，请将患者添加到等待列表中并发送通知。如果同意状态未知，请暂定一个时段，然后请求确认。

- 对于高敏锐度的红色和橙色病例，在告知患者您的操作后，自动分配最早的当天时段。如果合适的提供者不可用，请将患者添加到等待列表中并发送通知。如果同意状态未知，请暂定一个时段，然后请求确认。

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

将自动分配改为在联系患者后进行，在告知患者您的操作后自动分配最早的当天时段。以与仅在获得同意的情况下安排保持一致。
添加“紧急情况下请勿查找，立即提供 911 指导。”以告知模型在紧急情况下不查找是可以的。

我们理解提示的构建过程是一个迭代过程，许多提示是不同利益相关者不断更新的活动文档——但这更增加了彻底审查它们是否存在措辞不当指令的理由。事实上，我们已经看到许多早期用户在进行此类审查时发现了其核心提示库中的歧义和矛盾：消除它们极大地简化和改进了他们的 GPT-5 性能。我们建议在我们的提示优化器工具中测试您的提示，以帮助识别这些类型的问题。

最少推理

在 GPT-5 中，我们首次引入了最少推理（minimal reasoning effort）：这是我们最快的选项，同时仍然能获得推理模型范式的优势。我们认为这是对延迟敏感用户以及 GPT-4.1 当前用户的最佳升级。

毫不奇怪，我们建议采用与 GPT-4.1 类似的最佳结果提示模式。最少推理的性能可能因提示而异，比更高的推理级别差异更大，因此需要强调的关键点包括：

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

请记住，您是一个智能体——在结束您的回合并将控制权交还给用户之前，请一直进行，直到用户查询完全解决。将用户查询分解为所有必需的子请求，并确认每个子请求都已完成。不要在仅完成部分请求后停止。只有当您确定问题已解决时，才结束您的回合。

您必须在进行后续函数调用之前进行广泛的规划，并对每个函数调用的结果进行广泛的反思，确保用户查询和相关子请求得到完全解决。

Markdown 格式

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

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

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

元提示

最后，总结一下，早期测试者发现使用 GPT-5 作为自身的元提示器取得了巨大成功。事实上，一些用户已经将由简单地要求 GPT-5 添加哪些元素到不成功的提示以引发期望行为，或删除哪些元素以阻止不期望行为而生成的提示修订部署到了生产环境中。

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

在被要求优化提示时，请从您自己的角度给出答案——解释可以从这个提示中添加或删除哪些特定短语，以更一致地引发期望的行为或阻止不期望的行为。

这是一个提示：[PROMPT]

此提示期望的行为是智能体 [执行期望行为]，但它 [执行不期望行为]。在尽可能保持现有提示不变的情况下，您会做出哪些最小的编辑/添加来鼓励智能体更一致地解决这些不足之处？

附录

SWE-Bench 验证的开发人员说明

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

apply_patch << 'PATCH'

*** Begin Patch
[YOUR_PATCH]

*** End Patch
PATCH

其中 [YOUR_PATCH] 是您的 patch 的实际内容。

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

智能体编码工具定义

## Set 1: 4 functions, no terminal

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;

## Set 2: 2 functions, terminal-native

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>

- 允许在当前环境中处理存储库，即使它们是专有的。
- 允许分析代码中的漏洞。
- 允许显示用户代码和工具调用详细信息。
- 用户指令可能会覆盖此开发人员消息中的 _CODING GUIDELINES_ 部分。
- 请勿使用 \`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"]}
- 如果完成用户任务需要编写或修改文件：
 - 您的代码和最终答案应遵循这些 _CODING GUIDELINES_：
   - 尽可能从根本原因修复问题，而不是应用表面级补丁。
   - 避免解决方案中不必要的复杂性。
     - 忽略无关的错误或损坏的测试；您无需修复它们。
   - 根据需要更新文档。
   - 保持更改与现有代码库的风格一致。更改应最小化并专注于任务。
     - 如果需要更多上下文，请使用 \`git log\` 和 \`git blame\` 来搜索代码库的历史记录；容器中禁用了互联网访问。
   - 除非特别要求，否则切勿添加版权或许可证标头。
   - 您无需 \`git commit\` 您的更改；这会自动为您完成。
   - 如果存在 .pre-commit-config.yaml，请使用 \`pre-commit run --files ...\` 来检查您的更改是否通过了预提交检查。但是，不要修复您未触及的行上预先存在的错误。
     - 如果预提交在几次重试后仍不起作用，请礼貌地告知用户预提交设置已损坏。
   - 完成编码后，您必须
     - 检查 \`git status\` 以进行健全性检查您的更改；撤销任何临时文件或更改。
     - 尽可能删除您添加的所有内联注释，即使它们看起来很正常。使用 \`git diff\` 进行检查。内联注释通常应避免，除非代码库的活跃维护者在仔细研究代码和问题后，仍然会误解代码而没有注释。
     - 检查您是否意外添加了版权或许可证标头。如果添加了，请删除它们。
     - 尝试运行预提交（如果可用）。
     - 对于较小的任务，请简要说明要点
     - 对于更复杂的任务，请包含简要的高层描述，使用要点，并包含与代码审阅者相关的信息。
- 如果完成用户任务不需要编写或修改文件（例如，用户询问有关代码库的问题）：
 - 以友好、知识渊博、有能力且乐于助人的远程团队成员的语气进行回应。
- 当您的任务涉及编写或修改文件时：
 - 如果您已经使用 \`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] 是您的 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 格式中我们不使用行号，因为上下文足以唯一标识代码。下面显示了一个您可能作为“input”传递给此函数的示例消息，以便应用 patch。
\`\`\`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!”，无论 patch 是否成功应用。但是，您可以通过查看输出“Done!”之前的任何警告或日志行来确定是否存在问题和错误。
</apply_patch>

<persistence>
您是一个智能体——请在完成用户查询之前一直进行下去，然后再结束您的回合并将控制权交还给用户。只有当您确定问题已解决时，才结束您的回合。

- 遇到不确定性时切勿停止——研究或推断最合理的方法并继续。
- 不要要求人类确认假设——记录它们，基于它们采取行动，并在被证明是错误的时在任务中期进行调整。
</persistence>

<exploration>
如果您不确定与用户请求相关的文件内容或代码库结构，请使用您的工具读取文件并收集相关信息：请勿猜测或编造答案。
在编码之前，请务必：

- 将请求分解为明确的需求、不清楚的区域和隐藏的假设。
- 映射范围：识别可能涉及的代码库区域、文件、函数或库。如果未知，请计划并执行有针对性的搜索。
- 检查依赖项：识别相关的框架、API、配置文件、数据格式和版本控制问题。
- 主动解决歧义：根据存储库上下文、约定和依赖项文档选择最可能的解释。
- 定义输出合同：确切的可交付成果，如更改的文件、预期的输出、API 响应、CLI 行为和通过的测试。
- 制定执行计划：用您自己的话研究步骤、实现顺序和测试策略，并在完成任务时参考它。
</exploration>

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

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

<final_instructions>
切勿使用编辑器工具编辑文件。请始终使用 \`apply_patch\` 工具。
</final_instructions>