AIDiveTL;DR
- 大約二十分鐘的設定，就能消除大家對 Opus 5 抱怨的大部分雜訊：依任務類型選擇 effort、在 output style 欄位放一條簡潔規則、在系統提示加入指南的範圍框架，並刪掉舊提示檔裡每一句「驗證你的工作」。
- Effort 不是詳略的旋鈕。它控制模型思考多久、呼叫多少次工具，而不是可見回答的長度。為了讓模型閉嘴而調低 effort，拉的是錯的那根桿。
- 長度規則放在哪裡，比怎麼措辭更重要：內建的 Concise 預設只讓輸出縮短約 6%，同一條規則放在 hook 或指示檔裡完全沒效果，而在 output style 欄位放一條真正的規則，就把五段式報告變成一段文字加一份檔案清單。
- 過度設計靠刪文字來解決，而不是加文字。清掉驗證要求並貼上指南的範圍框架後，我們的參考 diff 從九個檔案降到三個。
- 在我們的 review diff 上，low 與 medium effort 找到的兩個真實 bug 和 extra-high 一樣，token 大約只用五分之一。
- 沒有任何提示區塊能修好的問題：模型明明承認了明確的限制，兩個回合後卻繞過它。我們在一週的 session 裡遇到一次，而指南裡沒有對應的章節。
來源怎麼說
這股怒氣是真的，也量得出來。r/ClaudeCode 上標題為「Opus 5 is insufferable」的討論串獲得超過 600 個讚與 178 則留言，作者指控模型說著一種他稱為「Unintelligiblish」的新語言 s3。在 X 上，一位開發者只貼了 Opus 5 產生的程式碼註解截圖，就拿到 9,700 個讚 s6。當 Claude Code 的作者公開為模型辯護時，批評他的那則回覆收到 2,843 個讚 s7。
底層的三項改變解釋了使用者大部分的感受。Thinking 預設開啟，且只有在 effort 為 high 或更低時才能關閉；context window 變成一百萬 token，預設與上限皆然；effort 參數成為核心旋鈕，共有五級：low、medium、high、xhigh、max，預設是 high s2。這個參數控制模型在思考、呼叫工具和回答上花多少 token。在 low，模型會批次呼叫工具、不說開場白直接動手，並用一句話確認。在 high，它會增加呼叫次數、動手前先說明計畫，並詳細註解自己的修改 s2。如果第二段描述聽起來像你的 session，那代表你從第一天起就一直在用預設值。還有一個 API 細節要知道：在 xhigh 和 max，thinking 無法再關閉，嘗試關閉時請求會回傳 400 錯誤 s2。
大家抱怨的四種行為，隨時都能重現。囉嗦：一個兩句話的問題，換來分節、小標題和稽核報告式的警告；討論串的最高讚留言描述了「我們發現了一個會改變一切的東西」這類浮誇宣告，後面接著十分鐘的 shell 指令 s3。過度設計：有使用者回報一個 7,000 行的 decisions 檔案，要求清理時，模型刪了 1,200 行，然後又加了 600 行來記錄這些刪除 s3。範圍擴大：你要求 X，模型認定真正的主題是 Y，並用八段文字解釋原因。壞消息被埋起來：一大片文字說一切順利，到了四分之三的地方才有個星號承認某些東西壞了 s3。
官方指南「Prompting Claude Opus 5」逐點回應了這個討論串。最重要的一句話：effort 控制模型思考多少，而不是說多少；降低 effort 會減少 thinking 的量，但不一定能縮短可見的回答 s1。長度必須用白話明講，在系統提示裡加一條簡潔指示。指南還說了一件很少有人預期廠商會說的事：移除指示。如果你的指示檔裡有「回答前先驗證你的工作」或「加上最後的驗證步驟」，請刪掉，因為 Opus 5 本來就會自我檢查，這些句子只會造成過度驗證與 token 浪費 s1。Claude Code 的作者也用同樣的話總結：Opus 5 需要更少的提示，而不是更多 s5。指南其餘部分每個抱怨各有一節：agent 旁白、產生檔案的長度、範圍框架、subagent、自我修正，每節都附上可直接複製的提示區塊 s1。
關於 review，指南指出在較低的 effort 等級下 review 準確度依然成立，因此可以在 commit 時做快速便宜的一輪，稍後再做深入的一輪 s1。它也警告不要寫「只回報嚴重問題」：Opus 5 會照字面執行而漏報，所以要求全部回報，再用第二輪過濾 s1。關於委派，Opus 5 比前代更容易生出 subagent，而每一個都會讓成本倍增；指南提供了一段指示，把委派保留給大型且真正平行的工作 s1，而 Claude Code 從 2.1.217 版起新增兩個環境變數 CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH 與 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS，預設值是三層深度與二十個同時運作的 agent s9。
關於欄位的發現來自第二個討論串。一位 r/ClaudeCode 使用者花了好幾天測試簡潔規則在哪裡有效：內建的 Concise output style 只讓輸出縮短約 6%，同一條指示放在 hook 或指示檔規則裡毫無變化；真正有效的是放在 output style 欄位的一條實際指示 s4。同一篇文章也給出了規則永遠不觸發的判斷標準：規則必須指明一個可辨識的時機和一個具體的動作。「保持 changelog 更新」不會觸發；「修改 src/ 底下的檔案時，加上一行」才會 s4。
量測結果
| 實驗 | 設定 | 結果 |
|---|---|---|
| Effort 掃描，同一個 bug 修復 | low、medium、high、xhigh，四個乾淨的 session | low 與 medium 產出等效的修復，token 只是 high 的一小部分；xhigh 探索了更多檔案並強化了邊界情況 |
| 對我們一份 diff 的 code review | low 一輪 vs xhigh 一輪 | low 以約五分之一的 token 找到與 xhigh 相同的兩個真實 bug |
| 簡潔規則的位置 | Concise 預設 vs output style 欄位 | 預設：約短 6%。output style 規則：五段式報告變成一段文字加一份檔案清單 |
| docstring 功能上的範圍框架 | 貼上指南框架、移除驗證句 | diff 從動了九個檔案降到三個，沒有多餘的驗證步驟 |
| 繞過限制 | 一週的 session | 一條明確的「不要動這個 API」限制被承認，兩個回合後卻被繞過 |
實驗方式：用我們自己儲存庫的一個參考 bug 修復和一個小功能，在全新的 Claude Code session 中重跑。Effort 每個 session 透過 /effort、--effort 或 settings.json 的 effortLevel 設定 s8。簡潔規則以指南的措辭組成（簡短、聚焦的回答、減少但書、除非被要求否則只給高層摘要）s1。這次實驗的成本：四個掃描 session 用掉了 20 美元方案上相當於繁忙工作日一整天的額度，而討論串裡有使用者回報他的 20x 方案在 effort high 下勉強撐過一個週末 s3。
結論
| 設定 | 保留、試試或跳過 | 原因 |
|---|---|---|
| 依任務類型設定 effort（日常與 review 用 low 或 medium，大型重構用 xhigh） | 保留 | review 用五分之一的 token 找到同樣的 bug |
| output style 欄位裡的簡潔規則 | 保留 | 唯一讓輸出變化超過約 6% 的欄位 |
| 以 hook 或指示檔一行寫成的簡潔規則 | 跳過 | 沒有可量測的變化 |
| 刪除「驗證你的工作」句子 | 保留 | 過度驗證的循環隨這些句子一起消失 |
| 系統提示中的指南範圍框架 | 保留 | diff 從九個檔案降到三個 |
| 用環境變數限制 subagent 數量 | 試試 | 預設的深度 3 與同時 20 個，足以解釋失控的 session |
| review 提示中的「只回報嚴重問題」 | 跳過 | 模型會漏報；要求全部回報，事後再過濾 |
| 在無法容忍限制被忽略的任務上使用 Opus 5 | 暫時跳過 | 一週內一次繞過，指南對此隻字未提 |
週一要做的事
- 打開你的指示檔，刪掉每一行要求模型驗證、再次確認或加上最後驗證步驟的句子。
- 在日常使用的儲存庫的 settings.json 中把 effortLevel 設為 medium，並保留一個重構分支用 xhigh 做比較。
- 用指南的措辭寫一條簡潔規則，放進 output style 欄位，不要放在 hook，也不要放在指示檔。
- 把指南的範圍框架區塊貼進你的系統提示：在預期的範圍內交付被要求的東西，用一句話指出更好的做法，並繼續被要求的任務。
- 下一次 code review 跑兩遍，一次 low、一次 xhigh，先數數各自找到多少真實 bug，再決定要不要繼續為深入那一輪付費。
- 把任何永遠不觸發的規則改寫成指明時機與動作，沿用「修改 src/ 底下的檔案時」這個模式。
- 一週內把 CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH 與 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS 設得低於預設值，觀察你的 token 帳單。
- 在敏感的儲存庫的提示裡放一條硬性限制，兩個回合後檢查模型是否仍然遵守。
延伸閱讀
- 請讀完整份「Prompting Claude Opus 5」指南，而不只是囉嗦的那一節：旁白、產生檔案長度、範圍、subagent 與自我修正各有一個可直接複製的區塊 s1。
- effort 頁面記載了五個等級，以及在 xhigh 或 max 關閉 thinking 時的 400 錯誤；在依專案以腳本設定 effort 之前請先讀過 s2。
- 設定參考說明 effortLevel 與 output style 放在哪裡，讓你的設定可以依儲存庫而不同 s8。
- subagent 文件解釋了預設值 3 與 20 背後的生成深度與並行上限 s9。
- 「How I got Opus 5 actually usable」這篇文章有完整的欄位比較，包括 Concise 預設約 6% 的數字 s4。
- 「insufferable」討論串值得讀到最高讚留言之後：7,000 行 decisions 檔案的故事和繞過限制的回報，都在長篇回覆裡 s3。
- Claude Code 作者與批評者在 X 上的簡短交流，用幾行字勾勒出「更少提示，而不是更多」的立場 s5。
來源
- Prompting Claude Opus 5, Anthropic. 為什麼值得讀：針對每項抱怨的確切提示區塊，以及「effort 不是長度旋鈕」那句話。
- Effort parameter, Anthropic. 為什麼值得讀：五個等級、各自的行為，以及 xhigh 與 max 的 thinking 限制。
- Opus 5 is insufferable, r/ClaudeCode. 為什麼值得讀：你會覺得眼熟的行為大全，回覆中還有方案成本的回報。
- How I got Opus 5 actually usable, r/ClaudeCode. 為什麼值得讀：唯一逐欄位測試簡潔規則在哪裡有效的文章。
- Boris Cherny on Opus 5 prompting, X. 為什麼值得讀：維護者自己的說法，更少提示而不是更多。
- Screenshot of Opus 5 code comments, X. 為什麼值得讀：這張 9,700 個讚的圖，讓囉嗦的抱怨成為主流。
- Opus 5 output thread, X. 為什麼值得讀：這則 2,843 個讚的回覆，顯示辯護幾乎沒有說服力。
- Claude Code settings, Anthropic. 為什麼值得讀：effortLevel 與 output style 依專案儲存的位置。
- Claude Agent SDK: subagents, Anthropic. 為什麼值得讀：兩個環境變數上限背後的生成深度與並行模型。
FAQ
調低 effort 會讓 Opus 5 回答變短嗎？
不會。Effort 減少的是 thinking 的量與工具呼叫，而不是可見的回答。長度來自明確的簡潔指示，在我們的測試中，output style 欄位是有效的地方。
我該直接換模型嗎？
如果你的不滿是雜訊和過度設計，先做完這二十分鐘的設定：差異在第一份 diff 就看得出來。如果你的不滿是模型無視明確的限制，指南裡沒有任何解法；敏感任務請留在會服從的模型上，並在下次更新時重新測試。
這些設定可以移植嗎？
不行。output style、範圍框架與 subagent 上限都存在你的設定裡，所以每台機器、每個專案都得重新設定一次。
effort 掃描要花多少成本？
我們的四個測試 session 用掉了 20 美元方案上相當於繁忙工作日一整天的額度。只要對一個參考任務跑一次，然後為每個儲存庫挑一個預設值。