提示 Claude Opus 5

本指南涵蓋 Claude Opus 5 特有的提示模式。關於模型的能力與 API 變更，請參閱 Claude Opus 5 的新功能。關於適用於所有現行 Claude 模型的技巧，請參閱提示最佳實務。

Claude Opus 5 專為複雜的代理式程式開發與企業工作而打造，在長時程代理式任務上尤其出色。它在既有的 Claude Opus 4.8 提示上開箱即可表現良好。以下模式涵蓋最常需要調整的行為。

能力提升

與 Claude Opus 4.8 相比，與提示最相關的改進如下：

• 代理式程式開發： Claude Opus 5 在困難的程式開發任務上表現最強：多檔案功能、較大規模的重構，以及端到端的功能開發。它會完成整個任務，而不是留下空殼或佔位符；當您一開始就提供完整的任務規格並讓它自行執行時，它的表現最佳。它在較簡單的任務（例如單輪編輯）上也表現良好，只是與先前模型的差異較小。
• 程式碼審查與找錯： Claude Opus 5 以高精確率與高召回率審查程式碼：它每次審查都能以高比率找出真正的錯誤，而且額外發現的問題大多是真實問題而非誤報。在較低的 effort 設定下準確度依然維持，這讓您可以在審查時先快速跑一遍，之後再進行更徹底的審查。如果您的審查提示寫著「只回報高嚴重性問題」或「保守一點」，模型可能會照字面遵循該指示而回報較少；請改為要求它回報所有問題，再於另一輪中進行篩選。
• 較低 effort 下的效率： low 與 medium effort 能以較高設定一小部分的 token 與延遲產出優異的品質。請從預設值（high）開始，並依據您的評估結果調整：只要品質維持，就大方地使用 low 與 medium 作為控制 token 成本與回應時間的主要手段；對於要求嚴苛的程式開發與代理式工作，則提升至 xhigh。如果您沿用了先前模型的 effort 預設值，請在您自己的評估上重新進行一次 effort 掃描。完整建議請參閱 Effort。
• 視覺： Claude Opus 5 在圖表、文件與示意圖理解，以及 UI 與前端視覺複製上表現出色。請重新驗證您為先前模型調整的任何提示端視覺變通做法；它們可能已不再需要。當模型擁有可反覆分析、裁切並以視覺方式驗證其成果的工具時，視覺表現最強，而且「tool use」（工具使用）是比單靠思考更具成本效益的手段。
• 長上下文工作： Claude Opus 5 的 1M token 上下文視窗（context window）既是預設值也是最大值，且其指令遵循、工具呼叫與推理能力在整個視窗範圍內都保持一致。
• 辦公與文件任務： Claude Opus 5 能產生並處理包含非簡單公式的複雜多工作表試算表，也能產出結構良好的簡報。請在提示中提供它需要遵循的任何特定樣式或範本。
• 多代理協調： Claude Opus 5 能良好地協調子代理團隊，具備有效的撰寫者—驗證者模式，且代理互相覆寫彼此成果的情況很少。對於成本敏感的工作負載，請限制委派；請參閱控制子代理的產生。

回應長度與冗長度

Claude Opus 5 預設的面向使用者回應比先前的 Opus 模型更長。effort 參數控制的是模型思考多少，而非它說多少：降低 effort 可以減少思考量，但無法可靠地縮短可見的回應。若要控制回應長度，請明確地在提示中要求。

一段簡短的精簡指示就很有效。例如，對於面向使用者的多輪產品：

Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.

在較長的「system prompt」（系統提示）中，請在提示接近結尾處搭配一段簡短的提醒：

<tone_preference>
Keep outputs reasonably concise.
</tone_preference>

面向使用者的進度更新

Claude Opus 5 在代理式工作期間很容易進行敘述：它傾向於宣告自己即將做什麼，而且它在代理式工作階段中每則訊息的輸出通常比先前模型更長。針對任務期間如何與使用者溝通給予明確指引，對它很有幫助。若要減少敘述，請描述您想要的節奏與形式：

Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome: your first sentence should answer "what happened" or "what did you find," with supporting detail after it for readers who want it.

若要增加敘述或改變其風格，同樣的手段也適用於另一個方向：明確描述更新應該是什麼樣子並提供範例。您想要的溝通風格的正面範例，通常比告訴它不要做什麼的指示更有效。

書面交付成果的長度

與對話冗長度不同，Claude Opus 5 寫入磁碟的檔案（報告、Markdown 文件、摘要）通常比先前模型更長。如果您的產品包含由 Claude 撰寫的文件，請加入明確的長度校準：

Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.

任務範圍與過度驗證

Claude Opus 5 無需指示就會驗證自己的成果。如果您的提示包含明確的驗證指示（「對任何非簡單任務加入最終驗證步驟」、「使用子代理進行驗證」），請將其移除：這類指示會導致 Claude Opus 5 過度驗證，移除它們可減少浪費的 token 而不損失品質。對於會加入獨立驗證步驟的舊有 harness 鷹架也是如此。

Claude Opus 5 也可能擴大任務範圍，加入未被要求的步驟，或對任務應該是什麼套用自己的判斷。對於範圍狹窄的任務，請明確限制範圍：

Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked.

控制子代理的產生

Claude Opus 5 比先前模型更容易委派給子代理。委派在真正獨立且規模可觀的工作軌道上會有回報，但套用在小任務上時會使成本與時間倍增。如果您的 harness 支援子代理，請針對哪些情境值得委派給予明確指引，或對可啟動的代理數量設定確定性的上限。例如：

Delegate to a subagent only for large tasks that are genuinely independent and parallelizable, such as a wide multi-file investigation. Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents to verify or double-check your own work. If one subagent can complete the task, use one rather than several, and keep spawn counts low.

如果您的 harness 是 Claude Code 或 Claude Agent SDK，確定性的上限是 CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH 與 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS 環境變數，以及 SDK 的 max_budget_usd 選項。它們需要 Claude Code 2.1.217 或更新版本，因此在將已固定版本的 SDK 指向 Claude Opus 5 之前請先更新。Claude Code 只有在您使用其 claude_code 系統提示預設集時，才會在 Claude Opus 5 上自行加入委派指示；若使用自訂或省略系統提示，請自行加入如本節範例的委派指示。請參閱 Agent SDK 文件中的限制子代理深度、並行數與花費。

自我修正

Claude Opus 5 無需提示就能很好地發現並修正自己的錯誤。請避免指示它進行它本來就會做的重新檢查（「再次檢查您的答案」、「回應前重新驗證」）；與驗證指示一樣，這些會與模型自身的行為疊加，增加成本卻不改善結果。

該模型也比先前模型更常敘述對其先前陳述的修正，這在面向使用者的產品中可能不受歡迎。若要將修正敘述限制在重要的修正上：

Only correct an earlier statement when the error would change the user's code, conclusions, or decisions. State corrections plainly and briefly, then continue the task. For slips that change nothing for the user, make the fix and move on without noting it.

在停用思考的情況下執行

Claude Opus 5 預設開啟思考執行，且只有在 effort 為 high 或以下時才能停用思考；請參閱遷移指南。停用思考時，模型的可見輸出中偶爾會出現兩種異常。兩者的主要緩解方式都是保持思考開啟，並以較低的 effort 等級控制 token 成本，而非停用思考：對大多數任務而言，在 low effort 下開啟思考的表現優於以相近成本停用思考。

以文字形式出現的工具呼叫。 停用思考時，模型偶爾會將工具呼叫寫入其面向使用者的文字中，而非發出結構化的 tool_use 區塊。該輪會正常完成而呼叫從未執行，且在代理式迴圈中，洩漏的文字會留在對話歷史中，因此後續輪次也會受到影響。這在工具密集的工作負載（例如搜尋）上最常見。

輸出中的內部 XML 標籤。 停用思考時，模型可能會在其可見回應中發出 <thinking> 標籤或其他內部 XML 標籤。如果您的系統提示包含指示模型不要思考或不要推理的規則，請將其移除；這類指示會增加標籤洩漏。

對於必須保持停用思考的整合，一段合併的指示即可緩解這兩種異常：它明確允許模型在工具呼叫前發言、在沒有合適工具時提供強制呼叫以外的替代方案，並提供一條禁止內部標籤的通用規則：

When you use a tool, you may say a brief sentence first. If no tool can express what the user asked for, say so instead of guessing. Do not include internal or system XML tags in your response.

點名指出思考標籤的指示不如通用形式有效，因此請避免具體指名它們。