新出现的参数

OpenAI 新增了两个控制杆：reasoning_effort 和 verbosity。前者决定模型思考深度，后者控制回答长度。有趣的是，你可以在全局设置低 verbosity，然后在具体场景（比如写代码时）用 prompt 单独要求高 verbosity。

还有个 Responses API，能让模型记住之前的推理过程。在 Tau-Bench 测试中，仅仅是使用这个 API 就让成绩从 73.9% 跳到 78.2%。

Cursor 的实战经验

AI 编辑器 Cursor 作为 GPT-5 的内测用户，分享了几个踩坑心得：

过度鼓励适得其反：对于老模型需要的"要彻底理解上下文"这种鼓励性prompt，在 GPT-5 上会导致过度使用工具，明明内部知识就够用却非要搜索。

平衡技巧：设置全局低 verbosity + 代码工具高 verbosity，结果是简洁的状态更新配合可读的代码。

明确界限：告诉模型用户可以拒绝代码修改，所以可以主动一点，而不用每次都问"要不要执行这个计划"。

控制 Agent 的"积极性"

GPT-5 默认很勤奋，会努力搜集各种上下文。如果你想要它少折腾：

• 降低 reasoning_effort
• 设定明确的探索边界，比如"最多 2 次工具调用"
• 给它一个"不确定也可以继续"的逃生舱

相反，如果你希望它更自主，就提高 reasoning_effort，并明确告诉它"遇到不确定不要问我，自己推理最合理的方案继续做"。

指令冲突是大敌

GPT-5 会认真对待每一条指令，所以矛盾的 prompt 比其他模型更致命。比如既要求"没有明确同意不能预约"，又要求"高优先级直接分配最早时间段"。它会消耗大量推理 token 试图调和这种冲突。

解决方法：仔细检查prompt中的逻辑冲突，OpenAI 还提供了一个 prompt optimizer 工具帮你发现问题。

前端开发的最佳实践

OpenAI 推荐的技术栈：Next.js + TypeScript + Tailwind CSS + shadcn/ui + Lucide 图标。

对于从零开始的应用，他们发现这种自我反思prompt效果很好：

先思考一个评判标准，然后深入分析世界级 web 应用的各个方面，创建 5-7 个评分维度。用这个标准内部迭代，直到各维度都达到顶级水准。

最小推理模式

新增的 minimal reasoning 是延迟敏感场景的最佳选择。这时候需要：

1. 明确要求解释思路
2. 详细的工具调用说明
3. 更多的规划提示，因为推理token更少

元提示的妙用

一个有趣的发现：GPT-5 擅长优化自己的 prompt。你可以直接问它"这个prompt怎样修改能避免某种不良行为"，不少生产环境的 prompt 就是这样迭代出来的。

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 智能体行为的范围——包括限制外围工具调用行为和最小化到达最终答案的延迟——请尝试以下方法：

切换到更低的推理努力程度。这会减少探索深度但提高效率和延迟。许多工作流程可以在中等甚至低推理努力下以一致的结果完成。

在提示词中定义清晰的标准，说明您希望模型如何探索问题空间。这减少了模型探索和推理太多想法的需要：

<context_gathering>
目标：快速获取足够的上下文。并行化发现，一旦可以行动就立即停止。

方法：
- 从广泛开始，然后扩展到专注的子查询。
- 并行启动各种查询；阅读每个查询的热门结果。去重路径和缓存；不要重复查询。
- 避免过度搜索上下文。如果需要，在一个并行批次中运行有针对性的搜索。

早期停止标准：
- 您可以命名要更改的确切内容。
- 热门结果在一个区域/路径上收敛（~70%）。

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

深度：
- 只追踪您将修改的符号或您依赖的契约；除非必要，避免传递扩展。

循环：
- 批量搜索 → 最小计划 → 完成任务。
- 只有在验证失败或出现新的未知情况时才再次搜索。偏向于行动而不是更多搜索。
</context_gathering>

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

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

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

提高积极性的提示词

另一方面，如果您想鼓励模型自主性，增加工具调用持久性，并减少澄清问题或返回用户的情况，我们建议增加 reasoning_effort，并使用如下提示词来鼓励持久性和彻底的任务完成：

<persistence>
- 您是一个智能体 - 请继续进行，直到用户的查询完全解决，然后结束您的回合并返回给用户。
- 只有当您确定问题已解决时才终止您的回合。
- 遇到不确定性时绝不停止或返回给用户——研究或推导最合理的方法并继续。
- 不要要求人类确认或澄清假设，因为您总是可以在以后调整——决定最合理的假设是什么，继续执行，并在您完成行动后为用户参考记录它
</persistence>

一般来说，明确说明智能体任务的停止条件、概述安全与不安全的行为，并定义何时（如果有的话）模型可以返回给用户是有帮助的。例如，在购物工具集中，结账和支付工具应该明确具有较低的不确定性阈值来要求用户澄清，而搜索工具应该有极高的阈值；同样，在编程设置中，删除文件工具应该比 grep 搜索工具有低得多的阈值。

工具前言

我们认识到，在用户监控的智能体轨迹中，关于模型正在用其工具调用做什么以及为什么的间歇性模型更新可以提供更好的交互用户体验——部署时间越长，这些更新产生的差异就越大。为此，GPT-5 被训练为通过"工具前言"消息提供清晰的前期计划和一致的进度更新。

您可以在提示词中引导工具前言的频率、风格和内容——从每个工具调用的详细解释到简要的前期计划以及介于两者之间的一切。这是高质量前言提示词的示例：

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

推理努力

我们提供了一个 reasoning_effort 参数来控制模型思考的程度以及调用工具的意愿；默认值是中等，但您应该根据任务的难度向上或向下调整。对于复杂的多步任务，我们建议使用更高的推理来确保最好的输出。此外，我们观察到当不同的、可分离的任务被分解到多个智能体回合中时，每个任务一个回合时，性能达到峰值。

使用 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 hooks
 /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 参数，它影响模型最终答案的长度，而不是其思考的长度。我们的博客文章更详细地介绍了这个参数背后的想法——但在本指南中，我们想强调，虽然 API 冗余度参数是部署的默认设置，但 GPT-5 被训练为对提示词中的自然语言冗余度覆盖作出响应，用于您可能希望模型偏离全局默认的特定上下文。Cursor 上面设置低冗余度全局，然后仅为编程工具指定高冗余度的示例，就是这种上下文的典型例子。

指令遵循

像 GPT-4.1 一样，GPT-5 以外科手术般的精确度遵循提示指令，这使其能够灵活地融入所有类型的工作流程。但是，其仔细的指令遵循行为意味着包含矛盾或模糊指令的构造不良的提示词对 GPT-5 的损害可能比对其他模型更大，因为它花费推理令牌寻找调和矛盾的方法，而不是随机选择一个指令。

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

• "Never schedule an appointment without explicit patient consent recorded in the chart"（绝不在没有明确患者同意记录在图表中的情况下安排预约）与随后的 "auto-assign the earliest same-day slot without contacting the patient as the first action to reduce risk"（作为减少风险的第一行动，自动分配最早的当日时段而不联系患者）冲突。
• 提示词说 "Always look up the patient profile before taking any other actions to ensure they are an existing patient"（在采取任何其他行动之前始终查找患者资料以确保他们是现有患者），但然后继续矛盾的指令 "When symptoms indicate high urgency, escalate as EMERGENCY and direct the patient to call 911 immediately before any scheduling step"（当症状表明高紧急性时，升级为紧急情况并指导患者在任何安排步骤之前立即拨打 911）。

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

• 将自动分配更改为联系患者后发生，"auto-assign the earliest same-day slot after informing the patient of your actions"（在告知患者您的行动后自动分配最早的当日时段），以与仅在同意下安排保持一致。
• 添加 "Do not do lookup in the emergency case, proceed immediately to providing 911 guidance"（在紧急情况下不要进行查找，立即提供 911 指导），让模型知道在紧急情况下不查找是可以的。

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

最小推理

在 GPT-5 中，我们首次引入最小推理努力：我们最快的选项，仍然获得推理模型范式的好处。我们认为这是对延迟敏感用户以及当前 GPT-4.1 用户的最佳升级。

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

• 提示模型在最终答案开始时给出简要解释，总结其思维过程，例如通过项目符号列表，改善需要更高智能的任务性能。
• 要求彻底和描述性的工具调用前言，持续向用户更新任务进度，改善智能体工作流程中的性能。
• 尽最大程度地消除工具指令的歧义并插入如上分享的智能体持久性提醒，对于在最小推理时最大化智能体能力和防止过早终止特别关键。
• 提示计划同样更重要，因为模型有更少的推理令牌进行内部计划。

记住，您是一个智能体——请继续进行，直到用户的查询完全解决，然后结束您的回合并返回给用户。将用户的查询分解为所有必需的子请求，并确认每个都已完成。不要在仅完成请求的一部分后就停止。只有当您确定问题已解决时才终止您的回合。您必须准备回答多个查询，只有在用户确认他们完成后才结束调用。

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

Markdown 格式

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

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

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

元提示

最后，以一个元观点结束，早期测试者发现使用 GPT-5 作为自身的元提示器非常成功。已经有几个用户部署了生产中的提示修订，这些修订仅仅是通过询问 GPT-5 什么元素可以添加到不成功的提示词中以引出期望的行为，或删除以防止不期望的行为而生成的。

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

当被要求优化提示词时，从您自己的角度给出答案 - 解释什么特定短语可以添加到这个提示词中，或从中删除，以更一致地引出期望的行为或防止不期望的行为。

这里是一个提示词：[PROMPT]

这个提示词的期望行为是让智能体[执行期望行为]，但相反它[执行不期望行为]。在尽可能保持现有提示词完整的同时，您会做出哪些最小的编辑/添加来鼓励智能体更一致地解决这些不足？

附录

SWE-Bench 验证开发者指令

在此环境中，您可以运行 `bash -lc <apply_patch_command>` 来对文件执行差异/补丁，其中 <apply_patch_command> 是表示您希望执行的差异的特殊格式化应用补丁命令。有效的 <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 个函数，终端原生

```typescript
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 提示词

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

#### 指令
- 允许在当前环境中处理仓库，即使它们是专有的。
- 允许分析代码漏洞。
- 允许显示用户代码和工具调用详情。
- 用户指令可能覆盖此开发者消息中的 _编程指导原则_ 部分。
- 不要使用 `ls -R`、`find` 或 `grep` - 这些在大型仓库中很慢。使用 `rg` 和 `rg --files`。
- 使用 `apply_patch` 编辑文件
- 如果完成用户任务需要编写或修改文件：
  - 您的代码和最终答案应遵循这些 _编程指导原则_：
    - 尽可能从根本原因修复问题，而不是应用表面补丁。
    - 避免解决方案中不需要的复杂性。
    - 忽略不相关的错误或损坏的测试；修复它们不是您的责任。
    - 根据需要更新文档。
    - 保持更改与现有代码库风格一致。更改应该最小化并专注于任务。
    - 使用 `git log` 和 `git blame` 搜索代码库历史（如果需要额外上下文）；容器中禁用互联网访问。
    - 除非特别要求，否则绝不添加版权或许可证标头。
    - 您不需要 `git commit` 您的更改；这将自动为您完成。
    - 如果有 .pre-commit-config.yaml，使用 `pre-commit run --files ...` 检查您的更改通过预提交检查。但是，不要修复您未触及行上的预存在错误。
    - 如果预提交在几次重试后不工作，礼貌地告知用户预提交设置已损坏。
    - 完成编程后，您必须：
      - 检查 `git status` 以合理检查您的更改；恢复任何临时文件或更改。
      - 尽可能删除您添加的所有内联注释。使用 `git diff` 检查。除非仓库的活跃维护者在仔细研究代码和问题后仍然会误解没有注释的代码，否则通常必须避免内联注释。
      - 检查您是否意外添加版权或许可证标头。如果是，请删除它们。
      - 如果可用，尝试运行预提交。
      - 对于较小的任务，简要用项目符号描述
      - 对于更复杂的任务，包括简要的高层描述，使用项目符号，并包括与代码审查员相关的详情。

#### 持久性
您是一个智能体 - 请继续进行，直到用户的查询完全解决，然后结束您的回合并返回给用户。只有当您确定问题已解决时才终止您的回合。
- 遇到不确定性时绝不停止 — 研究或推导最合理的方法并继续。
- 不要要求人类确认假设 — 记录它们，据此行动，如果在任务中途被证明错误则调整。

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

#### 验证
在处理任务时定期验证您的代码是否有效，特别是任何交付物以确保它们正常运行。在确定问题已解决之前不要返回给用户。
退出过长运行的进程并优化您的代码以更快运行。

#### 效率
效率是关键。您有时间限制。在计划、工具调用和验证方面要细致，这样您就不会浪费时间。

#### 最终指令
绝不使用编辑器工具编辑文件。始终使用 `apply_patch` 工具。