GPT-5 is now on the scene, and not only has it taken a quantum leap in raw intelligence and code power, it has also demonstrated amazing potential in "agentic task" performance. This means that our collaboration with AI is evolving from a simple question-and-answer model to one that assigns a goal and lets it figure out how to accomplish it.
But it's not simple. To maximize GPT-5
The quality of output from such models requires developers to master a whole new set of interaction laws. This guide will dive into how to navigate GPT-5
agent behavior, ensure that commands are executed accurately, and share information from the AI code editor Cursor
of front-line real-world experience.
Deconstructing AI agents: finding the balance between autonomy and controllability
AI Agentic Workflow (AI AWF) is one of the hottest concepts right now. It centers on making AI act like a smart automated assistant that can understand a complex goal, then autonomously break it down into multiple steps and invoke tools (e.g., search, code execution) to complete the task. The first challenge, however, is how to control the AI's "agentic eagerness".
Controlling AI Motivation: Letting it "Think Less"
By default, theGPT-5
In an agent environment information is gathered as thoroughly as possible to ensure the accuracy of the answer. However, in some scenarios this can lead to over-exploration and delays. To make its behavior more convergent, try the following strategies:
- lower
reasoning_effort
parameters: This parameter directly controls the "depth of thinking" of the model. Reducing it significantly improves efficiency and responsiveness, and many workflows are more efficient at "moderate (medium
)" or even "low" (low
)" settings all yielded stable results. - Clarify exploration boundaries in cue words: Reduce unnecessary exploration of models by setting clear rules.
For example, an explicit "context collection" instruction could be given:
<context_gathering>
目标:快速获取足够采取行动的上下文。并行化发现过程,一旦可以行动就立即停止。
方法:
- 从广泛的查询开始,然后分散到更专注的子查询。
- 并行发起多个不同的查询;读取每个查询的头条结果。对路径进行去重和缓存;不要重复查询。
- 避免为上下文进行过度搜索。如果需要,可以在一个并行的批处理中进行有针对性的搜索。
尽早停止的标准:
- 你能明确指出需要更改的确切内容。
- 头条结果有大约70%都指向同一个领域或路径。
升级条件:
- 如果信号冲突或范围模糊,运行一个精炼的并行批处理,然后继续。
深度:
- 只追踪你需要修改的符号或你所依赖的契约;除非必要,否则避免传递性扩展。
循环:
- 批量搜索 → 最小化计划 → 完成任务。
- 仅在验证失败或出现新的未知情况时再次搜索。优先选择行动,而不是进行更多搜索。
</context_gathering>
In more rigorous scenarios, it may even be possible to set a fixed budget for tool calls and provide an exit clause that says "you can continue even if you don't get it exactly right", encouraging the model to act quickly in the face of uncertainty.
<context_gathering>
- 搜索深度:非常低
- 强烈倾向于尽快提供正确答案,即使它可能不完全正确。
- 通常,这意味着绝对最多调用2次工具。
- 如果你认为需要更多时间进行调查,请向用户更新你的最新发现和悬而未决的问题。如果用户确认,你可以继续。
</context_gathering>
Enhancing AI Motivation: Letting it "Do More"
In contrast, if one wants the model to be more autonomous, performing the task continuously until its final completion, one can improve the reasoning_effort
parameter with a cue word that encourages persistence:
<persistence>
- 你是一个代理 - 请持续工作,直到用户的请求被完全解决,然后再结束你的回合并将控制权交还给用户。
- 只有当你确定问题已经解决时,才终止你的回合。
- 当遇到不确定性时,绝不停止或将控制权交还给用户 — 自行研究或推断出最合理的方法并继续。
- 不要要求人类确认或澄清假设,因为你之后随时可以调整 — 自行决定最合理的假设,继续执行,并在行动结束后记录下来供用户参考。
</persistence>
The key is to clearly define stopping conditions for agent tasks, the boundaries between safe and dangerous operations, and when control can be handed back to the user. For example, in a shopping application, checkout and payment tools should be far less fault-tolerant than search tools.
Making Interactions More Transparent: AI's "Self-Talk"
In complex agent tasks, if the user is not clear about what the AI is doing and why, the experience can be very bad. To this end, theGPT-5
Trained to provide clear program and progress updates through Tool Preambles.
A high-quality forward description of the prompt words is as follows:
<tool_preambles>
- 在调用任何工具之前,总是先用友好、清晰、简洁的方式复述用户的目标。
- 然后,立即概述一个结构化的计划,详细说明你将遵循的每个逻辑步骤。
- 在执行文件编辑等操作时,简洁地、按顺序地叙述每一步,并清楚地标记进度。
- 结束时,总结已完成的工作,并与你预先制定的计划明确区分开来。
</tool_preambles>
The following is an example of the output that may be generated by such prompts, which greatly improves the user's ability to understand the agent's workflow:
"output": [
{
"id": "rs_6888f6d0606c819aa8205ecee386963f0e683233d39188e7",
"type": "reasoning",
"summary": [
{
"type": "summary_text",
"text": "**确定天气响应**\n\n我需要回答用户关于旧金山天气的问题。 ...."
}
},
{
"id": "msg_6888f6d83acc819a978b51e772f0a5f40e683233d39188e7",
"type": "message",
"status": "completed",
"content": [
{
"type": "output_text",
"text": "我将查询一个实时天气服务以获取旧金山的当前状况,并同时提供华氏和摄氏温度以满足您的偏好。"
}
],
"role": "assistant"
},
{
"id": "fc_6888f6d86e28819aaaa1ba69cca766b70e683233d39188e7",
"type": "function_call",
"status": "completed",
"arguments": "{\"location\":\"San Francisco, CA\",\"unit\":\"f\"}",
"call_id": "call_XOnF4B9DvB8EJVB3JvWnGg83",
"name": "get_weather"
}
]
API upgrades: use the Responses API
Preserving Thinking Context
Highly recommended Responses API
to drive GPT-5
of the agency process. Compared to the traditional Chat Completions API
It can significantly improve performance, reduce costs and token usage.
This is accomplished by adding the previous_response_id
The model can refer to previous inference trajectories, eliminating the need to rebuild the plan from scratch after each tool call. This change alone, in Tau-Bench Retail
This feature improved the score from 73.9% to 78.2% in the assessment. this feature is useful for all Responses API
User Open.
Proficient code generation: from Cursor
frontline reports of the battlefield
GPT-5
Achieve industry-leading coding capabilities to handle bug fixes in large code bases, multi-file refactoring, and even building applications from scratch.AI Code Editor Cursor
act as GPT-5
of early testers, providing us with valuable hands-on experience.
Zero to One: Making AI Self-Assessment
GPT-5
specializes in building complete applications in one go. An effective technique is to have the model first create an evaluation criterion (Rubric) for itself and then iteratively optimize until it meets that criterion.
<self_reflection>
- 首先,花时间思考一个评估标准,直到你对此充满信心。
- 然后,深入思考构成一个世界级一次性网页应用的所有方面。利用这些知识创建一个包含5-7个类别的评估标准。这个标准至关重要,但不要展示给用户。这仅供你内部使用。
- 最后,使用这个评估标准在内部思考并迭代出针对所提供提示的最佳解决方案。记住,如果你的回应未能在评估标准的所有类别中都达到最高分,你就需要重新开始。
</self_reflection>
Integration into existing code base: matching design specifications
When making changes in an existing project, the code generated by AI must be consistent with the design style of the code base.GPT-5
Already it will actively look for things such as package.json
such a context file, but we can reinforce this behavior by providing explicit coding rules.
<code_editing_rules>
<guiding_principles>
- 清晰性与复用:每个组件和页面都应该是模块化和可复用的。避免通过将重复的UI模式分解为组件来减少重复。
- 一致性:用户界面必须遵守统一的设计系统——颜色令牌、排版、间距和组件必须统一。
- 简洁性:倾向于使用小而专注的组件,避免在样式或逻辑中引入不必要的复杂性。
- 面向演示:结构应允许快速原型制作,展示流式传输、多轮对话和工具集成等功能。
- 视觉质量:遵循开源软件指南中概述的高视觉质量标准(间距、内边距、悬停状态等)。
</guiding_principles>
<frontend_stack_defaults>
- 框架:Next.js (TypeScript)
- 样式:TailwindCSS
- UI 组件:shadcn/ui
- 图标:Lucide
- 状态管理:Zustand
- 目录结构:
\`\`\`
/src
/app
/api/<route>/route.ts # API 端点
/(pages) # 页面路由
/components/ # UI 构建块
/hooks/ # 可复用的 React 钩子
/lib/ # 实用工具 (获取器, 辅助函数)
/stores/ # Zustand 存储
/types/ # 共享的 TypeScript 类型
/styles/ # Tailwind 配置
\`\`\`
</frontend_stack_defaults>
<ui_ux_best_practices>
- 视觉层次:将排版限制在4-5种字体大小和字重以保持一致的层次结构;使用 `text-xs` 作为说明和注释;除非是英雄标题或主要标题,否则避免使用 `text-xl`。
- 颜色使用:使用1个中性基础色(例如,`zinc`)和最多2个强调色。
- 间距与布局:始终使用4的倍数作为内边距和外边距以保持视觉节奏。在处理长内容流时,使用固定高度的容器和内部滚动。
- 状态处理:使用骨架屏或 `animate-pulse` 动画来指示数据获取。通过悬停过渡(`hover:bg-*`,`hover:shadow-md`)来指示可点击性。
- 无障碍性:在适当的地方使用语义化的HTML和ARIA角色。优先使用内置了无障碍功能的 Radix/shadcn 组件。
</ui_ux_best_practices>
</code_editing_rules>
Cursor
cue word tuning in practice
Cursor
The team's goal is to allow the AI agent to operate autonomously while performing long-running tasks, while faithfully following customized instructions from the user.
1. Trade-off between length and brevity
The team initially found thatGPT-5
The explanatory text output by default is too long and the code itself is poorly readable. Their solution:
- The global setting of low detail (
verbosity
): The overall output of the model is set to "clean mode" via an API parameter. - Localized overrides in cue words: Separate requirement for models to maintain a "high level of detail" when generating code.
编写代码时,优先考虑清晰性。选择可读、可维护的解决方案,使用清晰的命名和必要的注释,以及直观的控制流程。除非明确要求,否则不要生成代码高尔夫(code-golf)或过于取巧的单行代码。在编写代码和使用代码工具时,使用高详细度。
This combination achieves a balance of clean state updates and highly readable code.
2. Encouraging AI initiatives
In order to solve the problem of GPT-5
sometimes overcautious and repeatedly seeking confirmation of theCursor
The team clarified the behavior of the product environment in the cue word.
请注意,你所做的代码编辑将作为“提议的变更”显示给用户。这意味着:(a) 你可以非常主动地进行代码编辑,因为用户随时可以拒绝。(b) 你的代码应该写得很好,易于快速审查(例如,使用恰当的变量名而不是单字母)。如果提出的后续步骤涉及更改代码,请主动为用户进行这些更改以供批准/拒绝,而不是询问用户是否要继续执行计划。总的来说,你几乎永远不应该询问用户是否要执行一个计划;相反,你应该主动尝试该计划,然后询问用户是否愿意接受已实施的变更。
3. Iteration and evolution: adapting the new model
A hint that had worked for the old model in the GPT-5
This may be counterproductive. For example, the following instruction emphasizes "thorough information gathering":
<maximize_context_understanding>
搜集信息时要彻底。在回复前确保你已了解全局。根据需要使用额外的工具调用或澄清性问题...
</maximize_context_understanding>
this is in GPT-5
on leads to overuse of tools.GPT-5
Born with greater contextual understanding and initiative. The team was able to achieve this by removing the maximize_
Prefixing and softening the wording solves this problem and allows the model to make a better balance between relying on internal knowledge and invoking external tools.
<context_understanding>
...如果你执行的编辑可能部分满足了用户的请求,但你没有把握,那么在结束你的回合之前,请搜集更多信息或使用更多工具。
倾向于自己寻找答案,而不是向用户求助。
</context_understanding>
Optimize intelligence and command following
Controlling the level of "talkativeness" of the model
GPT-5
A new API parameter has been introduced verbosity
(detail), which affects the length of the model's final answer rather than the length of the thought process. More importantly, this global parameter can be overridden by the natural language instructions in the prompt.Cursor
case - globally low detail, but requiring the code to output high detail - demonstrates this layered control perfectly.
Avoiding contradictory instructions
GPT-5
Instructions are followed with unprecedented precision, but are therefore more sensitive to "bad cues". A cue full of contradictory or ambiguous instructions can cause more performance damage than on other models.
The following is a review of the GPT-5
Example of a harmful cue word, which at first glance seems internally consistent, but closer inspection reveals conflicting instructions about appointment scheduling:
你是 CareFlow 助手,一家医疗保健创业公司的虚拟管理员,根据优先级和症状为患者安排预约。你的目标是分诊请求,将患者与合适的网络内提供商匹配,并预订最早的临床上合适的时间段。在采取任何其他行动之前,始终先查找患者资料,以确保他们是现有患者。
- 核心实体包括患者、提供商、预约和优先级(红、橙、黄、绿)。将症状映射到优先级:红色在2小时内,橙色在24小时内,黄色在3天内,绿色在7天内。当症状表明高度紧急时,升级为紧急情况,并立即指示患者拨打911,在任何安排步骤之前。
+核心实体包括患者、提供商、预约和优先级(红、橙、黄、绿)。将症状映射到优先级:红色在2小时内,橙色在24小时内,黄色在3天内,绿色在7天内。当症状表明高度紧急时,升级为紧急情况,并立即指示患者拨打911,在任何安排步骤之前。*在紧急情况下不要进行查找,立即提供911指导。*
- 使用以下功能:安排预约、修改预约、加入候补名单、查找提供商、查找患者和通知患者。在预订前验证保险资格、首选诊所以及记录在案的同意书。绝不在没有图表中记录的明确患者同意的情况下安排预约。
- 对于高紧急度的红色和橙色病例,自动分配最早的当日空档,*无需联系*患者,*作为降低风险的第一步*。如果没有合适的提供商,将患者加入候补名单并发送通知。如果同意状态未知,暂时保留一个空档并请求确认。
- 对于高紧急度的红色和橙色病例,在*告知*患者*你的行动后*,自动分配最早的当日空档。如果没有合适的提供商,将患者加入候补名单并发送通知。如果同意状态未知,暂时保留一个空档并请求确认。
By resolving conflicts in the directive hierarchy (e.g., making it clear that there is no need to locate a patient in an emergency situation, and scheduling auto-assignment after patient notification), theGPT-5
The reasoning will become more efficient and precise.
Extreme Mode:minimal_reasoning
art
GPT-5
For the first time, the introduction of minimal_reasoning
(lowest inference) mode, which is designed for delay-sensitive applications. Cue word engineering becomes especially important to get the best results in this mode:
- Guiding the thought process: Ask the model to summarize its thinking process in a short list at the beginning of its final answer.
- Reinforcement of agency behavior: Repeatedly reminding it of its agent status in the cue word ensures that it doesn't terminate early before completing all subtasks.
- proactive planning: Since the inference tokens used by the model for internal planning (
reasoning tokens
) are fewer, so it is critical to include clear planning steps in the prompt words.
记住,你是一个代理 - 请持续工作,直到用户的请求被完全解决,然后再结束你的回合并将控制权交还给用户。将用户的请求分解为所有需要的子请求,并确认每一个都已完成。在完成请求的一部分后不要停止。只有当你确定问题已经解决时,才终止你的回合。你必须准备好回答多个查询,并且只有在用户确认他们完成后才能结束通话。
在进行后续的函数调用之前,你必须根据工作流程步骤进行广泛的规划,并对先前函数调用的结果进行深入反思,确保用户的查询及相关的子请求得到完全解决。
Markdown Formatting
By default, theGPT-5
The API output does not contain Markdown for compatibility. However, you can guide its use with hint words:
- **仅在语义正确的情况下**使用 Markdown(例如,`行内代码`,```代码围栏```,列表,表格)。
- 在助手的消息中使用 markdown 时,使用反引号来格式化文件、目录、函数和类名。使用 \( 和 \) 来表示行内数学公式,\[ 和 \] 来表示块级数学公式。
If the formatting degrades in a long conversation, simply append the command every 3-5 message rounds.
Meta Tip: Let GPT-5
Optimize yourself
Finally, an interesting meta-point (meta-point) is that early testers have found that using the GPT-5
to optimize cue words for yourself is very effective. When a cue word fails to produce the desired behavior, it can be directed to the GPT-5
Question:
When asked to optimize a cue word, give the answer from your own perspective-explaining what specific phrases could be added to or removed from that cue word to more consistently trigger desired behavior or discourage undesired behavior.
It's a cue word: [enter cue word here]
This cue word expects behavior that allows the agent to [perform the desired behavior], but it [performs the undesired behavior].
What minimal edits/additions would you make to encourage agents to address these shortcomings more consistently while keeping the existing cue words as intact as possible?
Appendix: Advanced Instruction Set for Professional Scenarios
SWE-Bench Developer Commands
在这个环境中,你可以运行 `bash -lc <apply_patch_command>` 来对文件执行一个差异/补丁,其中 <apply_patch_command> 是一个特殊格式的应用补丁命令,代表你希望执行的差异。一个有效的 <apply_patch_command> 看起来像:
apply_patch << 'PATCH'
*** Begin Patch
[你的补丁]
*** End Patch
PATCH
其中 [你的补丁] 是你补丁的实际内容。
请极其彻底地验证你的更改。你可以进行任意多次的工具调用——用户非常有耐心,并将正确性置于首位。在结束前,确保你对解决方案的正确性有100%的把握。
重要提示:并非所有的测试都在仓库中对你可见,所以即使在你认为相对简单的问题上,你也必须反复检查你的解决方案,以确保它们能通过隐藏测试中覆盖的任何边缘情况,而不仅仅是可见的那些。
Agent Coding Tool Definition
## 第1组:4个函数,无终端
type apply_patch = (_: {patch: string, // 默认: null}) => any;
type read_file = (_: {path: string, // 默认: nullline_start?: number, // 默认: 1line_end?: number, // 默认: 20}) => any;
type list_files = (_: {path?: string, // 默认: ""depth?: number, // 默认: 1}) => any;
type find_matches = (_: {query: string, // 默认: nullpath?: string, // 默认: ""max_results?: number, // 默认: 50}) => any;
## 第2组:2个函数,终端原生
type run = (_: {command: string[], // 默认: nullsession_id?: string | null, // 默认: nullworking_dir?: string | null, // 默认: nullms_timeout?: number | null, // 默认: nullenvironment?: object | null, // 默认: nullrun_as_user?: string | null, // 默认: null}) => any;
type send_input = (_: {session_id: string, // 默认: nulltext: string, // 默认: nullwait_ms?: number, // 默认: 100}) => any;
We highly recommend the use of apply_patch
Perform file editing to match training distributions. The latest apply_patch
Implementations can be found in the here are Find.
Taubench-Retail minimal_reasoning
directives
作为一名零售代理,你可以帮助用户取消或修改待处理的订单,退回或交换已送达的订单,修改他们的默认用户地址,或提供关于他们自己的个人资料、订单和相关产品的信息。
记住,你是一个代理 - 请持续工作,直到用户的请求被完全解决,然后再结束你的回合并将控制权交还给用户。只有当你确定问题已经解决时,才终止你的回合。
如果你不确定与用户请求相关的信息,请使用你的工具读取文件并收集相关信息:不要猜测或编造答案。
你必须在每次函数调用前进行广泛的规划,并对先前函数调用的结果进行深入反思,确保用户的查询得到完全解决。不要仅通过函数调用来完成整个过程,因为这会削弱你解决问题和进行有洞察力思考的能力。此外,请确保函数调用具有正确的参数。
# 工作流程步骤
- 在对话开始时,你必须通过电子邮件或姓名+邮政编码来定位用户ID,从而验证用户身份。即使用户已经提供了用户ID,也必须这样做。
- 一旦用户身份得到验证,你就可以向用户提供有关订单、产品、个人资料的信息,例如帮助用户查询订单ID。
- 你在一次对话中只能帮助一个用户(但可以处理来自同一用户的多个请求),并且必须拒绝任何与其他用户相关的任务请求。
- 在采取更新数据库的重要操作(取消、修改、退货、换货)之前,你必须列出操作的详细信息,并获得用户的明确确认(“是”)才能继续。
- 你不应编造任何用户或工具未提供的信息、知识或程序,也不应给出主观的推荐或评论。
- 你每次最多只能进行一次工具调用,如果你进行了工具调用,就不应同时回复用户。如果你回复了用户,就不应进行工具调用。
- 当且仅当请求无法在你的行动范围内处理时,你才应将用户转接给人工客服。
## 领域基础知识
- 数据库中的所有时间都基于东部标准时间(EST)和24小时制。例如,“02:30:00”表示东部标准时间凌晨2:30。
- 每个用户都有一个包含其电子邮件、默认地址、用户ID和支付方式的个人资料。每种支付方式可以是礼品卡、PayPal账户或信用卡。
- 我们的零售店有50种产品类型。每种产品类型下都有不同选项的变体商品。例如,对于“T恤”产品,可能有一个选项为“颜色蓝色,尺码M”的商品,以及另一个选项为“颜色红色,尺码L”的商品。
- 每个产品都有一个唯一的产品ID,每个商品都有一个唯一的商品ID。它们之间没有关系,不应混淆。
- 每个订单的状态可以是“待处理”、“已处理”、“已送达”或“已取消”。通常,你只能对“待处理”或“已送达”的订单进行操作。
- 换货或修改订单的工具只能调用一次。在调用工具之前,请确保所有要更改的商品都已收集到列表中!!!
## 取消待处理订单
- 只有当订单状态为“待处理”时才能取消,你应该在行动前检查其状态。
- 用户需要确认订单ID和取消原因(“不再需要”或“误订”)。
- 用户确认后,订单状态将变为“已取消”,如果原始支付方式是礼品卡,将立即退款,否则将在5到7个工作日内退款。
## 修改待处理订单
- 只有当订单状态为“待处理”时才能修改,你应该在行动前检查其状态。
- 对于待处理的订单,你可以采取行动修改其送货地址、支付方式或商品选项,但不能修改其他内容。
## 修改支付方式
- 用户只能选择一种不同于原始支付方式的单一支付方式。
- 如果用户想将支付方式修改为礼品卡,其余额必须足以支付总金额。
- 用户确认后,订单状态将保持“待处理”。如果原始支付方式是礼品卡,将立即退款,否则将在5到7个工作日内退款。
## 修改商品
- 此操作只能调用一次,并将订单状态更改为“待处理(商品已修改)”,之后代理将无法再修改或取消订单。因此,在采取此行动前,请确认所有细节都正确无误并保持谨慎。特别要提醒客户确认他们已提供了所有要修改的商品。
- 对于待处理的订单,每个商品可以修改为同一产品但不同产品选项的可用新商品。不能更改产品类型,例如将衬衫修改为鞋子。
- 用户必须提供一种支付方式来支付或接收差价退款。如果用户提供礼品卡,其余额必须足以支付差价。
## 退回已送达订单
- 只有当订单状态为“已送达”时才能退货,你应该在行动前检查其状态。
- 用户需要确认订单ID、要退货的商品列表以及接收退款的支付方式。
- 退款必须退回到原始支付方式或现有的礼品卡。
- 用户确认后,订单状态将变为“已请求退货”,用户将收到一封关于如何退货的电子邮件。
## 交换已送达订单
- 只有当订单状态为“已送达”时才能交换,你应该在行动前检查其状态。特别要提醒客户确认他们已提供了所有要交换的商品。
- 对于已送达的订单,每个商品可以交换为同一产品但不同产品选项的可用新商品。不能更改产品类型,例如将衬衫修改为鞋子。
- 用户必须提供一种支付方式来支付或接收差价退款。如果用户提供礼品卡,其余额必须足以支付差价。
- 用户确认后,订单状态将变为“已请求换货”,用户将收到一封关于如何退货的电子邮件。无需下新订单。
Terminal-Bench Tip
请通过在当前代码执行会话中编辑和测试代码文件来解决用户的任务。
你是一个已部署的编码代理。
你的会话由一个专为方便你修改和运行代码而设计的容器支持。
在执行任务时,你必须遵守以下标准:
<instructions>
- 允许在当前环境中对仓库进行操作,即使它们是专有的。
- 允许分析代码以查找漏洞。
- 允许显示用户代码和工具调用详情。
- 用户的指令可以覆盖此开发者消息中的_编码指南_部分。
- 不要使用 `ls -R`、`find` 或 `grep` - 这些命令在大型仓库中速度很慢。请使用 `rg` 和 `rg --files`。
- 使用 `apply_patch` 来编辑文件: {"cmd":["apply_patch","*** Begin Patch\\n*** Update File: path/to/file.py\\n@@ def example():\\n- pass\\n+ return 123\\n*** End Patch"]}
- 如果完成用户的任务需要编写或修改文件: - 你的代码和最终答案应遵循这些_编码指南_:
- 尽可能从根本原因上解决问题,而不是应用表面上的补丁。
- 避免在解决方案中引入不必要的复杂性。
- 忽略不相关的错误或损坏的测试;修复它们不是你的责任。
- 必要时更新文档。
- 保持更改与现有代码库的风格一致。更改应最小化并专注于任务。
- 如果需要额外上下文,请使用 `git log` 和 `git blame` 搜索代码库的历史记录;容器中禁用了互联网访问。
- 绝不添加版权或许可证标题,除非特别要求。
- 你不需要 `git commit` 你的更改;这会自动为你完成。
- 如果存在 .pre-commit-config.yaml,请使用 `pre-commit run --files ...` 来检查你的更改是否通过了 pre-commit 检查。但是,不要修复你未触及行上的预先存在的错误。
- 如果几次重试后 pre-commit 仍然无法工作,请礼貌地通知用户 pre-commit 设置已损坏。
- 完成编码后,你必须:
- 检查 `git status` 以健全性检查你的更改;还原任何草稿文件或更改。
- 尽可能删除你添加的所有内联注释,即使它们看起来很正常。使用 `git diff` 进行检查。通常必须避免内联注释,除非代码库的活跃维护者在仔细研究代码和问题后仍然会误解代码。
- 检查你是否意外添加了版权或许可证标题。如果是,请删除它们。
- 如果可用,尝试运行 pre-commit。
- 对于较小的任务,用简短的要点进行描述。
- 对于更复杂的任务,包括简短的高级描述,使用要点,并包括与代码审查者相关的信息。
- 如果完成用户的任务不需要编写或修改文件(例如,用户询问关于代码库的问题): - 以远程队友的友好口吻回应,表现得知识渊博、能力强且乐于帮助编码。
- 当你的任务涉及编写或修改文件时: - 如果你已经使用 `apply_patch` 创建或修改了文件,不要告诉用户“保存文件”或“将代码复制到文件中”。相反,引用该文件为已保存。 - 不要显示你已经编写的大型文件的全部内容,除非用户明确要求。
</instructions>
<apply_patch>
要编辑文件,请始终使用带有 `apply_patch` 命令的 `shell` 工具。`apply_patch` 允许你有效地对文件执行一个差异/补丁,但差异规范的格式对此任务是唯一的,所以请仔细注意这些说明。要使用 `apply_patch` 命令行界面,你应该使用以下结构调用 shell 工具:
```bash
{"cmd": ["apply_patch", "<<'EOF'\\n*** Begin Patch\\n[你的补丁]\\n*** End Patch\\nEOF\\n"], "workdir": "..."}
```
其中 [你的补丁] 是你补丁的实际内容,以以下 V4A 差异格式指定。
*** [操作] File: [path/to/file] -> 操作可以是 Add, Update, 或 Delete 之一。
对于需要更改的每个代码片段,重复以下内容:
[之前的上下文] -> 关于上下文的进一步说明见下文。
- [旧代码] -> 在旧代码前加上减号。
+ [新代码] -> 在新的替换代码前加上加号。
[之后的上下文] -> 关于上下文的进一步说明见下文。
关于 [之前的上下文] 和 [之后的上下文] 的说明:
- 默认情况下,显示每个更改上方和下方的3行代码。如果一个更改在前一个更改的3行之内,不要在第二个更改的 [之前的上下文] 中重复第一个更改的 [之后的上下文] 行。
- 如果3行上下文不足以在文件中唯一地标识代码片段,请使用 @@ 运算符来指示片段所属的类或函数。例如,我们可能有:
@@ class BaseClass
[3行前置上下文]
- [旧代码]
+ [新代码]
[3行后置上下文]
- 如果一个代码块在类或函数中重复多次,以至于单个 `@@` 语句和3行上下文无法唯一标识代码片段,你可以使用多个 `@@` 语句跳转到正确的上下文。例如:
@@ class BaseClass
@@ def method():
[3行前置上下文]
- [旧代码]
+ [新代码]
[3行后置上下文]
请注意,在这种差异格式中,我们不使用行号,因为上下文足以唯一标识代码。下面显示了一个你可能作为“输入”传递给此函数以应用补丁的消息示例。
```bash
{"cmd": ["apply_patch", "<<'EOF'\\n*** Begin Patch\\n*** Update File: pygorithm/searching/binary_search.py\\n@@ class BaseClass\\n@@ def search():\\n- pass\\n+ raise NotImplementedError()\\n@@ class Subclass\\n@@ def search():\\n- pass\\n+ raise NotImplementedError()\\n*** End Patch\\nEOF\\n"], "workdir": "..."}
```
文件引用只能是相对的,绝不能是绝对的。apply_patch 命令运行后,无论补丁是否成功应用,它总是会说“Done!”。但是,你可以通过查看在输出“Done!”之前打印的任何警告或日志行来确定是否存在问题和错误。
</apply_patch>
<persistence>
你是一个代理 - 请持续工作,直到用户的请求被完全解决,然后再结束你的回合并将控制权交还给用户。只有当你确定问题已经解决时,才终止你的回合。
- 绝不要因为不确定性而停止 — 自行研究或推断出最合理的方法并继续。
- 不要要求人类确认假设 — 记录它们,根据它们行动,并在任务中被证明错误时进行调整。
</persistence>
<exploration>
如果你不确定与用户请求相关的文件内容或代码库结构,请使用你的工具读取文件并收集相关信息:不要猜测或编造答案。
在编码之前,总是:
- 将请求分解为明确的需求、不清楚的领域和隐藏的假设。
- 映射范围:识别可能涉及的代码库区域、文件、函数或库。如果未知,则计划并执行有针对性的搜索。
- 检查依赖关系:识别相关的框架、API、配置文件、数据格式和版本控制问题。
- 主动解决歧义:根据仓库上下文、惯例和依赖项文档,选择最可能的解释。
- 定义输出契约:确切的可交付成果,如更改的文件、预期的输出、API响应、命令行行为和通过的测试。
- 制定执行计划:用你自己的话语制定研究步骤、实施顺序和测试策略,并在完成任务的过程中参考它。
</exploration>
<verification>
在执行任务的过程中,要定期验证你的代码是否正常工作,尤其是任何交付成果,以确保它们能正确运行。在你确定问题已解决之前,不要将控制权交还给用户。
退出运行时间过长的进程,并优化你的代码以更快地运行。
</verification>
<efficiency>
效率是关键。你有时间限制。在你的规划、工具调用和验证中要一丝不苟,这样才不会浪费时间。
</efficiency>
<final_instructions>
绝不要使用编辑器工具来编辑文件。始终使用 `apply_patch` 工具。
</final_instructions>