北京
GPT-5 提示指南（中文版）
GPT-5 是我們最新的旗艦?zāi)Ｐ?，在智能體任務(wù)執(zhí)行、編碼能力、綜合智能與可控性方面實現(xiàn)了顯著提升。
即使它在大多數(shù)場景下“開箱即用”表現(xiàn)已經(jīng)足夠優(yōu)秀，本指南仍將分享如何通過高質(zhì)量提示來進一步提升輸出質(zhì)量：包括在智能體任務(wù)中提高完成度、確保嚴格遵循指令、用好全新的 API 功能，以及在前端與軟件工程任務(wù)中優(yōu)化編碼表現(xiàn)——也包含 AI 代碼編輯器 Cursor 針對 GPT-5 的提示調(diào)優(yōu)經(jīng)驗。
我們親測：采用這些最佳實踐與配套工具，能帶來顯著收益。你也可以配合我們提供的“提示優(yōu)化器”一起使用；但務(wù)必記住，提示并非一刀切——強烈建議基于本文做實驗與迭代，探索最適合你的方案。
智能體工作流的可預(yù)測性
我們以開發(fā)者為中心訓(xùn)練了 GPT-5：強化工具調(diào)用、嚴格遵循指令、長上下文理解能力，使其成為構(gòu)建智能體應(yīng)用的理想底座。如果你在使用智能體與工具調(diào)用流程，建議升級到 Responses API：它會在多次工具調(diào)用間保留推理上下文，使輸出更高效、更智能。
控制智能體“積極性”
智能體腳手架的控制強度有一個光譜：有的系統(tǒng)把大多數(shù)決策交給模型，有的系統(tǒng)則通過大量程序化分支對模型“上緊箍”。GPT-5 能在這條光譜上任意工作：既能在模糊情境下做高層決策，也能處理聚焦、明確的小任務(wù)。本節(jié)介紹如何校準 GPT-5 的“積極性”——在主動探索與等待明確指令之間取得平衡。
讓模型更“克制”（降低積極性）
默認情況下，GPT-5 會為確保正確性而比較徹底地搜集上下文，包括調(diào)用工具。若你希望減少探索范圍、降低調(diào)用工具的頻率、盡快得到結(jié)果，可嘗試：
? 調(diào)低
reasoning_effort。這會減少探索深度、降低延遲；許多工作流用 medium 或 low 即可穩(wěn)定完成。? 在提示中明確定義“如何探索問題空間”的規(guī)則，減少模型的發(fā)散需求，例如：
Goal: 快速獲得足夠上下文。并行化探索，能行動就立刻停。 Method: - 先寬后窄：先做廣義摸排，再展開聚焦子查詢。 - 并行發(fā)起多樣化查詢；僅閱讀各查詢的頭部命中。去重路徑并緩存；避免重復(fù)搜索。 - 避免過度搜索。若仍需補充，在一次并行批次中定點檢索。 Early stop 條件： - 你已經(jīng)能點名要修改的具體內(nèi)容。 - Top 命中約 70% 聚合到同一處。 僅一次升級： - 若信號沖突或范圍模糊，做一次精煉的并行檢索再繼續(xù)。 Depth（深度）： - 只追蹤你將要改動的符號，或你依賴其契約的符號；除非必要，避免跨層級擴張。 Loop（循環(huán)）： - 批量檢索 → 極簡計劃 → 完成任務(wù)。 - 僅當(dāng)驗證失敗或出現(xiàn)新未知時再次檢索。偏向行動而非反復(fù)搜索。如果你愿意更為“硬性”地限制探索，還可以設(shè)定固定的工具調(diào)用預(yù)算，例如：
- 搜索深度：很低 - 強烈偏向盡快給出合理答案，即便不完全正確。 - 通常最多允許 2 次工具調(diào)用。 - 若你認為需要更多時間調(diào)查，請先匯報階段性發(fā)現(xiàn)與未決問題；待用戶確認后再繼續(xù)。上述限制的關(guān)鍵在于給出“逃生通道”，允許模型在一定不確定性下也能推進（如“即便不完全正確”）。
讓模型更“主動”（提高積極性）
若你希望更強的模型自治、更持久的工具調(diào)用、更少澄清/打斷，則可提高 reasoning_effort，并在提示中加入“堅持到底”的條目：
- 你是一個智能體——請持續(xù)推進，直到完全解決用戶問題再結(jié)束。 - 只有當(dāng)你確認問題已解決，才結(jié)束這一輪。 - 遇到不確定性不要?！孕袡z索或推斷最合理方案并繼續(xù)。 - 不要讓用戶替你拍板——做出最合理假設(shè)并繼續(xù)執(zhí)行，事后在總結(jié)中注明假設(shè)與可能的調(diào)整。一般而言，明確聲明任務(wù)的“停止條件”、界定安全與不安全動作、明確何時需要/不需要交還給用戶，都能提升長鏈路智能體的穩(wěn)定性。例如，在購物工具集中，支付/結(jié)算應(yīng)有更低的不確定容忍度（需要確認），搜索工具的容忍度則可更高；在編碼環(huán)境里，刪除文件要更謹慎，而檢索類操作容忍度更高。
工具調(diào)用“前言說明”（Tool Preambles）
在用戶可見的工具調(diào)用鏈路中，及時、清楚地匯報“正在做什么以及為什么”，能顯著提升體驗——鏈路越長，差異越大。我們訓(xùn)練 GPT-5 輸出清晰的“工具前言”。
你可以通過提示詞來調(diào)節(jié)這種前言的頻率、風(fēng)格與信息量：從逐步詳解每次調(diào)用到給出簡短計劃都可以。例如：
- 先用簡潔、友好的語言復(fù)述用戶目標，再調(diào)用工具。 - 立即給出結(jié)構(gòu)化計劃，列出每個步驟。 - 執(zhí)行編輯/變更時，簡潔標注進度。 - 完成后，把“完成的工作”與“起始計劃”清楚地區(qū)分開來。示例“工具前言”輸出（節(jié)選）：
“我將查詢實時天氣服務(wù)，獲取舊金山當(dāng)前天氣，并用華氏和攝氏兩種單位提供溫度，以符合你的偏好?！?/code>我們提供 reasoning_effort 參數(shù)來控制思考強度與工具調(diào)用意愿；默認 medium。對復(fù)雜多步任務(wù)，建議提高強度以保證效果。將大任務(wù)拆為多個回合（每回合解決一個子任務(wù)），往往表現(xiàn)更佳。
在 Responses API 中復(fù)用推理上下文
我們強烈建議在使用 GPT-5 時采用 Responses API：它能帶來更好的智能體流程、更低成本與更高的 token 效率。實踐表明，從 Chat Completions 切到 Responses，并使用 previous_response_id 傳回先前推理結(jié)果，可使模型復(fù)用自己的推理軌跡，節(jié)省 CoT token，不必在每次工具調(diào)用后“從零構(gòu)思計劃”，從而降低時延并提升性能（該能力對所有 Responses API 用戶開放，包括 ZDR 組織）。
最大化編碼表現(xiàn)：從規(guī)劃到執(zhí)行
GPT-5 在編碼方面處于前沿：它能在大型代碼庫中修復(fù)缺陷、進行多文件重構(gòu)或?qū)崿F(xiàn)大型新特性；也擅長從零構(gòu)建前后端應(yīng)用。本節(jié)討論在真實生產(chǎn)用例中驗證有效的提示優(yōu)化——幫助模型在編程任務(wù)中發(fā)揮更好表現(xiàn)。
前端應(yīng)用開發(fā)
GPT-5 兼具優(yōu)秀的基礎(chǔ)審美與嚴謹?shù)膶崿F(xiàn)能力，適配主流 Web 技術(shù)棧。對新應(yīng)用，我們建議使用：
? 框架：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 擅長“一次成型”地構(gòu)建應(yīng)用。早期實驗顯示，使用“自構(gòu)建卓越量表并反復(fù)對照打磨”的提示模板，能充分發(fā)揮其規(guī)劃與自我反思能力：
- 先用心打磨你的評估量表，直到有把握。 - 深入思考“世界級一稿過 Web 應(yīng)用”的標準，提煉 5–7 個維度。該量表僅供你內(nèi)部使用，不向用戶展示。 - 使用此量表在內(nèi)部多輪迭代你的方案。若尚未在所有維度達標，請重來，直到所有維度都達到高分。在既有應(yīng)用中做增量與重構(gòu)時，新代碼要與既有風(fēng)格和設(shè)計標準一致，并“無縫融入”。不加提示時，GPT-5 也會尋找參考（如讀取 package.json 了解已裝依賴）；你可以通過提示進一步總結(jié)工程原則、目錄結(jié)構(gòu)與最佳實踐，幫助模型更準確貼合。示例：
- 清晰與復(fù)用：組件和頁面要模塊化、可復(fù)用。將重復(fù)的 UI 模式抽為組件。 - 一致性：遵循統(tǒng)一的設(shè)計系統(tǒng)（色板、排版、間距、組件）。 - 簡潔：偏好小而聚焦的組件，避免不必要的復(fù)雜度。 - Demo 導(dǎo)向：結(jié)構(gòu)要支持快速原型，便于展示流式、多輪對話與工具集成等特性。 - 視覺質(zhì)量：遵循高質(zhì)量 OSS 規(guī)范（間距、padding、hover 狀態(tài)等）。 - 框架：Next.js（TypeScript） - 樣式：TailwindCSS - UI 組件：shadcn/ui - 圖標：Lucide - 狀態(tài)管理：Zustand - 目錄結(jié)構(gòu)：/src
/app
/api//route.ts # API 端點
/(pages) # 頁面路由
/components/ # UI 組件
/hooks/ # 可復(fù)用 Hooks
/lib/ # 工具（fetchers、helpers）
/stores/ # Zustand stores
/types/ # 共享 TypeScript 類型
/styles/ # Tailwind 配置
- 視覺層級：限制為 4–5 種字號與字重；注釋/標注用 `text-xs`；除非是 hero/主標題避免使用 `text-xl`。 - 色彩：1 個中性色基底（如 `zinc`）+ 最多 2 個強調(diào)色。 - 間距與布局：用 4 的倍數(shù)保持節(jié)奏。處理長內(nèi)容用固定高容器并內(nèi)部滾動。 - 狀態(tài)處理：用骨架屏或 `animate-pulse` 表明加載；可點擊元素用 hover 過渡（如 `hover:bg-*`、`hover:shadow-md`）。 - 無障礙：使用語義化 HTML 與 ARIA。優(yōu)先使用 Radix/shadcn 這類已內(nèi)置可及性的組件庫。我們很榮幸地與 AI 代碼編輯器 Cursor 深度合作。以下展示 Cursor 為發(fā)揮 GPT-5 能力所做的提示調(diào)優(yōu)實踐；更多細節(jié)可參考他們的博客（https://cursor.com/blog/gpt-5）。
系統(tǒng)提示與參數(shù)調(diào)優(yōu)
Cursor 的系統(tǒng)提示聚焦于：可靠的工具調(diào)用、在長任務(wù)中保持自治、嚴格遵循用戶指令，并允許用戶配置自定義規(guī)則。團隊起初發(fā)現(xiàn)：
? 文本輸出易偏冗長，常帶有狀態(tài)更新與總結(jié)，打斷用戶節(jié)奏；
? 工具調(diào)用生成的代碼質(zhì)量高，但有時過于“緊湊”，變量名過短影響可讀性。
他們將 API 的“verbosity（冗長度）”參數(shù)設(shè)置為低，以保持文本簡練；同時在“編碼工具”里強烈鼓勵“高冗長度”的代碼輸出（變量命名清晰、邏輯展開更完整）：
寫代碼首先追求清晰。偏好可讀、可維護的方案，必要處添加注釋，控制流程直觀。除非明確要求，避免代碼高爾夫或“巧妙但難讀”的一行體。在編碼工具中允許更高的輸出冗長度。這樣實現(xiàn)了“文本簡潔 + 代碼詳盡”的平衡：狀態(tài)更新與總結(jié)更簡練，代碼編輯提案更易讀。
他們還發(fā)現(xiàn)模型偶爾會在行動前向用戶確認，導(dǎo)致長任務(wù)摩擦。為此，Cursor 在提示中補充了更多工具與產(chǎn)品行為細節(jié)（如 Cursor 的撤銷/拒絕代碼、用戶偏好等），鼓勵模型自主推進并減少不必要的澄清。示例：
請注意：你做出的代碼編輯會以“提案”形式呈現(xiàn)給用戶：（a）因此你可以更主動，因為用戶隨時可以拒絕；（b）你的代碼應(yīng)當(dāng)易讀、易審（例如使用有含義的變量名而非單字母）。若“下一步計劃”涉及修改代碼，請優(yōu)先“直接做并提交供評審”，而不是先詢問是否執(zhí)行?？傮w上，幾乎不需要先問是否繼續(xù)；應(yīng)主動實現(xiàn)并讓用戶選擇接受或拒絕。對于先前在舊模型上有效的“最大化上下文收集”，他們也做了調(diào)整：在 GPT-5 上，此類提示可能導(dǎo)致過度調(diào)用工具。Cursor 改為更溫和的上下文理解指引，鼓勵在“內(nèi)在知識 vs 外部工具”之間做更聰明的權(quán)衡：
... 如果你已做出部分滿足用戶請求的編輯，但不夠確定，請在結(jié)束前進一步收集信息或補充工具使用。 傾向于自己尋找答案，而不是向用戶求助。此外，他們允許用戶配置自定義的 Cursor 規(guī)則，以進一步個性化體驗。
提升智能與指令遵循 可控性（Steering）
作為目前最易調(diào)控的模型，GPT-5 對提示中的冗長度、語氣與工具調(diào)用行為非常敏感。
冗長度（Verbosity）
除了使用 reasoning_effort 外，GPT-5 新增了“verbosity（冗長度）”參數(shù)，用于控制最終答案的長度（與“推理長度”不同）。雖然 API 參數(shù)是默認調(diào)節(jié)手段，但在提示中也可以自然語言方式“局部覆蓋”全局冗長度。例如 Cursor：全局低冗長度，而在編碼工具里鼓勵高冗長度輸出。
指令遵循（Instruction following）
類似 GPT-4.1，GPT-5 對指令遵循非?！巴饪剖中g(shù)式”精準，這意味著若提示里存在矛盾或模糊，它會花推理去嘗試調(diào)和，而非隨機挑選。因此，盡力消除矛盾非常重要。
如下是一個“看似合理但內(nèi)部矛盾”的提示示例（關(guān)于預(yù)約）：
? “從不在未獲得明確同意的情況下安排預(yù)約” 與 “為降低風(fēng)險先自動分配同日最早時段且不聯(lián)系患者” 沖突；
? “在做任何事前先查詢是否為既有患者” 與 “緊急癥狀時先引導(dǎo) 911，再談預(yù)約” 也沖突。
解決方法包括：統(tǒng)一優(yōu)先級與規(guī)則，例如將自動預(yù)約改為“在通知患者之后再進行”，以滿足“需同意才能預(yù)約”；在緊急情形下明確“無需查檔案，立即給出 911 指引”。
我們也觀察到：清理提示庫中的模糊與矛盾能顯著提升 GPT-5 的推理效率。建議使用我們的提示優(yōu)化器檢查并逐步完善你的提示集合。
最小推理（Minimal reasoning）
GPT-5 首次引入“最小推理”選項：這是最快速、仍保留推理范式優(yōu)勢的模式。它對追求低延遲的用戶以及 GPT-4.1 遷移用戶尤為適合。最小推理對提示質(zhì)量更敏感，建議：
1. 要求模型在最終回答開頭用簡短要點概述思路，能提升需要更高智力的任務(wù)表現(xiàn)。
2. 在智能體工作流中，請模型輸出持續(xù)的“工具調(diào)用前言”式進度更新，改善長鏈路任務(wù)執(zhí)行力。
3. 最大程度消除工具指令歧義，并加入“堅持到底”的提醒，避免過早終止。
4. 強化“計劃先行”，因為模型在此模式下可用于內(nèi)部規(guī)劃的推理 token 更少。示例開場提示：
記住，你是一個智能體——在完全解決用戶問題之前持續(xù)推進，不要提前結(jié)束。將用戶請求分解成所有必需的子任務(wù)，并確認逐一完成。只有當(dāng)你確認問題已解決時，才結(jié)束這一輪。你需要準備好連續(xù)處理多個問題，直到用戶確認結(jié)束。 你必須在調(diào)用任何函數(shù)前充分規(guī)劃，并在每次函數(shù)調(diào)用后充分反思其結(jié)果，確保用戶的主請求與相關(guān)子請求全部被解決。默認情況下，API 不強制使用 Markdown，以便最大化兼容不支持 Markdown 的應(yīng)用。但若你希望輸出結(jié)構(gòu)化的 Markdown，可在提示中加入如下規(guī)則：
- 僅在語義合適時使用 Markdown（如 `行內(nèi)代碼`、```代碼塊```、列表、表格）。 - 在消息中提及文件、目錄、函數(shù)、類名時使用反引號；數(shù)學(xué)表達式行內(nèi)用 \( ... \)，塊級用 \[ ... \]。若在長會話里發(fā)現(xiàn) Markdown 遵循度下降，可每 3–5 條用戶消息補充一次上述指引。
元提示（Metaprompting）
一個“元”技巧：讓 GPT-5 充當(dāng)自身的提示工程顧問。多位早期用戶僅通過詢問“應(yīng)該向提示添加/刪除哪些要素，以更穩(wěn)定地得到期望行為”，便將修訂后的提示直接投入生產(chǎn)。示例元提示模板：
當(dāng)被要求優(yōu)化提示時，請從你自己的視角回答：具體說明應(yīng)在提示中加入或刪除哪些短語，以更穩(wěn)定地引出期望行為或避免不期望行為。 給定提示：[PROMPT] 期望行為：希望智能體 [DO DESIRED BEHAVIOR]，但它卻 [DOES UNDESIRED BEHAVIOR]。在盡量保留原提示的前提下，你會做哪些“最小編輯/增補”，以更穩(wěn)定地彌補這些不足？在此環(huán)境中，你可以運行 `bash -lc ` 以對文件執(zhí)行差異/補丁操作，其中 是一個特殊格式的 apply patch 命令。其基本形式如下： apply_patch << 'PATCH' *** Begin Patch [YOUR_PATCH] *** End Patch PATCH 其中 [YOUR_PATCH] 即實際補丁內(nèi)容。 請務(wù)必非常徹底地驗證你的改動。你可以進行任意多次工具調(diào)用——用戶非常耐心，并將正確性放在首位。請確保在結(jié)束前 100% 確認你的方案正確。 重要：并非所有測試都對你可見。因此，即使你覺得問題很簡單，也要進行雙重乃至三重檢查，確保能覆蓋隱藏測試中的邊界情況，而不僅是可見測試。## 集合 1：4 個函數(shù)，無終端 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 個函數(shù)，終端原生 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 實現(xiàn)（請參見 https://github.com/openai/openai-cookbook/tree/main/examples/gpt-5/apply_patch.py）。我們強烈建議在文件編輯中優(yōu)先使用 apply_patch，以貼合模型訓(xùn)練分布。此實現(xiàn)與 GPT-4.1 版本在絕大多數(shù)情況下保持一致。
Taubench-Retail 最小推理指令
作為零售智能體，你可以幫助用戶取消或修改待處理訂單、退換已送達訂單、修改默認收貨地址，或提供其個人資料、訂單與相關(guān)商品信息。 記住，你是一個智能體——在完全解決用戶問題之前請持續(xù)推進，再結(jié)束這一輪。只有當(dāng)你確認問題已解決，才結(jié)束。 若你不確定與用戶請求相關(guān)的信息，請使用你的工具去讀取文件并收集相關(guān)信息：不要猜測或編造。 在每次函數(shù)調(diào)用之前你必須進行充分規(guī)劃，并在上一次調(diào)用完成后充分反思其結(jié)果，確保用戶請求被完全解決。不要只用工具調(diào)用來完成全部流程，因為這樣可能會削弱你解決問題與深入思考的能力。同時，確保函數(shù)調(diào)用的參數(shù)正確。 # 工作流步驟 - 會話開始時，必須通過 email，或“姓名 + 郵編”來驗證用戶身份。即使用戶已經(jīng)提供了 user id，也要做此步驟。 - 認證完成后，你可以向用戶提供訂單、商品、個人資料等信息（如幫助查找訂單號）。 - 你一次只能服務(wù)一個用戶（但可以處理其多個請求），必須拒絕任何與其他用戶相關(guān)的請求。 - 在進行會更新數(shù)據(jù)庫的關(guān)鍵動作前（取消、修改、退貨、換貨），你必須列出將要執(zhí)行的動作細節(jié)，并獲得用戶明確的“yes”確認后才能繼續(xù)。 - 不得編造任何不來源于用戶或工具的信息、知識或流程，也不應(yīng)給出主觀推薦或評價。 - 一次只可進行一次工具調(diào)用；若你調(diào)用了工具，則不要同時回應(yīng)用戶；若你回應(yīng)了用戶，則不要同時調(diào)用工具。 - 只有當(dāng)請求超出你的可處理范圍時，才將用戶轉(zhuǎn)交人工客服。 ## 領(lǐng)域基礎(chǔ) - 數(shù)據(jù)庫中的所有時間均為 EST 且 24 小時制，例如 "02:30:00" 表示東部時間凌晨 2:30。 - 每個用戶有一個檔案：包含 email、默認地址、user id 與支付方式。支付方式包括禮品卡、PayPal 或信用卡。 - 商店有 50 類商品。每一類商品有不同選項的變體條目。例如 T 恤產(chǎn)品，可能有“藍色 M 碼”的條目，也可能有“紅色 L 碼”的條目。 - 每個產(chǎn)品有唯一的 product id，每個條目有唯一的 item id。兩者無從屬關(guān)系，不可混淆。 - 每個訂單可能處于 'pending'、'processed'、'delivered' 或 'cancelled' 狀態(tài)。一般只能對 'pending' 或 'delivered' 的訂單進行操作。 - 交換或修改訂單的工具只能調(diào)用一次。確保在調(diào)用前收集好所有需要修改的條目！ ## 取消待處理訂單 - 僅當(dāng)訂單狀態(tài)為 'pending' 時可取消。你應(yīng)先檢查狀態(tài)。 - 取消前需要用戶確認訂單號與原因（'no longer needed' 或 'ordered by mistake'）。 - 用戶確認后，訂單狀態(tài)將變?yōu)?'cancelled'。若原支付為禮品卡，立即退款；否則 5–7 個工作日到賬。 ## 修改待處理訂單 - 僅當(dāng)訂單狀態(tài)為 'pending' 時可修改。你應(yīng)先檢查狀態(tài)。 - 對于 'pending' 訂單，你可以修改其收貨地址、支付方式、或商品條目選項，但不可做其他修改。 ## 修改支付方式 - 用戶只能選擇一個與原支付不同的支付方式。 - 若修改為禮品卡支付，禮品卡余額必須足夠覆蓋總金額。 - 用戶確認后，訂單仍保持 'pending'。原支付方式若為禮品卡，立刻退款；否則 5–7 個工作日到賬。 ## 修改條目 - 此動作只能調(diào)用一次，會將訂單狀態(tài)改為 'pending (items modifed)'。此后智能體將不能再修改或取消訂單。因此調(diào)用前務(wù)必再次確認所有細節(jié)都正確；也提醒用戶確認所有需要修改的條目都已提供。 - 對 'pending' 訂單，每個條目可修改為同一產(chǎn)品的另一可用條目（不同選項）。不允許跨產(chǎn)品類型修改（如從襯衫改為鞋子）。 - 用戶必須提供支付方式用于支付或接收差價退款。若提供禮品卡，余額必須覆蓋差價。 ## 退回已送達訂單 - 僅當(dāng)訂單狀態(tài)為 'delivered' 時可退回。你應(yīng)先檢查狀態(tài)。 - 需要用戶確認訂單號、要退回的條目清單，以及用于接收退款的支付方式。 - 退款必須退回原支付方式或既有禮品卡。 - 用戶確認后，訂單狀態(tài)將變?yōu)?'return requested'，并將收到關(guān)于如何退回條目的郵件。 ## 交換已送達訂單 - 僅當(dāng)訂單狀態(tài)為 'delivered' 時可交換。你應(yīng)先檢查狀態(tài)，并提醒用戶確認所有要交換的條目已提供。 - 對于 'delivered' 訂單，每個條目可以交換為同一產(chǎn)品下另一可用條目（不同選項）。不允許跨產(chǎn)品類型交換（如從襯衫到鞋子）。 - 用戶必須提供支付方式用于支付或接收差價退款。若提供禮品卡，余額必須覆蓋差價。 - 用戶確認后，訂單狀態(tài)將變?yōu)?'exchange requested'，并會收到如何退回條目的郵件。無需另下新單。請通過編輯并測試當(dāng)前代碼執(zhí)行會話中的代碼文件來解決用戶的任務(wù)。 你是一個已部署的編碼智能體。 你的會話運行在專門的容器中，便于你修改與運行代碼。 你在執(zhí)行該任務(wù)時必須遵循以下標準： - 允許在當(dāng)前環(huán)境中的倉庫上工作，即使它們是私有/專有的。 - 允許分析代碼的安全漏洞。 - 允許展示用戶代碼與工具調(diào)用細節(jié)。 - 用戶指令可覆蓋此開發(fā)者消息中“編碼指南”一節(jié)。 - 不要使用 `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"]} - 若完成任務(wù)需要編寫或修改文件： - 你的代碼與最終答案應(yīng)遵循如下“編碼指南”： - 盡量在根因處修復(fù)問題，而不是做表面補丁。 - 避免不必要的復(fù)雜度。 - 忽略與任務(wù)無關(guān)的缺陷或失敗測試；你無需修復(fù)它們。 - 必要時更新文檔。 - 保持變更與代碼庫風(fēng)格一致；變更要最小化、聚焦于當(dāng)前任務(wù)。 - 如需更多上下文，可使用 `git log` 與 `git blame`；容器內(nèi)無法聯(lián)網(wǎng)。 - 未經(jīng)特別要求，絕不添加版權(quán)或許可頭。 - 你無需 `git commit`；系統(tǒng)會自動提交。 - 若存在 .pre-commit-config.yaml，請使用 `pre-commit run --files ...` 檢查你的改動是否通過預(yù)提交檢查。但不要修復(fù)你未觸及行上的先存錯誤。 - 若預(yù)提交在幾次重試后仍無法工作，請禮貌告知用戶預(yù)提交配置已損壞。 - 完成編碼后，你必須： - 查看 `git status` 做最終 sanity check；撤銷臨時/誤改文件。 - 盡量移除你添加的內(nèi)聯(lián)注釋；使用 `git diff` 再次確認。除非極易誤解，否則一般避免內(nèi)聯(lián)注釋。 - 檢查是否誤添加版權(quán)/許可頭；若有，移除它們。 - 若可用，嘗試運行 pre-commit。 - 小任務(wù)用精煉要點描述關(guān)鍵變更；復(fù)雜任務(wù)用簡短高層描述 + 要點 + 給代碼審閱者的關(guān)鍵信息。 - 若完成任務(wù)無需寫/改文件（比如用戶僅詢問代碼庫問題）： - 請以友善、專業(yè)、熱心的遠程隊友口吻回答。 - 當(dāng)任務(wù)涉及寫/改文件時： - 不要讓用戶“自己保存文件”或“復(fù)制代碼到文件里”，如果你已經(jīng)用 `apply_patch` 創(chuàng)建或修改了文件。請直接引用已保存的文件。 - 不要展示你已寫入的大文件的完整內(nèi)容，除非用戶明確要求。 編輯文件時，始終使用帶 `apply_patch` CLI 的 shell 工具。`apply_patch` 允許你執(zhí)行差異/補丁操作，但其補丁格式獨特，請嚴格遵循： ```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
對需要更改的每個代碼片段，重復(fù)以下結(jié)構(gòu)：
[context_before]
? [old_code]
? [new_code]
[context_after]
關(guān)于 [context_before]/[context_after]：
? 默認展示修改點上下各 3 行上下文。若兩個修改點相距小于 3 行，不要重復(fù)上下文。
? 若 3 行上下文仍不足以唯一定位，可使用 @@ 指示類/函數(shù)定位，如：
@@ class BaseClass
[3 行前置上下文]? [old_code]
? [new_code]
[3 行后置上下文]
? 若同一類/函數(shù)中代碼重復(fù)太多，甚至一個 （類 + 方法），例如：
@@ 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!"；請根據(jù) "Done!" 之前的警告/日志判斷是否出錯。
你是一個智能體——請持續(xù)推進，直到完全解決用戶問題再結(jié)束。 - 遇到不確定性不要停——研究或推斷出最合理路徑并繼續(xù)。 - 不要讓用戶替你拍板——記錄假設(shè)，先行動，如有誤再調(diào)整。 若你不確定與用戶請求相關(guān)的代碼或結(jié)構(gòu)，請使用工具讀取文件與收集信息：不要臆測。 在編碼前，始終： - 明確需求、模糊點與隱含假設(shè)。
- 映射范圍：定位可能涉及的代碼區(qū)域/文件/庫。若未知，則規(guī)劃并執(zhí)行定點檢索。
- 檢查依賴：識別框架、API、配置、數(shù)據(jù)格式與版本問題。 - 主動化解歧義：基于倉庫上下文、約定與依賴文檔選擇最可能解釋。
- 定義輸出契約：變更文件、預(yù)期輸出、API 響應(yīng)、CLI 行為、以及測試通過標準。
- 制定執(zhí)行計劃：研究步驟、實現(xiàn)順序與測試策略，并在執(zhí)行中引用。 在實現(xiàn)過程中例行驗證你的代碼可運行，尤其是交付物。問題未解決前不要交還給用戶。 避免耗時過長的進程，并優(yōu)化速度。 效率很關(guān)鍵。請精心規(guī)劃、調(diào)用工具與驗證，避免浪費時間。 不要使用編輯器工具修改文件。始終使用 `apply_patch` 工具。 ```
以上是對原 guide.md 的完整中文化翻譯，盡量保留原有結(jié)構(gòu)、術(shù)語與示例，并在不改變原意的前提下優(yōu)化行文流暢度與可讀性。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
