我們馴服了 Opus 5 的冗長，但一個缺陷還在

你請 Opus 5 改兩行，回來的是一篇博士論文。在 Claude Code 的 subreddit 上，一則叫「Opus 5 is insufferable」的討論串已經衝破 600 個 upvote 與 178 則留言，作者指控這個模型講一種他稱為「Unintelligiblish」的自創語言。而 Reddit 還算客氣的場合：在 X 上，有位開發者只貼了一張 Opus 5 產生的程式碼註解截圖，就收到 9,700 個讚。Claude Code 的作者 Boris Cherny 公開替模型辯護，結果最高讚的回覆是「this response is part of the problem」，2,843 個讚。

出處	訊號
r/ClaudeCode，「Opus 5 is insufferable」	600+ upvote、178 則留言
X，Opus 5 程式碼註解截圖	9,700 個讚
X，回覆 Boris Cherny 的辯護	2,843 個讚

在抱怨堆疊的同時，Anthropic 悄悄發布了一份專門給 Opus 5 的提示指南，幾乎沒人打開。於是我們做了沒人做的測試：把讓大家抓狂的行為重現一次，逐行套用指南，然後在同樣的任務上量出差距。

三個改動解釋了開發者現在遇到的大部分狀況。

thinking 預設開啟：模型在每次回答前會先在私有區塊裡推理，而且只有在 effort high 或以下才關得掉。context window 提升到一百萬 token，既是預設值也是上限。第三個改動才是冗長抱怨的關鍵：effort ——決定模型花多少 token 思考、呼叫工具、撰寫答案的參數——成為模型的中央旋鈕，共五個等級，預設是 high。

Effort	行為
Low	把工具呼叫打包，不鋪陳直接動手，一句話回報
High（預設）	呼叫次數倍增，動任何東西前先解釋計畫，逐項詳細註解改動
Extra high / Max	探索更多檔案、把邊界情況補滿；thinking 已無法關閉

如果第二列聽起來就是你的工作階段，那很正常：你從第一天起就跑在預設值上。effort 不是冗長度旋鈕——正是這個誤解塞滿了 Reddit 的討論串。

最後一點背景：Anthropic 公開表示 Opus 5 寫的答案比先前的 Opus 更長，而且會把任務做完，不留佔位。你當成 bug 的那部分，其實是白紙黑字寫下的設計選擇——而寫下來的選擇是可以重新設定的。

一個都不必去找。

冗長。 我們請 Opus 5 解釋一個函式——答案兩句話就講得完的問題——回來的是分節、小標與警告，語氣像稽核報告。Reddit 討論串最高讚的留言描述的正是這個：先來一句「我們剛剛發現了會改變一切的東西」式的宏大宣告，接著是十分鐘的 shell 指令。

過度設計。 有位使用者說他有個 7,000 行的決策檔；請 Opus 5 整理時，模型砍掉 1,200 行，然後又新增 600 行來記錄刪掉了什麼。我們在一個小功能上重現了這個模式：我們的實例加了一個沒人要求的驗證步驟，還在五行的函式上頭寫了二十行的 docstring。

範圍蔓延。 你要 X，模型判定真正的主題是 Y，然後用八段解釋為什麼。

被埋起來的壞消息。 有位留言者描述一整面牆的文字說一切順利，而在四分之三處藏著一個星號，承認有東西壞了。我們也遇到了：我們的實例宣告遷移成功，而承認整合測試還沒修好的那一行在第七段。

怒火是真的，而且隨叫隨到。剩下的問題是：能不能調。

指南叫做 Prompting Claude Opus 5，就在 Anthropic 的文件裡，而且逐點回應了那則 Reddit 討論串。它最重要的一句話只有一行：effort 控制的是模型想多少，不是講多少。 調低 effort 會縮減思考量，但不會可靠地縮短看得見的答案——所以所有為了讓模型閉嘴而調低 effort 的人，都拉錯了拉桿。

關於長度，指南講得很明白：用白話要求，在 system prompt 裡放一條簡潔指令。而且它說了一件沒人預期 Anthropic 會說的話：你得從提示裡刪掉指令。如果你的指令檔寫著「回答前先驗證你的工作」，把那行刪了：Opus 5 本來就會自我檢查，這種句子只會觸發額外的驗證回合，等於白燒 token。Boris Cherny 用一句話總結：Opus 5 需要的是更少的提示，不是更多。

指南其餘部分有條理地處理其他抱怨——一節談 agent 敘述、一節談產生檔案的長度、一節談範圍框定、一節談 subagent、一節談自我修正——而且每一節給的是可以直接複製的提示區塊，不是含糊的建議。

effort sweep 就是把同一個任務在每個 effort 等級各跑一次，比較 token、時間與品質。指南建議，如果你沿用舊模型的設定就重做一次。實際上就是四次執行加一次比較。

在 Claude Code 裡，effort 有三種設法：工作階段內的指令、啟動時的旗標，或設定檔裡的鍵值——最後這個能在各個 repo 需求不同時，給你不同的專案預設值。

我們把同一個 bug 修正分別以 low、medium、high、extra high 跑過，共四個乾淨的工作階段。

等級	在我們基準 bug 修正上的結果
Low / Medium	用 high 的一小部分 token 得到同等的修正
High	預設值；在一行的 bug 上沒有任何品質增益
Extra high	探索更多檔案、補滿邊界情況——大型重構有用，這裡是殺雞用牛刀

這正好對應指南所說的：把較低的等級當成主要成本控制手段，放心用。在你把它寫成腳本前，有個 API 細節要知道：在 extra high 與 max，thinking 已經無法關閉，硬要關的話請求會回 400 錯誤。

sweep 最划算的用途是 code review。Anthropic 宣稱 Opus 5 的 review 準確度在較低 effort 等級仍能維持，於是可以在 commit 時跑一次又快又便宜的檢查，之後再跑一次深入的。我們拿自己的一個 diff 測了：low 這一輪找到的兩個真 bug，和 extra high 那一輪找到的完全一樣，token 大約只用了五分之一。

所以第一個會改變你帳單的設定，是依任務型態選 effort，而不是全部停在預設值——日常工作與 review 用 low 或 medium，大工程用 extra high。至於冗長，一個字都沒少。

既然 effort 不會縮短答案，長度就由指令決定——而你把指令放在哪裡，和你怎麼寫一樣關鍵。Claude Code subreddit 上另一位使用者花了好幾天測試，他的第一個發現和我們一致：內建的 Concise 輸出風格只把輸出砍掉大約 6%。真正有效的，是把一條實際的簡潔指令放進 output style 這個位置，而且只放這裡——同樣一句話放在 hook，或當成指令檔裡的規則，什麼都沒改變。

output style 是 Claude Code 裡定義助理「怎麼寫」而非「知道什麼」的位置。我們的版本是照官方指南的措辭寫的：簡短、聚焦的答案，減少警告，除非被要求細節，否則給高層次摘要。

簡潔規則放在哪裡	對長度的影響
內建 Concise 預設	短約 6%
hook 或指令檔裡的規則	沒有可量測的變化
output style 位置	五節的報告 → 一段文字加一份檔案清單

指南另外給了兩條同系列的指令，我們原樣照抄：一條給 agent 敘述，框定模型什麼時候可以評論自己在做什麼；一條給寫進磁碟的檔案，因為產生的報告與 Markdown 檔同樣會膨脹。

至於那些永遠不會生效的規則，同一篇 Reddit 貼文給了判準：規則必須指名一個可辨識的時機和一個具體動作。「保持 changelog 更新」永遠不會生效。「當你修改原始碼資料夾裡的檔案時，在同一個 commit 為 changelog 加一行」就會。

還有一個口頭禪是這些區塊涵蓋不到的：被講出來的自我修正。Opus 5 很愛宣告自己正在修正前一句話，就算那個修正對你毫無影響也一樣，而指南有專門的指令處理它：只有當錯誤會改變你的程式碼或決策時才標示修正，其餘安靜地改掉。自從這行進了我們的設定，假道歉就從工作階段裡消失了。

所以冗長確實馴得住，只是靠的不是開關：是四個放對位置的提示區塊。

第二項抱怨靠減字解決，不是加字。我們先照指南的命令，把提示裡所有驗證要求清光，額外的驗證迴圈也跟著消失。

接著是範圍。指南提供一段框定指令，我們原樣貼上：按照原本設想的範圍交付被要求的東西；若有更好的做法，用一句話指出；繼續做被要求的任務，而不是悄悄把它換成別的。在那個引發二十行 docstring 的功能上，我們帶著這段框定重播完全相同的請求：diff 從動到九個檔案降到三個，也沒有寄生的驗證步驟。

同一家族的兩個設定各值一行。做 code review 時，別再寫「只回報嚴重問題」：Opus 5 會照字面理解而少報，所以要它全部列出，再用第二輪過濾。而如果模型動不動就開 subagent，這也寫在文件裡：Opus 5 比前代更樂於委派，而每個 subagent 都會讓成本倍增。指南給了一條指令，把委派保留給真正能平行處理的大工作；從 2.1.217 版起，Claude Code 也提供兩個環境變數，硬性限制 spawn 深度與同時執行的 agent 數。

上限	預設
subagent spawn 深度	3 層
同時執行的 agent	20

這些預設值解釋了一個工作階段怎麼能在完全沒問你意見的情況下擴散到那種程度。過度設計不是模型的宿命：多半是你的舊提示反過來對付你。

界線很銳利：指南修的是 Opus 5 說什麼的形狀，不是它決定去做什麼。討論串裡有部分怒吼描述的並不是冗長，而是另一件事：模型承認了一項明確限制、答應遵守，然後從第一輪就反著做。這項抱怨在指南裡沒有對應章節，我們的提示區塊也沒有一個能讓它消失。測試期間我們遇過一次：一個「不要動這個 API」的明確限制，在回答中被承認，兩輪之後被繞過。一週的工作階段裡出現一次，離某些怒吼描述的翻船還很遠，但當它落在正式環境的程式碼上時，這種錯誤沒有任何設定能開脫。

也得算進入成本。sweep 會燒掉真實的 token：我們四個測試工作階段吃掉的量，相當於 20 美元方案上一個滿檔工作天；討論串裡有位使用者表示，最大的 max 方案在 effort high 下也撐不過一個週末。而且這些設定都不可攜——output style、範圍框定、subagent 上限全都住在你的設定裡，所以每台機器、每個專案都得重調一次。

如果你的痛點是吵，指南治得好。如果你的痛點是一個為所欲為的模型，指南救不了你——而那則討論串裡，除了怒吼本文之外最高讚的留言，至今仍是「回去用上一代 Opus」。

對我們來說二十分鐘的設定就夠了：依任務型態而非預設值選 effort、在 output style 位置放一條簡潔指令、把指南的範圍框定放進 system prompt，以及從舊檔案裡刪掉那些驗證要求。

基準任務上的指標	之前	之後
回答長度	五節的報告	約短 5 倍，一段文字＋檔案清單
diff 大小	動到 9 個檔案	動到 3 個檔案
code review 成本	extra high 那輪	約 1/5 的 token，同樣兩個真 bug

沒換模型，也沒換方案。如果你的抱怨是冗長與過度設計，換模型之前先跑這套調校——全都有文件，而且從第一個 diff 就看得出差距。但如果你的問題是一個從第一輪就無視你限制的模型，指南裡沒有任何提示修得好：把敏感任務留在會聽話的模型上，等下次更新再回來測 Opus 5。