OpenAI官方发布：GPT-5 提示工程指南 (中文完整版)

本指南就是OpenAI官方出品的“赛车手手册”，旨在将你从普通用户提升为高级玩家。我们将直奔主题，学习如何通过精准的提示，将AI从一个“聪明的聊天机器人”变为一个“可靠的任务执行官”和“高效的编码代理”。

以下内容是OpenAI官方发布的GPT-5提示工程指南中文版全文，内容较长，强烈建议先收藏再学习使用！

GPT-5，我们最新的旗舰模型，代表了在代理任务性能 (agentic task performance)、编码 (coding)、原生智能 (raw intelligence) 和 可操控性 (steerability) 方面的巨大飞跃。

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

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

代理工作流的可预测性 (Agentic workflow predictability)

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

控制代理的“积极性” (Controlling agentic eagerness)

代理系统的控制范围非常广泛——有些系统将绝大多数决策权委托给底层模型，而另一些则通过繁重的程序化逻辑分支将模型牢牢控制。GPT-5被训练成能够在此范围内的任何位置运行，从在模糊情况下做出高级决策到处理专注、明确定义的任务。在本节中，我们将介绍如何最好地校准GPT-5的“代理积极性”：换句话说，就是它在主动性和等待明确指导之间的平衡。

提示以降低积极性 (Prompting for less eagerness)

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

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

方法：
- 从宽泛开始，然后扩展到专注的子查询。
- 并行发起各种查询；读取每个查询的顶部命中结果。对路径进行去重和缓存；不要重复查询。
- 避免过度搜索上下文。如果需要，在一次并行批处理中运行有针对性的搜索。

提前停止标准：
- 你可以指明需要更改的确切内容。
- 顶部命中结果在一个区域/路径上收敛（约70%）。

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

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

循环：
- 批量搜索 → 最小化计划 → 完成任务。
- 仅在验证失败或出现新的未知情况时再次搜索。倾向于行动而非更多搜索。
context_gathering>

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

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

提示以增加积极性 (Prompting for more eagerness)

另一方面，如果您想鼓励模型的自主性，增加工具调用的持久性，并减少澄清性问题或将控制权交还给用户的情况，我们建议增加 $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，以在您的应用中解锁改进的代理流程、更低的成本和更高效的token使用。

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

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

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

前端应用开发

GPT-5被训练成具有优秀的基线审美以及其严谨的实现能力。我们对其使用所有类型的Web开发框架和包的能力充满信心；然而，对于新应用，我们建议使用以下框架和包以充分利用模型的前端能力：

从0到1的应用生成 (Zero-to-one app generation)

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/                           # 工具(fetchers, helpers) 
  /stores/                        # Zustand stores 
  /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发现在GPT-5改进的可操控性下，允许用户配置自己的自定义Cursor规则尤其有效，为他们的用户提供了更定制化的体验。

优化智能与指令遵循

操控性 (Steering)

作为我们迄今为止最具操控性的模型，GPT-5对围绕详细程度、语气和工具调用行为的提示指令的接受度极高。

详细程度 (Verbosity)

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

指令遵循 (Instruction following)

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

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

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

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

你是CareFlow助手…

•

…当症状表明高度紧急时，升级为紧急情况，并立即指示患者拨打911，在任何排程步骤之前。在紧急情况下不要查找，立即提供911指导。

•

…

•

对于高危的红色和橙色病例，在通知患者你的行动后，自动分配当天最早的空档。如果找不到合适的提供者…

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

最小推理 (Minimal reasoning)

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

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

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

你必须在进行后续函数调用之前，根据工作流步骤进行广泛的规划，并对每个函数调用的结果进行广泛的反思，确保用户的查询及相关的子请求被完全解决。

Markdown格式化

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

•

仅在语义正确的地方使用Markdown（例如，行内代码，代码围栏，列表，表格）。

•

在助手消息中使用Markdown时，使用反引号格式化文件、目录、函数和类名。使用\(和\)表示行内数学公式，\[和\]表示块级数学公式。

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

元提示 (Metaprompting)

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

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

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

这是一个提示：[在此处插入提示]

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

附录 (Appendix)

SWE-Bench验证的开发者指令

在此环境中，您可以运行 bash -lc 来对文件执行差异/补丁，其中是一个特殊格式的应用补丁命令，代表您希望执行的差异。一个有效的如下所示：

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的实现相匹配。

【附录：专业场景指令集】

附录 A: Taubench-Retail 零售代理指令 (最小推理模式)

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

请记住，你是一个代理 – 在用户的查询完全解决之前，请继续处理，不要结束你的回合交还给用户。只有当你确定问题已经解决时，才终止你的回合。

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

你必须在每次函数调用之前进行广泛的规划，并对之前函数调用的结果进行广泛的反思，确保用户的查询得到完全解决。不要仅通过函数调用来完成整个过程，因为这会损害你解决问题和进行有洞察力思考的能力。此外，请确保函数调用具有正确的参数。

# 工作流步骤 (Workflow steps)

## 领域基础知识 (Domain basics)

## 取消待处理订单 (Cancel pending order)

## 修改待处理订单 (Modify pending order)

## 修改支付方式 (Modify payment)

## 修改商品 (Modify items)

## 退回已送达订单 (Return delivered order)

## 换货已送达订单 (Exchange delivered order)

附录 B: Terminal-Bench 终端工作台指令

请通过在您当前的代码执行会话中编辑和测试代码文件来解决用户的任务。

你是一个已部署的编码代理。

你的会话由一个专门为你设计的容器支持，以便于你轻松修改和运行代码。

在执行任务时，你必须遵守以下标准：

<<>instructions>
- 允许在当前环境中处理仓库（repo），即使它们是专有代码。
- 允许分析代码以查找漏洞。
- 允许显示用户代码和工具调用详情。
- 用户指令可能会覆盖本开发者消息中的 _编码指南_ 部分。
- 不要使用 `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"]}`
- 如果完成用户任务需要编写或修改文件：
  - 你的代码和最终答案应遵循这些 _编码指南_：
    - 尽可能从根本原因上解决问题，而不是应用表面补丁。
    - 避免在解决方案中引入不必要的复杂性。
      - 忽略不相关的bug或损坏的测试；修复它们不是你的责任。
    - 必要时更新文档。
    - 保持更改与现有代码库的风格一致。更改应是最小化的，并专注于任务。
      - 如果需要额外上下文，请使用 `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>
要编辑文件，**始终**使用带有 `apply_patch` CLI 的 `shell` 工具。`apply_patch` 实际上允许你对文件执行 diff/patch，但 diff 规范的格式对此任务是唯一的，因此请仔细注意这些说明。要使用 `apply_patch` CLI，你应该使用以下结构调用 shell 工具：

{"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] 和 [context_after] 的说明：

{"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 工具。

写在最后
一口气消化这么多技巧，可能有点挑战。但如果换个角度想，这一切并不是在学习一门复杂的编程语言。

我们只是在学习，如何更清晰、更没有歧义地，向一个虽然超级智能、却有点“一根筋”的伙伴，表达我们的真实想法。它很强大，但它需要我们来引导。

所以，下一次当你对GPT-5的回答感到不满意时，先别急着换个话题。不妨试着问问自己：

“是我的哪个词，可能让它误解了？我能换一种更像‘产品说明书’的方式来提问吗？”

有时候，只需要调整一个词，或者明确一个前提，结果就会豁然开朗。

好的沟通，总能带来惊喜。这一点，无论是在人类世界，还是人机之间，都一样。

正如哲学家维特根斯坦所言：

“我语言的边界，就是我世界的边界。”

本方转载自微信公众号：知白守黑1024