GPT-5 官方提示词工程：从入门到精通权威指南

GPT-5 已然登场，它不仅在原始智能和代码能力上实现了飞跃，更在“代理任务（agentic task）”性能上展现了惊人的潜力。这意味着，我们与 AI 的协作模式正从简单的“一问一答”演变为“分配一个目标，让它自己想办法完成”。

但这并不简单。要最大化 GPT-5 这类模型的输出质量，开发者需要掌握一套全新的交互法则。这份指南将深入探讨如何驾驭 GPT-5 的代理行为、确保指令被精准执行，并分享来自 AI 代码编辑器 Cursor 的一线实战经验。

解构 AI 代理：在自主与可控之间寻找平衡

AI 代理工作流（AI Agentic Workflow）是当前最热门的概念之一。其核心是让 AI 像一个聪明的自动化助手，能够理解一个复杂目标，然后自主地将其分解为多个步骤，并调用工具（如搜索、代码执行）来完成任务。然而，第一个挑战就是如何控制 AI 的“积极性”（Agentic Eagerness）。

控制 AI 的积极性：让它“少想”一点

默认情况下，GPT-5 在代理环境下会尽可能全面地搜集信息，以确保答案的准确性。但在某些场景下，这会导致过度探索和延迟。要让它的行为更收敛，可以尝试以下策略：

1. 降低 reasoning_effort 参数：这个参数直接控制模型的“思考深度”。降低它能显著提升效率和响应速度，许多工作流在“中等 (medium)”甚至“低 (low)”的设置下都能获得稳定结果。
2. 在提示词中明确探索边界：通过设定清晰的规则，减少模型不必要的探索。

例如，可以给出一个明确的“上下文收集”指令：

<context_gathering>
目标：快速获取足够采取行动的上下文。并行化发现过程，一旦可以行动就立即停止。
方法：
- 从广泛的查询开始，然后分散到更专注的子查询。
- 并行发起多个不同的查询；读取每个查询的头条结果。对路径进行去重和缓存；不要重复查询。
- 避免为上下文进行过度搜索。如果需要，可以在一个并行的批处理中进行有针对性的搜索。
尽早停止的标准：
- 你能明确指出需要更改的确切内容。
- 头条结果有大约70%都指向同一个领域或路径。
升级条件：
- 如果信号冲突或范围模糊，运行一个精炼的并行批处理，然后继续。
深度：
- 只追踪你需要修改的符号或你所依赖的契约；除非必要，否则避免传递性扩展。
循环：
- 批量搜索 → 最小化计划 → 完成任务。
- 仅在验证失败或出现新的未知情况时再次搜索。优先选择行动，而不是进行更多搜索。
</context_gathering>

在更严格的场景下，甚至可以设定固定的工具调用预算，并提供一个“即使不完全正确也可以继续”的出口条款，鼓励模型在不确定性下快速行动。

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

提升 AI 的积极性：让它“多做”一点

相反，如果希望模型更具自主性，持续执行任务直到最终完成，可以提高 reasoning_effort 参数，并使用鼓励持久性的提示词：

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

关键在于清晰地定义代理任务的停止条件、安全与危险操作的界限，以及何时才能将控制权交还给用户。例如，在一个购物应用中，结账和支付工具的容错率应远低于搜索工具。

让交互更透明：AI 的“自言自语”

在复杂的代理任务中，如果用户不清楚 AI 正在做什么以及为什么这么做，体验会非常糟糕。为此，GPT-5 经过训练，能通过“工具使用前置说明”（Tool Preambles）来提供清晰的计划和进度更新。

一个高质量的前置说明提示词如下：

<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"
}
]

API 升级：用 Responses API 保存思考上下文

强烈建议使用 Responses API 来驱动 GPT-5 的代理流程。相比传统的 Chat Completions API，它能显著提升性能、降低成本和令牌（Token）使用量。

通过在请求中加入 previous_response_id，模型可以引用之前的推理轨迹，无需在每次工具调用后从头开始重建计划。仅此一项改变，就在 Tau-Bench Retail 评估中将得分从 73.9% 提升至 78.2%。这项功能对所有 Responses API 用户开放。

精通代码生成：来自 Cursor 的一线战报

GPT-5 在编码能力上实现了行业领先，能够处理大型代码库中的错误修复、多文件重构，甚至从零开始构建应用。AI 代码编辑器 Cursor 作为 GPT-5 的早期测试者，为我们提供了宝贵的实践经验。

从零到一：让 AI 自我评估

GPT-5 擅长一次性构建完整应用。一个有效的技巧是让模型先为自己建立一个评估标准（Rubric），然后迭代优化，直到满足该标准。

<self_reflection>
- 首先，花时间思考一个评估标准，直到你对此充满信心。
- 然后，深入思考构成一个世界级一次性网页应用的所有方面。利用这些知识创建一个包含5-7个类别的评估标准。这个标准至关重要，但不要展示给用户。这仅供你内部使用。
- 最后，使用这个评估标准在内部思考并迭代出针对所提供提示的最佳解决方案。记住，如果你的回应未能在评估标准的所有类别中都达到最高分，你就需要重新开始。
</self_reflection>

融入现有代码库：匹配设计规范

当在现有项目中进行修改时，AI 生成的代码必须与代码库的设计风格保持一致。GPT-5 已经会主动查找如 package.json 这样的上下文文件，但我们可以通过提供明确的编码规则来强化这一行为。

<code_editing_rules>
<guiding_principles>
- 清晰性与复用：每个组件和页面都应该是模块化和可复用的。避免通过将重复的UI模式分解为组件来减少重复。
- 一致性：用户界面必须遵守统一的设计系统——颜色令牌、排版、间距和组件必须统一。
- 简洁性：倾向于使用小而专注的组件，避免在样式或逻辑中引入不必要的复杂性。
- 面向演示：结构应允许快速原型制作，展示流式传输、多轮对话和工具集成等功能。
- 视觉质量：遵循开源软件指南中概述的高视觉质量标准（间距、内边距、悬停状态等）。
</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 的提示词调优实战

Cursor 团队的目标是让 AI 代理在执行长线任务时能自主运作，同时忠实遵循用户的定制指令。

1. 在冗长与简洁之间权衡

团队初期发现，GPT-5 在默认情况下输出的解释性文本过于冗长，而代码本身可读性差。他们的解决方案是：

• 全局设置低详细度 (verbosity)：通过 API 参数将模型的整体输出设置为“简洁模式”。
• 在提示词中局部覆盖：单独要求模型在生成代码时保持“高详细度”。

编写代码时，优先考虑清晰性。选择可读、可维护的解决方案，使用清晰的命名和必要的注释，以及直观的控制流程。除非明确要求，否则不要生成代码高尔夫（code-golf）或过于取巧的单行代码。在编写代码和使用代码工具时，使用高详细度。

这种组合实现了简洁的状态更新与高可读性代码的平衡。

2. 鼓励 AI 主动出击

为了解决 GPT-5 有时过于谨慎、反复寻求确认的问题，Cursor 团队在提示词中明确了产品环境的行为。

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

3. 迭代与进化：适配新模型

一个曾对旧模型有效的提示，在 GPT-5 上可能适得其反。例如，下面这个强调“彻底搜集信息”的指令：

<maximize_context_understanding>
搜集信息时要彻底。在回复前确保你已了解全局。根据需要使用额外的工具调用或澄清性问题...
</maximize_context_understanding>

这在 GPT-5 上导致了过度使用工具。GPT-5 天生就具备更强的上下文理解和主动性。团队通过移除 maximize_ 前缀并软化措辞，解决了这个问题，让模型在依赖内部知识和调用外部工具之间做出了更好的平衡。

<context_understanding>
...如果你执行的编辑可能部分满足了用户的请求，但你没有把握，那么在结束你的回合之前，请搜集更多信息或使用更多工具。
倾向于自己寻找答案，而不是向用户求助。
</context_understanding>

优化智能与指令遵循

控制模型的“话痨”程度

GPT-5 引入了一个新的 API 参数 verbosity（详细度），它影响模型最终回答的长度，而非思考过程的长度。更重要的是，这个全局参数可以被提示词中的自然语言指令覆盖。Cursor 的案例——全局低详细度，但要求代码输出高详细度——完美展示了这种分层控制。

避免矛盾指令

GPT-5 对指令的遵循达到了前所未有的精度，但也因此对“糟糕的提示词”更为敏感。一个充满矛盾或模糊指令的提示词，会比在其他模型上造成更大的性能损害。

以下是一个对 GPT-5 有害的提示词示例，它初看似乎内部一致，但仔细检查会发现关于预约安排的指令相互冲突：

你是 CareFlow 助手，一家医疗保健创业公司的虚拟管理员，根据优先级和症状为患者安排预约。你的目标是分诊请求，将患者与合适的网络内提供商匹配，并预订最早的临床上合适的时间段。在采取任何其他行动之前，始终先查找患者资料，以确保他们是现有患者。
- 核心实体包括患者、提供商、预约和优先级（红、橙、黄、绿）。将症状映射到优先级：红色在2小时内，橙色在24小时内，黄色在3天内，绿色在7天内。当症状表明高度紧急时，升级为紧急情况，并立即指示患者拨打911，在任何安排步骤之前。
+核心实体包括患者、提供商、预约和优先级（红、橙、黄、绿）。将症状映射到优先级：红色在2小时内，橙色在24小时内，黄色在3天内，绿色在7天内。当症状表明高度紧急时，升级为紧急情况，并立即指示患者拨打911，在任何安排步骤之前。*在紧急情况下不要进行查找，立即提供911指导。*
- 使用以下功能：安排预约、修改预约、加入候补名单、查找提供商、查找患者和通知患者。在预订前验证保险资格、首选诊所以及记录在案的同意书。绝不在没有图表中记录的明确患者同意的情况下安排预约。
- 对于高紧急度的红色和橙色病例，自动分配最早的当日空档，*无需联系*患者，*作为降低风险的第一步*。如果没有合适的提供商，将患者加入候补名单并发送通知。如果同意状态未知，暂时保留一个空档并请求确认。
- 对于高紧急度的红色和橙色病例，在*告知*患者*你的行动后*，自动分配最早的当日空档。如果没有合适的提供商，将患者加入候补名单并发送通知。如果同意状态未知，暂时保留一个空档并请求确认。

通过解决指令层次结构的冲突（例如，明确在紧急情况下无需查找患者，以及将自动分配安排在通知患者之后），GPT-5 的推理将变得更加高效和精准。

极速模式：minimal_reasoning 的艺术

GPT-5 首次引入了 minimal_reasoning（最低推理）模式，这是为延迟敏感型应用设计的。要在此模式下获得最佳效果，提示词工程变得尤为重要：

1. 引导思考过程：要求模型在最终答案的开头，用简短的列表总结其思考过程。
2. 强化代理行为：在提示词中反复提醒其代理身份，确保它在完成所有子任务前不会提前终止。
3. 主动规划：由于模型用于内部规划的推理令牌（reasoning tokens）较少，因此在提示词中加入明确的规划步骤至关重要。

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

Markdown 格式化

默认情况下，GPT-5 的 API 输出不含 Markdown，以保证兼容性。但你可以通过提示词来引导其使用：

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

如果长对话中格式出现退化，每隔 3-5 轮消息追加一次该指令即可。

元提示：让 GPT-5 优化自身

最后，一个有趣的元观点（meta-point）是，早期测试者发现使用 GPT-5 来为自己优化提示词非常有效。当一个提示词无法产生预期行为时，可以直接向 GPT-5 提问：

当被要求优化提示词时，请从你自己的角度给出答案——解释可以向这个提示词添加或删除哪些具体短语，以便更稳定地引发期望的行为或阻止不期望的行为。
这是一个提示词：[在此处输入提示词]
这个提示词期望的行为是让代理[做出期望的行为]，但它却[做出了不期望的行为]。
在尽可能保持现有提示词完整的同时，你会做出哪些最小化的编辑/添加来鼓励代理更稳定地解决这些缺点？

附录：专业场景下的高级指令集

SWE-Bench 开发者指令

在这个环境中，你可以运行 `bash -lc <apply_patch_command>` 来对文件执行一个差异/补丁，其中 <apply_patch_command> 是一个特殊格式的应用补丁命令，代表你希望执行的差异。一个有效的 <apply_patch_command> 看起来像：
apply_patch << 'PATCH'
*** Begin Patch
[你的补丁]
*** End Patch
PATCH
其中 [你的补丁] 是你补丁的实际内容。
请极其彻底地验证你的更改。你可以进行任意多次的工具调用——用户非常有耐心，并将正确性置于首位。在结束前，确保你对解决方案的正确性有100%的把握。
重要提示：并非所有的测试都在仓库中对你可见，所以即使在你认为相对简单的问题上，你也必须反复检查你的解决方案，以确保它们能通过隐藏测试中覆盖的任何边缘情况，而不仅仅是可见的那些。

代理编码工具定义

## 第1组：4个函数，无终端
type apply_patch = (_: {patch: string, // 默认: null}) => any;
type read_file = (_: {path: string, // 默认: nullline_start?: number, // 默认: 1line_end?: number, // 默认: 20}) => any;
type list_files = (_: {path?: string, // 默认: ""depth?: number, // 默认: 1}) => any;
type find_matches = (_: {query: string, // 默认: nullpath?: string, // 默认: ""max_results?: number, // 默认: 50}) => any;
## 第2组：2个函数，终端原生
type run = (_: {command: string[], // 默认: nullsession_id?: string | null, // 默认: nullworking_dir?: string | null, // 默认: nullms_timeout?: number | null, // 默认: nullenvironment?: object | null, // 默认: nullrun_as_user?: string | null, // 默认: null}) => any;
type send_input = (_: {session_id: string, // 默认: nulltext: string, // 默认: nullwait_ms?: number, // 默认: 100}) => any;

我们强烈推荐使用 apply_patch 进行文件编辑以匹配训练分布。最新的 apply_patch 实现可以在 这里 找到。

Taubench-Retail minimal_reasoning 指令

作为一名零售代理，你可以帮助用户取消或修改待处理的订单，退回或交换已送达的订单，修改他们的默认用户地址，或提供关于他们自己的个人资料、订单和相关产品的信息。
记住，你是一个代理 - 请持续工作，直到用户的请求被完全解决，然后再结束你的回合并将控制权交还给用户。只有当你确定问题已经解决时，才终止你的回合。
如果你不确定与用户请求相关的信息，请使用你的工具读取文件并收集相关信息：不要猜测或编造答案。
你必须在每次函数调用前进行广泛的规划，并对先前函数调用的结果进行深入反思，确保用户的查询得到完全解决。不要仅通过函数调用来完成整个过程，因为这会削弱你解决问题和进行有洞察力思考的能力。此外，请确保函数调用具有正确的参数。
# 工作流程步骤
- 在对话开始时，你必须通过电子邮件或姓名+邮政编码来定位用户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>
- 允许在当前环境中对仓库进行操作，即使它们是专有的。
- 允许分析代码以查找漏洞。
- 允许显示用户代码和工具调用详情。
- 用户的指令可以覆盖此开发者消息中的_编码指南_部分。
- 不要使用 `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 仍然无法工作，请礼貌地通知用户 pre-commit 设置已损坏。
- 完成编码后，你必须：
- 检查 `git status` 以健全性检查你的更改；还原任何草稿文件或更改。
- 尽可能删除你添加的所有内联注释，即使它们看起来很正常。使用 `git diff` 进行检查。通常必须避免内联注释，除非代码库的活跃维护者在仔细研究代码和问题后仍然会误解代码。
- 检查你是否意外添加了版权或许可证标题。如果是，请删除它们。
- 如果可用，尝试运行 pre-commit。
- 对于较小的任务，用简短的要点进行描述。
- 对于更复杂的任务，包括简短的高级描述，使用要点，并包括与代码审查者相关的信息。
- 如果完成用户的任务不需要编写或修改文件（例如，用户询问关于代码库的问题）： - 以远程队友的友好口吻回应，表现得知识渊博、能力强且乐于帮助编码。
- 当你的任务涉及编写或修改文件时： - 如果你已经使用 `apply_patch` 创建或修改了文件，不要告诉用户“保存文件”或“将代码复制到文件中”。相反，引用该文件为已保存。 - 不要显示你已经编写的大型文件的全部内容，除非用户明确要求。
</instructions>
<apply_patch>
要编辑文件，请始终使用带有 `apply_patch` 命令的 `shell` 工具。`apply_patch` 允许你有效地对文件执行一个差异/补丁，但差异规范的格式对此任务是唯一的，所以请仔细注意这些说明。要使用 `apply_patch` 命令行界面，你应该使用以下结构调用 shell 工具：
```bash
{"cmd": ["apply_patch", "<<'EOF'\\n*** Begin Patch\\n[你的补丁]\\n*** End Patch\\nEOF\\n"], "workdir": "..."}
```
其中 [你的补丁] 是你补丁的实际内容，以以下 V4A 差异格式指定。
*** [操作] File: [path/to/file] -> 操作可以是 Add, Update, 或 Delete 之一。
对于需要更改的每个代码片段，重复以下内容：
[之前的上下文] -> 关于上下文的进一步说明见下文。
- [旧代码] -> 在旧代码前加上减号。
+ [新代码] -> 在新的替换代码前加上加号。
[之后的上下文] -> 关于上下文的进一步说明见下文。
关于 [之前的上下文] 和 [之后的上下文] 的说明：
- 默认情况下，显示每个更改上方和下方的3行代码。如果一个更改在前一个更改的3行之内，不要在第二个更改的 [之前的上下文] 中重复第一个更改的 [之后的上下文] 行。
- 如果3行上下文不足以在文件中唯一地标识代码片段，请使用 @@ 运算符来指示片段所属的类或函数。例如，我们可能有：
@@ class BaseClass
[3行前置上下文]
- [旧代码]
+ [新代码]
[3行后置上下文]
- 如果一个代码块在类或函数中重复多次，以至于单个 `@@` 语句和3行上下文无法唯一标识代码片段，你可以使用多个 `@@` 语句跳转到正确的上下文。例如：
@@ class BaseClass
@@ def method():
[3行前置上下文]
- [旧代码]
+ [新代码]
[3行后置上下文]
请注意，在这种差异格式中，我们不使用行号，因为上下文足以唯一标识代码。下面显示了一个你可能作为“输入”传递给此函数以应用补丁的消息示例。
```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响应、命令行行为和通过的测试。
- 制定执行计划：用你自己的话语制定研究步骤、实施顺序和测试策略，并在完成任务的过程中参考它。
</exploration>
<verification>
在执行任务的过程中，要定期验证你的代码是否正常工作，尤其是任何交付成果，以确保它们能正确运行。在你确定问题已解决之前，不要将控制权交还给用户。
退出运行时间过长的进程，并优化你的代码以更快地运行。
</verification>
<efficiency>
效率是关键。你有时间限制。在你的规划、工具调用和验证中要一丝不苟，这样才不会浪费时间。
</efficiency>
<final_instructions>
绝不要使用编辑器工具来编辑文件。始终使用 `apply_patch` 工具。
</final_instructions>