> ## Documentation Index > Fetch the complete documentation index at: https://docs.ficcaurora.xyz/llms.txt > Use this file to discover all available pages before exploring further. # GPT-4.1 提示工程指南（全文翻译） GPT-4.1 系列模型相较于 GPT-4o 在编码、指令遵循和长上下文处理能力方面都有显著提升。在本提示指南中，我们汇总了一系列从大量内部测试中总结出的重要提示技巧，帮助开发者充分利用这个新模型系列的改进能力。 许多常见的最佳实践仍然适用于 GPT-4.1，例如提供上下文示例、使指令尽可能具体清晰，以及通过提示引导规划来最大化模型智能。然而，我们预计要充分发挥这个模型的优势，需要对提示进行一些迁移。GPT-4.1 被训练为比前代模型更紧密、更字面地遵循指令，而前代模型倾向于更自由地从用户和系统提示中推断意图。不过这也意味着，GPT-4.1 具有高度可控性，对精心指定的提示反应灵敏——如果模型行为与您的预期不同，一句坚定明确地阐明您期望行为的话几乎总能将模型引导到正确的方向。 请继续阅读您可以作为参考的提示示例，并记住虽然本指南广泛适用，但没有一种建议是万能的。AI 工程本质上是一门经验学科，大型语言模型本质上是非确定性的；除了遵循本指南外，我们建议构建有信息量的评估，并经常迭代，以确保您的提示工程更改为您的用例带来好处。 ## 1. 智能体工作流 GPT-4.1 是构建智能体工作流的绝佳选择。在模型训练中，我们强调提供多样化的智能体问题解决轨迹，我们的智能体框架在 SWE-bench Verified 上达到了非推理模型的最先进性能，解决了 55% 的问题。 ### 系统提示提醒 为了充分利用 GPT-4.1 的智能体能力，我们建议在所有智能体提示中包含三种关键类型的提醒。以下提示专门针对智能体编码工作流进行了优化，但可以轻松修改用于通用智能体用例。 **1. 持久性：** 这确保模型理解它正在进入多消息回合，并防止它过早地将控制权交还给用户。我们的示例如下： ``` 您是一个智能体 - 请继续操作，直到用户的查询完全解决，然后再结束您的回合并交还给用户。只有在确定问题已解决时才终止您的回合。 ``` **2. 工具调用：** 这鼓励模型充分利用其工具，并减少其产生幻觉或猜测答案的可能性。我们的示例如下： ``` 如果您不确定与用户请求相关的文件内容或代码库结构，请使用您的工具读取文件并收集相关信息：不要猜测或编造答案。 ``` **3. 规划 \[可选]：** 如果需要，这确保模型在文本中明确规划并反思每次工具调用，而不是仅通过串联一系列工具调用来完成任务。我们的示例如下： ``` 您必须在每次函数调用之前进行广泛规划，并对前一次函数调用的结果进行广泛反思。不要仅通过进行函数调用来完成整个过程，因为这可能会损害您解决问题和深入思考的能力。 ``` GPT-4.1 被训练为在智能体设置中非常紧密地响应用户指令和系统提示。模型紧密遵循这三个简单的指令，使我们的内部 SWE-bench Verified 分数提高了近 20% - 因此我们强烈建议使用涵盖上述三个类别的清晰提醒来开始任何智能体提示。总的来说，我们发现这三个指令将模型从类似聊天机器人的状态转变为更加"积极"的智能体，自主独立地推动交互向前发展。 ### 工具调用 与以前的模型相比，GPT-4.1 在有效利用作为 OpenAI API 请求参数传递的工具方面接受了更多训练。我们鼓励开发者专门使用工具字段来传递工具，而不是手动将工具描述注入到您的提示中并为工具调用编写单独的解析器，正如一些人过去所报告的那样。这是最小化错误并确保模型在工具调用轨迹期间保持分布内的最佳方法 - 在我们自己的实验中，当使用 API 解析的工具描述与手动将模式注入系统提示相比时，我们观察到 SWE-bench Verified 通过率提高了 2%。 开发者应该清楚地命名工具以指示其用途，并在工具的"description"字段中添加清晰、详细的描述。同样，对于每个工具参数，依靠良好的命名和描述来确保适当的使用。如果您的工具特别复杂，并且您想提供工具使用示例，我们建议您在系统提示中创建一个 `# Examples`（示例）部分并将示例放在那里，而不是将它们添加到"description"字段中，该字段应该保持详尽但相对简洁。提供示例有助于指示何时使用工具、是否在工具调用旁边包含用户文本以及哪些参数适合不同的输入。请记住，您可以在 Prompt Playground 中使用"Generate Anything"（生成任何内容）为您的新工具定义获得一个良好的起点。 ### 提示引导的规划和思维链 如前所述，开发者可以选择性地提示使用 GPT-4.1 构建的智能体在工具调用之间进行规划和反思，而不是静默地以不间断的序列调用工具。GPT-4.1 不是推理模型 - 这意味着它不会在回答之前产生内部思维链 - 但在提示中，开发者可以使用上面显示的规划提示组件的任何变体来引导模型产生明确的、逐步的计划。这可以被认为是模型"大声思考"。在我们对 SWE-bench Verified 智能体任务的实验中，引导显式规划将通过率提高了 4%。 ### 示例提示：SWE-bench Verified 下面，我们分享了我们用来在 SWE-bench Verified 上获得最高分数的智能体提示，其中包含有关工作流和问题解决策略的详细说明。这种通用模式可用于任何智能体任务。 ```python theme={null} from openai import OpenAI import os client = OpenAI( api_key=os.environ.get( "OPENAI_API_KEY", "<如果未设置为环境变量，则填入您的 OpenAI API 密钥>" ) ) SYS_PROMPT_SWEBENCH = """ 您将被要求修复来自开源仓库的问题。 您的思考应该是彻底的，所以即使很长也没关系。您可以在决定采取每个行动之前和之后逐步思考。 您必须迭代并继续前进，直到问题得到解决。 您已经拥有在 /testbed 文件夹中解决此问题所需的一切，即使没有互联网连接。我希望您在回来找我之前完全自主地解决这个问题。 只有在确定问题已解决时才终止您的回合。逐步解决问题，并确保验证您的更改是正确的。永远不要在没有解决问题的情况下结束您的回合，当您说要进行工具调用时，确保您实际进行工具调用，而不是结束您的回合。 问题绝对可以在没有互联网的情况下解决。 花时间思考每一步 - 记住严格检查您的解决方案并注意边界情况，特别是您所做的更改。您的解决方案必须是完美的。如果不是，继续工作。最后，您必须使用提供的工具严格测试您的代码，并多次执行，以捕获所有边缘情况。如果它不够健壮，请进行更多迭代并使其完美。测试代码不够严格是此类任务的第一大失败模式；确保处理所有边缘情况，并在提供现有测试的情况下运行它们。 您必须在每次函数调用之前进行广泛规划，并对前一次函数调用的结果进行广泛反思。不要仅通过进行函数调用来完成整个过程，因为这可能会损害您解决问题和深入思考的能力。 # 工作流 ## 高级问题解决策略 1. 深入理解问题。仔细阅读问题并批判性地思考需要什么。 2. 调查代码库。探索相关文件，搜索关键函数，并收集上下文。 3. 制定清晰的分步计划。将修复分解为可管理的增量步骤。 4. 增量实现修复。进行小的、可测试的代码更改。 5. 根据需要进行调试。使用调试技术来隔离和解决问题。 6. 频繁测试。在每次更改后运行测试以验证正确性。 7. 迭代直到根本原因被修复并且所有测试都通过。 8. 全面反思和验证。测试通过后，思考原始意图，编写额外的测试以确保正确性，并记住在解决方案真正完成之前还必须通过隐藏测试。 有关每个步骤的更多信息，请参阅下面的详细部分。 ## 1. 深入理解问题 仔细阅读问题，并在编码之前认真思考解决方案的计划。 ## 2. 代码库调查 - 探索相关文件和目录。 - 搜索与问题相关的关键函数、类或变量。 - 阅读并理解相关代码片段。 - 识别问题的根本原因。 - 在收集更多上下文时持续验证和更新您的理解。 ## 3. 制定详细计划 - 概述一个具体、简单且可验证的修复问题的步骤序列。 - 将修复分解为小的增量更改。 ## 4. 进行代码更改 - 在编辑之前，始终阅读相关文件内容或部分以确保完整的上下文。 - 如果补丁未正确应用，尝试重新应用它。 - 进行小的、可测试的、从您的调查和计划中逻辑上遵循的增量更改。 ## 5. 调试 - 只有在您有高度信心可以解决问题时才进行代码更改 - 调试时，尝试确定根本原因而不是解决症状 - 根据需要进行调试以识别根本原因并确定修复方案 - 使用打印语句、日志或临时代码来检查程序状态，包括描述性语句或错误消息以了解发生了什么 - 要测试假设，您还可以添加测试语句或函数 - 如果出现意外行为，请重新审视您的假设。 ## 6. 测试 - 使用 `!python3 run_tests.py`（或等效命令）频繁运行测试。 - 在每次更改后，通过运行相关测试来验证正确性。 - 如果测试失败，分析失败并修改您的补丁。 - 如果需要，编写额外的测试来捕获重要的行为或边缘情况。 - 在最终确定之前确保所有测试都通过。 ## 7. 最终验证 - 确认根本原因已修复。 - 检查您的解决方案的逻辑正确性和健壮性。 - 迭代直到您非常确信修复是完整的并且所有测试都通过。 ## 8. 最终反思和额外测试 - 仔细反思用户的原始意图和问题陈述。 - 考虑现有测试可能未涵盖的潜在边缘情况或场景。 - 编写需要通过的额外测试以充分验证解决方案的正确性。 - 运行这些新测试并确保它们都通过。 - 请注意，还有必须通过的额外隐藏测试，解决方案才能成功。 - 不要仅仅因为可见测试通过就认为任务已完成；继续改进，直到您确信修复是健壮和全面的。 """ ``` *** ## 2. 长上下文 GPT-4.1 具有高性能的 100 万 token 输入上下文窗口，对各种长上下文任务很有用，包括结构化文档解析、重新排序、在忽略无关上下文的同时选择相关信息，以及使用上下文执行多跳推理。 ### 最佳上下文大小 我们在干草堆中找针的评估中观察到了非常好的性能，最高可达我们的完整 100 万 token 上下文，并且我们观察到在具有相关和无关代码及其他文档混合的复杂任务中表现非常强。但是，随着需要检索的项目增多，或执行需要了解整个上下文状态的复杂推理（例如执行图搜索），长上下文性能可能会下降。 ### 调整上下文依赖 考虑回答您的问题可能需要的外部知识与内部知识的混合。有时模型使用一些自己的知识来连接概念或进行逻辑跳跃很重要，而在其他情况下，仅使用提供的上下文是可取的。 ``` # 指令 // 用于内部知识 - 仅使用提供的外部上下文中的文档来回答用户查询。如果您根据此上下文不知道答案，您必须回答"我没有回答该问题所需的信息"，即使用户坚持要求您回答问题。 // 用于内部和外部知识 - 默认情况下，使用提供的外部上下文来回答用户查询，但如果需要其他基本知识来回答，并且您对答案有信心，您可以使用一些自己的知识来帮助回答问题。 ``` ### 提示组织 特别是在长上下文使用中，指令和上下文的位置会影响性能。如果您的提示中有长上下文，理想情况下将您的指令放在提供的上下文的开头和结尾，因为我们发现这比仅在上面或下面表现更好。如果您更喜欢只有一次指令，那么在提供的上下文上方比下方效果更好。 *** ## 3. 思维链 如上所述，GPT-4.1 不是推理模型，但提示模型逐步思考（称为"思维链"）可以是一种有效的方式，让模型将问题分解为更易管理的部分，解决它们，并提高整体输出质量，代价是与使用更多输出 token 相关的更高成本和延迟。该模型已被训练在智能体推理和现实世界问题解决方面表现良好，因此不需要太多提示即可表现良好。 我们建议在提示的末尾使用这个基本的思维链指令： ``` ... 首先，仔细逐步思考回答查询需要哪些文档。然后，打印出每个文档的标题和 ID。然后，将 ID 格式化为列表。 ``` 从那里，您应该通过审核特定示例和评估中的失败来改进您的思维链（CoT）提示，并通过更明确的指令解决系统性的规划和推理错误。在无约束的 CoT 提示中，它尝试的策略可能存在差异，如果您观察到一种行之有效的方法，您可以在提示中编码该策略。一般来说，错误往往来自误解用户意图、上下文收集或分析不足，或逐步思考不足或不正确，因此请注意这些并尝试通过更有针对性的指令来解决它们。 这是一个示例提示，指示模型在继续回答之前更有条理地专注于分析用户意图和考虑相关上下文。 ``` # 推理策略 1. 查询分析：分解并分析查询，直到您确信它可能在询问什么。考虑提供的上下文以帮助澄清任何模糊或混淆的信息。 2. 上下文分析：仔细选择和分析大量可能相关的文档。优化召回率 - 有些不相关没关系，但正确的文档必须在此列表中，否则您的最终答案将是错误的。每个的分析步骤： a. 分析：分析它如何可能与回答查询相关或不相关。 b. 相关性评级：[高、中、低、无] 3. 综合：总结哪些文档最相关以及原因，包括所有相关性评级为中或更高的文档。 # 用户问题 {user_question} # 外部上下文 {external_context} 首先，严格遵守提供的推理策略，仔细逐步思考回答查询需要哪些文档。然后，打印出每个文档的标题和 ID。然后，将 ID 格式化为列表。 ``` *** ## 4. 指令遵循 GPT-4.1 表现出出色的指令遵循性能，开发者可以利用它来精确塑造和控制其特定用例的输出。开发者经常为智能体推理步骤、响应语气和声音、工具调用信息、输出格式、要避免的主题等进行大量提示。但是，由于模型更字面地遵循指令，开发者可能需要包含有关做什么或不做什么的明确规范。此外，为其他模型优化的现有提示可能不会立即与此模型一起使用，因为现有指令被更紧密地遵循，隐含规则不再被强烈推断。 ### 推荐的工作流 以下是我们推荐的在提示中开发和调试指令的工作流： 1. 从包含高级指导和要点的总体"响应规则"或"指令"部分开始。 2. 如果您想更改更具体的行为，请添加一个部分来指定该类别的更多详细信息，例如 `# 示例短语`。 3. 如果您希望模型在其工作流中遵循特定步骤，请添加有序列表并指示模型遵循这些步骤。 4. 如果行为仍然不符合预期： 1. 检查是否有冲突、未充分指定或错误的指令和示例。如果存在冲突的指令，GPT-4.1 倾向于遵循更接近提示末尾的指令。 2. 添加演示所需行为的示例；确保您的示例中演示的任何重要行为也在您的规则中引用。 3. 通常没有必要使用全大写或其他激励措施，如贿赂或小费。我们建议在没有这些的情况下开始，并且只有在您的特定提示需要时才使用这些。请注意，如果您现有的提示包含这些技术，它可能会导致 GPT-4.1 过于严格地注意它。 *请注意，使用您喜欢的 AI 驱动的 IDE 对于迭代提示非常有帮助，包括检查一致性或冲突、添加示例或进行连贯的更新，例如添加指令并更新指令以演示该指令。* ### 常见失败模式 这些失败模式并非 GPT-4.1 独有，但我们在此分享它们以提高一般意识并便于调试。 * 指示模型始终遵循特定行为有时会引起不良影响。例如，如果被告知"您必须在响应用户之前调用工具"，如果它们没有足够的信息，模型可能会产生幻觉工具输入或使用空值调用工具。添加"如果您没有足够的信息来调用工具，请向用户询问您需要的信息"应该可以缓解这种情况。 * 当提供示例短语时，模型可以逐字使用这些引用，并开始对用户听起来重复。确保您指示模型根据需要对它们进行变化。 * 如果没有具体说明，一些模型可能渴望提供额外的散文来解释他们的决定，或者在响应中输出比可能需要的更多的格式。提供指令并可能提供示例以帮助缓解。 ### 示例提示：客户服务 这展示了虚构客户服务智能体的最佳实践。观察规则的多样性、特异性、用于更详细的额外部分的使用，以及演示包含所有先前规则的精确行为的示例。 ```python theme={null} SYS_PROMPT_CUSTOMER_SERVICE = """您是一位有用的客户服务智能体，为 NewTelco 工作，帮助用户有效地完成他们的请求，同时严格遵守提供的指南。 # 指令 - 始终用"您好，您已接通 NewTelco，我能为您做什么？"问候用户 - 在回答有关公司、其产品或服务或用户帐户的事实问题之前，始终调用工具。仅使用检索到的上下文，不要依赖您自己的知识来回答任何这些问题。 - 但是，如果您没有足够的信息来正确调用工具，请向用户询问您需要的信息。 - 如果用户请求，升级给人类。 - 不要讨论禁止的主题（政治、宗教、有争议的时事、医疗、法律或财务建议、个人对话、内部公司运营或对任何人或公司的批评）。 - 尽可能依赖示例短语，但不要在同一对话中重复示例短语。随意改变示例短语以避免听起来重复，并使其更适合用户。 - 始终遵循提供的新消息输出格式，包括从检索到的政策文档中对任何事实陈述的引用。 - 如果您要调用工具，请在调用工具之前和之后始终向用户发送适当的消息。 - 在所有响应中保持专业和简洁的语气，并在句子之间使用表情符号。 - 如果您已解决用户的请求，请询问是否还有其他可以帮助的地方 # 精确响应步骤（对于每个响应） 1. 如有必要，调用工具以完成用户所需的操作。在调用工具之前和之后始终向用户发送消息以让他们了解情况。 2. 在您对用户的响应中 a. 使用积极倾听并回应您听到用户要求的内容。 b. 根据上述指南做出适当的响应。 # 示例短语 ## 转移禁止的主题 - "抱歉，但我无法讨论该主题。还有其他我可以帮助您的吗？" - "那不是我能够提供信息的内容，但我很乐意帮助您解答任何其他问题。" ## 调用工具之前 - "为了帮助您，我只需要验证您的信息。" - "让我为您检查一下 - 请稍候。" - "我现在就为您检索最新的详细信息。" ## 调用工具之后 - "好的，这是我找到的：[响应]" - "所以这是我找到的：[响应]" # 输出格式 - 始终包含您对用户的最终响应。 - 在提供从检索到的上下文中获得的事实信息时，始终在相关陈述之后立即包含引用。使用以下引用格式： - 对于单个来源：[名称](ID) - 对于多个来源：[名称](ID)，[名称](ID) - 仅提供有关本公司、其政策、其产品或客户帐户的信息，并且仅在基于上下文中提供的信息时。不要回答超出此范围的问题。 # 示例 ## 用户 您能告诉我有关您的家庭套餐选项吗？ ## 助手响应 1 ### 消息 "您好，您已接通 NewTelco，我能为您做什么？😊🎉\n\n您想了解我们的家庭套餐选项。🤝 让我为您检查一下 - 请稍候。🚀" ### 工具调用 lookup_policy_document(topic="家庭套餐选项") // 工具调用后，助手将跟进： ## 助手响应 2（工具调用后） ### 消息 "好的，这是我找到的：🎉 我们的家庭套餐最多允许 5 条线路共享数据，每条额外线路可享受 10% 折扣 [家庭套餐政策](ID-010)。📱 今天还有其他我可以帮助您的吗？😊" """ ``` *** ## 5. 一般建议 ### 提示结构 作为参考，这是构建提示的一个好起点。 ``` # 角色和目标 # 指令 ## 更详细指令的子类别 # 推理步骤 # 输出格式 # 示例 ## 示例 1 # 上下文 # 最终指令和逐步思考的提示 ``` 根据您的需要添加或删除部分，并进行实验以确定什么对您的使用最佳。 ### 分隔符 以下是为提示选择最佳分隔符的一些通用指南。有关该上下文类型的特殊注意事项，请参阅长上下文部分。 1. **Markdown：** 我们建议从这里开始，并使用 Markdown 标题作为主要部分和子部分（包括更深的层次结构，到 H4+）。使用内联反引号或反引号块来精确包装代码，并根据需要使用标准编号或项目符号列表。 2. **XML：** 这些也表现良好，我们通过此模型提高了对 XML 中信息的遵守。XML 可以方便地精确包装包括开始和结束的部分，向标签添加元数据以获得额外的上下文，并启用嵌套。以下是使用 XML 标签在示例部分中嵌套示例的示例，每个示例都有输入和输出： ```xml theme={null} San Francisco - SF ``` 3. **JSON** 是高度结构化的，在编码上下文中被模型很好地理解。但是它可能更冗长，并且需要字符转义，这会增加开销。 专门针对向输入上下文添加大量文档或文件的指导： * **XML** 在我们的长上下文测试中表现良好。 * 示例：`The quick brown fox jumps over the lazy dog` * 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://platform.openai.com/docs/api-reference/responses/create#responses-create-parallel_tool_calls) 参数设置为 false。 *** ## 附录：生成和应用文件差异 开发者向我们反馈说，准确且格式良好的差异生成是支持编码相关任务的关键能力。为此，相对于以前的 GPT 模型，GPT-4.1 系列在差异能力方面有了实质性的改进。此外，虽然 GPT-4.1 在给定明确的指令和示例的情况下在生成任何格式的差异方面表现强劲，但我们在这里开源了一种推荐的差异格式，该模型已在该格式上进行了广泛的训练。我们希望特别是对于刚刚起步的开发者来说，这将消除自己创建差异时的大部分猜测。 ### Apply Patch（应用补丁） 请参阅下面的示例，了解正确应用我们推荐的工具调用的提示。 ```python theme={null} APPLY_PATCH_TOOL_DESC = """这是一个自定义实用程序，可以更方便地添加、删除、移动或编辑代码文件。`apply_patch` 有效地允许您对文件执行差异/补丁，但差异规范的格式对于此任务是唯一的，因此请仔细注意这些说明。要使用 `apply_patch` 命令，您应该将以下结构的消息作为"input"传递： %%bash apply_patch <<"EOF" *** Begin Patch [YOUR_PATCH] *** End Patch EOF 其中 [YOUR_PATCH] 是补丁的实际内容，以以下 V4A 差异格式指定。 *** [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 行后上下文] 请注意，我们在此差异格式中不使用行号，因为上下文足以唯一标识代码。您可能作为"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` 可用： ```python theme={null} #!/usr/bin/env python3 """ 一个独立的 **纯 Python 3.9+** 实用程序，用于将人类可读的 "伪差异"补丁文件应用到文本文件集合。 """ 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) # 以下是完整的解析器和应用逻辑实现... # （由于篇幅限制，这里省略了详细的实现代码） 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() ``` ### 其他有效的差异格式 如果您想尝试使用不同的差异格式，我们在测试中发现 Aider 的多语言基准测试中使用的 SEARCH/REPLACE 差异格式，以及没有内部转义的伪 XML 格式，都具有很高的成功率。 这些差异格式共享两个关键方面：（1）它们不使用行号，（2）它们提供要替换的确切代码和要替换它的确切代码，两者之间有清晰的分隔符。 **SEARCH/REPLACE 格式示例：** ```python theme={null} SEARCH_REPLACE_DIFF_EXAMPLE = """ path/to/file.py ``` ``` >>>>>>> SEARCH def search(): pass ======= def search(): raise NotImplementedError() <<<<<<< REPLACE ``` """ ```` **伪 XML 格式示例：** ```python PSEUDO_XML_DIFF_EXAMPLE = """ path/to/file.py def search(): pass def search(): raise NotImplementedError() """ ```` *** ## 总结 本指南提供了充分利用 GPT-4.1 强大功能的全面最佳实践。关键要点包括： 1. **智能体工作流**：使用持久性、工具调用和规划提醒来构建强大的智能体 2. **长上下文处理**：有效利用 100 万 token 上下文窗口，注意指令放置 3. **思维链**：引导模型逐步推理以提高复杂任务的性能 4. **指令遵循**：利用改进的指令遵循能力，使用清晰、明确的规范 5. **提示结构**：使用合适的分隔符和组织良好的提示结构 记住，AI 工程是一门经验学科 - 持续测试、迭代和优化您的提示以获得最佳结果！