隨著 Claude Opus 5 上線，Anthropic 官方近日發布開發者文件《Prompting Claude Opus 5》，整理這款模型在提示工程上的調校建議。Claude Opus 5 主打複雜的代理式程式開發與企業工作，特別適合跨多檔案功能、較大規模重構，以及需要長時間執行的任務。
隨著模型能力變強，舊有的提示習慣也需要調整。這份文件提醒開發者，Opus 5 已會主動驗證與修正產出。因此，過去常見的「完成後再檢查一次」或「交給子代理複查」不一定有幫助，反而可能增加工具呼叫與 token 用量。
Anthropic 的建議是，把提示詞用在具體規則上：回覆要多長、工作中何時更新進度、任務範圍到哪裡，以及哪些工作才需要交給子代理。《數位時代》以下整理這份文件中8個 Claude Opus 5 的提示詞調整重點供讀者參考。
（一） 別直接沿用 Opus 4.8 的設定
Anthropic 指出，和 Claude Opus 4.8 相比，Opus 5 更擅長處理複雜的程式工作，例如跨多個檔案開發功能、重構程式碼，以及找出程式中的 bug。它在較低的 effort 設定下，也能維持不錯的表現。
這代表，如果你之前為 Opus 4.8 加了很多提示規則，現在不一定要照用。例如，code review 時若要求模型「只報高嚴重度問題」，它就可能真的只列出少數問題。Anthropic 建議先讓 Opus 5 列出所有發現，再由後續流程決定哪些要處理。
Opus 5 大致能直接沿用既有的 Opus 4.8 提示詞。不過，若團隊沿用了前一代的 effort 預設值，官方建議重新比較不同設定在自身任務中的品質、成本與回應時間；過去為視覺任務加入的提示補強，也可重新確認是否仍有必要。
簡單來說，過去習慣固定使用高 effort 的團隊，也應重新測試 low、medium 是否已足夠；只有特別複雜的程式任務，再提高到 xhigh。
（二）設定回覆篇幅
Anthropic 指出，Claude Opus 5 預設給使用者看的回覆，通常比先前的 Opus 模型更長。這不代表模型想得愈多就一定說得愈多；effort 控制的是模型的思考量，不是畫面上顯示的回答長度。
因此，把 effort 從 high 調低到 medium 或 low，可能減少思考所用的 token 與回應時間，但不保證回覆會跟著縮短。若產品希望模型少寫一點，應直接在提示詞中說明篇幅與說明方式。
例如，Anthropic 建議在面向使用者、需要多輪對話的產品中加入：
回覆請保持聚焦、簡短、精煉。免責說明與注意事項請簡要帶過，主要篇幅用來回答核心問題。若使用者要求解釋，除非明確要求深入說明，否則先提供高層次摘要。
若系統提示本身很長，還可在提示詞接近結尾處加上一句簡短提醒，避免篇幅要求被前面的規則淹沒：
請讓輸出適度維持精簡。
這條規則適合客服、工作助手與產品內的聊天介面；它處理的是使用者實際看到的回答長度，不是模型在背景花多少篇幅思考。
（三） 設定任務進行中的回報規則
Opus 5 在使用工具時，傾向主動說明接下來要做什麼。這對需要透明度的工作流程有幫助，但若沒有規範，使用者可能先看到一串過程說明，最後才看見結果。
第一次使用工具前，用一句話說明接下來要做什麼。工作期間，只有在發現重要資訊或改變方向時才提供簡短更新。完成時，第一句先說明結果，再補充需要的細節。
重點不是禁止模型回報進度，而是定義回報的時機與篇幅。官方也建議，若要調整說明風格，提供你希望看到的正面範例，通常比列出一長串禁止事項更有效。
（四） 報告和文件要另外控制篇幅
除了對話回覆，Claude Opus 5 寫入檔案的報告、Markdown 文件與摘要，篇幅也可能比先前模型更長。若產品會自動產出這類文件，應另外加入長度規則，而不是只在對話提示詞中要求「簡短」。
書面文件的長度應符合任務需要：完整涵蓋必要內容，但不要用填充段落、重複摘要或制式內容湊篇幅。
這條規則處理的是交付文件的長度，不影響模型在聊天介面中的回覆篇幅。
（五） 移除重複驗證，限制任務範圍
官方指出，Opus 5 會自行驗證產出。若提示詞仍要求「每個非簡單任務都要進行最後驗證」或「另派子代理複查」，可能增加不必要的工具呼叫與 token 用量，卻不一定改善結果。
另一個問題是任務範圍擴大：模型可能加入沒有被要求的步驟，或自行改寫任務目標。對範圍明確的工作，可加入：
請依使用者要求，在原定範圍內交付成果。一般的例行判斷請自行處理；只有對需求的不同理解會導致實質不同的工作時，才向使用者確認。若你認為需求有誤，或有更好的做法，請用一句話說明，但仍依原要求繼續執行；不要自行縮小、擴大或改變任務。請完整完成任務，但不要進行明顯超出要求範圍的動作。
（六）設定子代理的啟動條件
Opus 5 能協調多個子代理，適合處理彼此獨立的大型工作，例如跨多檔案的廣泛調查。不過，小任務若也拆分處理，執行時間與成本都會增加。
只有大型、可獨立且可平行處理的工作才委派子代理。不要將可在少量工具呼叫內完成的工作外包，也不要用子代理複查自己的結果。若一個子代理能完成任務，就不要建立多個。
除了提示詞，對成本敏感的系統也應在工具層設定子代理數量上限。
（七）少加「再檢查」指令，只在必要時說明更正
Claude Opus 5 本身就會發現並修正錯誤，不需要再反覆要求它「再三確認答案」或「回覆前重新驗證」。這類指令和模型原有的檢查行為重疊，可能增加 token 用量與執行時間，品質卻不一定更好。
另一個差異是，Opus 5 比先前版本更常主動說明自己修正了前面的說法。這在內部工作流程未必是問題，但面向一般使用者的產品中，若每個小修正都另外解釋，對話容易變得冗長，也會打斷原本的工作。
若希望模型只交代重要更正，可加入：
只有當先前的錯誤會影響使用者的程式碼、結論或決策時，才更正先前的說法。更正時，請直接且簡短地說明，然後繼續完成任務。若錯誤不影響使用者，直接修正即可，不需要另外提起。
（八）不要隨便關閉thinking
Claude Opus 5 預設開啟 thinking，且只有在 high 或更低的 effort 設定下才能關閉。Anthropic 提醒，若關閉 thinking，模型偶爾會在使用者看得到的回覆中出現兩種異常輸出。
工具呼叫被寫成一般文字。
關閉 thinking 後，模型有時會把原本應以結構化格式送出的工具呼叫，直接寫進回覆文字裡。這代表工具其實沒有被執行；在多輪代理式工作中，這段文字還會留在對話紀錄裡，影響後續回合。需要頻繁使用搜尋等工具的任務，較容易出現這種情況。
回覆出現內部 XML 標籤。
模型也可能在可見回覆中輸出 <thinking> 或其他內部 XML 標籤。若系統提示裡有「不要思考」或「不要推理」等規則，建議移除，因為這類指令反而可能增加標籤外洩的機率。
官方的主要建議是：不要為了省 token 直接關閉 thinking，而是保留 thinking、改用較低的 effort 控制成本。多數任務下，開啟 thinking 的 low effort，在相近成本下通常比關閉 thinking 更穩定。
如果整合環境仍必須關閉 thinking，可加入以下規則：
使用工具前，你可以先說一句簡短說明。若沒有工具能完成使用者的要求，請直接說明，不要猜測。回覆中不得包含內部或系統 XML 標籤。
使用前提：先用自己的任務測一次
這份文件主要寫給透過 API 或系統提示整合 Claude Opus 5 的開發者。文中的規則可作為提示詞設計方向，但不代表每個產品都該原封不動套用；回覆長度、子代理數量與驗證流程，仍要看任務類型與產品介面決定，並應用實際任務重新測試。
延伸閱讀：Claude模型怎麼選？Fable、Opus、Sonnet、Haiku一表看懂，選錯可能會多花10倍成本
Graph Engineering是什麼？迴圈工程、Harness Engineering⋯5種AI工程術語差異一次看懂
資料來源：Anthropic
本文初稿為AI編撰，整理．編輯/黃若彤
