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 的完整中文化翻譯，盡量保留原有結構、術語與示例，并在不改變原意的前提下優化行文流暢度與可讀性。