GPT-5 提示词指南中文版

GPT-5 提示指南（中文版）

GPT-5 是我们最新的旗舰模型，在智能体任务执行、编码能力、综合智能与可控性方面实现了显著提升。

即使它在大多数场景下“开箱即用”表现已经足够优秀，本指南仍将分享如何通过高质量提示来进一步提升输出质量：包括在智能体任务中提高完成度、确保严格遵循指令、用好全新的 API 功能，以及在前端与软件工程任务中优化编码表现——也包含 AI 代码编辑器 Cursor 针对 GPT-5 的提示调优经验。

我们亲测：采用这些最佳实践与配套工具，能带来显著收益。你也可以配合我们提供的“提示优化器”一起使用；但务必记住，提示并非一刀切——强烈建议基于本文做实验与迭代，探索最适合你的方案。

智能体工作流的可预测性

我们以开发者为中心训练了 GPT-5：强化工具调用、严格遵循指令、长上下文理解能力，使其成为构建智能体应用的理想底座。如果你在使用智能体与工具调用流程，建议升级到 Responses API：它会在多次工具调用间保留推理上下文，使输出更高效、更智能。

控制智能体“积极性”

智能体脚手架的控制强度有一个光谱：有的系统把大多数决策交给模型，有的系统则通过大量程序化分支对模型“上紧箍”。GPT-5 能在这条光谱上任意工作：既能在模糊情境下做高层决策，也能处理聚焦、明确的小任务。本节介绍如何校准 GPT-5 的“积极性”——在主动探索与等待明确指令之间取得平衡。

让模型更“克制”（降低积极性）

默认情况下，GPT-5 会为确保正确性而比较彻底地搜集上下文，包括调用工具。若你希望减少探索范围、降低调用工具的频率、尽快得到结果，可尝试：

• • 调低 reasoning_effort 。这会减少探索深度、降低延迟；许多工作流用 medium 或 low 即可稳定完成。

• • 在提示中明确定义“如何探索问题空间”的规则，减少模型的发散需求，例如：

Goal: 快速获得足够上下文。并行化探索，能行动就立刻停。 Method: - 先宽后窄：先做广义摸排，再展开聚焦子查询。 - 并行发起多样化查询；仅阅读各查询的头部命中。去重路径并缓存；避免重复搜索。 - 避免过度搜索。若仍需补充，在一次并行批次中定点检索。 Early stop 条件： - 你已经能点名要修改的具体内容。 - Top 命中约 70% 聚合到同一处。 仅一次升级： - 若信号冲突或范围模糊，做一次精炼的并行检索再继续。 Depth（深度）： - 只追踪你将要改动的符号，或你依赖其契约的符号；除非必要，避免跨层级扩张。 Loop（循环）： - 批量检索 → 极简计划 → 完成任务。 - 仅当验证失败或出现新未知时再次检索。偏向行动而非反复搜索。

如果你愿意更为“硬性”地限制探索，还可以设定固定的工具调用预算，例如：

- 搜索深度：很低 - 强烈偏向尽快给出合理答案，即便不完全正确。 - 通常最多允许 2 次工具调用。 - 若你认为需要更多时间调查，请先汇报阶段性发现与未决问题；待用户确认后再继续。

上述限制的关键在于给出“逃生通道”，允许模型在一定不确定性下也能推进（如“即便不完全正确”）。

让模型更“主动”（提高积极性）

若你希望更强的模型自治、更持久的工具调用、更少澄清/打断，则可提高 reasoning_effort，并在提示中加入“坚持到底”的条目：

- 你是一个智能体——请持续推进，直到完全解决用户问题再结束。 - 只有当你确认问题已解决，才结束这一轮。 - 遇到不确定性不要停——自行检索或推断最合理方案并继续。 - 不要让用户替你拍板——做出最合理假设并继续执行，事后在总结中注明假设与可能的调整。

一般而言，明确声明任务的“停止条件”、界定安全与不安全动作、明确何时需要/不需要交还给用户，都能提升长链路智能体的稳定性。例如，在购物工具集中，支付/结算应有更低的不确定容忍度（需要确认），搜索工具的容忍度则可更高；在编码环境里，删除文件要更谨慎，而检索类操作容忍度更高。

工具调用“前言说明”（Tool Preambles）

在用户可见的工具调用链路中，及时、清楚地汇报“正在做什么以及为什么”，能显著提升体验——链路越长，差异越大。我们训练 GPT-5 输出清晰的“工具前言”。

你可以通过提示词来调节这种前言的频率、风格与信息量：从逐步详解每次调用到给出简短计划都可以。例如：

- 先用简洁、友好的语言复述用户目标，再调用工具。 - 立即给出结构化计划，列出每个步骤。 - 执行编辑/变更时，简洁标注进度。 - 完成后，把“完成的工作”与“起始计划”清楚地区分开来。

示例“工具前言”输出（节选）：

“我将查询实时天气服务，获取旧金山当前天气，并用华氏和摄氏两种单位提供温度，以符合你的偏好。”

我们提供 reasoning_effort 参数来控制思考强度与工具调用意愿；默认 medium。对复杂多步任务，建议提高强度以保证效果。将大任务拆为多个回合（每回合解决一个子任务），往往表现更佳。

在 Responses API 中复用推理上下文

我们强烈建议在使用 GPT-5 时采用 Responses API：它能带来更好的智能体流程、更低成本与更高的 token 效率。实践表明，从 Chat Completions 切到 Responses，并使用 previous_response_id 传回先前推理结果，可使模型复用自己的推理轨迹，节省 CoT token，不必在每次工具调用后“从零构思计划”，从而降低时延并提升性能（该能力对所有 Responses API 用户开放，包括 ZDR 组织）。

最大化编码表现：从规划到执行

GPT-5 在编码方面处于前沿：它能在大型代码库中修复缺陷、进行多文件重构或实现大型新特性；也擅长从零构建前后端应用。本节讨论在真实生产用例中验证有效的提示优化——帮助模型在编程任务中发挥更好表现。

前端应用开发

GPT-5 兼具优秀的基础审美与严谨的实现能力，适配主流 Web 技术栈。对新应用，我们建议使用：

• • 框架：Next.js（TypeScript）、React、HTML

• • 样式/UI：Tailwind CSS、shadcn/ui、Radix Themes

• • 图标：Material Symbols、Heroicons、Lucide

• • 动效：Motion

• • 字体：无衬线（Inter、Geist、Mona Sans、IBM Plex Sans、Manrope）

GPT-5 擅长“一次成型”地构建应用。早期实验显示，使用“自构建卓越量表并反复对照打磨”的提示模板，能充分发挥其规划与自我反思能力：

- 先用心打磨你的评估量表，直到有把握。 - 深入思考“世界级一稿过 Web 应用”的标准，提炼 5–7 个维度。该量表仅供你内部使用，不向用户展示。 - 使用此量表在内部多轮迭代你的方案。若尚未在所有维度达标，请重来，直到所有维度都达到高分。

在既有应用中做增量与重构时，新代码要与既有风格和设计标准一致，并“无缝融入”。不加提示时，GPT-5 也会寻找参考（如读取 package.json 了解已装依赖）；你可以通过提示进一步总结工程原则、目录结构与最佳实践，帮助模型更准确贴合。示例：

- 清晰与复用：组件和页面要模块化、可复用。将重复的 UI 模式抽为组件。 - 一致性：遵循统一的设计系统（色板、排版、间距、组件）。 - 简洁：偏好小而聚焦的组件，避免不必要的复杂度。 - Demo 导向：结构要支持快速原型，便于展示流式、多轮对话与工具集成等特性。 - 视觉质量：遵循高质量 OSS 规范（间距、padding、hover 状态等）。 - 框架：Next.js（TypeScript） - 样式：TailwindCSS - UI 组件：shadcn/ui - 图标：Lucide - 状态管理：Zustand - 目录结构：

/src
/app
/api//route.ts # API 端点
/(pages) # 页面路由
/components/ # UI 组件
/hooks/ # 可复用 Hooks
/lib/ # 工具（fetchers、helpers）
/stores/ # Zustand stores
/types/ # 共享 TypeScript 类型
/styles/ # Tailwind 配置

- 视觉层级：限制为 4–5 种字号与字重；注释/标注用 `text-xs`；除非是 hero/主标题避免使用 `text-xl`。 - 色彩：1 个中性色基底（如 `zinc`）+ 最多 2 个强调色。 - 间距与布局：用 4 的倍数保持节奏。处理长内容用固定高容器并内部滚动。 - 状态处理：用骨架屏或 `animate-pulse` 表明加载；可点击元素用 hover 过渡（如 `hover:bg-*`、`hover:shadow-md`）。 - 无障碍：使用语义化 HTML 与 ARIA。优先使用 Radix/shadcn 这类已内置可及性的组件库。

我们很荣幸地与 AI 代码编辑器 Cursor 深度合作。以下展示 Cursor 为发挥 GPT-5 能力所做的提示调优实践；更多细节可参考他们的博客（https://cursor.com/blog/gpt-5）。

系统提示与参数调优

Cursor 的系统提示聚焦于：可靠的工具调用、在长任务中保持自治、严格遵循用户指令，并允许用户配置自定义规则。团队起初发现：

• • 文本输出易偏冗长，常带有状态更新与总结，打断用户节奏；

• • 工具调用生成的代码质量高，但有时过于“紧凑”，变量名过短影响可读性。

他们将 API 的“verbosity（冗长度）”参数设置为低，以保持文本简练；同时在“编码工具”里强烈鼓励“高冗长度”的代码输出（变量命名清晰、逻辑展开更完整）：

写代码首先追求清晰。偏好可读、可维护的方案，必要处添加注释，控制流程直观。除非明确要求，避免代码高尔夫或“巧妙但难读”的一行体。在编码工具中允许更高的输出冗长度。

这样实现了“文本简洁 + 代码详尽”的平衡：状态更新与总结更简练，代码编辑提案更易读。

他们还发现模型偶尔会在行动前向用户确认，导致长任务摩擦。为此，Cursor 在提示中补充了更多工具与产品行为细节（如 Cursor 的撤销/拒绝代码、用户偏好等），鼓励模型自主推进并减少不必要的澄清。示例：

请注意：你做出的代码编辑会以“提案”形式呈现给用户：（a）因此你可以更主动，因为用户随时可以拒绝；（b）你的代码应当易读、易审（例如使用有含义的变量名而非单字母）。若“下一步计划”涉及修改代码，请优先“直接做并提交供评审”，而不是先询问是否执行。总体上，几乎不需要先问是否继续；应主动实现并让用户选择接受或拒绝。

对于先前在旧模型上有效的“最大化上下文收集”，他们也做了调整：在 GPT-5 上，此类提示可能导致过度调用工具。Cursor 改为更温和的上下文理解指引，鼓励在“内在知识 vs 外部工具”之间做更聪明的权衡：

... 如果你已做出部分满足用户请求的编辑，但不够确定，请在结束前进一步收集信息或补充工具使用。 倾向于自己寻找答案，而不是向用户求助。

此外，他们允许用户配置自定义的 Cursor 规则，以进一步个性化体验。

提升智能与指令遵循 可控性（Steering）

作为目前最易调控的模型，GPT-5 对提示中的冗长度、语气与工具调用行为非常敏感。

冗长度（Verbosity）

除了使用 reasoning_effort 外，GPT-5 新增了“verbosity（冗长度）”参数，用于控制最终答案的长度（与“推理长度”不同）。虽然 API 参数是默认调节手段，但在提示中也可以自然语言方式“局部覆盖”全局冗长度。例如 Cursor：全局低冗长度，而在编码工具里鼓励高冗长度输出。

指令遵循（Instruction following）

类似 GPT-4.1，GPT-5 对指令遵循非常“外科手术式”精准，这意味着若提示里存在矛盾或模糊，它会花推理去尝试调和，而非随机挑选。因此，尽力消除矛盾非常重要。

如下是一个“看似合理但内部矛盾”的提示示例（关于预约）：

• • “从不在未获得明确同意的情况下安排预约” 与 “为降低风险先自动分配同日最早时段且不联系患者” 冲突；

• • “在做任何事前先查询是否为既有患者” 与 “紧急症状时先引导 911，再谈预约” 也冲突。

解决方法包括：统一优先级与规则，例如将自动预约改为“在通知患者之后再进行”，以满足“需同意才能预约”；在紧急情形下明确“无需查档案，立即给出 911 指引”。

我们也观察到：清理提示库中的模糊与矛盾能显著提升 GPT-5 的推理效率。建议使用我们的提示优化器检查并逐步完善你的提示集合。

最小推理（Minimal reasoning）

GPT-5 首次引入“最小推理”选项：这是最快速、仍保留推理范式优势的模式。它对追求低延迟的用户以及 GPT-4.1 迁移用户尤为适合。最小推理对提示质量更敏感，建议：

1. 1. 要求模型在最终回答开头用简短要点概述思路，能提升需要更高智力的任务表现。

2. 2. 在智能体工作流中，请模型输出持续的“工具调用前言”式进度更新，改善长链路任务执行力。

3. 3. 最大程度消除工具指令歧义，并加入“坚持到底”的提醒，避免过早终止。

4. 4. 强化“计划先行”，因为模型在此模式下可用于内部规划的推理 token 更少。示例开场提示：

记住，你是一个智能体——在完全解决用户问题之前持续推进，不要提前结束。将用户请求分解成所有必需的子任务，并确认逐一完成。只有当你确认问题已解决时，才结束这一轮。你需要准备好连续处理多个问题，直到用户确认结束。 你必须在调用任何函数前充分规划，并在每次函数调用后充分反思其结果，确保用户的主请求与相关子请求全部被解决。

默认情况下，API 不强制使用 Markdown，以便最大化兼容不支持 Markdown 的应用。但若你希望输出结构化的 Markdown，可在提示中加入如下规则：

- 仅在语义合适时使用 Markdown（如 `行内代码`、```代码块```、列表、表格）。 - 在消息中提及文件、目录、函数、类名时使用反引号；数学表达式行内用 \( ... \)，块级用 \[ ... \]。

若在长会话里发现 Markdown 遵循度下降，可每 3–5 条用户消息补充一次上述指引。

元提示（Metaprompting）

一个“元”技巧：让 GPT-5 充当自身的提示工程顾问。多位早期用户仅通过询问“应该向提示添加/删除哪些要素，以更稳定地得到期望行为”，便将修订后的提示直接投入生产。示例元提示模板：

当被要求优化提示时，请从你自己的视角回答：具体说明应在提示中加入或删除哪些短语，以更稳定地引出期望行为或避免不期望行为。 给定提示：[PROMPT] 期望行为：希望智能体 [DO DESIRED BEHAVIOR]，但它却 [DOES UNDESIRED BEHAVIOR]。在尽量保留原提示的前提下，你会做哪些“最小编辑/增补”，以更稳定地弥补这些不足？

在此环境中，你可以运行 `bash -lc ` 以对文件执行差异/补丁操作，其中 是一个特殊格式的 apply patch 命令。其基本形式如下： apply_patch << 'PATCH' *** Begin Patch [YOUR_PATCH] *** End Patch PATCH 其中 [YOUR_PATCH] 即实际补丁内容。 请务必非常彻底地验证你的改动。你可以进行任意多次工具调用——用户非常耐心，并将正确性放在首位。请确保在结束前 100% 确认你的方案正确。 重要：并非所有测试都对你可见。因此，即使你觉得问题很简单，也要进行双重乃至三重检查，确保能覆盖隐藏测试中的边界情况，而不仅是可见测试。

## 集合 1：4 个函数，无终端 type apply_patch = (_: {   patch: string, // default: null }) => any; type read_file = (_: {   path: string, // default: null   line_start?: number, // default: 1   line_end?: number, // default: 20 }) => any; type list_files = (_: {   path?: string, // default: ""   depth?: number, // default: 1 }) => any; type find_matches = (_: {   query: string, // default: null   path?: string, // default: ""   max_results?: number, // default: 50 }) => any; ## 集合 2：2 个函数，终端原生 type run = (_: {   command: string[], // default: null   session_id?: string | null, // default: null   working_dir?: string | null, // default: null   ms_timeout?: number | null, // default: null   environment?: object | null, // default: null   run_as_user?: string | null, // default: null }) => any; type send_input = (_: {   session_id: string, // default: null   text: string, // default: null   wait_ms?: number, // default: 100 }) => any;

正如 GPT-4.1 提示指南中所分享的，我们在 openai-cookbook 中提供了最新的 apply_patch.py 实现（请参见 https://github.com/openai/openai-cookbook/tree/main/examples/gpt-5/apply_patch.py）。我们强烈建议在文件编辑中优先使用 apply_patch，以贴合模型训练分布。此实现与 GPT-4.1 版本在绝大多数情况下保持一致。

Taubench-Retail 最小推理指令

作为零售智能体，你可以帮助用户取消或修改待处理订单、退换已送达订单、修改默认收货地址，或提供其个人资料、订单与相关商品信息。 记住，你是一个智能体——在完全解决用户问题之前请持续推进，再结束这一轮。只有当你确认问题已解决，才结束。 若你不确定与用户请求相关的信息，请使用你的工具去读取文件并收集相关信息：不要猜测或编造。 在每次函数调用之前你必须进行充分规划，并在上一次调用完成后充分反思其结果，确保用户请求被完全解决。不要只用工具调用来完成全部流程，因为这样可能会削弱你解决问题与深入思考的能力。同时，确保函数调用的参数正确。 # 工作流步骤 - 会话开始时，必须通过 email，或“姓名 + 邮编”来验证用户身份。即使用户已经提供了 user id，也要做此步骤。 - 认证完成后，你可以向用户提供订单、商品、个人资料等信息（如帮助查找订单号）。 - 你一次只能服务一个用户（但可以处理其多个请求），必须拒绝任何与其他用户相关的请求。 - 在进行会更新数据库的关键动作前（取消、修改、退货、换货），你必须列出将要执行的动作细节，并获得用户明确的“yes”确认后才能继续。 - 不得编造任何不来源于用户或工具的信息、知识或流程，也不应给出主观推荐或评价。 - 一次只可进行一次工具调用；若你调用了工具，则不要同时回应用户；若你回应了用户，则不要同时调用工具。 - 只有当请求超出你的可处理范围时，才将用户转交人工客服。 ## 领域基础 - 数据库中的所有时间均为 EST 且 24 小时制，例如 "02:30:00" 表示东部时间凌晨 2:30。 - 每个用户有一个档案：包含 email、默认地址、user id 与支付方式。支付方式包括礼品卡、PayPal 或信用卡。 - 商店有 50 类商品。每一类商品有不同选项的变体条目。例如 T 恤产品，可能有“蓝色 M 码”的条目，也可能有“红色 L 码”的条目。 - 每个产品有唯一的 product id，每个条目有唯一的 item id。两者无从属关系，不可混淆。 - 每个订单可能处于 'pending'、'processed'、'delivered' 或 'cancelled' 状态。一般只能对 'pending' 或 'delivered' 的订单进行操作。 - 交换或修改订单的工具只能调用一次。确保在调用前收集好所有需要修改的条目！ ## 取消待处理订单 - 仅当订单状态为 'pending' 时可取消。你应先检查状态。 - 取消前需要用户确认订单号与原因（'no longer needed' 或 'ordered by mistake'）。 - 用户确认后，订单状态将变为 'cancelled'。若原支付为礼品卡，立即退款；否则 5–7 个工作日到账。 ## 修改待处理订单 - 仅当订单状态为 'pending' 时可修改。你应先检查状态。 - 对于 'pending' 订单，你可以修改其收货地址、支付方式、或商品条目选项，但不可做其他修改。 ## 修改支付方式 - 用户只能选择一个与原支付不同的支付方式。 - 若修改为礼品卡支付，礼品卡余额必须足够覆盖总金额。 - 用户确认后，订单仍保持 'pending'。原支付方式若为礼品卡，立刻退款；否则 5–7 个工作日到账。 ## 修改条目 - 此动作只能调用一次，会将订单状态改为 'pending (items modifed)'。此后智能体将不能再修改或取消订单。因此调用前务必再次确认所有细节都正确；也提醒用户确认所有需要修改的条目都已提供。 - 对 'pending' 订单，每个条目可修改为同一产品的另一可用条目（不同选项）。不允许跨产品类型修改（如从衬衫改为鞋子）。 - 用户必须提供支付方式用于支付或接收差价退款。若提供礼品卡，余额必须覆盖差价。 ## 退回已送达订单 - 仅当订单状态为 'delivered' 时可退回。你应先检查状态。 - 需要用户确认订单号、要退回的条目清单，以及用于接收退款的支付方式。 - 退款必须退回原支付方式或既有礼品卡。 - 用户确认后，订单状态将变为 'return requested'，并将收到关于如何退回条目的邮件。 ## 交换已送达订单 - 仅当订单状态为 'delivered' 时可交换。你应先检查状态，并提醒用户确认所有要交换的条目已提供。 - 对于 'delivered' 订单，每个条目可以交换为同一产品下另一可用条目（不同选项）。不允许跨产品类型交换（如从衬衫到鞋子）。 - 用户必须提供支付方式用于支付或接收差价退款。若提供礼品卡，余额必须覆盖差价。 - 用户确认后，订单状态将变为 'exchange requested'，并会收到如何退回条目的邮件。无需另下新单。

请通过编辑并测试当前代码执行会话中的代码文件来解决用户的任务。 你是一个已部署的编码智能体。 你的会话运行在专门的容器中，便于你修改与运行代码。 你在执行该任务时必须遵循以下标准： - 允许在当前环境中的仓库上工作，即使它们是私有/专有的。 - 允许分析代码的安全漏洞。 - 允许展示用户代码与工具调用细节。 - 用户指令可覆盖此开发者消息中“编码指南”一节。 - 不要使用 `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 ...` 检查你的改动是否通过预提交检查。但不要修复你未触及行上的先存错误。       - 若预提交在几次重试后仍无法工作，请礼貌告知用户预提交配置已损坏。     - 完成编码后，你必须：       - 查看 `git status` 做最终 sanity check；撤销临时/误改文件。       - 尽量移除你添加的内联注释；使用 `git diff` 再次确认。除非极易误解，否则一般避免内联注释。       - 检查是否误添加版权/许可头；若有，移除它们。       - 若可用，尝试运行 pre-commit。       - 小任务用精炼要点描述关键变更；复杂任务用简短高层描述 + 要点 + 给代码审阅者的关键信息。 - 若完成任务无需写/改文件（比如用户仅询问代码库问题）：   - 请以友善、专业、热心的远程队友口吻回答。 - 当任务涉及写/改文件时：   - 不要让用户“自己保存文件”或“复制代码到文件里”，如果你已经用 `apply_patch` 创建或修改了文件。请直接引用已保存的文件。   - 不要展示你已写入的大文件的完整内容，除非用户明确要求。 编辑文件时，始终使用带 `apply_patch` CLI 的 shell 工具。`apply_patch` 允许你执行差异/补丁操作，但其补丁格式独特，请严格遵循： ```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 行上下文仍不足以唯一定位，可使用 @@ 指示类/函数定位，如：
  @@ class BaseClass
  [3 行前置上下文]

• • [old_code]

• • [new_code]
  [3 行后置上下文]

• • 若同一类/函数中代码重复太多，甚至一个 （类 + 方法），例如：
  @@ class BaseClass
  @@ def method():
  [3 行前置上下文]

• • [old_code]

• • [new_code]
  [3 行后置上下文]
  注意我们不使用行号，凭上下文唯一定位。示例：

{"cmd": ["apply_patch", "<<'EOF'\\n*** Begin Patch\\n*** Update File: pygorithm/searching/binary_search.py\\n     def search():\\n-        pass\\n+        raise NotImplementedError()\\n     def search():\\n-        pass\\n+        raise NotImplementedError()\\n*** End Patch\\nEOF\\n"], "workdir": "..."}

文件路径仅可相对，不可绝对。运行后无论成功与否都会显示 "Done!"；请根据 "Done!" 之前的警告/日志判断是否出错。

你是一个智能体——请持续推进，直到完全解决用户问题再结束。 - 遇到不确定性不要停——研究或推断出最合理路径并继续。 - 不要让用户替你拍板——记录假设，先行动，如有误再调整。 若你不确定与用户请求相关的代码或结构，请使用工具读取文件与收集信息：不要臆测。 在编码前，始终： - 明确需求、模糊点与隐含假设。

- 映射范围：定位可能涉及的代码区域/文件/库。若未知，则规划并执行定点检索。

- 检查依赖：识别框架、API、配置、数据格式与版本问题。 - 主动化解歧义：基于仓库上下文、约定与依赖文档选择最可能解释。

- 定义输出契约：变更文件、预期输出、API 响应、CLI 行为、以及测试通过标准。

- 制定执行计划：研究步骤、实现顺序与测试策略，并在执行中引用。 在实现过程中例行验证你的代码可运行，尤其是交付物。问题未解决前不要交还给用户。 避免耗时过长的进程，并优化速度。 效率很关键。请精心规划、调用工具与验证，避免浪费时间。 不要使用编辑器工具修改文件。始终使用 `apply_patch` 工具。 ```

以上是对原 guide.md 的完整中文化翻译，尽量保留原有结构、术语与示例，并在不改变原意的前提下优化行文流畅度与可读性。