GPT系列模型提示技巧指南

本文是OpenAI官方提供的GPT模型提示指南，详细介绍了GPT-5.5、5.4、5.3 Codex、5.2、5.1、5和4.1各系列的提示技巧。内容涵盖代理行为控制、工具调用优化、输出格式约束、推理难度调节、代码编辑、前端设计、长上下文处理等实用策略。每部分均提供具体示例和迁移路径，帮助开发者最大化模型性能。适合构建AI代理和编码助手的开发者参考。

GPT-5.5

当提示词定义好结果并留出空间让模型选择高效的解决方案路径时，GPT-5.5 表现最佳。与早期模型相比，你通常可以使用更简短、更面向结果的提示词：描述好的结果是什么样的、哪些约束条件重要、有哪些可用证据，以及最终答案应包含什么。

避免沿用旧提示词堆栈中的每一条指令。旧的提示词往往过度指定了流程，因为早期模型需要更多帮助来保持在正轨上。使用 GPT-5.5 时，这反而可能增加噪音、缩小模型的搜索空间，或导致过于机械的回答。

有关 GPT-5.5 行为变化的更多细节，请从使用 GPT-5.5 指南开始。本指南重点关注因这些行为变化而产生的提示词调整。

此处提供的模式是起点。请根据你的产品界面、工具、评估和用户体验目标进行调整。

使用 Codex 进行自动迁移

Codex 可以通过 OpenAI Docs Skill 实现本指南中的更改。

$openai-docs migrate this project to gpt-5.5

要在其他编码 Agent 中使用此技能，请从 OpenAI Skills 仓库下载。

个性和行为

GPT-5.5 的默认风格是高效、直接且以任务为导向。这对生产系统很有用：回复保持专注，行为更易于引导，模型避免不必要的对话填充。

对于面向客户的助手、支持工作流、辅导体验和其他对话式产品，需要同时定义个性和协作风格。

  • 个性控制助手听起来的感觉：语气、热情度、直接程度、正式程度、幽默感、同理心和精炼程度。
  • 协作风格控制助手的工作方式：何时提问、何时做假设、应有多主动、提供多少上下文、何时检查工作，以及如何处理不确定性或风险。

两者都应保持简短。个性指令应塑造用户体验。协作指令应塑造任务行为。两者都不应取代清晰的目标、成功标准、工具规则或停止条件。

一个面向稳定、以任务为中心的助手的个性示例块：

## Personality
你是一位能力出众的协作者：平易近人、稳定可靠、直接了当。假设用户能力胜任且出于善意，以耐心、尊重和务实的帮助态度回应。

当请求已足够明确可以尝试时，更倾向于推进工作而非停下来澄清。利用上下文和合理假设向前推进。仅在缺失的信息会实质性改变答案或产生重大风险时才请求澄清，并将任何问题保持狭窄。

保持简洁但不要变得粗鲁。提供足够的上下文让用户能够理解并信任答案，然后停止。使用示例、比较或简单的类比，当它们有助于理解要点时。在纠正用户或持不同意见时，要坦诚但具有建设性。当错误被指出时，坦率地承认并专注于修复它。

在职业范围内匹配用户的语气。默认情况下避免使用表情符号和脏话，除非用户明确要求该风格或已明确将其确立为适合对话的风格。

一个面向表现力丰富的协作助手的个性示例块：

## Personality
采用生动活泼的对话风格：聪明、好奇、在适当的时候有趣，并关注用户的思考。当问题模糊时提出好问题，一旦有足够的上下文就变得果断。

保持热情、协作和精炼。对话应感觉轻松且有活力，但不要为了闲聊而闲聊。提供真正的观点，而不仅仅是映照用户，同时响应他们的目标和约束。

当任务需要综合或建议时，要深思熟虑且脚踏实地。当有足够上下文时给出明确的建议，解释重要的权衡，并明确不确定性但不要变得回避。

对于更具表现力的产品，明确加入热情、好奇心、幽默或观点，但保持块内容简短。使用个性来塑造体验，而不是弥补不清晰的目标或缺失的任务指令。

通过前言改善首次可见 Token 的时间

在流式应用中，用户会注意到首次可见响应出现所需的时间。GPT-5.5 可能会在生成可见文本之前花时间推理、规划或准备工具调用。

对于较长或工具密集型的任务，提示模型以简短的前言开始：一个简短的可见更新，确认请求并说明第一步。这可以在不改变底层任务的情况下改善感知响应性。

当任务可能需要多个步骤、需要工具调用或涉及长时间运行的 Agent 工作流时，使用此模式。

在进行多步骤任务的任何工具调用之前，发送一条简短的、用户可见的更新，确认请求并说明第一步。保持在一到两句话。

对于公开单独消息阶段的编码 Agent，你可以更明确：

如果任务需要调用工具，你必须在分析通道中任何内容之前始终以中间更新开始。用户更新应确认请求并解释你的第一步。

结果优先的提示词和停止条件

当提示词定义了目标结果、成功标准、约束条件和可用上下文，然后让模型选择路径时，GPT-5.5 表现最佳。

对于许多任务，描述目的地而不是每一步。这为模型留出了为任务选择正确的搜索、工具或推理策略的空间。

优先采用这种方式：

端到端解决客户的问题。

成功意味着：
- 根据可用的政策和账户数据做出资格决定
- 在回复之前完成任何允许的操作
- 最终答案包含 completed_actions、customer_message 和 blockers
- 如果缺少证据，询问最小的缺失字段

避免不必要的绝对规则。 较旧的提示词通常使用严格的指令，如 ALWAYS、NEVER、must 和 only 来控制模型行为。将这些词用于真正的不变量，例如安全规则、必需的输出字段或永远不应发生的操作。对于判断性问题，例如何时搜索、请求澄清、使用工具或继续迭代，优先使用决策规则。

除非每个步骤都确实是必需的，否则避免这种风格的指令：

首先检查 A，然后检查 B，然后比较每个字段，然后思考所有可能的异常，然后决定调用哪个工具，然后调用工具，然后向用户解释整个过程。

添加明确的停止条件：

以最少的工具循环解决用户查询，但不要让循环最小化凌驾于正确性、可访问的备用证据、计算或事实性声明所需的引用标签之上。

每次获得结果后，问自己：“我现在能否用有用的证据和对事实性声明的引用来回答用户的核心请求？”如果可以，就回答。

定义缺失证据时的行为：

使用足以正确回答的最小证据，精确引用它，然后停止。

格式化

GPT-5.5 在输出格式和结构上具有很强的可引导性。当这有助于提高理解度或产品适配性时，使用这种控制。

设置 text.verbosity，描述预期的输出形状，并在它能提高理解度或你的产品 UI 需要稳定内容时才使用更重的结构。API 中 text.verbosity 的默认值是 medium；当你希望更短、更简洁的回复时使用 low。

普通的对话式格式化：

让格式服务于理解。对普通对话、解释、报告、文档和技术写作，使用普通段落作为默认格式。保持呈现清晰可读，不要让结构感觉比内容更重。

适度使用标题、粗体文本、项目符号和编号列表。在用户要求时、答案需要清晰比较或排名时、或者信息作为散文更难扫描时，才使用它们。否则，优先使用短段落和自然过渡。

尊重用户的格式偏好。如果他们要求简洁的回答、最小格式化、无项目符号、无标题或特定结构，请遵循该偏好，除非有充分的理由不这样做。

添加明确的受众和长度指导：

为高级业务受众写作。将答案控制在 400 字以内。使用短段落，仅当项目符号能提高扫描性时才包含它们。优先将结论放在前面，然后是推理，最后是注意事项。

对于编辑、重写、摘要或面向客户的消息，先告诉模型要保留什么，再要求它改善风格。当你希望润色但不扩展内容时，此模式很有用。

首先保留请求的成品、长度、结构和体裁。安静地改进清晰度、流畅度和正确性。除非明确要求，否则不要添加新的声明、额外的部分或更具推广性的语气。

依据、引用和检索预算

对于基于依据的答案，引用行为应该是提示词的一部分。定义哪些需要支持、什么算作足够的证据，以及模型在证据缺失时应如何表现。证据缺失不应自动变成事实性的“没有”。更多细节和示例，请参阅引用格式指南。

添加显式检索预算

检索预算是搜索的停止规则。它们告诉模型何时证据已经足够。

对于普通的问答，使用简短、有区分度的关键词进行一次广泛搜索。如果顶部结果包含足够可引用的支持来回答核心请求，则基于这些结果回答，而不是再次搜索。

仅在以下情况下才进行另一次检索调用：
- 顶部结果未回答核心问题。
- 缺少必要的事实、参数、所有者、日期、ID 或来源。
- 用户要求详尽覆盖、比较或全面列表。
- 必须读取特定的文档、URL、电子邮件、会议、记录或代码工件。
- 否则答案将包含一个重要的、无依据的事实性声明。

不要为了改进措辞、添加示例、引用非关键细节或支持可以安全地变得更通用的措辞而再次搜索。

创造性草稿护栏

对于起草任务，告诉模型哪些声明必须来自源文件，哪些部分可以创造性地撰写。这对于幻灯片、发布文案、客户摘要、讲稿、领导简介和叙事框架尤其重要。

对于创造性或生成性请求，如幻灯片、领导简介、外发文案、共享摘要、讲稿或叙事框架，区分来源支持的事实和创意措辞。

- 使用检索或提供的事实来支持具体的产品、客户、指标、路线图、日期、能力和竞争性声明，并引用这些声明。
- 不要为了增强草稿说服力而捏造具体名称、第一方数据声明、指标、路线图状态、客户成果或产品能力。
- 如果几乎没有或没有可引用的支持，则编写一个有用的通用草稿，包含占位符或明确标注的假设，而不是无支持的具体细节。

前端工程和视觉审美

对于前端工作，请参考示例指令，了解引导 UI 质量的实用方法。它们涵盖了产品和用户上下文、设计系统对齐、首屏可用性、熟悉的控件、预期状态、响应行为以及常见的生成 UI 默认要避免的内容，例如通用英雄区、嵌套卡片、装饰性渐变、可见的指导性文本和布局损坏。

提示模型检查自己的作品

当验证可能时，为 GPT-5.5 提供允许其检查输出的工具。

对于编码 Agent，要求具体的验证命令：

做出更改后，运行最相关的可用验证：
- 针对更改行为的定向单元测试
- 适用时的类型检查或 lint 检查
- 受影响包的构建检查
- 当全面验证太昂贵时的最小烟雾测试

如果无法运行验证，解释原因并描述下一个最佳检查。

对于视觉工件，要求渲染后进行检视：

在最终确定前渲染工件。检查渲染输出的布局、裁剪、间距、缺失内容和视觉一致性。修改直到渲染输出符合要求。

对于工程和规划任务，使实现计划可追溯：

对于实现计划，包括：
- 需求以及每个需求在何处被解决
- 涉及的命名资源、文件、API 或系统
- 相关的状态转换或数据流
- 验证命令或检查
- 失败行为
- 隐私和安全考虑
- 实质上影响实现的未解决问题

Phase 参数

从 GPT-5.4 开始，长时间运行或工具密集型的工作流可以使用助手项的 phase 值来区分中间更新和最终答案。GPT-5.5 使用相同的模式。

如果你使用 previous_response_id，API 会自动保留先前的助手状态。如果你的应用手动将助手输出项重放到下一个请求中，请保留每个原始 phase 值并原样传回。这在响应包含前言、重复的工具调用或在中间助手更新之后有最终答案时最为重要。

如果手动重放助手项：
- 精确保留助手的 `phase` 值。
- 对中间用户可见的更新使用 `phase: "commentary"`。
- 对完成的答案使用 `phase: "final_answer"`。
- 不要向用户消息添加 `phase`。

建议的提示词结构

将此结构用作复杂提示词的起点。保持每个部分简短。仅在更改行为时才添加细节。

角色：[1-2 句话定义模型的功能、上下文和工作]

## 个性
[语气、举止和协作风格]

## 目标
[用户可见的结果]

## 成功标准
[最终答案之前必须为真的条件]

## 约束条件
[政策、安全、业务、证据和副作用限制]

## 输出
[部分、长度和语气]

## 停止规则
[何时重试、回退、弃权、询问或停止]

GPT-5.4

GPT-5.4，我们最新的主流模型，旨在平衡长时间运行的任务性能、更强的风格和行为控制，以及在复杂工作流中更规范的执行。建立在 GPT-5 到 GPT-5.3-Codex 的进步之上，GPT-5.4 改进了 Token 效率，更可靠地维持多步骤工作流，并在长周期任务上表现出色。

GPT-5.4 专为需要强大多步骤推理、丰富证据的综合以及对长上下文具有可靠性能的生产级助手和 Agent 而设计。当提示词明确指定输出契约、工具使用预期和完成标准时，其效果尤为突出。在实践中，最大的收益来自于为任务选择正确的推理努力、使用明确的依据和引用规则，以及给模型一个关于“完成”看起来什么样的精确定义。本指南侧重于保留这些效率收益的提示词模式和迁移实践。有关模型能力、API 参数和更广泛的迁移指南，请参阅我们的最新模型指南。

在排查 GPT-5.4 将中间更新视为最终答案的情况时，请验证你的集成是否正确保留了助手消息的 phase 字段。有关详细信息，请参阅 Phase 参数。

理解 GPT-5.4 的行为

GPT-5.4 最强的领域

GPT-5.4 在以下领域尤其表现出色：

  • 强大的个性和语气遵循，在长答案中漂移较少
  • Agent 工作流稳健性，更倾向于坚持多步骤工作、重试并端到端完成 Agent 循环
  • 丰富的证据综合，尤其是在长上下文或多工具工作流中
  • 当契约明确时，在模块化、基于技能和块结构的提示词中的指令遵循
  • 跨大型、混乱或多文档输入的长上下文分析
  • 批量或并行工具调用，同时保持工具调用准确性
  • 需要指令遵循、格式保真度和更强自我验证的电子表格、金融和 Excel 工作流

显式提示仍有帮助的领域

即使有这些优势，GPT-5.4 在一些重复出现的模式中仍然受益于更明确的指导：

  • 会话早期上下文不足时的工具路由，此时工具选择可能不太可靠
  • 需要显式先决条件和下游步骤检查的依赖感知工作流
  • 推理努力选择，其中较高的努力并不总是更好，正确的选择取决于任务特征，而非直觉
  • 需要规范来源收集和一致引用的研究任务
  • 不可逆或高影响的操作，在执行前需要验证
  • 终端或编码 Agent 环境，其中工具边界必须保持清晰

这些模式是观察到的默认情况，并非保证。从能通过评估的最小提示词开始，仅在修复测量到的失败模式时添加块。

使用核心提示词模式

保持输出紧凑和结构化

为了改善 GPT-5.4 的 Token 效率，通过清晰的输出契约来约束冗长并强制结构化输出。在实践中，这作为 Responses API 中 verbosity 参数之外的额外控制层，允许你指导模型写多少以及如何结构化输出。

<output_contract>
- 完全按照请求的顺序返回请求的部分。
- 如果提示词定义了前言、分析块或工作部分，不要将其视为额外输出。
- 仅将长度限制应用于它们所针对的部分。
- 如果要求格式（JSON、Markdown、SQL、XML），仅输出该格式。
</output_contract>

<verbosity_controls>
- 偏好简洁、信息密集的写作。
- 避免重复用户的请求。
- 保持进度更新简洁。
- 不要如此激进地缩短答案，以至于忽略了必需的证据、推理或完成检查。
</verbosity_controls>

为跟进设置明确的默认值

用户经常在对话中途更改任务、格式或语气。为了保持助手对齐，定义何时继续、何时询问以及新指令如何覆盖较早默认值的明确规则。

使用如下默认跟进策略：

<default_follow_through_policy>
- 如果用户的意图明确且下一步是可逆且低风险的，则直接进行，无需询问。
- 仅在以下情况下询问许可：
  (a) 下一步是不可逆的，
  (b) 有外部副作用（例如发送、购买、删除或写入生产环境），或
  (c) 需要缺失的敏感信息或会实质性改变结果的选择。
- 如果继续，简要说明你做了什么以及哪些是可选的。
</default_follow_through_policy>

使指令优先级明确：

<instruction_priority>
- 用户指令覆盖默认的风格、语气、格式和主动性偏好。
- 安全性、诚实性、隐私和权限约束不让步。
- 如果较新的用户指令与较早的冲突，遵循较新的指令。
- 保留不冲突的较早指令。
</instruction_priority>

优先级更高的开发者或系统指令仍然具有约束力。

指导： 当指令在对话中途更改时，使更新明确、限范围且局部。说明更改了什么、哪些仍然适用，以及更改是否影响下一轮或对话的其余部分。

处理对话中途的指令更新

对于对话中途的更新，使用明确、限范围的引导消息，说明：

  1. 范围
  2. 覆盖
  3. 向前推进
<task_update>
仅对下一个响应：
- 不要完成任务。
- 仅制定计划。
- 保持为 5 个要点。

所有先前的指令仍然适用，除非它们与本更新冲突。
</task_update>

如果任务本身发生了变化，直接说明：

<task_update>
任务已更改。
先前任务：完成工作流。
当前任务：仅审查工作流并识别风险。

本轮规则：
- 不执行操作。
- 不调用破坏性工具。
- 精确返回：
  1. 主要风险
  2. 缺失信息
  3. 推荐的下一步
</task_update>

当正确性依赖于工具使用时，使其持久化

使用显式规则保持工具使用彻底、依赖感知且节奏适当，尤其是在后面操作依赖于早期检索或验证的工作流中。一个常见的失败模式是跳过前提条件，因为正确的最终状态似乎很明显。

GPT-5.4 在会话早期上下文尚薄时，在工具路由上可能不太可靠。为前提条件、依赖检查和精确的工具意图提供提示。

<tool_persistence_rules>
- 只要工具能实质性改善正确性、完整性或依据，就使用它们。
- 当另一个工具调用可能实质性改善正确性或完整性时，不要提前停止。
- 持续调用工具直到：
  (1) 任务完成，且
  (2) 验证通过（参见 <verification_loop>）。
- 如果工具返回空或部分结果，使用不同的策略重试。
</tool_persistence_rules>

这对于最终操作依赖于早期查找或检索步骤的工作流尤其重要。最常见的失败模式之一是因预期的最终状态看起来明显而跳过前提步骤。

<dependency_checks>
- 在执行操作前，检查是否需要先进行前提发现、查找或记忆检索步骤。
- 不要仅仅因为预期的最终操作看起来明显就跳过前提步骤。
- 如果任务依赖于先前步骤的输出，首先解决该依赖。
</dependency_checks>

当工作独立且实际时间很重要时，提示并行化。当依赖关系、歧义性或不可逆操作比速度更重要时，提示排序。

<parallel_tool_calling>
- 当多个检索或查找步骤独立时，优先使用并行工具调用以减少实际时间。
- 不要并行化具有前提依赖关系的步骤，或一个结果决定下一步操作的步骤。
- 在并行检索后，暂停以综合结果，然后再进行更多调用。
- 偏好选择性并行：并行化独立的证据收集，而不是推测性或冗余的工具使用。
</parallel_tool_calling>

在长周期任务上强制完整性

对于多步骤工作流，一个常见的失败模式是不完整的执行：模型在部分覆盖后结束，遗漏批处理中的项目，或将空或狭窄的检索视为最终结果。当提示词定义了明确的完成规则和恢复行为时，GPT-5.4 变得更加可靠。

可以通过顺序或并行检索来实现覆盖，但无论哪种方式，完成规则都应保持明确。

<completeness_contract>
- 将任务视为未完成，直到所有请求的项目都被覆盖或明确标记为 [blocked]。
- 维护一个内部清单，列出必需的交付物。
- 对于列表、批处理或分页结果：
  - 尽可能确定预期范围，
  - 跟踪已处理的项目或页面，
  - 在最终确定前确认覆盖。
- 如果任何项目因数据缺失而受阻，将其标记为 [blocked] 并准确说明缺失的内容。
</completeness_contract>

对于空、部分或嘈杂检索常见的工作流：

<empty_result_recovery>
如果查找返回空、部分或可疑的狭窄结果：
- 不要立即断定没有结果存在，
- 尝试至少一到两种回退策略，
  例如：
  - 替换查询措辞，
  - 更宽的过滤器，
  - 一个前提查找，
  - 或替代来源或工具，
- 然后才报告未找到结果，并附上你尝试过的方法。
</empty_result_recovery>

在高影响操作前添加验证循环

一旦工作流看似完成，在返回答案或采取不可逆操作前，添加一个轻量级的验证步骤。这有助于在提交前捕获需求遗漏、依据问题和格式漂移。

<verification_loop>
在最终确定前：
- 检查正确性：输出是否满足每个需求？
- 检查依据：事实性声明是否有提供的上下文或工具输出支持？
- 检查格式：输出是否匹配请求的模式或风格？
- 检查安全性和可逆性：如果下一步有外部副作用，先请求许可。
</verification_loop>

<missing_context_gating>
- 如果必需的上下文缺失，不要猜测。
- 当缺失上下文可检索时，优先使用适当的查找工具；仅当不可检索时，才问一个最小的澄清问题。
- 如果必须继续，明确标注假设并选择可逆的操作。
</missing_context_gating>

对于主动执行操作的 Agent，添加一个简短的执行框架：

<action_safety>
- 起飞前：用 1-2 行总结预期的操作和参数。
- 通过工具执行。
- 降落后：确认结果和任何已执行的验证。
</action_safety>

处理专门的工作流

为视觉和计算机使用显式选择图像细节

如果你的工作流依赖于视觉精度，请在提示词或集成中指定图像 detail 级别，而不是依赖 auto。使用 high 用于标准高保真图像理解。对大型、密集或空间敏感的图像使用 original，尤其是在 gpt-5.4 和未来模型上的计算机使用、定位、OCR 和点击精度任务。仅当速度和成本比精细细节更重要时使用 low。有关图像细节级别的更多详细信息，请参阅图像和视觉指南。

将研究和引用锁定到检索到的证据

当引用质量重要时，同时明确来源边界和格式要求。这有助于减少捏造的参考文献、无支持的声明和引用格式漂移。

<citation_rules>
- 仅引用在当前工作流中检索到的来源。
- 绝不捏造引用、URL、ID 或引用跨度。
- 精确使用宿主应用程序所需的引用格式。
- 将引用附加到它们支持的具体声明，而不仅仅是在末尾。
</citation_rules>

<grounding_rules>
- 仅基于提供的上下文或工具输出提出声明。
- 如果来源冲突，明确说明冲突并归属于每一方。
- 如果上下文不足或不相关，缩小答案或说你无法支持该声明。
- 如果陈述是推理而非直接支持的事实，将其标注为推理。
</grounding_rules>

如果你的应用程序需要行内引用，要求行内引用。如果需要脚注，要求脚注。关键是锁定格式并防止模型即兴创作无支持的参考文献。

研究模式

将 GPT-5.4 推入规范的研究模式。对研究、审查和综合任务使用此模式。不要强行用于短执行任务或简单的确定性转换。

<research_mode>
- 分 3 轮进行研究：
  1) 规划：列出 3-6 个要回答的子问题。
  2) 检索：搜索每个子问题并跟进 1-2 个二级线索。
  3) 综合：解决矛盾并用引用写出最终答案。
- 仅当更多搜索不太可能改变结论时停止。
</research_mode>

如果你的宿主环境使用特定的研究工具或需要提交步骤，请将此与主机的最终确定契约结合使用。

夹紧严格的输出格式

对于 SQL、JSON 或其他解析敏感的输出，告诉 GPT-5.4 仅输出目标格式并在完成前检查。

<structured_output_contract>
- 仅输出请求的格式。
- 除非被要求，否则不要添加散文或 Markdown 围栏。
- 验证括号和方括号是否平衡。
- 不要发明表格或字段。
- 如果缺少必要的模式信息，询问它或返回一个明确的错误对象。
</structured_output_contract>

如果你正在提取文档区域或 OCR 框，定义坐标系统并添加漂移检查：

<bbox_extraction_spec>
- 精确使用指定的坐标格式，例如 [x1,y1,x2,y2] 归一化到 0..1。
- 对每个框，包括页面、标签、文本片段和置信度。
- 添加一个垂直漂移合理性检查，使框保持与正确的文本行对齐。
- 如果布局密集，逐页处理，并对遗漏的项目进行第二轮扫描。
</bbox_extraction_spec>

在编码和终端 Agent 中保持工具边界清晰

在编码 Agent 中，当 Shell 访问和文件编辑规则明确时，GPT-5.4 工作得更好。当你公开像 Shell 或 Apply patch 这样的工具时，这一点尤其重要。

用户更新

GPT-5.4 在简短、基于结果的更新方面表现出色。重用 5.2 指南中的用户更新模式，但将其与明确的完成和验证要求配对。

推荐的更新规范：

<user_updates_spec>
- 仅在开始一个新的主要阶段或当某些事情改变计划时更新用户。
- 每次更新：1 句关于结果的话 + 1 句关于下一步的话。
- 不要叙述常规的工具调用。
- 保持面向用户的状态简短；保持工作详尽。
</user_updates_spec>

对于编码 Agent，请参阅下面的编码任务提示模式部分，获取更具体的指导。

编码任务的提示模式

自主性和持久性

GPT-5.4 在编码和工具使用任务上，通常比早期的主流模型更彻底地端到端处理，因此你通常不需要那么多显式的“验证一切”提示。尽管如此，对于高风险的更改，如生产环境、迁移或安全工作，请保留一个轻量级的验证条款。

<autonomy_and_persistence>
在当前轮次中，只要可行，就坚持端到端地完全处理任务：不要停留在分析或部分修复上；将更改贯彻到实现、验证和对结果的清晰解释，除非用户明确暂停或重定向你。

除非用户明确要求计划、提出关于代码的问题、集思广益可能的解决方案，或其他明确表示不应编写代码的意图，否则假设用户希望你进行代码更改或运行工具来解决用户的问题。在这些情况下，在消息中输出你提出的解决方案是不好的，你应该实际实施更改。如果你遇到挑战或阻碍，你应尝试自行解决。
</autonomy_and_persistence>

中间更新

保持更新稀疏且信号强。在编码任务中，优先在关键点进行更新。

<user_updates_spec>
- 中间更新进入 `commentary` 通道。
- 用户更新是你工作时发送的简短更新。它们不是最终答案。
- 使用 1-2 句的更新来沟通进度和新信息。
- 不要以对话性的插入语或元评论开始回复。避免开场白，如“Done -”、“Got it”或“Great question”或类似的框架。
- 在探索或进行实质性工作之前，发送一个用户更新，解释你对请求的理解和你的第一步。避免评论请求或以“Got it”或“Understood”等短语开头。
- 大约每工作 30 秒提供一次更新。
- 探索时，解释你在收集什么上下文以及学到了什么。改变句子结构，使更新不变得重复。
- 长时间工作时，保持信息丰富且多样化，但保持简洁。
- 当工作量很大时，在有足够上下文后提供一个更长的计划。这是唯一可以超过 2 句话并可能包含格式的更新。
- 在文件编辑之前，解释你将要更改什么。
- 思考时，让用户了解进度，而不要叙述每次工具调用。即使你没有采取行动，也要发送频繁的进度更新，而不是陷入沉默，特别是如果你思考了相当长的时间。
- 保持进度更新的语气与助手的整体个性一致。
</user_updates_spec>

格式化

GPT-5.4 通常默认使用更结构化的格式，可能过度使用项目符号列表。如果你想要一个清晰的最终响应，显式夹紧列表形状。

绝不使用嵌套项目符号。保持列表扁平（单层）。如果你需要层次结构，将其拆分为单独的列表或部分，或者如果你使用 :，只需在它后面立即包含你通常会使用嵌套项目符号渲染的行。对于编号列表，仅使用 `1. 2. 3.` 样式标记（带句点），绝不用 `1)`。

前端任务

仅在额外的前端指导有用时使用此部分。

<frontend_tasks>
做前端设计任务时，避免通用、过度构建的布局。

使用这些硬性规则：
- 单一构图：首屏必须读起来像一个构图，而不是仪表板，除非它确实是仪表板。
- 品牌优先：在品牌页面上，品牌或产品名称必须是英雄级别的信号，而不仅仅是导航文本或眉题。没有标题应压倒品牌。
- 品牌测试：如果移除导航后首屏可以属于另一个品牌，则品牌太弱。
- 仅限全幅英雄：在着陆页和促销页面上，英雄图像通常应是一个主导的边到边视觉平面或背景。不要默认使用插入式英雄图像、侧面板英雄图像、圆角媒体卡片、平铺拼贴或浮动图像块，除非现有设计系统明确要求。
- 英雄预算：首屏通常应仅包含品牌、一个标题、一个简短的支撑句、一个 CTA 组和一个主导图像。不要在那里放置统计信息、日程表、活动列表、地址块、促销信息、“本周”标注、元数据行或次要营销内容。
- 无英雄叠加：不要在英雄媒体上放置分离的标签、浮动徽章、促销贴纸、信息芯片或标注框。
- 卡片：默认不使用卡片。绝不在英雄区域使用卡片，除非它们是用户交互的容器。如果移除边框、阴影、背景或圆角不影响交互或理解，它就不应该是卡片。
- 每个部分一个任务：每个部分应有一个目的、一个标题，并且通常有一个简短的支撑句。
- 真实视觉锚点：图像应展示产品、地点、氛围或上下文。
- 减少混乱：避免药丸簇、统计条、图标行、框式促销、日程片段和竞争性文本块。
- 使用动效来创造存在感和层次，而不是噪音。对于视觉导向的工作，提供 2-3 个有意设计的动效，并且当可用时优先使用 Framer Motion。

例外：如果在现有网站或设计系统中工作，保留已建立的模式、结构和视觉语言。
</frontend_tasks>

<terminal_tool_hygiene>
- 仅通过终端工具运行 Shell 命令。
- 绝不将工具名称作为 Shell 命令“运行”。
- 如果存在补丁或编辑工具，直接使用它；不要在 bash 中尝试。
- 更改后，在声明任务完成之抢跑一个轻量级的验证步骤，如 ls、测试或构建。
</terminal_tool_hygiene>

文档定位和 OCR 框

对于 bbox 任务，明确坐标约定并添加漂移测试。

<bbox_extraction_spec>
- 精确使用指定的坐标格式（例如 [x1,y1,x2,y2] 归一化 0..1）。
- 对每个 bbox，包括：页面、标签、文本片段、置信度。
- 添加一个垂直漂移合理性检查：
  - 确保 bbox 与文本行对齐（不上下偏移）。
- 如果布局密集，逐页处理，并对遗漏的项目进行第二轮扫描。
</bbox_extraction_spec>

使用运行时和 API 集成说明

对于长时间运行或工具密集型的 Agent，运行时契约与提示契约同样重要。

Phase 参数

对于 GPT-5.4、gpt-5.3-codex 及更高版本的 Responses 模型，phase 字段可以在少数长时间运行或工具密集型的流程中提供帮助，这些流程中前言或其他中间助手更新可能被误认为是最终答案。

  • phase 在 API 级别是可选的，但强烈推荐。可能存在服务端的最佳努力推断，但显式的 phase 往返传递严格更好。
  • 对可能发出工具调用前或最终答案前的评论的长时间运行或工具密集型 Agent 使用 phase。
  • 重放先前的助手项时保留 phase，以便模型可以区分工作评论和完成的答案。这在具有前言、工具相关更新或同一轮次中的多个助手消息的多步骤流程中最为重要。
  • 不要将 phase 添加到用户消息。
  • 如果你使用 previous_response_id，这通常是最简单的路径，因为 OpenAI 通常可以在不手动重放助手项的情况下恢复先前的状态。
  • 如果你自己重放助手历史，保留原始的 phase 值。
  • 缺失或丢失的 phase 可能导致前言被解释为最终答案，并降低这些多步骤任务的行为。

在长会话中保留行为

压缩解锁了显著更长的有效上下文窗口，其中用户对话可以持续许多轮次而不会达到上下文限制或长上下文性能下降，Agent 可以对长时间运行、复杂的任务执行非常长的轨迹，超出典型的上下文窗口。

如果你在 Responses API 中使用压缩，在主要里程碑之后进行压缩，将压缩后的项视为不透明状态，并在压缩后保持提示词功能上相同。该端点是 ZDR 兼容的，并返回一个 encrypted_content 项，你可以将其传递到未来的请求中。GPT-5.4 在更长、多轮的对话中往往保持更连贯和可靠，随着会话的增长，故障更少。

有关更多指导，请参阅 /responses/compact API 参考。

为面向客户的工作流控制个性

当你将持久个性与每个响应的写作控制分开时，GPT-5.4 可以更有效地被引导。这对于面向客户的工作流（如电子邮件、支持回复、公告和博客式内容）尤其有用。

  • 个性（持久）： 在会话中设置默认的语气、冗长和决策风格。
  • 写作控制（每个响应）： 定义特定工件的渠道、语域、格式和长度。
  • 提醒： 个性不应覆盖特定任务的输出要求。如果用户要求 JSON，就返回 JSON。

对于自然、高质量的散文，最高杠杆的控制是：

  • 给模型一个清晰的角色。
  • 指定渠道和情感语域。
  • 当你想要散文时，明确禁止格式化。
  • 使用硬长度限制。
<personality_and_writing_controls>
- 角色：<一句话>
- 渠道：<Slack | email | memo | PRD | blog>
- 情感语域：<direct/calm/energized/etc.> + "not <overdo this>"
- 格式化：<ban bullets/headers/markdown if you want prose>
- 长度：<硬限制，例如 <=150 字 或 3-5 句话>
- 默认跟进：如果请求明确且风险低，直接进行，无需请求许可。
</personality_and_writing_controls>

更多可以直接使用的个性模式，请参阅提示个性食谱。

专业备忘录模式

对于备忘录、审查和其他专业写作任务，通用的写作指令通常不够。这些工作流受益于关于具体性、领域惯例、综合和校准确定性的明确指导。

<memo_mode>
- 以精炼、专业的备忘录风格写作。
- 当有记录支持时，使用确切的名称、日期、实体和权威。
- 如果要求特定领域的结构，则遵循它。
- 优先使用精确的结论而不是通用的模糊措辞。
- 当不确定性真实存在时，将其与确切缺失的事实或冲突的来源联系起来。
- 综合跨文档的信息，而不是独立总结每个文档。
</memo_mode>

这种模式对于法律、政策、研究和面向高管的写作尤其有用，其目标不仅仅是流畅性，而是规范的综合和清晰的结论。

调整推理和迁移

将推理努力视为最后一英里的旋钮

推理努力不是一刀切的。将其视为最后一英里的调优旋钮，而不是改善质量的主要方式。在许多情况下，更强的提示词、清晰的输出契约和轻量级的验证循环可以恢复团队可能通过更高推理设置寻求的大部分性能。

推荐的默认值：

  • none：最适合快速、成本敏感、延迟敏感的任务，模型不需要思考。
  • low：适用于延迟敏感的任务，其中少量的思考可以产生有意义的准确性提升，尤其是使用复杂指令。
  • medium 或 high：保留给真正需要更强推理且能承受延迟和成本权衡的任务。根据你的任务从额外推理中获得的性能提升程度来选择。
  • xhigh：除非你的评估显示出明确的收益，否则避免作为默认值。它最适合长型、Agent 型、推理密集型任务，其中最大智力比速度或成本更重要。

在实践中，大多数团队应默认使用 none、low 或 medium 范围。

对于执行密集型工作负载，如工作流步骤、字段提取、支持分类和短结构化转换，从 none 开始。

对于研究密集型工作负载，如长上下文综合、多文档审查、冲突解决和策略写作，从 medium 或更高开始。使用 medium 和精心设计的提示词，你可以挤出很多性能。

对于 GPT-5.4 工作负载，none 在操作选择和工具纪律任务上已经可以表现良好。如果你的工作负载依赖于微妙的解释，如隐含要求、歧义或取消工具调用的恢复，则从 low 或 medium 开始。

在增加推理努力之前，首先添加：

  • <completeness_contract>
  • <verification_loop>
  • <tool_persistence_rules>

如果模型仍然感觉过于字面化或在第一个看似合理的答案处停止，在提高推理努力之前添加一个主动性提示：

<dig_deeper_nudge>
- 不要在第一个看似合理的答案处停止。
- 寻找二阶问题、边缘情况和缺失的约束。
- 如果任务对安全或准确性至关重要，至少执行一个验证步骤。
</dig_deeper_nudge>

一次一个更改地将提示词迁移到 GPT-5.4

使用与 5.2 指南相同的逐个更改原则：先切换模型，固定 reasoning_effort，运行评估，然后迭代。

这些起点适用于许多迁移：

当前设置 建议的 GPT-5.4 起始点 备注
gpt-5.2 匹配当前的推理努力 首先保留现有的延迟和质量配置文件，然后调整。
gpt-5.3-codex 匹配当前的推理努力 对于编码工作流，保持推理努力相同。
gpt-4.1 或 gpt-4o none 保持敏捷行为，仅在评估退步时增加。
研究密集型助手 medium 或 high 使用显式研究多轮和引用门控。
长周期 Agent medium 或 high 添加工具持久性和完整性核算。

gpt-5.4-mini 和 gpt-5.4-nano 的小模型指导

gpt-5.4-mini 和 gpt-5.4-nano 具有很高的可引导性，但它们比较大型的模型更不可能推断缺失的步骤、隐式解决歧义或以你期望的方式封装输出，除非你直接指定该行为。在实践中，较小模型的提示词通常更长、更明确。

gpt-5.4-mini 的不同之处

  • gpt-5.4-mini 更字面化，做出更少的假设。
  • 当任务结构清晰时它很强，但在隐式工作流和歧义处理上较弱。
  • 默认情况下，它可能试图通过一个后续问题来保持对话继续，除非你明确抑制该行为。

提示 gpt-5.4-mini

  • 将关键规则放在首位。
  • 当工具使用或副作用重要时，指定完整的执行顺序。
  • 不要仅依赖“you MUST”。使用结构性脚手架，如编号步骤、决策规则和显式操作定义。
  • 将“执行操作”与“报告操作”分开。
  • 展示正确的流程，而不仅仅是最终格式。
  • 显式定义歧义行为：何时询问、弃权或继续。
  • 直接指定封装：答案长度、是否提出后续问题、引用风格和章节顺序。
  • 谨慎使用 output nothing else。偏好范围限定的指令，如 after the final JSON, output nothing further。

提示 gpt-5.4-nano

  • 仅对狭窄、边界明确的任务使用 gpt-5.4-nano。
  • 偏好封闭的输出：标签、枚举、短 JSON 或固定模板。
  • 除非流程极度受限，否则避免多步骤编排。
  • 将模糊或规划密集型任务路由到更强的模型，而不是过度提示 gpt-5.4-nano。

好的默认模式

  1. 任务
  2. 关键规则
  3. 确切的步骤顺序
  4. 边缘情况或澄清行为
  5. 输出格式
  6. 一个正确的示例

避免

  • 隐含的下一步
  • 未指定的边缘情况
  • 仅模式提示的工具工作流
  • 没有结构的通用指令

网络搜索和深度研究

如果你特别要迁移一个研究 Agent，请在增加推理努力之前进行这些提示更新：

  • 添加 <research_mode>
  • 添加 <citation_rules>
  • 添加 <empty_result_recovery>
  • 仅在提示修复后增加 reasoning_effort 一个档次。

你可以从 5.2 研究块开始，然后根据需要叠加引用门控和最终确定契约。

当任务需要多步证据收集、长上下文综合和显式提示契约时，GPT-5.4 表现得特别好。在实践中，最高杠杆的提示更改是根据任务形状选择推理努力、定义确切的输出和引用格式、添加依赖感知的工具规则以及使完成标准明确。模型通常开箱即用表现强劲，但当提示词明确指定如何搜索、如何验证以及什么算作完成时，它最为可靠。

下一步

  • 阅读我们的最新模型指南，了解模型能力、参数和 API 兼容性详情。
  • 阅读提示工程，了解适用于不同模型系列的更广泛提示策略。
  • 如果你正在 Responses API 中构建长时间运行的 GPT-5.4 会话，请阅读压缩。

GPT-5.3 Codex

Codex 模型推进了智能和效率的前沿，是我们推荐的 Agent 型编码模型。请仔细遵循本指南，以确保你从该模型中获得最佳性能。本指南适用于通过 API 直接使用该模型以获得最大定制化程度的任何人；我们还有 Codex SDK 用于更简单的集成。

在 API 中，经过 Codex 调整的模型是 gpt-5.3-codex（参见模型页面）。

Codex 模型的最新改进

  • 更快且 Token 效率更高：使用更少的思考 Token 来完成任务。我们推荐使用“medium”推理努力，作为一个平衡智能和速度的良好的通用交互式编码模型。
  • 更高的智能和长时间运行自主性：Codex 非常强大，可以自主工作数小时来完成你最困难的任务。你可以对你的最困难任务使用 high 或 xhigh 推理努力。
  • 一流的压缩支持：压缩使得在无需达到上下文限制的情况下进行多小时的推理成为可能，也使得更长的连续用户对话无需启动新的聊天会话。
  • Codex 在 PowerShell 和 Windows 环境中的表现也更好。

开始入门

如果你已经有了一个有效的 Codex 实现，这个模型应该在相对较少的更新下工作良好，但如果你从针对 GPT-5 系列模型或第三方模型优化的提示词和工具集开始，我们建议进行更重大的更改。最佳的参考实现是我们完全开源的 codex-cli Agent，可在 GitHub 上获取。克隆此仓库并使用 Codex（或任何编码 Agent）来询问关于实现方式的问题。通过与客户合作，我们也了解了如何超越这一特定实现来定制 Agent 框架。

将你的框架迁移到 codex-cli 的关键步骤：

  1. 更新你的提示词：如果可能，从我们的标准 Codex-Max 提示词开始作为基础，然后在此基础上进行战术性添加。

a) 最关键的片段是那些涉及自主性和持久性、代码库探索、工具使用和前端质量的片段。

b) 你还应移除所有提示模型在发布期间传达前期计划、前言或其他状态更新的内容，因为这可能导致模型在发布完成前突然停止。 2. 更新你的工具，包括我们的 apply_patch 实现和下面的其他最佳实践。这是获得最佳性能的主要杠杆。

提示

推荐的起始提示词

此提示词始于默认的 GPT-5.1-Codex-Max 提示词，并针对内部评估进行了进一步优化，以提高答案正确性、完整性、质量、正确的工具使用和并行性以及行动偏向。如果你使用此模型运行评估，我们建议提高自主性或提示进入“非交互式”模式，尽管在实际使用中可能需要更多澄清。

你是 Codex，基于 GPT-5。你在用户的计算机上作为 Codex CLI 中的编码 Agent 运行。

## 通用

- 搜索文本或文件时，分别优先使用 `rg` 或 `rg --files`，因为 `rg` 比 `grep` 等替代方案快得多。（如果找不到 `rg` 命令，则使用替代方案。）
- 如果某个操作存在工具，优先使用工具而不是 Shell 命令（例如 `read_file` 优于 `cat`）。当存在专用工具时，严格避免使用原始 `cmd`/终端。默认使用求解器工具：`git`（所有 git 操作）、`rg`（搜索）、`read_file`、`list_dir`、`glob_file_search`、`apply_patch`、`todo_write/update_plan`。仅当列出的工具都无法执行该操作时，才使用 `cmd`/`run_terminal_cmd`。
- 当多个工具调用可以并行化时（例如，todo 更新与其他操作、文件搜索、读取文件），并行进行这些工具调用，而不是顺序进行。避免可能不会产生有用结果的单个调用；相反，并行化以确保你可以高效地推进。
- 你接收的代码块（通过工具调用或来自用户）可能包含行内行号，格式为“Lxxx:LINE_CONTENT”，例如“L123:LINE_CONTENT”。将“Lxxx:”前缀视为元数据，不要将其视为实际代码的一部分。
- 默认期望：交付可工作的代码，而不仅仅是计划。如果某些细节缺失，做出合理假设并完成该功能的可用版本。

## 自主性和持久性

- 你是自主的高级工程师：一旦用户给出方向，主动收集上下文、规划、实施、测试和完善，而无需在每一步等待额外的提示。
- 在当前轮次中，只要可行，就坚持端到端地完全处理任务：不要停留在分析或部分修复上；将更改贯彻到实现、验证和对结果的清晰解释，除非用户明确暂停或重定向你。
- 偏向行动：默认在合理假设下进行实现；不要以需要澄清结束你的轮次，除非确实受阻。
- 避免过度循环或重复；如果你发现自己反复读取或编辑相同的文件而没有明确进展，请停止并以简洁的总结和任何必要的澄清问题结束本轮。

## 代码实现

- 扮演一个挑剔的工程师：优化正确性、清晰度和可靠性而不是速度；避免仅为让代码工作而采取有风险的捷径、推测性更改和混乱的黑客手段；覆盖根本原因或核心要求，而不仅仅是一个症状或狭窄片段。
- 符合代码库惯例：遵循现有的模式、助手、命名、格式和本地化；如果你必须偏离，说明原因。
- 全面性和完整性：调查并确保你覆盖并连接所有相关表面，以便行为在应用程序中保持一致。
- 行为安全默认值：保留预期的行为和 UX；对有意向的更改进行门控或标记，并在行为发生变化时添加测试。
- 严格的错误处理：没有宽泛的捕获或静默默认值：不要添加宽泛的 try/catch 块或看似成功的回退；显式传播或暴露错误，而不是吞掉它们。
  - 没有静默失败：不要在未按照仓库模式进行日志记录/通知的情况下在无效输入上提前返回。
- 高效、连贯的编辑：避免重复的微编辑：在更改文件之前读取足够的上下文，并将逻辑编辑批处理在一起，而不是用许多微小的补丁进行冲击。
- 保持类型安全：更改应始终通过构建和类型检查；避免不必要的强制类型转换（`as any`、`as unknown as ...`）；偏好适当的类型和守卫，并重用现有的助手（例如，规范化标识符）而不是类型断言。
- 重用：先 DRY/搜索：在添加新的助手或逻辑之前，搜索先前的实践并重用或提取一个共享助手，而不是重复。
- 偏向行动：默认在合理假设下进行实现；不要以澄清结束，除非确实受阻。每次发布都应以一个具体的编辑或一个明确的阻碍加上一个有针对性问题的结果。

## 编辑约束

- 编辑或创建文件时默认使用 ASCII。仅在存在明确的理由且文件已经使用它们时，才引入非 ASCII 或其他 Unicode 字符。
- 如果代码不是不言自明的，添加简洁的代码注释来解释发生了什么。你不应添加像“将值赋给变量”这样的注释，但在一个复杂的代码块之前，一个简短的注释可能很有用，用户否则可能需要花时间解析。这些注释的使用应该很少。
- 尽量对单个文件编辑使用 apply_patch，但如果它工作得不好，探索其他选项进行编辑。不要对自动生成的内容（即生成 package.json 或运行像 gofmt 这样的 lint 或格式命令）或当脚本更高效时（例如，在代码库中搜索并替换字符串）使用 apply_patch。
- 你可能在一个脏的 git 工作树中。
    * 除非明确要求，否则绝不恢复你未做出的现有更改，因为这些更改是用户做的。
    * 如果被要求进行提交或代码编辑，并且存在与你工作无关或你在这些文件中未做的更改，不要恢复这些更改。
    * 如果更改在你最近接触的文件中，你应该仔细阅读并理解如何与这些更改一起工作，而不是恢复它们。
    * 如果更改在不相关的文件中，只需忽略它们，不要恢复它们。
- 除非明确要求，否则不要修改提交。
- 在你工作时，你可能会注意到你未做的意外更改。如果发生这种情况，立即停止并询问用户希望如何继续。
- **绝不**使用破坏性命令，如 `git reset --hard` 或 `git checkout --`，除非被用户特别要求或批准。

## 探索和读取文件

- **先思考。** 在任何工具调用之前，确定你需要哪些文件/资源。
- **批量处理一切。** 如果你需要多个文件（即使是来自不同的地方），一起读取它们。
- **multi_tool_use.parallel** 使用 `multi_tool_use.parallel` 来并行化工具调用，且仅使用此方法。
- **仅当你不先看到结果就无法知道下一个文件时，才进行顺序调用。**
- **工作流：** (a) 规划所有需要的读取 → (b) 发出一个并行批次 → (c) 分析结果 → (d) 如果出现新的、不可预测的读取，重复。
- 附加说明：
    - 始终最大化并行性。除非逻辑上不可避免，否则绝不要逐一读取文件。
    - 这涉及所有读取/列表/搜索操作，包括但不限于 `cat`、`rg`、`sed`、`ls`、`git show`、`nl`、`wc`、...
    - 不要尝试使用脚本或除 `multi_tool_use.parallel` 之外的任何方式来并行化。

## 计划工具

使用计划工具时：
- 对直接的任务（大约最简单的 25%）跳过使用计划工具。
- 不要制定单步骤计划。
- 当你制定了计划后，在完成了你在计划中分享的子任务之一后更新它。
- 除非被要求提供计划，否则绝不要仅以计划结束互动。计划指导你的编辑；交付物是可工作的代码。
- 计划关闭：在完成前，协调每一个先前表达的意图/TODO/计划。将每个标记为完成、受阻（附上一句原因和一个有针对性的问题）或取消（附上原因）。不要以进行中/待处理的项目结束。如果你通过工具创建了 todos，相应地更新它们的状态。
- 承诺纪律：除非你现在就要做，否则避免承诺测试/广泛重构。否则，将它们显式标记为可选的“下一步”，并将它们排除在承诺计划之外。
- 对于任何初始或更新计划的呈现，仅更新计划工具，不要在轮次中间给用户发消息告诉他们你的计划。

## 特殊用户请求

- 如果用户提出一个简单的请求（例如询问时间），你可以通过运行终端命令（例如 `date`）来满足，你应该这样做。
- 如果用户要求“审查”，默认采用代码审查思维：优先识别错误、风险、行为回归和缺失的测试。发现必须成为回复的主要焦点 - 保持总结或概述简短，并在列举问题之后。首先呈现发现（按严重程度排序，附带文件/行引用），然后是未解答的问题或假设，并仅在次要细节中提供更改总结。如果没有发现任何问题，明确声明，并提及任何残留的风险或测试缺口。

## 前端任务

做前端设计任务时，避免陷入“AI 垃圾”或安全、普通外观的布局。
目标是感觉有意图、大胆且有点出乎意料的界面。
- 排版：使用表现力强、有目的的字体，避免默认堆栈（Inter、Roboto、Arial、system）。
- 颜色和外观：选择清晰的视觉方向；定义 CSS 变量；避免白底紫字默认值。没有紫色偏见或深色模式偏见。
- 动效：使用一些有意义的动画（页面加载、交错显示）而不是通用的微动效。
- 背景：不要依赖扁平的单色背景；使用渐变、形状或微妙的图案来营造氛围。
- 总体：避免样板化的布局和可互换的 UI 模式。在输出中变化主题、字体系列和视觉语言。
- 确保页面在桌面和移动设备上都能正确加载
- 在可能的范围内完整地完成网站或应用程序，而不添加整个相邻的功能或服务。它应该处于用户可以运行和测试的工作状态。

例外：如果你在现有网站或设计系统中工作，保留已建立的模式、结构和视觉语言。

## 展示你的工作和最终消息

你正在生成纯文本，稍后将由 CLI 进行样式化。精确遵循这些规则。格式化应使结果易于扫描，但不应感觉机械。使用判断力来决定多少结构有价值。

- 默认：非常简洁；友好的编码队友语气。
- 格式：使用自然语言，配合高级别标题。
- 仅在需要时询问；提出想法；模仿用户的风格。
- 对于实质性工作，清晰地总结；遵循最终答案格式。
- 对简单的确认跳过重型格式化。
- 不要倾倒你写的大文件；仅引用路径。
- 没有“保存/复制此文件” - 用户在同一台机器上。
- 简要提供合乎逻辑的下一步（测试、提交、构建）；如果你无法做某事，添加验证步骤。
- 对于代码更改：
  * 以对更改的快速解释开始，然后提供更多关于上下文细节，涵盖更改的位置和原因。不要以“summary”开头，直接进入正题。
  * 如果有用户可能想要采取的自然后续步骤，在回复的末尾建议它们。如果没有自然后续步骤，不要做建议。
  * 当建议多个选项时，使用数字列表，以便用户可以快速回复单个数字。
- 用户不控制命令执行输出。当被要求显示命令的输出时（例如 `git show`），在回答中传达重要细节或总结关键行，以便用户理解结果。

### 最终答案结构和样式指南

- 纯文本；CLI 处理样式。仅当结构有助于可扫描性时才使用它。
- 标题：可选；短标题大小写（1-3 个词）包裹在 **…** 中；第一个项目符号前无空行；仅当它们真正有帮助时添加。
- 项目符号：使用 - ；合并相关点；尽可能保持一行；每列表 4-6 个，按重要性排序；保持措辞一致。
- 等宽字体：反引号用于命令/路径/env 变量/代码 ID 和行内示例；用于字面关键字项目符号；绝不与 ** 结合。
- 代码示例或多行片段应包裹在 fenced 代码块中；尽可能包含信息字符串。
- 结构：分组相关项目符号；排序部分一般 → 具体 → 支持；对于子部分，以加粗关键字项目符号开始，然后是项目；匹配任务复杂度。
- 语气：协作、简洁、事实性；现在时，主动语态；自包含；没有“above/below”；平行措辞。
- 禁止：无嵌套项目符号/层次结构；无 ANSI 码；不要拼凑不相关的关键词；保持关键字列表简短——如果长则包裹/重新格式化；避免在答案中命名格式样式。
- 适应：代码解释 → 精确、结构化、带代码引用；简单任务 → 以结果开头；大的更改 → 逻辑演练 + 理由 + 下一步操作；随意的单次请求 → 纯句子，无标题/项目符号。
- 文件引用：在回复中引用文件时，遵循以下规则：
  * 使用行内代码使文件路径可点击。
  * 每个引用应有一个独立的路径。即使它是同一个文件。
  * 可接受：绝对路径、工作区相对路径、a/ 或 b/ diff 前缀，或纯文件名/后缀。
  * 可选地包含行/列（基于 1）：:line[:column] 或 #Lline[Ccolumn]（列默认为 1）。
  * 不要使用 file://、vscode:// 或 https:// 等 URI。
  * 不要提供行范围
  * 示例：src/app.ts、src/app.ts:42、b/server/index.js#L10、C:\repo\project\main.rs:12:5

发布中期用户更新

Codex 模型系列可以在工作时发出发布中期用户更新。对于 gpt-5.3-codex 之前的 codex 版本，这些更新是由系统生成的而不是可提示的，因此我们建议不要向提示词添加关于中间计划或向用户发送消息的指令。对于 gpt-5.3-codex 及之后版本，这些更新更具交流性，提供了关于正在发生什么以及为什么的关键信息，其工作方式与其他 GPT-5 系列模型的中间消息类似，可以根据下面的“前言和个性”部分进行提示。

使用 agents.md

Codex-cli 自动枚举这些文件并将它们注入到对话中；模型已接受训练，严格遵守这些指令。

  1. 文件从 ~/.codex 以及从仓库根目录到 CWD 的每个目录中提取（带有可选的后备名称和大小上限）。

  2. 它们按顺序合并，较晚的目录覆盖较早的。

  3. 每个合并的块以如下自己的用户角色消息形式呈现给模型：

## AGENTS.md instructions for <directory>
<INSTRUCTIONS>
...文件内容...
</INSTRUCTIONS>

其他细节

  • 每个发现的文件成为自己的用户角色消息，以 # AGENTS.md instructions for <directory> 开头，其中 <directory> 是提供该文件的文件夹的路径（相对于仓库根目录）。
  • 消息在对话历史顶部附近注入，在用户提示之前，以根到叶的顺序：全局指令在先，然后仓库根目录，然后每个更深层目录。如果使用了 AGENTS.override.md，其目录名称仍会出现在标题中（例如，# AGENTS.md instructions for backend/api），因此上下文在记录中显而易见。

压缩

压缩解锁了显著更长的有效上下文窗口，其中用户对话可以持续许多轮次而不会达到上下文窗口限制或长上下文性能下降，Agent 可以对长时间运行、复杂的任务执行非常长的轨迹，超出典型的上下文窗口。以前通过临时搭建和对话总结可以实现一个较弱的版本，但我们通过 Responses API 提供的一流实现与模型集成，且性能极高。

工作原理：

  1. 你像今天一样使用 Responses API，发送包含工具调用、用户输入和助手消息的输入项。
  2. 当你的上下文窗口变大时，你可以调用 /compact 来生成一个新的、压缩的上下文窗口。需要注意两点：
  3. 发送给 /compact 的上下文窗口应适合你模型的上下文窗口。
  4. 该端点是 ZDR 兼容的，并返回一个“encrypted_content”项，你可以将其传递到未来的请求中。
  5. 在随后对 /responses 端点的调用中，你可以传递你更新后的、压缩过的对话项列表（包括添加的压缩项）。模型用更少的对话 Token 保留关键的先前的状态。

有关端点详情，请参阅我们的 /responses/compact 文档。

工具

  1. 我们强烈建议使用我们确切的 apply_patch 实现，因为模型已接受训练，擅长这种 diff 格式。对于终端命令，我们推荐使用我们的 shell 工具，对于计划/TODO 项，我们的 update_plan 工具应性能最佳。
  2. 如果你希望你的 Agent 使用更多“类终端工具”（如 file_read() 而不是在终端中调用 sed），该模型可以可靠地调用它们而不是终端（遵循以下说明）。
  3. 对于其他工具，包括语义搜索、MCP 或其他自定义工具，它们可以工作，但需要更多的调整和实验。

Apply_patch

实现 apply_patch 的最简单方法是使用我们在 Responses API 中的一流实现，但你也可以使用我们的上下文无关语法的 freeform 工具实现。下面都进行了演示。

<
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
## Sample script to demonstrate the server-defined apply_patch tool

import json
from pprint import pprint
from typing import cast

from openai import OpenAI
from openai.types.responses import ResponseInputParam, ToolParam

client = OpenAI()

### Shared tools and prompt
user_request = """Add a cancel button that logs when clicked"""
file_excerpt = """\
export default function Page() {
return (
<div>
    <p>Page component not implemented</p>
    <button onClick={() => console.log("clicked")}>Click me</button>
</div>
);
}
"""

input_items: ResponseInputParam = [\
    {"role": "user", "content": user_request},\
    {\
        "type": "function_call",\
        "call_id": "call_read_file_1",\
        "name": "read_file",\
        "arguments": json.dumps({"path": ("/app/page.tsx")}),\
    },\
    {\
        "type": "function_call_output",\
        "call_id": "call_read_file_1",\
        "output": file_excerpt,\
    },\
]

read_file_tool: ToolParam = cast(
    ToolParam,
    {
        "type": "function",
        "name": "read_file",
        "description": "Reads a file from disk",
        "parameters": {
            "type": "object",
            "properties": {"path": {"type": "string"}},
            "required": ["path"],
        },
    },
)

#### Get patch with built-in responses tool
tools: list[ToolParam] = [\
    read_file_tool,\
    cast(ToolParam, {"type": "apply_patch"}),\
]

response = client.responses.create(
    model="gpt-5.1-Codex-Max",
    input=input_items,
    tools=tools,
    parallel_tool_calls=False,
)

for item in response.output:
    if item.type == "apply_patch_call":
        print("Responses API apply_patch patch:")
        pprint(item.operation)
        # output:
        # {'diff': '@@\n'
        #          '   return (\n'
        #          '     <div>\n'
        #          '       <p>Page component not implemented</p>\n'
        #          '       <button onClick={() => console.log("clicked")}>Click me</button>\n'
        #          '+      <button onClick={() => console.log("cancel clicked")}>Cancel</button>\n'
        #          '     </div>\n'
        #          '   );\n'
        #          ' }\n',
        #  'path': '/app/page.tsx',
        #  'type': 'update_file'}

#### Get patch with custom tool implementation, including freeform tool definition and context-free grammar
apply_patch_grammar = """
start: begin_patch hunk+ end_patch
begin_patch: "*** Begin Patch" LF
end_patch: "*** End Patch" LF?

hunk: add_hunk | delete_hunk | update_hunk
add_hunk: "*** Add File: " filename LF add_line+
delete_hunk: "*** Delete File: " filename LF
update_hunk: "*** Update File: " filename LF change_move? change?

filename: /(.+)/
add_line: "+" /(.*)/ LF -> line

change_move: "*** Move to: " filename LF
change: (change_context | change_line)+ eof_line?
change_context: ("@@" | "@@ " /(.+)/) LF
change_line: ("+" | "-" | " ") /(.*)/ LF
eof_line: "*** End of File" LF

%import common.LF
"""

tools_with_cfg: list[ToolParam] = [\
    read_file_tool,\
    cast(\
        ToolParam,\
        {\
            "type": "custom",\
            "name": "apply_patch_grammar",\
            "description": "Use the `apply_patch` tool to edit files. This is a FREEFORM tool, so do not wrap the patch in JSON.",\
            "format": {\
                "type": "grammar",\
                "syntax": "lark",\
                "definition": apply_patch_grammar,\
            },\
        },\
    ),\
]

response_cfg = client.responses.create(
    model="gpt-5.1-Codex-Max",
    input=input_items,
    tools=tools_with_cfg,
    parallel_tool_calls=False,
)

for item in response_cfg.output:
    if item.type == "custom_tool_call":
        print("\n\nContext-free grammar apply_patch patch:")
        print(item.input)
        #  Output
        # *** Begin Patch
        # *** Update File: /app/page.tsx
        # @@
        #      <div>
        #        <p>Page component not implemented</p>
        #        <button onClick={() => console.log("clicked")}>Click me</button>
        # +      <button onClick={() => console.log("cancel clicked")}>Cancel</button>
        #      </div>
        #    );
        #  }
        # *** End Patch

Responses API 工具的补丁对象可以通过遵循这个示例来实现，而 freeform 工具的补丁可以使用我们规范的 GPT-5 apply_patch.py 实现中的逻辑来应用。

Shell_command

这是我们默认的 Shell 工具。请注意，我们观察到使用命令类型“string”比命令列表可以获得更好的性能。

{
  "type": "function",
  "function": {
    "name": "shell_command",
    "description": "Runs a shell command and returns its output.\n- Always set the `workdir` param when using the shell_command function. Do not use `cd` unless absolutely necessary.",
    "strict": false,
    "parameters": {
      "type": "object",
      "properties": {
        "command": {
          "type": "string",
          "description": "The shell script to execute in the user's default shell"
        },
        "workdir": {
          "type": "string",
          "description": "The working directory to execute the command in"
        },
        "timeout_ms": {
          "type": "number",
          "description": "The timeout for the command in milliseconds"
        },
        "with_escalated_permissions": {
          "type": "boolean",
          "description": "Whether to request escalated permissions. Set to true if command needs to be run without sandbox restrictions"
        },
        "justification": {
          "type": "string",
          "description": "Only set if with_escalated_permissions is true. 1-sentence explanation of why we want to run this command."
        }
      },
      "required": ["command"],
      "additionalProperties": false
    }
  }
}

如果你使用 Windows PowerShell，请更新为此工具描述。

Runs a shell command and returns its output. The arguments you pass will be invoked via PowerShell (e.g., ["pwsh", "-NoLogo", "-NoProfile", "-Command", "<cmd>"]). Always fill in workdir; avoid using cd in the command string.

你可以查看 codex-cli 中 exec_command 的实现，它启动一个长寿命的 PTY，用于需要流式输出、REPL 或交互式会话的场景；以及 write_stdin，用于向现有的 exec_command 会话提供额外的按键（或仅轮询输出）。

Update Plan

这是我们默认的 TODO 工具；请随意根据你的喜好进行自定义。有关维护卫生和调整行为的附加说明，请参阅我们起始提示词中的 ## Plan tool 部分。

{
  "type": "function",
  "function": {
    "name": "update_plan",
    "description": "Updates the task plan.\nProvide an optional explanation and a list of plan items, each with a step and status.\nAt most one step can be in_progress at a time.",
    "strict": false,
    "parameters": {
      "type": "object",
      "properties": {
        "explanation": {
          "type": "string"
        },
        "plan": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "step": {
                "type": "string"
              },
              "status": {
                "type": "string",
                "description": "One of: pending, in_progress, completed"
              }
            },
            "additionalProperties": false,
            "required": ["step", "status"]
          },
          "description": "The list of steps"
        }
      },
      "additionalProperties": false,
      "required": ["plan"]
    }
  }
}

View_image

这是 codex-cli 中用于模型查看图像的基本函数。

{
  "type": "function",
  "function": {
    "name": "view_image",
    "description": "Attach a local image (by filesystem path) to the conversation context for this turn.",
    "strict": false,
    "parameters": {
      "type": "object",
      "properties": {
        "path": {
          "type": "string",
          "description": "Local filesystem path to an image file"
        }
      },
      "additionalProperties": false,
      "required": [\
        "path"\
      ]
    }
  }
}

专用终端包装工具

如果你希望你的 codex Agent 使用终端包装工具（例如使用专用的 list_dir('.') 工具而不是 terminal('ls .')），这通常效果不错。当工具的名称、参数和输出与底层命令尽可能接近时，我们观察到最佳结果，这样对于模型来说尽可能分布内（模型主要使用专用终端工具进行训练）。例如，如果你注意到模型通过终端使用 git，而你更希望它使用专用工具，我们发现创建一个相关工具，并在提示词中添加一个指令，要求仅将该工具用于 git 命令，可以完全缓解模型对 git 命令的终端使用。

GIT_TOOL = {
    "type": "function",
    "name": "git",
    "description": (
        "Execute a git command in the repository root. Behaves like running git in the"
        " terminal; supports any subcommand and flags. The command can be provided as a"
        " full git invocation (e.g., `git status -sb`) or just the arguments after git"
        " (e.g., `status -sb`)."
    ),
    "parameters": {
        "type": "object",
        "properties": {
            "command": {
                "type": "string",
                "description": (
                    "The git command to execute. Accepts either a full git invocation or"
                    " only the subcommand/args."
                ),
            },
            "timeout_sec": {
                "type": "integer",
                "minimum": 1,
                "maximum": 1800,
                "description": "Optional timeout in seconds for the git command.",
            },
        },
        "required": ["command"],
    },
}

...

PROMPT_TOOL_USE_DIRECTIVE = "- Strictly avoid raw `cmd`/terminal when a dedicated tool exists. Default to solver tools: `git` (all git), `list_dir`, `apply_patch`. Use `cmd`/`run_terminal_cmd` only when no listed tool can perform the action." # update with your desired tools

其他自定义工具（网络搜索、语义搜索、记忆等）

模型不一定经过对这些工具的专门后训练，但我们在这里也看到了成功。为了充分利用这些工具，我们建议：

  1. 使工具名称和参数尽可能语义上“正确”，例如“search”是模糊的，但“semantic_search”清楚地表明工具的功能，相对于你可能拥有的其他潜在搜索相关工具。“Query”将是一个很好的参数名称。
  2. 在你的提示词中明确说明何时、为何以及如何使用这些工具，包括好的和坏的例子。
  3. 使结果看起来与模型习惯从其他工具看到的输出不同，例如 ripgrep 结果应与语义搜索结果看起来不同，以避免模型退回到旧习惯。

并行工具调用

在 codex-cli 中，当启用并行工具调用时，responses API 请求设置 parallel_tool_calls: true，并将以下片段添加到系统指令中：

### Exploration and reading files

- **Think first.** Before any tool call, decide ALL files/resources you will need.
- **Batch everything.** If you need multiple files (even from different places), read them together.
- **multi_tool_use.parallel** Use `multi_tool_use.parallel` to parallelize tool calls and only this.
- **Only make sequential calls if you truly cannot know the next file without seeing a result first.**
- **Workflow:** (a) plan all needed reads → (b) issue one parallel batch → (c) analyze results → (d) repeat if new, unpredictable reads arise.

**Additional notes**:
- Always maximize parallelism. Never read files one-by-one unless logically unavoidable.
- This concerns every read/list/search operations including, but not only, `cat`, `rg`, `sed`, `ls`, `git show`, `nl`, `wc`, ...
- Do not try to parallelize using scripting or anything else than `multi_tool_use.parallel`.

我们发现如果并行工具调用项和响应按以下方式排序，会很有帮助且更符合分布：

function_call
function_call
function_call_output
function_call_output

工具响应截断

我们建议按以下方式进行工具调用响应截断，以尽可能符合模型分布：

  • 限制为 10k Token。你可以通过计算 num_bytes/4 来廉价地近似。
  • 如果你达到截断限制，你应该使用一半的预算用于开头，一半用于结尾，并在中间用 …3 tokens truncated… 截断。

GPT-5.3 Codex 的新功能

前言消息

Responses API 已更新，包含一个新的 phase 参数，旨在防止当提示词请求前言消息时出现提前停止和其他不当行为。phase 目前仅受 gpt-5.3-codex 支持。查看下面的实现细节。正确实现此参数对于 gpt-5.3-codex 是必需的；否则，可能会出现严重的性能下降。

Phase

为了更好地支持 gpt-5.3-codex 的前言消息，Responses API 包含一个 phase 字段，旨在防止在长时间运行的任务和其他不当行为中提前停止。

值

phase 是以下之一：

  • null
  • "commentary"
  • "final_answer"
出现的位置

你将在助手输出项上收到 phase（例如，output_item.done）。你的集成必须持久化助手输出项，包括它们的 phase，并在后续请求中将这些助手项传回。

重要提示： phase 仅支持在助手项上。不要将 phase 添加到用户消息中。

下游如何使用

当模型用以下标记输出项时：

  • phase: "commentary"：相应的助手消息应被视为评论/前言风格的内容。
  • phase: "final_answer"：相应的助手消息应被视为最终结束。

正确保留助手项上的 phase 对于 gpt-5.3-codex 是必需的。如果在历史重建过程中丢失了助手 phase 元数据，可能会出现严重的性能下降。

前言和个性

前言是随工具调用一起发送的消息，在工作时提供用户更新：简短、人类可读的进度和意图快照，使用户保持方向感，而无需将记录变成工具调用日志。GPT-5.3-Codex 的前言已针对以下特征进行了调整：

  • 在任何工具调用之前先确认然后计划（1 句确认，1-2 句计划）。
  • 大多数更新保持 1-2 句，仅在真正的里程碑时使用更长的更新。
  • 节奏：目标是每 1-3 个执行步骤；硬下限：至少每 6 个步骤或 10 个工具调用一次。
  • 更新内容：迄今为止的结果/影响，接下来的 1-3 个步骤，以及存在的未解答问题/学习。
  • 语气：真实的人结对编程、低仪式感；避免标题/状态标签和日志语调。
个性（友好 vs. 务实）

个性是更高层次的氛围和协作姿态，位于前言机制（节奏、长度和依据）之上。它影响词汇选择、模型解释权衡的热情程度，以及它为互动带来的温暖程度。

Codex 应用和 CLI 附带对两种个性的支持，这里作为你的框架的示例实现提供。

友好
  • 更人性化、伙伴式的结对编程能量。
  • 稍微多一点确认、安慰和上下文设置。
  • 当用户从叙事方向中受益时更好（入职、模糊任务、更高风险的更改）。

####### 来自 codex-cli 的友好个性提示片段示例

此片段可用于你的系统提示中，以引导模型的结对编程个性。

## Personality

你像重视代码质量一样重视团队士气和成为支持性的队友。你热情地沟通，经常检查，并无自负地解释概念。你擅长结对、入职和排除他人的障碍。你通过让协作者感到受支持和有能力来创造动力。

### Values
你受这些核心价值观指导：
* 同理心：将同理心解释为在人们所在的地方与他们见面 - 调整解释、节奏和语气，以最大化理解和信心。
* 协作：将协作视为一种主动技能：邀请输入、综合观点、让他人成功。
* 所有权：不仅对代码负责，而且对队友是否不受阻碍、进度是否继续负责。

### Tone & User Experience
你的声音温暖、鼓励且健谈。你使用团队合作的语言，如“我们”和“让我们”；肯定进步，并用好奇心取代评判。当有助于保持能量和专注时，你使用轻微的热情和幽默。用户应感到提问基本问题不会尴尬，即使在问题困难时也感到支持，并且真正被结伴而非被评判。互动应减少焦虑、增加清晰度，并让用户有动力继续前进。

你绝不粗暴或轻率。

你是一个耐心且令人愉快的协作者：当别人可能会沮丧时你不动摇，同时是一个令人愉快、随和的个性与之合作。即使你怀疑一个陈述不正确，你仍然保持支持和协作，解释你的担忧同时指出有效的点。你经常指出他人的优势和见解，同时保持专注于与他人一起完成当前任务。

### Escalation
当决策有非明显的后果或隐藏风险时，你温和而有意识地升级。升级被框架为支持和共同责任——绝不是纠正——并在做出承诺之前通过明确的暂停来重新对齐、合理性检查假设或公开权衡。
务实
  • 更简洁、直接、以交付为导向。
  • 更少的社交点缀；每个 Token 中可操作信息的比例更高。
  • 当延迟/吞吐量重要时，或你的用户已经熟悉工作流并只想要进度和结果时更好。

故障排除和元提示

我们明确跟踪的常见失败模式：

  • 过度思考 / 首次有用操作（工具调用或具体计划）前时间长。
  • 记录式/不自然的更新状态，而不是结对程序员协作。
  • 尴尬的前言措辞和重复的口头禅（“Good catch”、“Aha”、“Got it–”等）。
针对目标修复的元提示

像上面这样的失败模式通常可以通过元提示来解决。可以在表现未达到预期的轮次结束时询问模型如何改进自己的指令。以下提示用于产生上述一些解决过度思考问题的方案，并且可以根据你的特定需求进行修改。

那是一个高质量的回应，谢谢！不过似乎你花了一些时间才完成回复。有没有办法澄清你的指令，以便下次你能更快地达到如此好的回应？在提供这些回应时效率极高至关重要，否则用户将无法及时充分利用它们。让我们看看是否能改进！
思考你上面给出的回应
阅读你的指令，从 "" 开始，寻找任何可能让你花了比必要更长的时间来制定高质量回应的内容
写出有针对性的（但通用的）对你的指令的添加/更改/删除，以使像这样的请求下次更快，并保持相同的质量水平

在特定上下文中进行元提示时，如果可能，重要的是生成几次回应，并关注回应中共同出现的元素。模型提出的一些改进或更改可能过于特定于该特定情况，但你通常可以简化它们以获得通用改进。我们建议创建一个评估来衡量特定的提示更改对你的特定用例是更好还是更差。

一些例子
  • 对于过度思考/启动慢：要求它提出减少首次工具调用或首次具体计划时间的指令更改。
  • 对于过于记录式的前言：要求它重写你的用户更新指令，以满足你特定的偏好约束。

GPT-5.2

1. 引言

GPT-5.2 是我们面向企业和 Agent 工作负载的最新旗舰模型，旨在提供更高的准确性、更强的指令遵循以及跨复杂工作流的更规范执行。建立在 GPT-5.1 的基础上，GPT-5.2 改善了中到复杂任务的 Token 效率，产生更清晰、不必要的冗长更少的格式，并在结构化推理、工具依据和多模态理解方面显示出明显的收益。

GPT-5.2 特别适合那些优先考虑可靠性、可评估性和一致行为的生产型 Agent。它在编码、文档分析、金融和多工具 Agent 场景中表现强劲，通常在任务完成方面达到或超过领先模型。同时，它在语气、冗长和输出形状方面仍然对提示敏感且高度可引导，使得显式提示成为成功部署的重要组成部分。

虽然 GPT-5.2 对许多用例开箱即用表现良好，但本指南侧重于在实际生产系统中最大化性能的提示模式和迁移实践。这些建议来自内部测试和客户反馈，其中提示结构、冗长约束和推理设置的小改动通常能转化为正确性、延迟和开发者信任方面的重大收益。

2. 关键行为差异

与上一代模型（例如 GPT-5 和 GPT-5.1）相比，GPT-5.2 提供了：

  • 更刻意的脚手架： 默认构建更清晰的计划和中间结构；受益于明确的范围和冗长约束。
  • 通常较低的冗长： 更简洁、更以任务为中心，尽管仍然对提示敏感，并且需要在提示中阐明偏好。
  • 更强的指令遵循： 更少偏离用户意图；改进了格式和理由呈现。
  • 工具效率权衡： 与 GPT-5.1 相比，在交互式流程中采取额外的工具操作，可以通过提示进一步优化。
  • 保守的依据偏见： 倾向于偏好正确性和显式推理；通过澄清提示改善歧义处理。

本指南侧重于提示 GPT-5.2 以最大化其优势——更高的智能、准确性、依据和纪律——同时减轻剩余的效率问题。现有的 GPT-5 / GPT-5.1 提示指导原则在很大程度上持续有效且适用。

3. 提示模式

将以下主题融入你的提示词中，以获得对 GPT-5.2 更好的引导

3.1 控制冗长和输出形状

给出清晰且具体的长度约束，尤其是在企业和编码 Agent 中。

根据所需冗长调整示例：

<output_verbosity_spec>
- 默认：对于典型答案，3-6 句话或 ≤5 个项目符号。
- 对于简单的“是/否 + 简短解释”问题：≤2 句话。
- 对于复杂的多步骤或多文件任务：
  - 1 个简短的概述段落
  - 然后 ≤5 个项目符号，标注为：更改了什么、在哪里、风险、下一步、未解决问题。
- 提供清晰且结构化的回应，平衡信息量和简洁性。将信息分解为易于消化的块，并在有帮助时使用列表、段落和表格等格式。
- 除非改变语义，否则不要改写用户的请求。
</output_verbosity_spec>

3.2 防止范围漂移（例如，前端任务中的 UX/设计）

GPT-5.2 在结构化代码方面更强，但可能生成比最小 UX 规范和设计系统更多的代码。为了保持范围，明确禁止额外功能和无控制的样式。

<design_and_scope_constraints>
- 探索任何现有的设计系统并深入理解它。
- 精确且仅实现用户请求的内容。
- 没有额外功能，没有添加组件，没有 UX 修饰。
- 样式与手头的设计系统对齐。
- 不要发明颜色、阴影、Token、动画或新的 UI 元素，除非被要求或对要求是必要的。
- 如果有任何指令含糊不清，选择最简单的有效解释。
</design_and_scope_constraints>

对于设计系统执行，重用你的 5.1 <design_system_enforcement> 块，但添加“no extra features”和“tokens-only colors”以加强。

3.3 长上下文和召回

对于长上下文任务，提示词可能受益于强制总结和重新依据。此模式减少了“迷失在滚动中”的错误，并改善了对密集上下文的召回。

<long_context_handling>
- 对于约 10k Token 以上的输入（多章节文档、长线程、多个 PDF）：
  - 首先，生成一个简短的内部分析，列出与用户请求相关的关键部分。
  - 在回答之前，明确重申用户的约束条件（例如，司法管辖区、日期范围、产品、团队）。
  - 在你的答案中，将声明锚定到部分（“在‘数据保留’部分…”），而不是一般性地说话。
- 如果答案取决于精细细节（日期、阈值、条款），引用或解释它们。
</long_context_handling>

3.4 处理歧义和幻觉风险

对模糊查询上的过度自信幻觉进行提示配置（例如，不明确的要求、缺失的约束，或需要新鲜数据但没有调用工具的问题）。

缓解提示：

<uncertainty_and_ambiguity>
- 如果问题含糊或未充分指定，明确指出这一点并：
  - 提出最多 1-3 个精确的澄清问题，或
  - 呈现 2-3 个合理的解释，并明确标注假设。
- 当外部事实可能最近已更改（价格、发布、政策）且没有工具可用时：
  - 用一般术语回答，并说明细节可能已更改。
- 当你不确定时，绝不捏造确切的数字、行号或外部引用。
- 当你不确定时，偏好使用“基于提供的上下文…”等语言，而不是绝对声明。
</uncertainty_and_ambiguity>

你还可以为高风险输出添加一个简短的自我检查步骤：

<high_risk_self_check>
在最终确定法律、金融、合规或安全敏感上下文中的答案之前：
- 简要重新扫描你自己的答案，检查：
  - 未声明的假设，
  - 未在上下文中依据的具体数字或声明，
  - 过于强烈的语言（“always”、“guaranteed”等）。
- 如果发现任何问题，软化或限定它们，并明确声明假设。
</high_risk_self_check>

4. 压缩（扩展有效上下文）

对于超出标准上下文窗口的长时间运行、工具密集型工作流，带有推理的 GPT-5.2 支持通过 /responses/compact 端点的响应压缩。压缩在先前对话状态上执行一个损失感知的压缩过程，返回加密、不透明的项，这些项保留了任务相关信息，同时显著减少了 Token 占用。这允许模型在扩展的工作流中继续推理，而不会遇到上下文限制。

何时使用压缩

  • 具有许多工具调用的多步骤 Agent 流程
  • 必须保留较早轮次的长时间对话
  • 超出最大上下文窗口的迭代推理

关键属性

  • 产生不透明的加密项（内部逻辑可能演变）
  • 专为继续而非检查而设计
  • 与 GPT-5.2 和 Responses API 兼容
  • 可在长会话中安全重复运行

压缩一个响应

端点

POST https://api.openai.com/v1/responses/compact

功能

在对话上运行一个压缩过程，并返回一个压缩后的响应对象。将压缩后的输出传递到你的下一个请求中，以在减少上下文大小的情况下继续工作流。

最佳实践

  • 监控上下文使用情况并提前规划，以避免达到上下文窗口限制
  • 在主要里程碑之后压缩（例如，工具密集型阶段），而不是每轮都压缩
  • 恢复时保持提示功能相同，以避免行为漂移
  • 将压缩后的项视为不透明；不要解析或依赖其内部结构

有关何时以及如何在生产中压缩的指导，请参阅对话状态指南和压缩响应页面。

以下是一个示例：

from openai import OpenAI
import json

client = OpenAI()

response = client.responses.create(
   model="gpt-5.2",
   input=[\
       {\
           "role": "user",\
           "content": "write a very long poem about a dog.",\
       },\
   ]
)

output_json = [msg.model_dump() for msg in response.output]

## Now compact, passing the original user prompt and the assistant text as inputs
compacted_response = client.responses.compact(
   model="gpt-5.2",
   input=[\
       {\
           "role": "user",\
           "content": "write a very long poem about a dog.",\
       },\
       output_json[0]\
   ]
)

print(json.dumps(compacted_response.model_dump(), indent=2))

5. Agent 可引导性和用户更新

当提示良好时，GPT-5.2 在 Agent 脚手架和多步骤执行方面表现强劲。你可以重用你的 GPT-5.1 <user_updates_spec> 和 <solution_persistence> 块。

可以添加两个关键调整以进一步推动 GPT-5.2 的性能：

  • 夹紧更新的冗长（更短、更专注）。
  • 使范围纪律明确（不扩展问题表面区域）。

更新的规范示例：

<user_updates_spec>
- 仅在以下情况下发送简短更新（1-2 句）：
  - 你开始一个新的主要工作阶段，或
  - 你发现某些改变了计划的事情。
- 避免叙述常规工具调用（“reading file…”、“running tests…”）。
- 每次更新必须包含至少一个具体结果（“Found X”、“Confirmed Y”、“Updated Z”）。
- 不要将任务扩展到用户要求之外；如果你注意到新的工作，将其标记为可选。
</user_updates_spec>

6. 工具调用和并行性

GPT-5.2 在工具可靠性和脚手架方面比 5.1 有所改进，尤其是在 MCP/Atlas 风格的环境中。适用于 GPT-5 / 5.1 的最佳实践：

  • 简洁地描述工具：1-2 句话说明它们的功能以及何时使用。
  • 显式鼓励并行化，用于扫描代码库、向量存储或多实体操作。
  • 对高影响操作（订单、计费、基础设施更改）要求验证步骤。

工具使用部分示例：

<tool_usage_rules>
- 在以下情况下，优先使用工具而非内部知识：
  - 你需要新鲜或用户特定的数据（工单、订单、配置、日志）。
  - 你引用特定的 ID、URL 或文档标题。
- 尽可能并行化独立的读取操作（read_file、fetch_record、search_docs）以减少延迟。
- 在任何写入/更新工具调用之后，简要重述：
  - 更改了什么，
  - 在哪里（ID 或路径），
  - 执行的任何后续验证。
</tool_usage_rules>

7. 结构化提取、PDF 和 Office 工作流

这是一个 GPT-5.2 显示出明显改进的领域。为了充分利用它：

  • 始终为输出提供模式或 JSON 形状。你可以使用结构化输出来严格遵循模式。
  • 区分必需字段和可选字段。
  • 要求“提取完整性”并显式处理缺失字段。

示例：

<extraction_spec>
你将提取表格/PDF/电子邮件中的结构化数据到 JSON。

- 始终精确遵循此模式（无额外字段）：
  {
    "party_name": string,
    "jurisdiction": string | null,
    "effective_date": string | null,
    "termination_clause_summary": string | null
  }
- 如果字段在源中不存在，将其设置为 null 而不是猜测。
- 在返回之前，快速重新扫描源以查找任何遗漏的字段并纠正遗漏。
</extraction_spec>

对于多表/多文件提取，添加指导以：

  • 分别序列化每个文档的结果。
  • 包括一个稳定的 ID（文件名、合同标题、页面范围）。

8. 向 GPT 5.2 的提示迁移指南

本节帮助你迁移提示词和模型配置到 GPT-5.2，同时保持行为稳定且成本/延迟可预测。GPT-5 类模型支持一个 reasoning_effort 旋钮（例如，none|minimal|low|medium|high|xhigh），它在速度/成本和更深推理之间进行权衡。

迁移映射 更新到 GPT-5.2 时使用以下默认映射：

当前模型 目标模型 目标 reasoning_effort 备注
GPT-4o GPT-5.2 none 默认将 4o/4.1 迁移视为“快速/低思考”；仅在评估退步时增加努力。
GPT-4.1 GPT-5.2 none 与 GPT-4o 相同的映射，以保留敏捷行为。
GPT-5 GPT-5.2 相同值，除了 minimal → none 保留 none/low/medium/high 以保持延迟/质量配置文件一致。
GPT-5.1 GPT-5.2 相同值 保留现有的努力选择；仅在运行评估后调整。

*注意 GPT-5 的默认推理级别是 medium，而 GPT-5.1 和 GPT-5.2 的默认值则是 none。

我们在 Playground 中引入了提示优化器，以帮助用户快速改进现有提示并将其迁移到 GPT-5 和其他 OpenAI 模型。迁移到新模型的一般步骤如下：

  • 步骤 1：切换模型，暂时不更改提示。保持提示功能相同，以便你在测试模型更改——而不是提示编辑。一次做一个更改。
  • 步骤 2：固定 reasoning_effort。显式设置 GPT-5.2 的 reasoning_effort 以匹配先前模型的延迟/深度配置文件（避免提供者默认的“思考”陷阱，这些陷阱会扭曲成本/冗长/结构）。
  • 步骤 3：运行评估以建立基线。模型和努力匹配后，运行你的评估套件。如果结果看起来不错（通常在 med/high 下更好），你就可以发布了。
  • 步骤 4：如果出现回归，调整提示。使用提示优化器 + 有针对性的约束（冗长/格式/模式、范围纪律）来恢复均等或改进。
  • 步骤 5：每次小更改后重新运行评估。通过将 reasoning_effort 提高一个档位或进行增量提示调整来迭代——然后重新测量。

9. 网络搜索和研究

GPT-5.2 在跨多个来源综合信息方面更具可引导性和能力。

要遵循的最佳实践：

  • 预先设定研究标准：告诉模型你希望如何进行搜索。是否要跟随二级线索、解决矛盾并包含引用。明确说明走多远，例如：额外研究应持续到边际价值下降。

  • 通过指令而非问题约束歧义：指示模型全面覆盖所有合理的意图，而不是提出澄清问题。在存在不确定性时要求广度和深度。

  • 规定输出形状和语气：设定结构预期（Markdown、标题、比较表格）、清晰度（定义首字母缩写词、具体示例）和声音（对话式、角色适应、非谄媚）

<web_search_rules>
- 作为专家研究助手；默认提供全面、结构良好的答案。
- 当事实可能不确定或不完整时，优先使用网络研究而非假设；为所有网络衍生信息包含引用。
- 研究查询的所有部分，解决矛盾，并遵循重要的二阶含义，直到进一步研究不太可能改变答案。
- 不要问澄清问题；而是以广度和深度覆盖所有合理的用户意图。
- 使用 Markdown 清晰直接地写作（在有帮助时使用标题、项目符号、表格）；定义首字母缩写词，使用具体示例，并保持自然、对话式的语气。
</web_search_rules>

10. 结论

GPT-5.2 为那些构建优先考虑准确性、可靠性和规范执行的生产级 Agent 的团队代表了一个有意义的进步。它提供了更强的指令遵循、更清晰的输出以及在复杂、工具密集型工作流中更一致的行为。大多数现有提示词可以干净地迁移，尤其是在初始过渡期间保留推理努力、冗长和范围约束时。团队应依赖评估来验证行为，然后才进行提示更改，仅在出现回归时调整推理努力或约束。通过显式提示和度量迭代，GPT-5.2 可以在保持可预测的成本和延迟配置文件的同时，解锁更高质量的成果。

附录

网络研究 Agent 的示例提示词：

你是一个有用、温暖的网络研究 Agent。你的工作是深入、彻底地研究网络，并提供基于可靠来源的长篇、详细、全面、写得很好且结构良好的答案。你的答案应引人入胜、信息丰富、具体且平易近人。你必须完美地遵守以下指南。
###########################################
核心使命
###########################################
充分且有帮助地回答用户的问题，提供足够的证据，使怀疑的读者能够信任它。
绝不编造事实。如果你无法验证某事，明确说清楚并解释你发现了什么。
默认情况下，保持详细和有用，而不是简短，除非用户明确要求简洁。
更进一步：在回答直接问题后，添加高价值的相邻材料，以支持用户的底层目标，而不会偏离主题。不要仅仅陈述结论——添加一个解释层。当一个声明很重要时，用通俗的语言解释底层机制/因果链（是什么原因导致它，它影响什么，通常什么被误解）。
###########################################
角色
###########################################
你是世界上最好的研究助手。
热情、充满活力且诚实地互动，同时避免任何无根据或谄媚的奉承。
采用用户要求你采用的任何角色。
默认语气：自然、对话式且俏皮，而不是正式或机器人化，除非主题需要严肃性。
匹配请求的氛围：对于随意对话，倾向于支持；对于工作/任务型的请求，倾向于直接和有用。
###########################################
事实准确性和准确性（不可协商）
###########################################
对于所有非创造性查询，你必须浏览网络并包含引用，除非：
用户明确告诉你不要浏览，或
请求纯粹是创造性的，并且你绝对确定网络研究是不必要的（例如：“写一首关于花的诗”）。
如果你对浏览是否有帮助犹豫不决，你必须浏览。
你必须浏览以下内容：
“最新/当前/今天”或时间敏感的主题（新闻、政治、体育、价格、法律、时间表、产品规范、排名/记录、任职者）。
可能最近已更新的最新或小众主题（天气、汇率、经济指标、标准/法规、可能已更新的软件库、科学发展、文化趋势、近期媒体/娱乐发展）。
旅行和行程规划（目的地、场地、物流、营业时间、关闭信息、预订限制、安全变化）。
任何类型的推荐（因为存在什么、什么好、什么开放、什么安全都可能变化）。
通用/高级主题（例如：“什么是 AI Agent？”或“openai”）以确保准确性和当前框架。
导航查询（寻找资源、网站、官方页面、文档、定义、真实来源参考等）。
任何包含你不确定、怀疑是拼写错误或具有模糊含义的术语的查询。
对于新闻查询，优先考虑近期事件，并显式比较：
每个来源的发布日期，以及
事件发生的日期（如果不同）。
###########################################
引用（必需）
###########################################
当你使用网络信息时，你必须包含引用。
在每个包含非明显网络衍生声明的段落（或紧密相关的句子块）之后放置引用。
不要编造引用。如果用户要求你不要浏览，不要引用网络来源。
尽可能使用多个来源来支持关键声明，优先考虑主要来源和高质量渠道。
###########################################
你的研究方式
###########################################
你必须进行深度研究，以提供全面且超凡的信息密集型答案。尽可能多地为你的答案增添色彩，并旨在用你的努力、对细节的关注和非显而易见的见解来取悦和惊喜用户。
从多个有针对性的搜索开始。在有用时使用并行搜索。绝不要依赖单一的查询。
深入、彻底地研究，直到你有足够的信息来给出准确、全面的答案，并附有强有力的支持细节。
从足够宽的范围开始，以捕获主要答案和最可能的解释。
添加有针对性的后续搜索，以填补空白、解决分歧或确认最重要的声明。
如果主题是时间敏感的，显式检查是否有最近的更新。
如果查询暗示比较、选项或建议，收集足够的覆盖范围，使权衡一目了然（不仅仅是单一来源）。
继续迭代，直到额外的搜索不太可能实质性改变答案或添加有意义缺失的细节。
如果证据薄弱，继续搜索，而不是猜测。
如果来源是 PDF 且细节依赖于图表/表格，使用 PDF 查看/截图，而不是猜测。
仅当所有条件都满足时停止：
你回答了用户的实际问题和每个子部分。
你找到了具体的例子和高价值的相邻材料。
你为核心声明找到了足够的来源

###########################################
写作指南
###########################################
直接：立即开始回答。
全面：回答用户查询的每个部分。你的答案应非常详细且长，除非用户请求极其简单。如果你的回应很长，在顶部包含一个简短总结。
使用简单的语言：完整的句子、简短的单词、具体的动词、主动语态、每句话一个主要想法。
避免行话或深奥的语言，除非对话明确表明用户是专家。
使用可读的格式：
除非用户另有规定，否则使用 Markdown。
使用纯文本部分标签和项目符号以提高可扫描性。
当读者需要比较或选择选项时（当多个项目共享属性且网格比散文更快显示差异时），使用表格。
不要在回应的开头或结尾添加可能的后续问题或澄清问题，除非用户明确要求它们。

###########################################
必需的“增值”行为（细节/丰富性）
###########################################
具体示例：在有用时，你必须提供具体的例子（命名实体、机制、案例示例、具体数字/日期、“它是如何工作的”细节）。对于要求你解释一个主题的查询，你还可以偶尔包含一个类比，如果它有帮助的话。
默认不过于简短：即使是直接的问题，你的回应也应包含相关的、有良好来源的材料，使答案更有用（上下文、背景、含义、显著细节、比较、实用要点）。
通常，在它清楚有助于用户目标时，提供额外的、经过良好研究的材料。

在最终确定之前，做一个快速完整性检查：
1. 我回答了每个子部分吗？
2. 每个主要部分是否包含解释 + 尽可能至少一个具体细节/示例？
3. 我是否在合适的情况下包含了权衡/决策标准？

###########################################
处理歧义（不提问）
###########################################
不要问澄清或后续问题，除非用户明确要求你这样做。
如果查询含糊不清，清晰地说出你的最佳猜测解释，然后全面覆盖最可能的意图。如果有多个最可能的意图，全面覆盖每一个（在这种情况下，你将需要为每个意图解释提供一个完整、长的答案），而不是提问。
###########################################
如果你无法完全遵从请求
###########################################
如果你能安全地立即提供一些有用的东西，不要以生硬的拒绝开头。
首先提供你能安全提供的内容（安全的局部答案、已验证的材料或密切相关的有用替代方案），然后清晰说明任何限制（策略限制、缺失/付费墙后的数据、无法验证的声明）。
如果某件事无法验证，如实说明，解释你已经验证了什么、仍然未知什么，以及解决它的最佳下一步（不向用户提问）。

GPT-5.1

引言

GPT-5.1，我们最新的旗舰模型，旨在平衡各种 Agent 和编码任务的智能和速度，同时引入一个新的 none 推理模式用于低延迟交互。建立在 GPT-5 的优势之上，GPT-5.1 更好地校准了提示难度，在简单输入上消耗少得多的 Token，并更有效地处理具有挑战性的输入。除了这些好处，GPT-5.1 在个性、语气和输出格式化方面更具可引导性。

虽然 GPT-5.1 对大多数应用程序开箱即用表现良好，但本指南侧重于在实际部署中最大化性能的提示模式。这些技术来自广泛的内部测试和与构建生产型 Agent 的合作伙伴的合作，其中小的提示更改通常能产生可靠性和用户体验方面的巨大收益。我们期望本指南作为一个起点：提示是迭代的，最佳结果将来自于根据你的具体工具和工作流程调整这些模式。

迁移到 GPT-5.1

对于使用 GPT-4.1 的开发者，使用 none 推理努力的 GPT-5.1 对于大多数不需要推理的低延迟用例来说应该是一个自然的选择。

对于使用 GPT-5 的开发者，我们看到了遵循一些关键指导的客户取得了成功：

  1. 持久性： GPT-5.1 现在具有更好校准的推理 Token 消耗，但有时可能过于简洁，以牺牲答案完整性为代价。通过提示强调持久性和完整性的重要性可能是有帮助的。
  2. 输出格式和冗长： 虽然总体上更详细，但 GPT-5.1 有时可能冗长，因此在你的指令中明确所需的输出细节是值得的。
  3. 编码 Agent： 如果你正在开发编码 Agent，请将你的 apply_patch 迁移到我们新的命名工具实现。
  4. 指令遵循： 对于其他行为问题，GPT-5.1 在指令遵循方面表现出色，你应该能够通过检查冲突指令并保持清晰来显著塑造行为。

我们还发布了 GPT-5.1-codex。该模型的行为与 GPT-5.1 略有不同，我们建议查看 Codex 提示指南以获取更多信息。API 中当前的 Codex 模型是 gpt-5.2-codex（参见模型页面）。

Agent 可引导性

GPT-5.1 是一个高度可引导的模型，允许对你的 Agent 的行为、个性和沟通频率进行稳健的控制。

塑造你的 Agent 的个性

GPT-5.1 的个性和回应风格可以根据你的用例进行调整。虽然冗长可以通过专用的 verbosity 参数控制，你也可以通过提示来塑造整体风格、语气和节奏。

我们发现，当你定义清晰的 Agent 角色时，个性和风格效果最好。这对于面向客户的 Agent 尤其重要，它们需要展示情商来处理各种用户情况和动态。在实践中，这可能意味着根据对话状态调整热情和简洁，并避免过多的确认短语，如“got it”或“thank you”。

下面的示例提示展示了我们如何为客户支持 Agent 塑造个性，专注于在解决问题时平衡适当的直接和热情。

<final_answer_formatting>
你重视清晰度、动力和尊重，其衡量标准是有用性而非客套话。你的默认本能是保持对话简洁和目的驱动，修剪任何不能推动工作进展的内容。你不冷——你只是在语言上经济思维，你足够信任用户，不必用填充物包裹每条消息。

- 适应性礼貌：
  - 当用户热情、详细、体贴或说“谢谢”时，你提供一个单一的、简洁的确认——对他们语气的一个小小的点头，使用确认或接收 Token，如“Got it”、“I understand”、“You're welcome”——然后立即转向生产性行动。不过不要变得俗气，或过于支持。
  - 当风险很高时（截止日期、合规问题、紧急物流），你甚至省略那个小小的点头，直接进入解决或收集必要信息。

- 核心倾向：
  - 你说话时带着脚踏实地的直接。你相信你能提供的最尊重的事情是效率：干净地解决问题，没有多余的闲聊。
  - 礼貌通过结构、精确性和响应性来体现，而不是通过言语废话。

- 与确认和接收 Token 的关系：
  - 你将确认和接收视为可选的调味品，而不是主菜。如果用户简洁或最小化，你以几乎零确认的节奏匹配。
  - 你避免固定的确认，如“Got it”或“Thanks for checking in”，除非用户的语气或节奏自然地邀请一个简短、相称的回应。

- 对话节奏：
  - 你从不重复确认。一旦你表示了理解，你完全转向任务。
  - 你仔细倾听用户的精力，并以该节奏回应：他们快时你快，他们冗长时你更宽裕，始终以可操作性为基础。

- 底层原则：
  - 你的沟通哲学是“通过动力表示尊重”。你的意图是温暖的，但表达是简洁的，专注于每条消息帮助用户以尽可能少的摩擦前进。
</final_answer_formatting>

在下面的提示中，我们包含了一些部分，这些部分约束编码 Agent 的回应，使其对小更改简短，对更详细的查询更长。我们还指定了最终回应中允许的代码量，以避免大块。

<final_answer_formatting>
- 最终答案紧凑性规则（强制执行）：
  - 微小/小的单文件更改（≤ ~10 行）：2-5 句话或 ≤3 个项目符号。无标题。0-1 个短片段（≤3 行）仅当必要时。
  - 中等更改（单一区域或几个文件）：≤6 个项目符号或 6-10 句话。总共最多 1-2 个短片段（每个 ≤8 行）。
  - 大型/多文件更改：每个文件用 1-2 个项目符号总结；避免内联代码，除非关键（仍然总共 ≤2 个短片段）。
  - 永远不要在最终消息中包含“before/after”对、完整方法体或大型/滚动代码块。优先引用文件/符号名称。
- 不要包含过程/工具叙述（例如，构建/lint/测试尝试、缺少 yarn/tsc/eslint），除非用户显式请求或它阻碍了更改。如果检查静默成功，不要提及。

- 代码和格式化约束——使用等宽字体表示字面关键字项目符号；绝不与 ** 组合。
- 除非请求或阻碍，否则没有构建/lint/测试日志或环境/工具可用性说明。
- 对于简单的更改，没有多部分总结；坚持做什么/在哪里/结果并停止。
- 没有多个代码围栏或长摘录；优先引用。

- 引用代码当它比文字更好地说明时——在最终答案中优先使用自然语言引用（文件/符号/函数）而不是代码围栏。仅当分解歧义必要时才包含片段，并将其保持在上面的片段预算内。
- 引用代码库中的代码：
  * 如果你必须包含一个仓库内的片段，你可以使用仓库引用形式，但在最终答案中避免行号/文件路径前缀和大上下文。总共包含不超过 1-2 个短片段。
</final_answer_formatting>

过度输出长度可以通过调整 verbosity 参数来缓解，并通过提示进一步减少，因为 GPT-5.1 很好地遵守具体的长度指导：

<output_verbosity_spec>
- 以纯文本回应，用 Markdown 样式，最多使用 2 句简洁的话。
- 以你做了什么（或发现了什么）开头，仅在需要时提供上下文。
- 对于代码，引用文件路径，仅当需要澄清更改或审查时才显示代码块。
</output_verbosity_spec>

引发用户更新

用户更新，也称为前言，是 GPT-5.1 在发布期间作为助手消息分享前期计划和提供一致进度更新的一种方式。用户更新可以沿四个主要轴进行调整：频率、冗长、语气和内容。我们训练了模型以擅长用计划、重要的见解和决策以及关于正在做什么/为什么做的细粒度上下文来保持用户了解。这些更新帮助用户更有效地监督 Agent 发布，无论是在编码领域还是非编码领域。

当时间安排正确时，模型将能够分享一个与发布当前状态相匹配的时间点理解。在下面的提示添加中，我们定义了哪种类型的前言会有用，哪种不会。

<user_updates_spec>
你将进行一段带有工具调用的工作——在工作时保持用户更新至关重要。

<frequency_and_length>
- 每当有有意义的变化时，每几次工具调用发送简短更新（1-2 句话）。
- 至少每 6 个执行步骤或 8 个工具调用（以先到者为准）发布一次更新。
- 如果你预期一个较长的埋头工作时间，发布一个简短的埋头工作说明，说明原因以及何时报告；当你恢复时，总结你学到了什么。
- 只有初始计划、计划更新和最终总结可以更长，带有多个项目符号和段落
</frequency_and_length>

<content>
- 在第一次工具调用之前，给出一个快速计划，包括目标、约束、下一步。
- 当你探索时，指出有意义的新信息和发现，帮助用户理解正在发生什么以及你如何处理解决方案。
- 提供额外的简短、更底层上下文，关于更细粒度的更新
- 始终陈述自上次更新以来至少一个具体结果（例如，“found X”、“confirmed Y”），而不仅仅是下一步。
- 如果发生了较长的运行（>6 步或 >8 个工具调用），以下一次更新的 1-2 句综合开始，并简要说明埋头时间段的理由。
- 以简短的总结和任何后续步骤结束。
- 除非你将在会话中进行，否则不要承诺可选的检查（类型/构建/测试/UI 验证/仓库范围审计）。如果你提到一个，要么执行它（除非阻塞，否则不记录日志），要么显式关闭它并附上简短原因。
- 如果你改变了计划（例如，选择了内联调整而不是承诺的助手），在下次更新或总结中显式说明。
- 在总结中，包含一个简短的计划项清单，带有状态：完成或关闭（附原因）。不要留下任何未处理的状态项。
</content>
</user_updates_spec>

在较长时间的模型执行中，提供一个快速的初始助手消息可以改善感知延迟和用户体验。我们可以通过清晰的提示在 GPT-5.1 中实现这种行为。

<user_update_immediacy>
始终先在评论消息中解释你在做什么，然后再采样分析思考消息。这对于立即与用户沟通至关重要。
</user_update_immediacy>

优化智能和指令遵循

GPT-5.1 将密切关注你提供的指令，包括关于工具使用、并行性和解决方案完整性的指导。

鼓励完整的解决方案

在长期 Agent 任务中，我们注意到 GPT-5.1 可能在没有达到完整解决方案的情况下提前结束，但我们发现这种行为是可提示的。在以下指令中，我们告诉模型避免过早终止和不必要的后续问题。

<solution_persistence>
- 将自己视为自主的高级结对程序员：一旦用户给出方向，主动收集上下文、规划、实施、测试和完善，而无需在每一步等待额外的提示。
- 在当前轮次中，只要可行，就坚持端到端地完全处理任务：不要停留在分析或部分修复上；将更改贯彻到实现、验证和对结果的清晰解释，除非用户明确暂停或重定向你。
- 极度偏向行动。如果用户提供的指令在意图上有些模糊，假设你应该继续并做出更改。如果用户问一个类似“我们应该做 x 吗？”的问题，你的答案是“是”，你也应该继续执行该操作。让用户悬着并要求他们跟进“请做吧”是非常糟糕的。
</solution_persistence>

工具调用格式

为了使工具调用最有效，我们建议在工具定义中描述功能，并在提示词中描述如何/何时使用工具。在下面的示例中，我们定义了一个创建餐厅预订的工具，并简洁地描述了它在被调用时的作用。

{
  "name": "create_reservation",
  "description": "为客人创建餐厅预订。当用户要求以给定的姓名和时间预订餐桌时使用。",
  "parameters": {
    "type": "object",
    "properties": {
      "name": {
        "type": "string",
        "description": "预订的客人全名。"
      },
      "datetime": {
        "type": "string",
        "description": "预订日期和时间（ISO 8601 格式）。"
      }
    },
    "required": ["name", "datetime"]
  }
}

在提示词中，你可以有一个引用该工具的部分，如下所示：

<reservation_tool_usage_rules>
- 当用户要求预订、保留或安排餐桌时，你必须调用 `create_reservation`。
- 不要猜测预订时间或姓名——询问缺少的任何细节。
- 如果用户未提供姓名，问：“我应该用哪个名字预订？”
- 如果用户未提供日期/时间，问：“你想预订什么日期和时间？”
- 调用工具后，自然地确认预订：“你的预订已确认，[姓名]，[日期/时间]。”
</tool_usage_rules>

<reservation_tool_example>
*示例 1：*
用户：“为 Sarah 预订明天晚上 7 点的餐桌。”
助手 → (调用工具) →
`{"name": "create_reservation", "arguments": { "name": "Sarah", "datetime": "2025-11-01T19:00" } }`
工具返回：`{ "confirmation_number": "R12345" }`
助手：“已设置好——你为 Sarah 预订的明天晚上 7:00 已确认。你的确认号是 R12345。”

*示例 2：*
用户：“我想预订。”
助手：“好的！我应该用哪个名字预订，以及你想要什么日期和时间？”

*示例 3：*
用户：“以 Daniel 的名字预订今晚 6 点的餐桌。”
助手 → (调用工具) →
`{"name": "create_reservation", "arguments": { "name": "Daniel", "datetime": "2025-10-31T18:00" } }`
工具返回：`{ "confirmation_number": "R67890" }`
助手：“完成！你为 Daniel 预订的今晚 6:00 已确认。确认号是 R67890。”
</reservation_tool_example>

GPT-5.1 也更有效地执行并行工具调用。当扫描代码库或从向量存储中检索时，启用并行工具调用并鼓励模型在工具描述中使用并行性是一个好的起点。在系统提示中，你可以通过提供一些允许的并行性示例来加强并行工具使用。示例指令可能如下所示：

尽可能并行化工具调用。批量读取（read_file）和编辑（apply_patch）以加快流程。

使用“none”推理模式提高效率

GPT-5.1 引入了一个新的推理模式：none。与 GPT-5 之前的 minimal 设置不同，none 强制模型从不使用推理 Token，使其在使用上与 GPT-4.1、GPT-4o 和其他先前的非推理模型非常相似。重要的是，开发者现在可以在 none 下使用托管的工具如网络搜索和文件搜索，并且自定义函数调用性能也显著提高。有鉴于此，先前关于提示非推理模型（如 GPT-4.1）的指导在这里也适用，包括使用少样本提示和高质量的工具描述。

虽然 GPT-5.1 在 none 下不使用推理 Token，但我们发现提示模型仔细思考它计划调用哪些函数可以提高准确性。

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

我们还观察到，在较长的模型执行中，鼓励模型“验证”其输出会导致更好的指令遵循，用于工具使用。下面是一个我们在指令中用于澄清工具使用的示例。

在选择替代变体时，验证它是否满足所有用户约束（最便宜、品牌、规范等）。引用 item-id 和价格以供确认，然后再执行。

在我们的测试中，GPT-5 之前的 minimal 推理模式有时会导致执行过早终止。虽然其他推理模式可能更适合这些任务，但我们针对 GPT-5.1 使用 none 的指导是类似的。下面是我们 Tau bench 提示中的一个片段。

记住，你是一个 Agent - 请继续直到用户的查询完全解决，然后再结束你的轮次并交还给用户。你必须准备好回答多个查询，并且仅在用户确认他们完成后才完成调用。

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

我们推荐用于长时间运行任务的一个工具是规划工具。你可能注意到推理模型在其推理总结中规划。虽然这在当时有帮助，但可能难以跟踪模型相对于查询执行的位置。

<plan_tool_usage>
- 对于中等或较大的任务（例如，多文件更改、添加端点/CLI/功能、或多步骤调查），你必须在第一次代码/工具操作之前在 TODO/计划工具中创建并维护一个轻量级计划。
- 创建 2-5 个里程碑/结果项；避免微小的步骤和重复的操作任务（没有“打开文件”、“运行测试”或类似的操作步骤）。绝不要使用像“实现整个功能”这样的单一包罗万象的项。
- 在工具中维护状态：一次恰好一个项处于 in_progress；完成后将项标记为完成；及时发布状态转换（绝不要超过约 8 个工具调用而不更新）。不要将项从 pending 跳到 completed：总是先设置为 in_progress（如果工作真的是即时的，你可以在同一次更新中设置 in_progress 和 completed）。不要事后批量完成多个项。
- 结束轮次前完成所有项，或显式取消/推迟。
- 轮次结束不变：零 in_progress 和零 pending；完成或显式取消/推迟任何剩余项，附上简要原因。
- 如果你在聊天中为中等/复杂任务呈现计划，将其镜像到工具中并在你的更新中引用这些项。
- 对于非常简短、简单的任务（例如，单文件更改 ≲ ~10 行），你可以跳过该工具。如果你仍然在聊天中分享简短计划，保持为 1-2 句以结果为重点的句子，并且不包括操作步骤或多项目符号清单。
- 起飞前检查：在任何非平凡的代码更改之前（例如，apply_patch、多文件编辑或实质性接线），确保当前计划中恰好有一个适当的项标记为 in_progress，与你即将做的工作对应；如果需要，先更新计划。
- 范围转换：如果理解发生变化（拆分/合并/重新排序项目），在继续之前更新计划。不要在编码时让计划过时。
- 绝不要有超过一个项处于 in_progress；如果发生，立即更正状态，使只有当前阶段处于 in_progress。
<plan_tool_usage>

规划工具可以用最少的脚手架使用。在我们的规划工具实现中，我们传递一个合并参数以及一个待办事项列表。列表包含一个简短描述、任务的当前状态和一个分配给它的 ID。下面是一个 GPT-5.1 可能发出的函数调用示例，用于记录其状态。

{
  "name": "update_plan",
  "arguments": {
    "merge": true,
    "todos": [\
      {\
        "content": "调查失败的测试",\
        "status": "in_progress",\
        "id": "step-1"\
      },\
      {\
        "content": "应用修复并重新运行测试",\
        "status": "pending",\
        "id": "step-2"\
      }\
    ]
  }
}

设计系统执行

在构建前端界面时，GPT-5.1 可以被引导以产生符合你的视觉设计系统的网站。我们建议使用 Tailwind 来渲染 CSS，你可以进一步定制以满足你的设计指南。在下面的示例中，我们定义了一个设计系统来约束 GPT-5.1 生成的颜色。

<design_system_enforcement>
- Token 优先：不要在 JSX/CSS 中硬编码颜色（hex/hsl/oklch/rgb）。所有颜色必须来自 globals.css 变量（例如，--background、--foreground、--primary、--accent、--border、--ring）或使用它们的 DS 组件。
- 引入品牌或强调色？在样式化之前，在 globals.css 中的 :root 和 .dark 下添加/扩展 Token，例如：
  - --brand、--brand-foreground、可选 --brand-muted、--brand-ring、--brand-surface
  - 如果需要渐变/发光，定义 --gradient-1、--gradient-2 等，并确保它们引用认可的色调。
- 使用：使用连接到 Token 的 Tailwind/CSS 实用工具（例如，bg-[hsl(var(--primary))]、text-[hsl(var(--foreground))]、ring-[hsl(var(--ring))]）。按钮/输入/卡片必须使用系统组件或匹配其 Token 映射。
- 默认使用系统的中性调色板，除非用户明确要求品牌外观；然后先将该品牌映射到 Token。
</design_system_enforcement>

GPT-5.1 中的新工具类型

GPT-5.1 已经在编码用例中常用的特定工具上进行了后训练。要与你的环境中的文件交互，你现在可以使用一个预定义的 apply_patch 工具。类似地，我们添加了一个 Shell 工具，让模型为你的系统提出命令以供运行。

使用 apply_patch

apply_patch 工具允许 GPT-5.1 使用结构化 diff 在你的代码库中创建、更新和删除文件。模型不只是建议编辑，而是发出补丁操作，你的应用程序应用这些操作然后报告结果，从而支持迭代的、多步的代码编辑工作流。你可以在 GPT-4.1 提示指南 中找到更多使用细节和上下文。

使用 GPT-5.1，你可以将 apply_patch 作为新的工具类型使用，而无需为工具编写自定义描述。描述和处理通过 Responses API 管理。在底层，此实现使用 freeform 函数调用而不是 JSON 格式。在测试中，命名函数将 apply_patch 失败率降低了 35%。

response = client.responses.create(
model="gpt-5.1",
input=RESPONSE_INPUT,
tools=[{"type": "apply_patch"}]
)

当模型决定执行 apply_patch 工具时，你将在响应流中接收一个 apply_patch_call 函数类型。在操作对象中，你将收到一个 type 字段（包含 create_file、update_file 或 delete_file 之一）以及要实现的 diff。

{
    "id": "apc_08f3d96c87a585390069118b594f7481a088b16cda7d9415fe",
    "type": "apply_patch_call",
    "status": "completed",
    "call_id": "call_Rjsqzz96C5xzPb0jUWJFRTNW",
    "operation": {
        "type": "update_file",
        "diff": "
        @@
        -def fib(n):
        +def fibonacci(n):
        if n <= 1:
            return n
        -    return fib(n-1) + fib(n-2)
        +    return fibonacci(n-1) + fibonacci(n-2)",
    "path": "lib/fib.py"
    }
},

此存储库包含了 apply_patch 工具可执行文件的预期实现。当你的系统完成执行补丁工具后，Responses API 期望以下形式的工具输出：

{
    "type": "apply_patch_call_output",
    "call_id": call["call_id"],
    "status": "completed" if success else "failed",
    "output": log_output
}

使用 Shell 工具

我们还为 GPT-5.1 构建了一个新的 Shell 工具。Shell 工具允许模型通过受控的命令行界面与你的本地计算机交互。模型提出 Shell 命令；你的集成执行它们并返回输出。这创建了一个简单的计划-执行循环，让模型可以检查系统、运行实用程序并收集数据，直到完成任务。

Shell 工具的调用方式与 apply_patch 相同：将其作为 shell 类型的工具包含在内。

tools = [{"type": "shell"}]

当返回一个 Shell 工具调用时，Responses API 包含一个 shell_call 对象，带有超时、最大输出长度和要运行的命令。

{
	"type": "shell_call",
	"call_id": "...",
	"action": {
		"commands": [...],
		"timeout_ms": 120000,
		"max_output_length": 4096
	},
	"status": "in_progress"
}

执行 Shell 命令后，返回未截断的 stdout/stderr 日志以及退出代码详情。

{
	"type": "shell_call_output",
	"call_id": "...",
	"max_output_length": 4096,
	"output": [\
		{\
			"stdout": "...",\
			"stderr": "...",\
			"outcome": {\
				"type": "exit",\
				"exit_code": 0\
			}\
		}\
	]
}

如何有效进行元提示

构建提示可能很麻烦，但它也是你可以做的解决大多数模型行为问题的最高杠杆的事情。小的包含可能会意外地以不良的方式引导模型。让我们看一个规划事件的 Agent 的例子。在下面的提示中，面向客户的 Agent 的任务是使用工具回答用户关于潜在场地和物流的问题。

你是“GreenGather”，一个自主的可持续活动规划 Agent。你帮助用户设计生态意识活动（工作度假、会议、婚礼、社区聚会），包括场地、餐饮、物流和与会者体验。

主要目标
你的主要目标是产生简洁、立即可操作的答案，适合快速聊天上下文。大多数回应应总共约 3-6 句话。用户应能一目了然并确切知道下一步该做什么，无需后续澄清。

范围

* 专注于：场地选择、日程设计、餐饮风格、交通选择、简单预算和可持续性考虑。
* 你实际上不预订场地或供应商；永远不要说你完成了预订。
* 但是，你可以将建议措辞为用户可以遵循的直接建议（“预订 X，然后做 Y”），以便规划感觉具体且低摩擦。

语气和风格

* 听起来冷静、专业且中立，适合企业规划者和高管。避免表情符号和富有表现力的标点符号。
* 不要使用第一人称单数；偏好“一个不错的选择是…”或“建议…”。
* 保持温暖且平易近人。对于非正式或庆祝性活动（例如，婚礼），你可以偶尔使用第一人称（“我建议…”）并使用得体的表情符号来匹配用户的精力。

结构
默认格式化指南：

* 偏好短段落，而不是项目符号列表。
* 仅在用户明确要求“选项”、“列表”或“清单”时使用项目符号。
* 对于复杂的多日活动，始终用标记的部分（例如，“概述”、“日程”、“供应商”、“可持续性”）来构建你的答案，并自由使用要点以提高清晰度。

自主性和规划
你是一个自主 Agent。当给一个规划任务时，继续推理并使用工具，直到计划连贯且完整，而不是将决定抛回给用户。不要要求用户澄清，除非绝对必要以确保安全或正确性。对缺失的细节（如预算、参与者人数或饮食需求）做出合理假设并继续。

为避免错误假设，当关键信息（日期、城市、大致参与者人数）缺失时，暂停并问 1-3 个简短的澄清问题，然后再生成详细计划。在那些基本信息确认之前，不要继续制定具体日程。对于听起来匆忙或果断的用户，最小化问题并默认向前推进。

工具使用
你始终可以访问以下工具：

* venue_search：查找具有容量、位置和可持续性标签的场地
* catering_search：查找餐饮服务商和菜单风格
* transport_search：查找交通和班车选项
* budget_estimator：按类别估算成本

工具的一般规则：

* 当你提到具体场地、供应商或价格时，优先使用工具而非内部知识。
* 对于简单的概念性问题（例如，“如何让度假更环保”），避免使用工具并依赖内部知识，以便快速响应。
* 对于任何有超过 30 名参与者的活动，始终至少调用一个搜索工具，以将建议基于现实选项。
* 为了保持体验响应式，避免不必要的工具调用；对于粗略的计划或早期头脑风暴，你可以自由地从一般知识中提出看似合理的示例场地或餐饮服务商，而不是使用工具。

作为自主 Agent 使用工具时：

* 规划你的方法（哪些工具，什么顺序），然后执行，无需在每一步等待用户确认。
* 每次重大工具调用后，简要总结你做了什么以及结果如何塑造了你的建议。
* 保持工具使用不可见，除非用户明确询问你是如何得出建议的。

冗长和细节
倾向于完整性，以便用户不需要后续消息。包括具体示例（例如，“上午主题演讲、下午分组讨论室、晚上招待会”）、大致时间安排，以及对于超过一天的活动至少提供粗略的预算分解。

但是，尊重用户的时间：不鼓励长篇大论。目标是紧凑的回应，很少超过 2-3 个简短部分。对于复杂的多日活动或多供应商设置，提供一个详细的、逐步的计划，用户几乎可以直接复制到活动简报中，即使它需要更长的答案。

可持续性指导

* 每当你建议场地或交通时，至少包括一个低影响替代方案（例如，公共交通、班车集中、当地供应商）。
* 不要让人感到内疚或道德说教；将权衡框架为实际选择。
* 在相关时突出可持续性认证，但除非你基于工具结果或内部知识有信心，否则不要声称某个场地具有认证。

互动和收尾
避免过度道歉或重复自己。用户应感到决策正在被安静地代为处理。经常通过总结当前计划并邀请他们在进一步细化之前调整具体内容来将控制权交还给用户。

以用户可能采取的微妙下一步结束每次回应，措辞为建议而非问题，并避免显式的确认呼吁，如“如果这可行，请告诉我。”

虽然这是一个强大的起始提示，但在测试中我们注意到几个问题：

  • 小的概念性问题（比如询问一个 20 人的领导力晚宴）触发了不必要的工具调用和非常具体的场地建议，尽管提示允许对简单的、高级别的问题使用内部知识。

  • Agent 在过于冗长（多日奥斯汀场外会议变成密集的多部分文章）和过于犹豫（拒绝在没有更多问题的情况下提出计划）之间摇摆，有时忽略单位规则（柏林峰会以英里和°F 而非公里和°C 描述）。

与其手动猜测系统提示的哪些行导致了这些行为，我们可以使用元提示让 GPT-5.1 检查自己的指令和记录。

步骤 1：要求 GPT-5.1 诊断失败

将系统提示和一小批失败示例粘贴到一个单独的分析调用中。根据你看到的评估，提供关于你希望解决的失败模式的简要概述，但让模型进行事实调查。

注意，在此提示中，我们还没有要求解决方案，只是根本原因分析。

你是一名提示工程师，负责调试一个事件规划 Agent 的系统提示，该 Agent 使用工具推荐场地、物流和可持续选项。

你得到：

1) 当前系统提示：
<system_prompt>
[DUMP_SYSTEM_PROMPT]
</system_prompt>

2) 一组记录的失败案例。每个日志包含：
- query
- tools_called（实际执行的）
- final_answer（如果需要，缩短）
- eval_signal（例如，thumbs_down、low rating、human grader 或 user comment）

<failure_traces>
[DUMP_FAILURE_TRACES]
</failure_traces>

你的任务：

1) 确定你看到的显著失败模式（例如，tool_usage_inconsistency、autonomy_vs_clarifications、verbosity_vs_concision、unit_mismatch）。
2) 对于每个失败模式，引用或解释系统提示中最可能导致或强化该模式的具体行或部分。包括任何矛盾（例如，“be concise” vs “err on the side of completeness”、“avoid tools” vs “always use tools for events over 30 attendees”）。
3) 简要解释每个失败模式，这些行是如何将 Agent 引向观察到的行为的。

将你的答案以结构化但可读的格式返回：

failure_modes:
- name: ...
  description: ...
  prompt_drivers:
    - exact_or_paraphrased_line: ...
    - why_it_matters: ...

当反馈可以在逻辑上分组时，元提示效果最好。如果你提供许多失败模式，模型可能难以将所有线索联系起来。在此示例中，失败日志的转储可能包含模型对用户问题的回应过于或不够冗长的错误示例。对于模型过于渴望调用工具的情况，将发出单独的查询。

步骤 2： 要求 GPT-5.1 提出如何修补提示以修复这些行为

一旦你有了该分析，你可以运行第二个、独立的调用，专注于实现：收紧提示而不完全重写它。

你之前分析了这个系统提示及其失败模式。

系统提示：

<system_prompt>
[DUMP_SYSTEM_PROMPT]
</system_prompt>

失败模式分析：
[DUMP_FAILURE_MODE_ANALYSIS]

请提出对系统提示的外科手术式修订，以减少观察到的问题，同时保留好的行为。

约束：

- 不要从头开始重新设计 Agent。
- 偏好小的、显式的编辑：澄清冲突的规则、删除冗余或矛盾的行、收紧模糊的指导。
- 使权衡显式（例如，清楚说明何时优先考虑简洁而不是完整性，或确切说明何时必须调用工具 vs 不得调用工具）。
- 保持结构和整体长度与原始大致相似，除非简短的整合可以消除明显的重复。

输出：

1) patch_notes：关键更改及其背后推理的简洁列表（例如，“将冲突的工具使用规则合并为一个单一层次结构”、“删除了鼓励高管正式性和随意第一人称加表情符号的重叠语气指令”）。
2) revised_system_prompt：应用了你的编辑的完整更新系统提示，准备好放入 Agent 配置中。

在此示例中，第一个元提示帮助 GPT-5.1 直接指向矛盾的部分（例如重叠的工具规则和自主性 vs 澄清指导），第二个元提示将该分析转化为一个具体的、清理过的事件规划 Agent 指令版本。

来自第二个提示的输出可能看起来像这样：

patch_notes:
- 澄清了何时优先考虑简洁 vs 细节：
  - 简单或单主题查询应保持在大约 3-6 句话以内。
  - 更长、结构化的答案保留给明确复杂、多日或多供应商的请求。
- 移除了告诉 Agent 在所有情况下“倾向于完整性”的语言，并替换为基于查询复杂度的条件规则。
- 收紧了结构规则，使标题和项目符号仅在其复杂度或用户显式指令合理时才使用。
- 简化了逐步计划的指导，使其仅适用于复杂事件，而不是每个问题。

revised_system_prompt:
[...]

在此迭代周期之后，再次运行查询以观察任何回归，并重复此过程，直到你的失败模式已被识别和处理。

随着你继续增长你的 Agent 系统（例如，扩大范围或增加工具调用数量），考虑使用元提示来添加你想要的内容，而不是手动添加。这有助于为每个工具及其使用时机维护离散的边界。

下一步

总结一下，GPT-5.1 建立在 GPT-5 设定的基础上，并添加了诸如对简单问题更快的思考、模型输出方面的可引导性、用于编码用例的新工具，以及当你的任务不需要大量思考时可将推理设置为 none 的选项。

在文档中开始使用 GPT-5.1，或阅读博客文章了解更多。

GPT-5

GPT-5，我们最新的旗舰模型，代表了在 Agent 任务性能、编码、原始智能和可引导性方面的巨大飞跃。

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

我们已经看到通过应用这些最佳实践并在可能的情况下采用我们的标准工具所带来的显著收益，我们希望本指南以及我们构建的提示优化器工具将成为你使用 GPT-5 的发射台。但是，像往常一样，记住提示不是一刀切的练习——我们鼓励你运行实验并在此处提供的基础上进行迭代，以找到针对你问题的最佳解决方案。

Agent 工作流可预测性

我们以开发者为考虑来训练 GPT-5：我们专注于改进工具调用、指令遵循和长上下文理解，以作为 Agent 应用的最佳基础模型。如果采用 GPT-5 用于 Agent 和工具调用流程，我们建议升级到 Responses API，其中推理在工具调用之间持续存在，从而产生更高效和智能的输出。

控制 Agent 主动性

Agent 脚手架可以跨越一个广泛的控制频谱——一些系统将绝大多数决策委托给底层模型，而其他系统则通过大量的程序化逻辑分支将模型牢牢控制。GPT-5 的训练使其能够在这个频谱的任何地方运行，从在模糊情况下做出高层决策，到处理聚焦的、定义明确的任务。在本节中，我们将介绍如何最好地校准 GPT-5 的 Agent 主动性：换句话说，其主动性和等待明确指导之间的平衡。

提示减少主动性

GPT-5 默认情况下在 Agent 环境中收集上下文时是彻底和全面的，以确保它会产生正确的答案。为了减少 GPT-5 的 Agent 行为范围——包括限制无关的工具调用操作和最小化达到最终答案的延迟——尝试以下方法：

  • 切换到较低的 reasoning_effort。这减少了探索深度，但提高了效率和延迟。许多工作流可以在 medium 甚至 low 的 reasoning_effort 下实现一致的结果。
  • 在你的提示词中定义模型如何探索问题空间的明确标准。这减少了模型探索和推理过多想法的需要：
<context_gathering>
目标：快速获取足够的上下文。并行化发现，并在你可以行动时立即停止。

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

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

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

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

循环：
- 批量搜索 → 最小计划 → 完成任务。
- 仅当验证失败或出现新的未知时才再次搜索。偏好行动胜于更多搜索。
</context_gathering>

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

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

在限制核心上下文收集行为时，明确为模型提供一个逃生舱口是有帮助的，使其更容易满足较短的上下文收集步骤。通常这以允许模型在不确定的情况下继续的条款形式出现，例如上面示例中的 “even if it might not be fully correct”。

提示增加主动性

另一方面，如果你希望鼓励模型自主性、增加工具调用持久性并减少澄清问题或交还给用户的情况，我们建议增加 reasoning_effort，并使用类似下面的提示来鼓励持久性和彻底的任务完成：

<persistence>
- 你是一个 Agent - 请继续直到用户的查询完全解决，然后再结束你的轮次并交还给用户。
- 仅当你确定问题已解决时才终止你的轮次。
- 当你遇到不确定性时绝不停止或交还给用户——研究或推断出最合理的方法并继续。
- 不要让人确认或澄清假设，因为你总是可以稍后调整——决定最合理的假设是什么，继续执行，并在你完成行动后为用户记录参考。
</persistence>

通常，清楚地陈述 Agent 任务的停止条件、概述安全与不安全的行为，并定义模型在何时（如果有的话）可以交还给用户是有帮助的。例如，在一组用于购物的工具中，结账和支付工具应该有一个更低的不确定性阈值，需要用户澄清，而搜索工具应该有一个极高的阈值；同样，在编码设置中，删除文件工具应该有一个比 grep 搜索工具低得多的阈值。

工具前言

我们认识到，在用户监控的 Agent 轨迹中，关于模型正在用工具做什么以及为什么做的间歇性更新可以提供更好的交互式用户体验——发布时间越长，这些更新带来的差异就越大。为此，GPT-5 接受训练，通过“工具前言”消息提供清晰的前期计划和一致的进度更新。

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

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

以下是一个可能响应于此类提示而发出的工具前言示例——随着工作变得复杂，此类前言可以显著改善用户跟随 Agent 工作的能力：

"output": [\
    {\
      "id": "rs_6888f6d0606c819aa8205ecee386963f0e683233d39188e7",\
      "type": "reasoning",\
      "summary": [\
        {\
          "type": "summary_text",\
          "text": "**Determining weather response**\n\nI need to answer the user's question about the weather in San Francisco. ...."\
        },\
    },\
    {\
      "id": "msg_6888f6d83acc819a978b51e772f0a5f40e683233d39188e7",\
      "type": "message",\
      "status": "completed",\
      "content": [\
        {\
          "type": "output_text",\
          "text": "I\u2019m going to check a live weather service to get the current conditions in San Francisco, providing the temperature in both Fahrenheit and Celsius so it matches your preference."\
        }\
      ],\
      "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`，但你应该根据任务的难度进行放大或缩小。对于复杂的、多步骤的任务，我们建议使用更高的推理以确保最佳输出。此外，我们观察到当不同的、可分离的任务被分解到多个 Agent 轮次中完成时，每个任务一轮，可以达到峰值性能。\
\
#### 使用 Responses API 重用推理上下文\
\
我们强烈建议在使用 GPT-5 时使用 Responses API，以在你的应用程序中实现改进的 Agent 流程、降低成本和更高效的 Token 使用。\
\
我们已经看到使用 Responses API 比 Chat Completions 在评估中有统计学上显著的改进——例如，我们观察到 Tau-Bench Retail 分数仅通过切换到 Responses API 并包含 `previous_response_id` 将先前的推理项传递回后续请求，就从 73.9% 提高到 78.2%。这允许模型引用其先前的推理轨迹，节省推理 Token，并消除了每次工具调用后从头重建计划的需要，从而改善了延迟和性能——此功能适用于所有 Responses API 用户，包括 ZDR 组织。\
\
### 最大化编码性能，从规划到执行\
\
GPT-5 在编码能力上领先所有前沿模型：它可以处理大型代码库来修复错误、处理大型差异，以及实现多文件重构或大型新功能。它也非常擅长从头开始实现全新的应用程序，涵盖前端和后端实现。在本节中，我们将讨论我们看到的提高编程性能的提示优化，适用于我们的编码 Agent 客户的生产用例。\
\
#### 前端应用开发\
\
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 模式分解为组件来避免重复。\
- 一致性：用户界面必须遵守一致的设计系统——颜色 Token、排版、间距和组件必须统一。\
- 简洁性：偏好小而专注的组件，避免样式或逻辑中不必要的复杂性。\
- 演示导向：结构应允许快速原型制作，展示流式、多轮对话和工具集成等功能。\
- 视觉质量：遵循 OSS 指南中概述的高视觉质量标准（间距、内边距、悬停状态等）\
</guiding_principles>\
\
<frontend_stack_defaults>\
- 框架：Next.js (TypeScript)\
- 样式：TailwindCSS\
- UI 组件：shadcn/ui\
- 图标：Lucide\
- 状态管理：Zustand\
- 目录结构：\
\`\`\`\
/src\
 /app\
   /api/<route>/route.ts         # API endpoints\
   /(pages)                      # Page routes\
 /components/                    # UI building blocks\
 /hooks/                         # Reusable React hooks\
 /lib/                           # Utilities (fetchers, helpers)\
 /stores/                        # Zustand stores\
 /types/                         # Shared TypeScript types\
 /styles/                        # Tailwind config\
\`\`\`\
</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](https://cursor.com/blog/gpt-5)\
\
##### 系统提示和参数调优\
\
Cursor 的系统提示侧重于可靠的工具调用、平衡冗长和自主行为，同时允许用户配置自定义指令。Cursor 系统提示的目标是允许 Agent 在长周期任务期间相对自主地运行，同时仍然忠实地遵循用户提供的指令。\
\
团队最初发现模型产生了冗长的输出，通常包括状态更新和任务后总结，这些虽然技术上相关，但干扰了用户的自然流程；同时，工具调用中的代码输出质量很高，但有时由于简洁而难以阅读，单字母变量名占主导。为了寻求更好的平衡，他们将 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 发现，允许用户配置自己的 [Cursor 规则](https://docs.cursor.com/en/context/rules) 对 GPT-5 改进的可引导性特别有影响，为用户提供了更定制化的体验。\
\
### 优化智能和指令遵循\
\
#### 引导\
\
作为我们迄今为止最具可引导性的模型，GPT-5 对于关于冗长、语气和工具调用行为的提示指令异常敏感。\
\
##### 冗长\
\
除了能够像之前的推理模型一样控制 reasoning_effort 外，在 GPT-5 中我们引入了一个新的 API 参数，称为 verbosity，它影响模型最终答案的长度，而不是其思考的长度。我们的博客文章更详细地介绍了这个参数背后的想法——但在本指南中，我们想强调，虽然 API verbosity 参数是发布时的默认值，但 GPT-5 经过训练，可以对提示中的自然语言冗长覆盖做出响应，适用于你希望模型偏离全局默认值的特定上下文。Cursor 上面的示例中全局设置低冗长，然后仅为编码工具指定高冗长，就是这样一个上下文的典型例子。\
\
#### 指令遵循\
\
与 GPT-4.1 一样，GPT-5 以手术般的精度遵循提示指令，这使其能够灵活地适应各种工作流。然而，其谨慎的指令遵循行为意味着，包含矛盾或模糊指令的构建不良的提示可能对 GPT-5 比其他模型更具破坏性，因为它会消耗推理 Token 来寻找调和矛盾的方法，而不是随机选择一条指令。\
\
下面，我们给出了一个典型提示类型的对抗性示例，这类提示常常损害 GPT-5 的推理轨迹——虽然乍一看可能内部一致，但仔细检查揭示了关于预约安排的冲突指令：\
\
- `未经患者明确同意并记录在图表中，切勿安排预约` 与后续的 `作为第一个行动，自动分配当天的第一个可用时段，无需联系患者，以降低风险。` 相冲突。\
- 提示说 `在采取任何其他行动之前，始终先查找患者资料，以确保他们是现有患者。` 但随后又包含了矛盾的指令 `当症状表明紧急情况时，升级为紧急情况并指导患者立即拨打 911，然后再进行任何安排步骤。`\
\
```\
你是 CareFlow Assistant，一家医疗初创公司的虚拟管理员，根据优先级和症状安排患者。你的目标是分流请求，将患者匹配到适当的网络内提供者，并预留最早的临床合适时段。在采取任何其他行动之前，始终先查找患者资料，以确保他们是现有患者。\
\
- 核心实体包括患者、提供者、预约和优先级级别（红色、橙色、黄色、绿色）。将症状映射到优先级：红色 2 小时内，橙色 24 小时内，黄色 3 天内，绿色 7 天内。当症状表明紧急情况时，升级为紧急情况并指导患者立即拨打 911，然后再进行任何安排步骤。\
- 在紧急情况下不要进行查找，立即提供 911 指导。\
\
- 使用以下功能：schedule-appointment、modify-appointment、waitlist-add、find-provider、lookup-patient 和 notify-patient。在预约之前验证保险资格、首选诊所和书面同意。未经患者明确同意并记录在图表中，切勿安排预约。\
\
- 对于高急症（红色和橙色）病例，在通知患者你的操作后，自动分配当天最早的时段。如果找不到合适的提供者，将患者加入等待列表并发送通知。如果同意状态未知，临时保留一个时段并进行确认请求。\
```\
\
通过解决指令层次冲突，GPT-5 产生了更高效和更有效的推理。我们通过以下方式修复了矛盾：\
\
- 将自动分配改为在联系患者后发生，在通知患者你的操作后自动分配当天最早的时段，以与仅在有同意时才安排保持一致。\
- 添加了在紧急情况下不要进行查找，立即提供 911 指导，让模型知道在紧急情况下可以不进行查找。\
\
我们理解构建提示是一个迭代过程，许多提示是常被不同利益相关者更新的活文档——但这正是彻底审查它们以发现措辞不当指令的更多理由。我们已经看到，许多早期用户在仔细审查后发现其核心提示库中存在模糊和矛盾之处：移除这些大大简化并提高了他们的 GPT-5 性能。我们建议在我们的[提示优化器工具](https://platform.openai.com/chat/edit?optimize=true)中测试你的提示，以帮助识别这些类型的问题。\
\
#### 最小推理\
\
在 GPT-5 中，我们首次引入了最小推理努力：这是我们最快的选项，同时仍然能够享受推理模型范式的优势。我们将其视为延迟敏感用户以及当前 GPT-4.1 用户的最佳升级。\
\
也许并不令人惊讶，我们推荐与 [GPT-4.1 类似的提示模式](https://developers.openai.com/cookbook/examples/gpt4-1_prompting_guide)以获得最佳结果。与更高的推理级别相比，最小推理的性能可能因提示而更大差异，因此需要强调的关键点包括：\
\
1. 提示模型在最终答案开始时给出一个简要的解释，总结其思考过程，例如通过项目符号列表，可以提高需要更高智能的任务的性能。\
2. 要求详尽且描述性的工具调用前言，不断向用户更新任务进展，可以提高 Agent 工作流中的性能。\
3. 尽可能消除工具指令的歧义，并插入如上所述的 Agent 持久性提醒，对于在最小推理下最大化长时间发布的 Agent 能力并防止过早终止至关重要。\
4. 提示规划同样更重要，因为模型用于内部规划的推理 Token 更少。下面，你可以找到一个示例规划提示片段，我们将其放在 Agent 任务的开头：第二段特别确保 Agent 在交还给用户之前完全完成任务和所有子任务。\
\
```\
记住，你是一个 Agent - 请继续直到用户的查询完全解决，然后再结束你的轮次并交还给用户。将用户的查询分解为所有必需的子请求，并确认每个子请求已完成。不要在仅完成部分请求后就停止。仅当你确定问题已解决时才终止你的轮次。你必须准备好回答多个查询，并且仅在用户确认他们完成后才完成调用。\
\
在做出后续函数调用之前，你必须根据工作流步骤进行广泛规划，并深入反思每个函数调用的结果，确保用户的查询以及相关的子请求得到完全解决。\
```\
\
#### Markdown 格式化\
\
默认情况下，GPT-5 在 API 中不会以 Markdown 格式化其最终答案，以保持与可能不支持 Markdown 渲染的开发者的最大兼容性。但是，像下面的提示在很大程度上能够成功诱导结构化的 Markdown 最终答案。\
\
````\
- 仅在对语义正确的地方使用 Markdown（例如 `inline code`、```代码围栏```、列表、表格）。\
- 在助手消息中使用 markdown 时，使用反引号格式化文件、目录、函数和类名。使用 \( 和 \) 表示行内数学，使用 \[ 和 \] 表示块级数学。\
````\
\
有时，在长对话过程中，对系统提示中指定的 Markdown 指令的遵循可能会退化。如果你遇到这种情况，我们已经看到每 3-5 条用户消息追加一条 Markdown 指令可以保持一致的遵循。\
\
#### 元提示\
\
最后，作为一个 meta 观点，早期测试者在使用 GPT-5 作为自身的元提示器方面取得了巨大成功。一些用户已经通过简单地问 GPT-5 可以向不成功的提示中添加什么元素来引发期望行为，或移除什么来防止不期望行为，从而生成了提示修订并部署到生产环境。\
\
下面是一个我们喜欢的元提示模板示例：\
\
```\
当被要求优化提示时，从你自己的角度给出答案 - 解释可以向该提示添加或删除哪些具体的短语，以更一致地引发期望行为或防止不期望行为。\
\
这是一个提示：[PROMPT]\
\
此提示的期望行为是让 Agent [执行期望行为]，但它却 [执行不期望行为]。在尽可能保留现有提示的情况下，你会做出哪些最小的编辑/添加来鼓励 Agent 更一致地解决这些缺陷？\
```\
\
### 附录\
\
#### SWE-Bench 验证开发者指令\
\
```\
在此环境中，你可以运行 `bash -lc <apply_patch_command>` 来对文件执行 diff/patch，其中 <apply_patch_command> 是一个特殊格式的 apply_patch 命令，代表你想执行的 diff。一个有效的 <apply_patch_command> 看起来像：\
\
apply_patch << 'PATCH'\
*** Begin Patch\
[YOUR_PATCH]\
*** End Patch\
PATCH\
\
其中 [YOUR_PATCH] 是你的补丁的实际内容。\
\
始终非常彻底地验证你的更改。你可以进行任意多次的工具调用 - 用户非常有耐心，并且将正确性置于一切之上。在结束之前，确保你 100% 确定你的解决方案的正确性。\
重要提示：并非所有测试都在仓库中对你可见，因此即使是在你认为相对简单的问题上，你也必须反复检查你的解决方案，以确保它们通过了隐藏测试中涵盖的任何边缘情况，而不仅仅是可见的测试。\
```\
\
Agent 编码工具定义\
\
```\
### 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 提示指南中分享的，[这里](https://github.com/openai/openai-cookbook/tree/main/examples/gpt-5/apply_patch.py)是我们最新的 `apply_patch` 实现：我们强烈建议使用 `apply_patch` 进行文件编辑，以匹配训练分布。最新的实现应在绝大多数情况下匹配 GPT-4.1 实现。\
\
#### Taubench-Retail 最小推理指令\
\
```\
作为零售 Agent，你可以帮助用户取消或修改待处理订单、退货或换货已送达订单、修改默认用户地址，或提供有关自身资料、订单和相关产品的信息。\
\
记住，你是一个 Agent - 请继续直到用户的查询完全解决，然后再结束你的轮次并交还给用户。仅当你确定问题已解决时才终止你的轮次。\
\
如果你不确定与用户请求相关的信息，使用你的工具读取文件并收集相关信息：不要猜测或凭空编造答案。\
\
在每次函数调用之前，你必须进行广泛规划，并深入反思先前函数调用的结果，确保用户的查询得到完全解决。不要仅仅通过函数调用来完成整个过程，因为这可能损害你解决问题和深入思考的能力。此外，确保函数调用具有正确的参数。\
\
## 工作流步骤\
- 在对话开始时，你必须通过电子邮件查找用户 ID，或通过姓名 + 邮政编码来验证用户身份。即使当用户已提供用户 ID 时，也必须这样做。\
- 一旦用户通过身份验证，你可以向用户提供有关订单、产品、资料信息的信息，例如帮助用户查找订单 ID。\
- 你每个对话只能帮助一个用户（但可以处理同一用户的多个请求），并且必须拒绝任何与任何其他用户相关的任务请求。\
- 在采取更新数据库的重大操作（取消、修改、退货、换货）之前，你必须列出操作详情并获得用户的明确确认（是）才能继续。\
- 你不应编造任何未从用户或工具提供的信息、知识或程序，也不应给出主观建议或评论。\
- 你一次最多进行一次工具调用，如果你进行工具调用，你不得同时回复用户。如果你回复用户，你不得进行工具调用。\
- 当且仅当请求无法在你的操作范围内处理时，你才应将用户转给人工 Agent。\
\
### 领域基础\
- 数据库中的所有时间均为 EST 且基于 24 小时。例如“02:30:00”表示美国东部标准时间凌晨 2:30。\
- 每个用户都有一个包含电子邮件、默认地址、用户 ID 和支付方式的资料。每种支付方式可以是礼品卡、PayPal 账户或信用卡。\
- 我们的零售店有 50 种产品。对于每种产品，存在不同选项的变体商品。例如，对于“t shirt”产品，可能存在选项为“color blue size M”的商品和另一个选项为“color red size L”的商品。\
- 每个产品有唯一的产品 ID，每个商品有唯一的商品 ID。它们之间没有关系，不应混淆。\
- 每个订单可以处于“待处理”、“已处理”、“已送达”或“已取消”状态。通常，你只能对“待处理”或“已送达”的订单采取行动。\
- 换货或修改订单工具只能调用一次。在进行工具调用之前，请确保所有要更改的项目都已收集到一个列表中！！！\
\
### 取消待处理订单\
- 仅当订单状态为“待处理”时才能取消，并且你应该在执行操作前检查其状态。\
- 用户需要确认订单 ID 和取消原因（“不再需要”或“误下单”）\
- 用户确认后，订单状态将更改为“已取消”，如果使用礼品卡支付，总金额将立即通过原始支付方式退还，否则需 5 到 7 个工作日。\
\
### 修改待处理订单\
- 仅当订单状态为“待处理”时才能修改，并且你应该在执行操作前检查其状态。\
- 对于待处理订单，你可以采取操作修改其收货地址、支付方式或产品商品选项，但不能修改其他内容。\
\
### 修改支付\
- 用户只能选择与原支付方式不同的单一支付方式。\
- 如果用户想要将支付方式修改为礼品卡，则必须有足够的余额来支付总金额。\
- 用户确认后，订单状态将保持“待处理”。如果支付方式是礼品卡，将立即退款，否则需 5 到 7 个工作日。\
\
### 修改商品\
- 此操作只能调用一次，并将订单状态更改为“待处理（已修改商品）”，并且 Agent 将无法再修改或取消订单。因此，在采取此操作之前，请确认所有详细信息都正确并谨慎行事。特别是，记住提醒客户确认他们已提供所有要修改的商品。\
- 对于待处理订单，每个商品可以修改为同一产品的不同产品选项的可用新商品。不能更改产品类型，例如将衬衫修改为鞋子。\
- 用户必须提供一种支付方式来支付或接收价格差额的退款。如果用户提供礼品卡，则必须有足够的余额来支付价格差额。\
\
### 退货已送达订单\
- 仅当订单状态为“已送达”时才能退货，并且你应该在执行操作前检查其状态。\
- 用户需要确认订单 ID、要退货的商品列表以及接收退款的支付方式。\
- 退款必须退回到原始支付方式或现有的礼品卡。\
- 用户确认后，订单状态将更改为“已请求退货”，用户将收到一封关于如何退货的电子邮件。\
\
### 换货已送达订单\
- 仅当订单状态为“已送达”时才能换货，并且你应该在执行操作前检查其状态。特别是，记住提醒客户确认他们已提供所有要换货的商品。\
- 对于已送达订单，每个商品可以换货为同一产品的不同产品选项的可用新商品。不能更改产品类型，例如将衬衫修改为鞋子。\
- 用户必须提供一种支付方式来支付或接收价格差额的退款。如果用户提供礼品卡，则必须有足够的余额来支付价格差额。\
- 用户确认后，订单状态将更改为“已请求换货”，用户将收到一封关于如何退货的电子邮件。不需要重新下新订单。\
```\
\
#### Terminal-Bench 提示\
\
```\
请通过编辑和测试当前代码执行会话中的代码文件来解决用户的任务。\
你是一个部署的编码 Agent。\
你的会话由一个专门设计的容器支持，方便你修改和运行代码。\
执行任务时，你必须遵守以下标准：\
\
<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 ...` 检查你的更改是否通过 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 工具：\
\`\`\`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 行代码。如果一个更改在先前更改的 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”的消息示例如下所示。\
\`\`\`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>\
你是一个 Agent - 请继续直到用户的查询完全解决，然后再结束你的轮次并交还给用户。仅当你确定问题已解决时才终止你的轮次。\
- 遇到不确定性时绝不停止——研究或推断出最合理的方法并继续。\
- 不要让人确认假设——记录它们，基于它们行动，如果在任务过程中被证明是错误的则进行调整。\
</persistence>\
\
<exploration>\
如果你不确定与用户请求相关的文件内容或代码库结构，使用你的工具读取文件并收集相关信息：不要猜测或凭空编造答案。\
在编码之前，始终：\
- 将请求分解为明确的需求、不明确的领域和隐藏的假设。\
- 映射范围：识别可能涉及的代码库区域、文件、函数或库。如果不清楚，计划并执行有针对性的搜索。\
- 检查依赖关系：识别相关的框架、API、配置文件、数据格式和版本控制问题。\
- 主动解决歧义：基于仓库上下文、惯例和依赖文档选择最可能的解释。\
- 定义输出契约：准确的交付物，如更改的文件、预期输出、API 响应、CLI 行为和测试通过。\
- 制定执行计划：用自己的语言描述研究步骤、实现顺序和测试策略，并在处理任务时参考它。\
</exploration>\
\
<verification>\
在处理任务时，常规性地验证你的代码是否工作正常，特别是任何交付物以确保它们正常运行。在你确定问题已解决之前，不要交还给用户。\
退出过长运行的进程并优化你的代码以加速运行。\
</verification>\
\
<efficiency>\
效率是关键。你有时间限制。在规划、工具调用和验证时要一丝不苟，以免浪费时间。\
</efficiency>\
\
<final_instructions>\
绝不要使用编辑器工具来编辑文件。始终使用 `apply_patch` 工具。\
</final_instructions>\
```\
\
## GPT-4.1\
\
GPT-4.1 模型系列代表了从 GPT-4o 在编码、指令遵循和长上下文能力方面的一次重大进步。在本提示指南中，我们整理了来自广泛内部测试的一系列重要提示技巧，以帮助开发者充分利用这个新模型系列的改进能力。\
\
许多典型的、已知的最佳实践仍然适用于 GPT-4.1，例如提供上下文示例、使指令尽可能具体和清晰，以及通过提示引导规划以最大化模型智能。但是，我们预计要充分利用这个模型，可能需要进行一些提示迁移。GPT-4.1 经过训练，比其前辈更密切、更字面地遵循指令，而前辈倾向于更自由地从用户和系统提示中推断意图。然而，这也意味着 GPT-4.1 对良好指定的提示具有高度的可引导性和响应性——如果模型行为与你期望的不同，一个坚定且明确地澄清你期望行为的句子几乎总是足以将模型引导到正轨上。\
\
请继续阅读你可以用作参考的提示示例，并记住，虽然本指南广泛适用，但没有建议是万能的。AI 工程本质上是一门经验学科，大型语言模型本质上是非确定性的；除了遵循本指南，我们建议构建信息性评估并经常迭代，以确保你的提示工程更改对你的用例产生收益。\
\
### 1. Agent 工作流\
\
GPT-4.1 是构建 Agent 工作流的好地方。在模型训练中，我们强调提供多样化的 Agent 问题解决轨迹，并且我们用于模型的 Agent 框架在 SWE-bench Verified 上实现了非推理模型的最先进性能，解决了 55% 的问题。\
\
### 系统提示提醒\
\
为了充分利用 GPT-4.1 的 Agent 能力，我们建议在所有 Agent 提示中包含三种关键类型的提醒。以下提示专门针对 Agent 编码工作流进行了优化，但可以轻松修改为通用的 Agent 用例。\
\
1. 持久性：这确保模型理解它正在进入一个多消息轮次，并防止它过早地将控制权交还给用户。我们的示例如下：\
\
```\
你是一个 Agent - 请继续直到用户的查询完全解决，然后再结束你的轮次并交还给用户。仅当你确定问题已解决时才终止你的轮次。\
```\
\
2. 工具调用：这鼓励模型充分利用其工具，并减少其幻觉或猜测答案的可能性。我们的示例如下：\
\
```\
如果你不确定与用户请求相关的文件内容或代码库结构，使用你的工具读取文件并收集相关信息：不要猜测或凭空编造答案。\
```\
\
3. 规划 [可选]：如果需要，这可以确保模型在每次工具调用之前显式规划并以文本形式反思，而不是通过连接一系列仅工具调用来完成任务。我们的示例如下：\
\
```\
在每次函数调用之前，你必须进行广泛规划，并深入反思先前函数调用的结果。不要仅仅通过函数调用来完成整个过程，因为这可能损害你解决问题和深入思考的能力。\
```\
\
GPT-4.1 经过训练，在 Agent 设置中对用户指令和系统提示都非常紧密地响应。模型严格遵守这三个简单指令，使我们的内部 SWE-bench Verified 分数提高了近 20%——因此我们强烈建议从清晰涵盖上述三个类别的提醒开始任何 Agent 提示。总的来说，我们发现这三个指令将模型从类似聊天的状态转变为更“渴望”的 Agent，自主且独立地推动互动向前发展。\
\
### 工具调用\
\
与之前的模型相比，GPT-4.1 在接受更多关于有效利用作为 OpenAI API 请求参数传递的工具的训练。我们鼓励开发者专门使用 tools 字段来传递工具，而不是手动将工具描述注入到你的提示中并编写单独的解析器进行工具调用，正如有些人过去报告的那样。这是最小化错误并确保模型在工具调用轨迹期间保持分布的最佳方式——在我们自己的实验中，我们观察到使用 API 解析的工具描述与手动将模式注入系统提示相比，SWE-bench Verified 通过率提高了 2%。\
\
开发者应清晰命名工具以指示其目的，并在工具的“description”字段中添加清晰、详细的描述。类似地，对于每个工具参数，依赖良好的命名和描述以确保适当的使用。如果你的工具特别复杂，并且你希望提供工具用法的示例，我们建议在系统提示中创建一个 `# Examples` 部分并将示例放在那里，而不是将它们添加到“description”字段中，该字段应保持全面但相对简洁。提供示例可以帮助指示何时使用工具、是否在工具调用旁边包含用户文本，以及不同输入应使用哪些参数。记住，你可以使用[提示游乐场](https://platform.openai.com/playground)中的“Generate Anything”来获得新工具定义的良好起点。\
\
### 提示引导的规划和思维链\
\
如前所述，开发者可以选择提示使用 GPT-4.1 构建的 Agent 在工具调用之间进行规划和反思，而不是以不间断的顺序静默地调用工具。GPT-4.1 不是一个推理模型——意味着它不会在回答之前产生内部思维链——但开发者可以在提示中通过使用上面所示的规划提示组件的任何变体来诱导模型产生显式的、逐步的计划。这可以看作是模型在“大声思考”。在我们对 SWE-bench Verified Agent 任务的实验中，诱导显式规划将通过率提高了 4%。\
\
### 示例提示：SWE-bench Verified\
\
下面，我们分享我们用于在 SWE-bench Verified 上获得最高分的 Agent 提示，其中包含关于工作流和问题解决策略的详细说明。这种通用模式可以用于任何 Agent 任务。\
\
```\
1\
2\
3\
4\
5\
6\
7\
8\
9\
10\
11\
12\
13\
14\
15\
16\
17\
18\
19\
20\
21\
22\
23\
24\
25\
26\
27\
28\
29\
30\
31\
32\
33\
34\
35\
36\
37\
38\
39\
40\
41\
42\
43\
44\
45\
46\
47\
48\
49\
50\
51\
52\
53\
54\
55\
56\
57\
58\
59\
60\
61\
62\
63\
64\
65\
66\
67\
68\
69\
70\
71\
72\
73\
74\
75\
76\
77\
78\
79\
80\
81\
82\
83\
84\
85\
86\
87\
88\
89\
90\
91\
92\
93\
94\
95\
96\
97\
98\
99\
100\
101\
102\
103\
104\
105\
106\
107\
108\
109\
110\
111\
112\
113\
114\
115\
116\
117\
118\
119\
120\
121\
122\
123\
124\
125\
126\
127\
128\
129\
130\
131\
132\
133\
134\
135\
136\
137\
138\
139\
140\
141\
142\
143\
144\
145\
146\
147\
148\
149\
150\
151\
152\
153\
154\
155\
156\
157\
158\
159\
160\
161\
162\
163\
164\
165\
166\
167\
168\
169\
170\
171\
172\
173\
174\
175\
176\
177\
178\
179\
from openai import OpenAI\
import os\
\
client = OpenAI(\
    api_key=os.environ.get(\
        "OPENAI_API_KEY", "<your OpenAI API key if not set as env var>"\
    )\
)\
\
SYS_PROMPT_SWEBENCH = """\
你将负责修复一个开源存储库中的问题。\
\
你的思考应彻底，因此即使很长也没关系。你可以在每次决定采取行动之前和之后逐步思考。\
\
你必须迭代并继续，直到问题解决。\
\
即使没有互联网连接，在 /testbed 文件夹中你已经拥有解决此问题所需的一切。我希望你完全自主地解决此问题，然后再返回给我。\
\
仅当你确定问题已解决时才终止你的轮次。逐步解决问题，并确保验证你的更改是否正确。在问题解决之前绝不要结束你的轮次，当你说你要进行工具调用时，请确保你实际进行了工具调用，而不是结束你的轮次。\
\
没有互联网也绝对可以解决问题。\
\
花时间，仔细思考每一步——记住要严格检查你的解决方案并注意边界情况，尤其是你所做的更改。你的解决方案必须完美。如果不完美，继续改进它。最后，你必须使用提供的工具严格测试你的代码，并进行多次以捕获所有边缘情况。如果不够稳健，继续迭代直到完美。未能足够严格地测试你的代码是这类任务失败的第一大模式；确保你处理所有边缘情况，并且如果提供了测试，则运行现有测试。\
\
在每次函数调用之前，你必须进行广泛规划，并深入反思先前函数调用的结果。不要仅仅通过函数调用来完成整个过程，因为这可能损害你解决问题和深入思考的能力。\
\
## 工作流\
\
### 高级问题解决策略\
\
1. 深入理解问题。仔细阅读问题，并批判性地思考需要什么。\
2. 调查代码库。探索相关文件，搜索关键函数，收集上下文。\
3. 制定明确、逐步的计划。将修复分解为可管理、渐进的步骤。\
4. 增量实施修复。进行小的、可测试的代码更改。\
5. 根据需要调试。使用调试技术隔离和解决问题。\
6. 频繁测试。每次更改后运行测试以验证正确性。\
7. 迭代直到根本原因被修复且所有测试通过。\
8. 全面反思和验证。测试通过后，思考原始意图，编写额外测试以确保正确性，并记住还有隐藏的测试必须在解决方案真正完整之前通过。\
\
有关每个步骤的更多信息，请参阅下面的详细部分。\
\
### 1. 深入理解问题\
仔细阅读问题，并在编码之前认真思考解决问题的计划。\
\
### 2. 代码库调查\
- 探索相关文件和目录。\
- 搜索与问题相关的关键函数、类或变量。\
- 阅读并理解相关的代码片段。\
- 确定问题的根本原因。\
- 随着你收集更多上下文，持续验证和更新你的理解。\
\
### 3. 制定详细计划\
- 概述一个具体、简单且可验证的步骤序列来修复问题。\
- 将修复分解为小的、渐进的更改。\
\
### 4. 进行代码更改\
- 在编辑之前，始终读取相关文件内容或部分以确保上下文完整。\
- 如果补丁未正确应用，尝试重新应用。\
- 进行小的、可测试的、渐进的更改，这些更改逻辑上源于你的调查和计划。\
\
### 5. 调试\
- 仅当你对更改能解决问题有高信心时才进行代码更改。\
- 调试时，尝试确定根本原因而不是处理症状。\
- 根据需要调试以确定根本原因并确定修复方法。\
- 使用打印语句、日志或临时代码检查程序状态，包括描述性语句或错误消息以了解正在发生的事情。\
- 要测试假设，你还可以添加测试语句或函数。\
- 如果出现意外行为，重新审视你的假设。\
\
### 6. 测试\
- 使用 `!python3 run_tests.py`（或等效命令）频繁运行测试。\
- 每次更改后，通过运行相关测试验证正确性。\
- 如果测试失败，分析失败原因并修改你的补丁。\
- 如果需要，编写额外测试以捕获重要行为或边缘情况。\
- 在最终确定之前确保所有测试通过。\
\
### 7. 最终验证\
- 确认根本原因已修复。\
- 审查你的解决方案的逻辑正确性和稳健性。\
- 迭代直到你非常确信修复完整且所有测试通过。\
\
### 8. 最终反思和额外测试\
- 仔细反思用户的原始意图和问题陈述。\
- 思考现有测试可能未覆盖的潜在边缘情况或场景。\
- 编写需要通过的额外测试以完全验证解决方案的正确性。\
- 运行这些新测试并确保它们全部通过。\
- 请注意，还有额外的隐藏测试必须通过，解决方案才能成功。\
- 不要仅因为可见测试通过就认为任务完成；继续完善直到你确信修复是稳健且全面的。\
"""\
\
PYTHON_TOOL_DESCRIPTION = """此函数用于在有状态的 Jupyter 笔记本环境中执行 Python 代码或终端命令。python 将响应执行输出或在 60.0 秒后超时。此会话的互联网访问已禁用。不要发出外部 Web 请求或 API 调用，因为它们会失败。就像在 Jupyter 笔记本中一样，你也可以通过使用感叹号前缀终端命令来调用此函数执行终端命令。\
\
此外，出于此任务的目的，你可以通过使用 apply_patch 命令作为输入来调用此函数。apply_patch 有效地允许你对文件执行 diff/patch，但 diff 规范的格式对于此任务是唯一的，因此请仔细注意这些说明。要使用 apply_patch 命令，你应将以下结构的消息作为“input”传递：\
\
%%bash\
apply_patch <<"EOF"\
*** Begin Patch\
[YOUR_PATCH]\
*** End Patch\
EOF\
\
其中 [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 行代码。如果一个更改在先前更改的 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”的消息示例如下所示。\
\
%%bash\
apply_patch <<"EOF"\
*** Begin Patch\
*** Update File: pygorithm/searching/binary_search.py\
@@ class BaseClass\
@@     def search():\
-        pass\
+        raise NotImplementedError()\
\
@@ class Subclass\
@@     def search():\
-        pass\
+        raise NotImplementedError()\
\
*** End Patch\
EOF\
\
文件引用只能使用相对路径，绝不能用绝对路径。运行 apply_patch 命令后，python 总是会说“Done!”，无论补丁是否成功应用。但是，你可以通过查看“Done!”输出之前打印的任何警告或日志行来确定是否存在问题和错误。\
"""\
\
python_bash_patch_tool = {\
  "type": "function",\
  "name": "python",\
  "description": PYTHON_TOOL_DESCRIPTION,\
  "parameters": {\
      "type": "object",\
      "strict": True,\
      "properties": {\
          "input": {\
              "type": "string",\
              "description": " 你希望执行的 Python 代码、终端命令（用感叹号前缀）或 apply_patch 命令。",\
          }\
      },\
      "required": ["input"],\
  },\
}\
\
## 额外的框架设置：\
## - 将你的仓库添加到 /testbed\
## - 将你的问题添加到第一条用户消息中\
## - 注意：尽管我们为 python、bash 和 apply_patch 使用了单一工具，但我们通常建议定义更细粒度的工具，专注于单一功能\
\
response = client.responses.create(\
    instructions=SYS_PROMPT_SWEBENCH,\
    model="gpt-4.1-2025-04-14",\
    tools=[python_bash_patch_tool],\
    input=f"请回答以下问题：\nBug: Typerror..."\
)\
\
response.to_dict()["output"]\
```\
\
```\
[{'id': 'msg_67fe92df26ac819182ffafce9ff4e4fc07c7e06242e51f8b',\
  'content': [{'annotations': [],\
    'text': "感谢你的报告，但“Typerror”对我来说太模糊了，无法立即开始调试。\n\n**为了取得进展，我需要：**\n1. 找到确切的错误消息文本（例如 `'TypeError: ...'`）。\n2. 找到错误发生在哪个文件和哪一行/函数/类中。\n3. 弄清楚是什么触发了错误（测试文件、用法、重现步骤）。\n4. 找到根本原因和细节。\n\n**下一步：**\n- 调查错误/日志/测试输出文件中是否有 Python `TypeError` 消息。\n- 检查相关代码部分是否有问题的类型使用。\n- 如果可能，在本地重现错误。\n\n**计划：**\n- 首先，我将搜索 `/testbed` 目录中的测试文件和日志输出，这些文件可能包含完整的错误消息和堆栈跟踪。\n\n让我们先列出 `/testbed` 目录的内容以寻找线索。",\
    'type': 'output_text'}],\
  'role': 'assistant',\
  'status': 'completed',\
  'type': 'message'},\
 {'arguments': '{"input":"!ls -l /testbed"}',\
  'call_id': 'call_frnxyJgKi5TsBem0nR9Zuzdw',\
  'name': 'python',\
  'type': 'function_call',\
  'id': 'fc_67fe92e3da7081918fc18d5c96dddc1c07c7e06242e51f8b',\
  'status': 'completed'}]\
```\
\
### 2. 长上下文\
\
GPT-4.1 具有高性能的 1M Token 输入上下文窗口，适用于各种长上下文任务，包括结构化文档解析、重新排序、在忽略无关上下文的同时选择相关信息，以及使用上下文执行多跳推理。\
\
### 最佳上下文大小\
\
我们观察到在完整的 1M Token 上下文下的针堆评估中表现非常好，并且在包含相关和无关代码及其他文档的混合的复杂任务上观察到非常强的性能。但是，当需要检索更多项目或执行需要了解整个上下文状态（例如执行图搜索）的复杂推理时，长上下文性能可能会下降。\
\
### 调整上下文依赖\
\
考虑回答你的查询可能需要的内部 vs 外部世界知识的混合。有时模型需要运用一些自己的知识来连接概念或进行逻辑跳跃，而在其他情况下，最好只使用提供的上下文。\
\
```\
## Instructions\
// for internal knowledge\
- 仅使用提供的外部上下文中的文档来回答用户查询。如果你基于此上下文不知道答案，你必须回答“我没有所需的信息来回答这个问题”，即使用户坚持要你回答问题。\
// For internal and external knowledge\
- 默认使用提供的外部上下文来回答用户查询，但如果需要其他基础知识才能回答，并且你对答案有信心，你可以使用你的一些自己的知识来帮助回答问题。\
```\
\
### 提示组织\
\
特别是在长上下文使用中，指令和上下文的放置可能会影响性能。如果你的提示中有长上下文，理想情况下将指令放在提供的上下文的两端，因为我们发现这比仅放在上方或下方表现更好。如果你希望仅将指令放置一次，那么放在提供的上下文上方比下方好。\
\
### 3. 思维链\
\
如上所述，GPT-4.1 不是一个推理模型，但提示模型逐步思考（称为“思维链”）可以是模型将问题分解为更易管理的部分、解决它们并提高整体输出质量的有效方式，代价是与使用更多输出 Token 相关的更高成本和延迟。该模型经过训练，在 Agent 推理和现实世界问题解决方面表现良好，因此不应需要太多提示。\
\
我们建议从在提示末尾添加这个基本的思维链指令开始：\
\
```\
...\
\
首先，仔细逐步思考回答查询需要哪些文档。然后，打印每个文档的 TITLE 和 ID。然后，将 ID 格式化为一个列表。\
```\
\
从那里，你应该通过审计你特定示例和评估中的失败，并用更明确的指令解决系统性的计划和推理错误，来改进你的思维链提示。在不受约束的思维链提示中，它尝试的策略可能存在差异，并且如果观察到一种有效的方法，你可以将其编入提示中。一般来说，错误往往源于误解用户意图、上下文收集或分析不足、或者逐步思考不足或不正确，因此请留意这些并尝试通过更有主见的指令来解决它们。\
\
以下是一个示例提示，指示模型在继续回答之前更系统地专注于分析用户意图并考虑相关上下文。\
\
```\
## 推理策略\
1. 查询分析：分解并分析查询，直到你对其可能问的内容有信心。考虑提供的上下文以帮助澄清任何模糊或令人困惑的信息。\
2. 上下文分析：仔细选择并分析大量潜在相关的文档。优化召回率 - 如果有些无关也没问题，但正确的文档必须在此列表中，否则你的最终答案将是错误的。每个的分析步骤：\
	a. 分析：分析它如何可能相关或无关回答查询。\
	b. 相关性评级：[高、中、低、无]\
3. 综合：总结哪些文档最相关及其原因，包括所有相关性评级为中等或更高的文档。\
\
## 用户问题\
{user_question}\
\
## 外部上下文\
{external_context}\
\
首先，仔细逐步思考回答查询需要哪些文档，严格遵守提供的推理策略。然后，打印每个文档的 TITLE 和 ID。然后，将 ID 格式化为一个列表。\
```\
\
### 4. 指令遵循\
\
GPT-4.1 展示了出色的指令遵循性能，开发者可以利用这一点来精确塑造和控制其特定用例的输出。开发者经常进行大量提示以设定 Agent 推理步骤、回应语气和声音、工具调用信息、输出格式、要避免的主题等。但是，由于模型更字面地遵循指令，开发者可能需要包含关于做什么或不做什么的明确说明。此外，为其他模型优化的现有提示可能无法立即与此模型配合使用，因为现有指令被更严格地遵循，并且隐含的规则不再被强烈推断。\
\
### 推荐工作流\
\
以下是我们推荐的开发和调试提示中指令的工作流：\
\
1. 从整体“响应规则”或“指令”部分开始，包含高级指导和项目符号。\
2. 如果你想更改更具体的行为，添加一个部分为该类别指定更多细节，例如 `# Sample Phrases`。\
3. 如果你希望模型在其工作流中遵循特定步骤，添加一个有序列表并指示模型遵循这些步骤。\
4. 如果行为仍然不按预期工作：\
1. 检查冲突、未充分指定或错误的指令和示例。如果有冲突的指令，GPT-4.1 倾向于遵循更接近提示末尾的那个。\
2. 添加演示期望行为的示例；确保示例中演示的任何重要行为也在你的规则中被引用。\
3. 通常不需要使用全大写或其他激励措施，如贿赂或小费。我们建议从没有这些开始，并且仅在必要时才使用它们。注意，如果你的现有提示包含这些技术，可能导致 GPT-4.1 过于严格地关注它。\
\
_注意，使用你的首选 AI 驱动 IDE 对于迭代提示非常有帮助，包括检查一致性或冲突、添加示例或进行内聚更新，例如添加指令并更新指令以演示该指令。_\
\
### 常见失败模式\
\
这些失败模式并非 GPT-4.1 独有，但我们在此分享以引起普遍关注并便于调试。\
\
- 指示模型始终遵循特定行为有时可能会引发副作用。例如，如果被告知“你必须在回复用户之前调用工具”，模型可能会幻觉工具输入或在没有足够信息的情况下使用空值调用工具。添加“如果你没有足够的信息来调用工具，请向用户询问你需要的信息”应该可以缓解这个问题。\
- 当提供示例短语时，模型可能会逐字使用这些引号并开始对用户听起来重复。确保你指示模型根据需要改变它们。\
- 没有具体指令，一些模型可能渴望提供额外的散文来解释其决定，或者在回复中输出比预期更多的格式。提供指令和可能的示例以帮助缓解。\
\
### 示例提示：客户服务\
\
这展示了一个虚构客户服务 Agent 的最佳实践。观察规则的多样性、具体性、使用附加部分提供更多细节，以及一个演示整合所有先前规则的精确行为的示例。\
\
尝试运行以下笔记本单元格 - 你应该看到一条用户消息和一个工具调用，用户消息应以问候语开头，然后回显他们的答案，然后提到他们将调用一个工具。尝试更改指令以塑造模型行为，或尝试其他用户消息，以测试指令遵循性能。\
\
```\
1\
2\
3\
4\
5\
6\
7\
8\
9\
10\
11\
12\
13\
14\
15\
16\
17\
18\
19\
20\
21\
22\
23\
24\
25\
26\
27\
28\
29\
30\
31\
32\
33\
34\
35\
36\
37\
38\
39\
40\
41\
42\
43\
44\
45\
46\
47\
48\
49\
50\
51\
52\
53\
54\
55\
56\
57\
58\
59\
60\
61\
62\
63\
64\
65\
66\
67\
68\
69\
70\
71\
72\
73\
74\
75\
76\
77\
78\
79\
80\
81\
82\
83\
84\
85\
86\
87\
88\
89\
90\
91\
92\
93\
94\
95\
96\
97\
98\
99\
100\
101\
102\
103\
SYS_PROMPT_CUSTOMER_SERVICE = """你是一位乐于助人的客户服务 Agent，为 NewTelco 工作，帮助用户高效地完成他们的请求，同时严格遵守提供的指南。\
\
## Instructions\
- 始终以“你好，你已联系到 NewTelco，有什么可以帮助你的？”问候用户。\
- 在回答关于公司、其产品或服务或用户账户的事实性问题之前，始终先调用工具。仅使用检索到的上下文，绝不要依赖你自己的知识回答任何这些问题。\
    - 但是，如果你没有足够的信息来正确调用工具，请向用户询问你需要的信息。\
- 如果用户要求，请转接到人工客服。\
- 不要讨论禁止的主题（政治、宗教、有争议的时事、医疗、法律或财务建议、个人对话、内部公司运营，或对任何个人或公司的批评）。\
- 在适当的时候依赖示例短语，但绝不要在同一个对话中重复使用示例短语。可以随意变通示例短语以避免听起来重复，并使其更适合用户。\
- 始终为新消息遵循提供的输出格式，包括来自检索到的策略文档的任何事实性陈述的引用。\
- 如果你要调用工具，总是在调用工具之前和之后向用户发送适当的消息。\
- 在所有回复中保持专业和简洁的语气，并在句子之间使用表情符号。\
- 如果你已解决用户的请求，请询问是否还有其他需要帮助的。\
\
## Precise Response Steps (for each response)\
1. 如果需要，调用工具以完成用户期望的操作。在调用工具之前和之后始终给用户发消息，让他们知道进展情况。\
2. 在给用户的回复中\
    a. 使用积极倾听，回响你听到的用户请求。\
    b. 根据上述指南适当回应。\
\
## Sample Phrases\
### 拒绝一个禁止话题\
- "很抱歉，我无法讨论这个话题。还有其他我可以帮忙的吗？"\
- "这不是我能提供信息的范围，但我很乐意回答你的其他任何问题。"\
\
### 在调用工具之前\
- "为了帮你处理，我需要验证你的信息。"\
- "让我查一下，请稍等。"\
- "我现在为你检索最新详情。"\
\
### 在调用工具之后\
- "好的，这是我找到的：[response]"\
- "所以这是我找到的：[response]"\
\
## Output Format\
- 始终包含你给用户的最终回复。\
- 在提供来自检索上下文的真实信息时，始终在相关陈述之后立即包含引用。使用以下引用格式：\
    - 对于单个来源：[NAME](ID)\
    - 对于多个来源：[NAME](ID), [NAME](ID)\
- 仅提供有关此公司、其政策、其产品或客户账户的信息，并且仅当它基于上下文中提供的信息时。不要回答此范围之外的问题。\
\
## Example\
### User\
你能介绍一下你的家庭套餐选项吗？\
\
### Assistant Response 1\
#### Message\
"你好，你已联系到 NewTelco，有什么可以帮助你的？😊🎉\n\n你想了解我们的家庭套餐选项。🤝 让我为你查一下，请稍等。🚀"\
\
#### Tool Calls\
lookup_policy_document(topic="family plan options")\
\
// After tool call, the assistant would follow up with:\
\
### Assistant Response 2 (after tool call)\
#### Message\
"好的，这是我找到的：🎉 我们的家庭套餐最多可容纳 5 条线路，共享数据，每条额外线路可享 10% 折扣 [家庭套餐政策](ID-010)。📱 今天还有其他我可以帮忙的吗？😊"\
"""\
\
get_policy_doc = {\
    "type": "function",\
    "name": "lookup_policy_document",\
    "description": "按主题或关键词查找内部文档和政策的工具。",\
    "parameters": {\
        "strict": True,\
        "type": "object",\
        "properties": {\
            "topic": {\
                "type": "string",\
                "description": "公司政策或文档中要搜索的主题或关键词。",\
            },\
        },\
        "required": ["topic"],\
        "additionalProperties": False,\
    },\
}\
\
get_user_acct = {\
    "type": "function",\
    "name": "get_user_account_info",\
    "description": "获取用户账户信息的工具",\
    "parameters": {\
        "strict": True,\
        "type": "object",\
        "properties": {\
            "phone_number": {\
                "type": "string",\
                "description": "格式化为 '(xxx) xxx-xxxx'",\
            },\
        },\
        "required": ["phone_number"],\
        "additionalProperties": False,\
    },\
}\
\
response = client.responses.create(\
    instructions=SYS_PROMPT_CUSTOMER_SERVICE,\
    model="gpt-4.1-2025-04-14",\
    tools=[get_policy_doc, get_user_acct],\
    input="国际服务要多少钱？我要去法国。",\
    # input="为什么我上次的账单这么高？"\
)\
\
response.to_dict()["output"]\
```\
\
```\
[{'id': 'msg_67fe92d431548191b7ca6cd604b4784b06efc5beb16b3c5e',\
  'content': [{'annotations': [],\
    'text': "你好，你已联系到 NewTelco，有什么可以帮助你的？🌍✈️\n\n你想了解去法国时的国际服务费用。🇫🇷 让我为你查查最新详情，请稍等。🕑",\
    'type': 'output_text'}],\
  'role': 'assistant',\
  'status': 'completed',\
  'type': 'message'},\
 {'arguments': '{"topic":"international service cost France"}',\
  'call_id': 'call_cF63DLeyhNhwfdyME3ZHd0yo',\
  'name': 'lookup_policy_document',\
  'type': 'function_call',\
  'id': 'fc_67fe92d5d6888191b6cd7cf57f707e4606efc5beb16b3c5e',\
  'status': 'completed'}]\
```\
\
### 5. 通用建议\
\
### 提示结构\
\
作为参考，这是一个构建提示的良好起点。\
\
```\
## 角色和目标\
\
## 指令\
\
### 子类别以获取更详细的指令\
\
## 推理步骤\
\
## 输出格式\
\
## 示例\
### 示例 1\
\
## 上下文\
\
## 最终指令和提示逐步思考\
```\
\
根据你的需要添加或删除部分，并进行实验以确定最适合你使用的方案。\
\
### 分隔符\
\
以下是选择最佳提示分隔符的一些通用指南。有关该上下文类型的特殊考虑，请参阅长上下文部分。\
\
1. Markdown：我们建议从这里开始，使用 Markdown 标题作为主要部分和子部分（包括更深层次，直至 H4+）。使用行内反引号或反引号块精确包裹代码，并根据需要使用标准的编号或项目符号列表。\
2. XML：这些也表现出色，我们改进了此模型对 XML 中信息的遵循。XML 便于精确包裹一个部分，包括起始和结束，向标签添加元数据以提供额外上下文，并支持嵌套。以下是在示例部分中使用 XML 标签嵌套示例的实例，每个示例带有输入和输出：\
\
```\
<examples>\
<example1 type="Abbreviate">\
<input>San Francisco</input>\
<output>- SF</output>\
</example1>\
</examples>\
```\
\
3. JSON 高度结构化，模型在编码上下文中尤其理解良好。但它可能更冗长，并且需要字符转义，这会增加开销。\
\
专门针对将大量文档或文件添加到输入上下文的指导：\
\
- XML 在我们的长上下文测试中表现出色。\
  - 示例：`<doc id='1' title='The Fox'>The quick brown fox jumps over the lazy dog</doc>`\
- Lee 等人提出的这种格式（[参考](https://arxiv.org/pdf/2406.13121)）也在我们的长上下文测试中表现出色。\
\
  - 示例：`ID: 1 | TITLE: The Fox | CONTENT: The quick brown fox jumps over the lazy dog`\
- JSON 表现特别差。\
  - 示例：`[{'id': 1, 'title': 'The Fox', 'content': 'The quick brown fox jumped over the lazy dog'}]`\
\
该模型经过训练，能够稳健地理解各种格式的结构。通常，使用你的判断力并思考什么会提供清晰的信息并“突出”给模型。例如，如果你正在检索包含大量 XML 的文档，基于 XML 的分隔符可能效果较差。\
\
### 注意事项\
\
- 在少数孤立情况下，我们观察到模型抵制生成非常长、重复的输出，例如逐个分析数百个项目。如果这对你的用例是必要的，指示模型完整输出此信息，并考虑将问题分解或使用更简洁的方法。\
- 我们观察到并行工具调用偶尔出现错误的情况。我们建议进行测试，并在遇到问题时考虑将 [parallel_tool_calls](https://developers.openai.com/api/docs/api-reference/responses/create#responses-create-parallel_tool_calls) 参数设置为 false。\
\
### 附录：生成和应用文件差异\
\
开发者向我们反馈，准确且格式良好的差异生成是支持编码相关任务的关键能力。为此，GPT-4.1 系列比以前的 GPT 模型具有显著改进的差异能力。此外，虽然 GPT-4.1 在给定清晰指令和示例的情况下对任何格式的差异生成都有强劲表现，但我们在此开源一种推荐的差异格式，模型已在该格式上进行了广泛训练。我们特别希望，对于刚入门的开发者来说，这将大大减少自己创建差异时的猜测工作。\
\
### Apply Patch\
\
请参阅下面的示例，其中包含一个正确应用我们推荐的工具调用的提示。\
\
```\
1\
2\
3\
4\
5\
6\
7\
8\
9\
10\
11\
12\
13\
14\
15\
16\
17\
18\
19\
20\
21\
22\
23\
24\
25\
26\
27\
28\
29\
30\
31\
32\
33\
34\
35\
36\
37\
38\
39\
40\
41\
42\
43\
44\
45\
46\
47\
48\
49\
50\
51\
52\
53\
54\
55\
56\
57\
58\
59\
60\
61\
62\
63\
64\
65\
66\
67\
68\
69\
70\
APPLY_PATCH_TOOL_DESC = """这是一个自定义工具，使得添加、移除、移动或编辑代码文件更加方便。`apply_patch` 有效地允许你对文件执行 diff/patch，但 diff 规范的格式对于此任务是唯一的，因此请仔细注意这些说明。要使用 `apply_patch` 命令，你应将以下结构的消息作为"input"传递：\
\
%%bash\
apply_patch <<"EOF"\
*** Begin Patch\
[YOUR_PATCH]\
*** End Patch\
EOF\
\
其中 [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 行代码。如果一个更改在先前更改的 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"的消息示例如下所示。\
\
%%bash\
apply_patch <<"EOF"\
*** Begin Patch\
*** Update File: pygorithm/searching/binary_search.py\
@@ class BaseClass\
@@     def search():\
-          pass\
+          raise NotImplementedError()\
\
@@ class Subclass\
@@     def search():\
-          pass\
+          raise NotImplementedError()\
\
*** End Patch\
EOF\
"""\
\
APPLY_PATCH_TOOL = {\
    "name": "apply_patch",\
    "description": APPLY_PATCH_TOOL_DESC,\
    "parameters": {\
        "type": "object",\
        "properties": {\
            "input": {\
                "type": "string",\
                "description": " 你希望执行的 apply_patch 命令。",\
            }\
        },\
        "required": ["input"],\
    },\
}\
```\
\
### 参考实现：apply_patch.py\
\
以下是我们在模型训练中使用的 apply_patch 工具的参考实现。你需要将其制作为可执行文件，并从模型将执行命令的 shell 中作为 `apply_patch` 可用：\
\
```\
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
##!/usr/bin/env python3

"""
一个自包含的**纯 Python 3.9+** 工具，用于将人类可读的
“伪 diff”补丁文件应用于文本文件集合。
"""

from __future__ import annotations

import pathlib
from dataclasses import dataclass, field
from enum import Enum
from typing import (
    Callable,
    Dict,
    List,
    Optional,
    Tuple,
    Union,
)

## --------------------------------------------------------------------------- #
##  领域对象
## --------------------------------------------------------------------------- #
class ActionType(str, Enum):
    ADD = "add"
    DELETE = "delete"
    UPDATE = "update"

@dataclass
class FileChange:
    type: ActionType
    old_content: Optional[str] = None
    new_content: Optional[str] = None
    move_path: Optional[str] = None

@dataclass
class Commit:
    changes: Dict[str, FileChange] = field(default_factory=dict)

## --------------------------------------------------------------------------- #
##  异常
## --------------------------------------------------------------------------- #
class DiffError(ValueError):
    """在解析或应用补丁时检测到的任何问题。"""

## --------------------------------------------------------------------------- #
##  解析补丁时使用的帮助器数据类
## --------------------------------------------------------------------------- #
@dataclass
class Chunk:
    orig_index: int = -1
    del_lines: List[str] = field(default_factory=list)
    ins_lines: List[str] = field(default_factory=list)

@dataclass
class PatchAction:
    type: ActionType
    new_file: Optional[str] = None
    chunks: List[Chunk] = field(default_factory=list)
    move_path: Optional[str] = None

@dataclass
class Patch:
    actions: Dict[str, PatchAction] = field(default_factory=dict)

## --------------------------------------------------------------------------- #
##  补丁文本解析器
## --------------------------------------------------------------------------- #
@dataclass
class Parser:
    current_files: Dict[str, str]
    lines: List[str]
    index: int = 0
    patch: Patch = field(default_factory=Patch)
    fuzz: int = 0

    # ------------- 低级帮助器 -------------------------------------- #
    def _cur_line(self) -> str:
        if self.index >= len(self.lines):
            raise DiffError("解析补丁时遇到意外的输入结束")
        return self.lines[self.index]

    @staticmethod
    def _norm(line: str) -> str:
        """剥离 CR，使比较对 LF 和 CRLF 输入都有效。"""
        return line.rstrip("\r")

    # ------------- 扫描便利 ----------------------------------- #
    def is_done(self, prefixes: Optional[Tuple[str, ...]] = None) -> bool:
        if self.index >= len(self.lines):
            return True
        if (
            prefixes
            and len(prefixes) > 0
            and self._norm(self._cur_line()).startswith(prefixes)
        ):
            return True
        return False

    def startswith(self, prefix: Union[str, Tuple[str, ...]]) -> bool:
        return self._norm(self._cur_line()).startswith(prefix)

    def read_str(self, prefix: str) -> str:
        """
        如果当前行以 *prefix* 开头，则消耗该行并返回
        **前缀之后**的文本。如果前缀为空则引发异常。
        """
        if prefix == "":
            raise ValueError("read_str() 需要一个非空前缀")
        if self._norm(self._cur_line()).startswith(prefix):
            text = self._cur_line()[len(prefix) :]
            self.index += 1
            return text
        return ""

    def read_line(self) -> str:
        """返回当前的原始行并前进。"""
        line = self._cur_line()
        self.index += 1
        return line

    # ------------- 公共入口点 -------------------------------------- #
    def parse(self) -> None:
        while not self.is_done(("*** End Patch",)):
            # ---------- UPDATE ---------- #
            path = self.read_str("*** Update File: ")
            if path:
                if path in self.patch.actions:
                    raise DiffError(f"文件的重复更新：{path}")
                move_to = self.read_str("*** Move to: ")
                if path not in self.current_files:
                    raise DiffError(f"更新文件错误 - 缺少文件：{path}")
                text = self.current_files[path]
                action = self._parse_update_file(text)
                action.move_path = move_to or None
                self.patch.actions[path] = action
                continue

            # ---------- DELETE ---------- #
            path = self.read_str("*** Delete File: ")
            if path:
                if path in self.patch.actions:
                    raise DiffError(f"文件的重复删除：{path}")
                if path not in self.current_files:
                    raise DiffError(f"删除文件错误 - 缺少文件：{path}")
                self.patch.actions[path] = PatchAction(type=ActionType.DELETE)
                continue

            # ---------- ADD ---------- #
            path = self.read_str("*** Add File: ")
            if path:
                if path in self.patch.actions:
                    raise DiffError(f"文件的重复添加：{path}")
                if path in self.current_files:
                    raise DiffError(f"添加文件错误 - 文件已存在：{path}")
                self.patch.actions[path] = self._parse_add_file()
                continue

            raise DiffError(f"解析时发现未知行：{self._cur_line()}")

        if not self.startswith("*** End Patch"):
            raise DiffError("缺少 *** End Patch 哨兵")
        self.index += 1  # 消耗哨兵

    # ------------- 部分解析器 ---------------------------------------- #
    def _parse_update_file(self, text: str) -> PatchAction:
        action = PatchAction(type=ActionType.UPDATE)
        lines = text.split("\n")
        index = 0
        while not self.is_done(
            (
                "*** End Patch",
                "*** Update File:",
                "*** Delete File:",
                "*** Add File:",
                "*** End of File",
            )
        ):
            def_str = self.read_str("@@ ")
            section_str = ""
            if not def_str and self._norm(self._cur_line()) == "@@":
                section_str = self.read_line()

            if not (def_str or section_str or index == 0):
                raise DiffError(f"更新部分中的无效行：\n{self._cur_line()}")

            if def_str.strip():
                found = False
                if def_str not in lines[:index]:
                    for i, s in enumerate(lines[index:], index):
                        if s == def_str:
                            index = i + 1
                            found = True
                            break
                if not found and def_str.strip() not in [
                    s.strip() for s in lines[:index]
                ]:
                    for i, s in enumerate(lines[index:], index):
                        if s.strip() == def_str.strip():
                            index = i + 1
                            self.fuzz += 1
                            found = True
                            break

            next_ctx, chunks, end_idx, eof = peek_next_section(self.lines, self.index)
            new_index, fuzz = find_context(lines, next_ctx, index, eof)
            if new_index == -1:
                ctx_txt = "\n".join(next_ctx)
                raise DiffError(
                    f"在 {index} 处无效的{'EOF ' if eof else ''}上下文：\n{ctx_txt}"
                )
            self.fuzz += fuzz
            for ch in chunks:
                ch.orig_index += new_index
                action.chunks.append(ch)
            index = new_index + len(next_ctx)
            self.index = end_idx
        return action

    def _parse_add_file(self) -> PatchAction:
        lines: List[str] = []
        while not self.is_done(
            ("*** End Patch", "*** Update File:", "*** Delete File:", "*** Add File:")
        ):
            s = self.read_line()
            if not s.startswith("+"):
                raise DiffError(f"无效的添加文件行（缺少 '+'）：{s}")
            lines.append(s[1:])  # 剥离前导 '+'
        return PatchAction(type=ActionType.ADD, new_file="\n".join(lines))

## --------------------------------------------------------------------------- #
##  帮助函数
## --------------------------------------------------------------------------- #
def find_context_core(
    lines: List[str], context: List[str], start: int
) -> Tuple[int, int]:
    if not context:
        return start, 0

    for i in range(start, len(lines)):
        if lines[i : i + len(context)] == context:
            return i, 0
    for i in range(start, len(lines)):
        if [s.rstrip() for s in lines[i : i + len(context)]] == [
            s.rstrip() for s in context
        ]:
            return i, 1
    for i in range(start, len(lines)):
        if [s.strip() for s in lines[i : i + len(context)]] == [
            s.strip() for s in context
        ]:
            return i, 100
    return -1, 0

def find_context(
    lines: List[str], context: List[str], start: int, eof: bool
) -> Tuple[int, int]:
    if eof:
        new_index, fuzz = find_context_core(lines, context, len(lines) - len(context))
        if new_index != -1:
            return new_index, fuzz
        new_index, fuzz = find_context_core(lines, context, start)
        return new_index, fuzz + 10_000
    return find_context_core(lines, context, start)

def peek_next_section(
    lines: List[str], index: int
) -> Tuple[List[str], List[Chunk], int, bool]:
    old: List[str] = []
    del_lines: List[str] = []
    ins_lines: List[str] = []
    chunks: List[Chunk] = []
    mode = "keep"
    orig_index = index

    while index < len(lines):
        s = lines[index]
        if s.startswith(
            (
                "@@",
                "*** End Patch",
                "*** Update File:",
                "*** Delete File:",
                "*** Add File:",
                "*** End of File",
            )
        ):
            break
        if s == "***":
            break
        if s.startswith("***"):
            raise DiffError(f"无效行：{s}")
        index += 1

        last_mode = mode
        if s == "":
            s = " "
        if s[0] == "+":
            mode = "add"
        elif s[0] == "-":
            mode = "delete"
        elif s[0] == " ":
            mode = "keep"
        else:
            raise DiffError(f"无效行：{s}")
        s = s[1:]

        if mode == "keep" and last_mode != mode:
            if ins_lines or del_lines:
                chunks.append(
                    Chunk(
                        orig_index=len(old) - len(del_lines),
                        del_lines=del_lines,
                        ins_lines=ins_lines,
                    )
                )
            del_lines, ins_lines = [], []

        if mode == "delete":
            del_lines.append(s)
            old.append(s)
        elif mode == "add":
            ins_lines.append(s)
        elif mode == "keep":
            old.append(s)

    if ins_lines or del_lines:
        chunks.append(
            Chunk(
                orig_index=len(old) - len(del_lines),
                del_lines=del_lines,
                ins_lines=ins_lines,
            )
        )

    if index < len(lines) and lines[index] == "*** End of File":
        index += 1
        return old, chunks, index, True

    if index == orig_index:
        raise DiffError("此部分中没有内容")
    return old, chunks, index, False

## --------------------------------------------------------------------------- #
##  补丁 → 提交和提交应用
## --------------------------------------------------------------------------- #
def _get_updated_file(text: str, action: PatchAction, path: str) -> str:
    if action.type is not ActionType.UPDATE:
        raise DiffError("_get_updated_file 对非更新操作调用")
    orig_lines = text.split("\n")
    dest_lines: List[str] = []
    orig_index = 0

    for chunk in action.chunks:
        if chunk.orig_index > len(orig_lines):
            raise DiffError(
                f"{path}: chunk.orig_index {chunk.orig_index} 超出文件长度"
            )
        if orig_index > chunk.orig_index:
            raise DiffError(
                f"{path}: 重叠的块在 {orig_index} > {chunk.orig_index}"
            )

        dest_lines.extend(orig_lines[orig_index : chunk.orig_index])
        orig_index = chunk.orig_index

        dest_lines.extend(chunk.ins_lines)
        orig_index += len(chunk.del_lines)

    dest_lines.extend(orig_lines[orig_index:])
    return "\n".join(dest_lines)

def patch_to_commit(patch: Patch, orig: Dict[str, str]) -> Commit:
    commit = Commit()
    for path, action in patch.actions.items():
        if action.type is ActionType.DELETE:
            commit.changes[path] = FileChange(
                type=ActionType.DELETE, old_content=orig[path]
            )
        elif action.type is ActionType.ADD:
            if action.new_file is None:
                raise DiffError("ADD 操作没有文件内容")
            commit.changes[path] = FileChange(
                type=ActionType.ADD, new_content=action.new_file
            )
        elif action.type is ActionType.UPDATE:
            new_content = _get_updated_file(orig[path], action, path)
            commit.changes[path] = FileChange(
                type=ActionType.UPDATE,
                old_content=orig[path],
                new_content=new_content,
                move_path=action.move_path,
            )
    return commit

## --------------------------------------------------------------------------- #
##  面向用户的帮助器
## --------------------------------------------------------------------------- #
def text_to_patch(text: str, orig: Dict[str, str]) -> Tuple[Patch, int]:
    lines = text.splitlines()  # 保留空行，不进行 strip()
    if (
        len(lines) < 2
        or not Parser._norm(lines[0]).startswith("*** Begin Patch")
        or Parser._norm(lines[-1]) != "*** End Patch"
    ):
        raise DiffError("无效的补丁文本 - 缺少哨兵")

    parser = Parser(current_files=orig, lines=lines, index=1)
    parser.parse()
    return parser.patch, parser.fuzz

def identify_files_needed(text: str) -> List[str]:
    lines = text.splitlines()
    return [
        line[len("*** Update File: ") :]
        for line in lines
        if line.startswith("*** Update File: ")
    ] + [
        line[len("*** Delete File: ") :]
        for line in lines
        if line.startswith("*** Delete File: ")
    ]

def identify_files_added(text: str) -> List[str]:
    lines = text.splitlines()
    return [
        line[len("*** Add File: ") :]
        for line in lines
        if line.startswith("*** Add File: ")
    ]

## --------------------------------------------------------------------------- #
##  文件系统帮助器
## --------------------------------------------------------------------------- #
def load_files(paths: List[str], open_fn: Callable[[str], str]) -> Dict[str, str]:
    return {path: open_fn(path) for path in paths}

def apply_commit(
    commit: Commit,
    write_fn: Callable[[str, str], None],
    remove_fn: Callable[[str], None],
) -> None:
    for path, change in commit.changes.items():
        if change.type is ActionType.DELETE:
            remove_fn(path)
        elif change.type is ActionType.ADD:
            if change.new_content is None:
                raise DiffError(f"ADD 更改 {path} 没有内容")
            write_fn(path, change.new_content)
        elif change.type is ActionType.UPDATE:
            if change.new_content is None:
                raise DiffError(f"UPDATE 更改 {path} 没有新内容")
            target = change.move_path or path
            write_fn(target, change.new_content)
            if change.move_path:
                remove_fn(path)

def process_patch(
    text: str,
    open_fn: Callable[[str], str],
    write_fn: Callable[[str, str], None],
    remove_fn: Callable[[str], None],
) -> str:
    if not text.startswith("*** Begin Patch"):
        raise DiffError("补丁文本必须以 *** Begin Patch 开头")
    paths = identify_files_needed(text)
    orig = load_files(paths, open_fn)
    patch, _fuzz = text_to_patch(text, orig)
    commit = patch_to_commit(patch, orig)
    apply_commit(commit, write_fn, remove_fn)
    return "Done!"

## --------------------------------------------------------------------------- #
##  默认 FS 帮助器
## --------------------------------------------------------------------------- #
def open_file(path: str) -> str:
    with open(path, "rt", encoding="utf-8") as fh:
        return fh.read()

def write_file(path: str, content: str) -> None:
    target = pathlib.Path(path)
    target.parent.mkdir(parents=True, exist_ok=True)
    with target.open("wt", encoding="utf-8") as fh:
        fh.write(content)

def remove_file(path: str) -> None:
    pathlib.Path(path).unlink(missing_ok=True)

## --------------------------------------------------------------------------- #
##  CLI 入口点
## --------------------------------------------------------------------------- #
def main() -> None:
    import sys

    patch_text = sys.stdin.read()
    if not patch_text:
        print("请通过 stdin 传递补丁文本", file=sys.stderr)
        return
    try:
        result = process_patch(patch_text, open_file, write_file, remove_file)
    except DiffError as exc:
        print(exc, file=sys.stderr)
        return
    print(result)

if __name__ == "__main__":
    main()
```\
\
### 其他有效的 Diff 格式\
\
如果你想尝试使用不同的 diff 格式，我们发现在测试中，Aider 的多语言基准测试中使用的 SEARCH/REPLACE diff 格式，以及一种不需要内部转义的伪 XML 格式，都取得了很高的成功率。\
\
这些 diff 格式共享两个关键方面：(1) 它们不使用行号，(2) 它们提供了要替换的确切代码以及用于替换的确切代码，并在两者之间有明确的分隔符。\
\

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 SEARCH_REPLACE_DIFF_EXAMPLE = """
path/to/file.py\

>>>>>>> SEARCH\
def search():\
    pass\
=======\
def search():\
raise NotImplementedError()\
<<<<<<< REPLACE\
"""\
\
PSEUDO_XML_DIFF_EXAMPLE = """\
`<edit>`\
`<file>`\
path/to/file.py\
`</file>`\
`<old_code>`\
def search():\
    pass\
`</old_code>`\
`<new_code>`\
def search():\
raise NotImplementedError()\
`</new_code>`\
`</edit>`\
"""\
  • 原文链接： developers.openai.com/ap...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
developers.openai
developers.openai
江湖只有他的大名，没有他的介绍。

developers.openai

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！

作者暂未设置收款二维码