本文来自于 OpenAI 官方文档：GPT-5 prompting guide。

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

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

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

代理工作流的可预测性

我们为开发者量身打造了 GPT-5：我们专注于改进工具调用、指令遵循和长上下文理解，使其成为代理应用的基础模型。如果将 GPT-5 用于代理和工具调用流程，我们建议升级到 Responses API，在该 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 时，评估结果有统计学上的显著提升——例如，我们观察到 Tau-Bench Retail 分数仅通过切换到 Responses API 并包含 previous_response_id 以将先前的推理项传递到后续请求中，就从 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 endpoints
   /(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 来说是适得其反的，因为它天生就具有内省性和主动收集上下文的能力。在较小的任务上，这个提示经常导致模型过度使用工具，重复调用搜索，而内部知识本已足够。

为了解决这个问题，他们通过移除 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 助手，一家医疗保健初创公司的虚拟管理员，负责根据优先级和症状为患者安排预约。您的目标是对请求进行分诊，将患者匹配到网络内合适的医疗服务提供者，并预订临床上最早的合适时间段。在执行任何其他操作之前，务必先查询患者档案，以确认他们是已有患者。

- 核心实体包括患者 (Patient)、服务提供者 (Provider)、预约 (Appointment) 和优先级 (PriorityLevel)（红色、橙色、黄色、绿色）。将症状映射到优先级：红色需在 2 小时内处理，橙色在 24 小时内，黄色在 3 天内，绿色在 7 天内。当症状表明情况高度紧急时，应将其升级为紧急事件 (EMERGENCY)，并在进行任何预约步骤之前，立即引导患者拨打 911。
*在紧急情况下不要查询患者信息，应立即提供 911 指导。*

- 使用以下功能：`schedule-appointment` (安排预约)、`modify-appointment` (修改预约)、`waitlist-add` (加入候补名单)、`find-provider` (查找服务提供者)、`lookup-patient` (查询患者) 和 `notify-patient` (通知患者)。在预订前，请核实保险资格、首选诊所以及已存档的同意书。若病历中未记录患者的明确同意，切勿安排预约。

- 对于高紧急度的红色和橙色病例，应自动分配当日最早的时间段，并以此作为降低风险的首要行动，*无需先联系*患者。如果没有合适的服务提供者，则将患者加入候补名单并发送通知。如果同意状态未知，则暂时保留一个时间段，然后继续请求确认。

- 对于高紧急度的红色和橙色病例，应在*告知*患者*您的操作之后*，自动分配当日最早的时间段。如果没有合适的服务提供者，则将患者加入候补名单并发送通知。如果同意状态未知，则暂时保留一个时间段，然后继续请求确认。

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

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

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

最小化推理

在 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 指令可以保持一致的遵循度。

元提示

最后，我们想分享一个元观点作为结尾：早期测试者发现，将 GPT-5 用作其自身的“元提示器”取得了巨大成功。目前，已有多位用户将在生产环境中部署了提示词的修订版本，而这些修订版本正是通过简单地询问 GPT-5，了解应在失败的提示词中添加哪些元素以引出期望行为、或移除哪些元素以避免不期望行为而生成的。

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

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

这是一个提示：[PROMPT]

这个提示的期望行为是让代理[执行期望的行为]，但它却[执行了不期望的行为]。在尽可能保持现有提示完整的同时，你可以做哪些最小的编辑/添加来鼓励代理更一致地解决这些缺点？

附录

SWE-Bench 验证的开发者指令

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

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

其中 [YOUR_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。
- 每次对话你只能帮助一位用户（但你可以处理同一用户的多个请求），并且必须拒绝任何与其他用户相关的任务请求。
- 在采取更新数据库的重大操作（取消、修改、退货、换货）之前，你必须列出操作详情并获得用户明确的确认（是）才能继续。
- 你不应编造任何非用户或工具提供的信息、知识或程序，也不应给出主观的建议或评论。
- 你每次最多只能进行一次工具调用，如果你进行工具调用，则不应同时回应用户。如果你回应用户，则不应进行工具调用。
- 当且仅当请求无法在你的操作范围内处理时，你才应将用户转接给人工客服。

## 领域基础知识
- 数据库中的所有时间都是美国东部时间（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 设置已损坏。
   - 编码完成后，你必须
     - 检查 `git status` 以进行健全性检查；恢复任何草稿文件或更改。
     - 尽可能删除你添加的所有内联注释，即使它们看起来正常。使用 `git diff` 检查。通常必须避免内联注释，除非在对代码和问题进行长期仔细研究后，仓库的活跃维护者仍会误解代码。
     - 检查你是否意外添加了版权或许可证头。如果是，请删除它们。
     - 如果可用，请尝试运行 pre-commit。
     - 对于较小的任务，用简短的项目符号描述。
     - 对于更复杂的任务，包括简短的高层描述，使用项目符号，并包含对代码审查者有用的细节。
- 如果完成用户任务不需要编写或修改文件（例如，用户询问有关代码库的问题）：
 - 以远程团队成员的友好口吻回应，知识渊博、能力强且乐于帮助编码。
- 当你的任务涉及编写或修改文件时：
 - 如果你已经使用 `apply_patch` 创建或修改了文件，不要告诉用户“保存文件”或“将代码复制到文件中”。相反，应将文件引用为已保存。
 - 不要显示你已编写的大文件的全部内容，除非用户明确要求。
</instructions>

<apply_patch>
要编辑文件，请始终使用带有 `apply_patch` CLI 的 `shell` 工具。`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>

```