為 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 在困難的編碼任務上最為出色：多檔案功能、較大規模的重構，以及端到端的功能開發。它會完成完整的任務，而不是留下殘段（stub）或佔位符，並且在一開始就獲得完整的任務規格並讓它自行執行時表現最佳。它在較簡單的任務（如單輪編輯）上也表現良好，只是與先前模型的差異較小。
• 程式碼審查與錯誤尋找： Claude Opus 5 以高精確率（precision）和高召回率（recall）審查程式碼：它每次掃描都能以高比率找到真正的錯誤，而且其額外的發現大多是真實問題而非誤報。準確度在較低的 effort 設定下仍能維持，這支援在審查時先進行快速掃描，之後再進行更徹底的掃描。如果您的審查提示寫著「只回報高嚴重性問題」或「保守一點」，模型可能會照字面遵循該指示而回報較少；請改為要求它回報所有內容，並在另一個獨立的步驟中進行過濾。
• 較低 effort 下的效率： low 和 medium effort 能以較高設定的一小部分 token 和延遲產生強勁的品質。從預設值（high）開始，並根據您的評估進行調整：在品質維持的情況下，大量使用 low 和 medium 作為控制 token 成本和回應時間的主要手段，並在要求嚴苛的編碼和代理式工作中提升至 xhigh。如果您從先前的模型沿用了 effort 預設值，請在您自己的評估上重新執行 effort 掃描。完整建議請參閱 Effort。
• 視覺： Claude Opus 5 在圖表、文件和示意圖理解，以及 UI 和前端視覺複製方面表現強勁。請重新驗證您為先前模型調整的任何提示端視覺變通方案；它們可能不再需要。當模型擁有可以迭代分析、裁切和視覺驗證其工作的工具時，視覺效能最強，而工具使用比單純的思考是更具成本效益的手段。
• 長上下文工作： Claude Opus 5 擁有 100 萬 token 的上下文視窗，這既是預設值也是最大值，而且其指令遵循、工具呼叫和推理在整個視窗中保持一致。
• 辦公與文件任務： 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.

在較長的系統提示中，請在提示接近結尾處搭配一個簡短的提醒：

<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 比先前的模型更容易委派給子代理。委派在真正獨立、規模可觀的工作軌道上是值得的，但套用在小型任務上時會使成本和時間倍增。如果您的框架支援子代理，請提供明確的指引說明哪些情境值得委派，或對可以啟動的代理數量設定確定性的上限。例如：

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.



自我修正

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.

明確點名思考標籤的指示比一般性的形式效果更差，因此請避免具體點名它們。