解決 Claude Opus 5 思維淺層化的方案

概述

將 Claude Code 切換到 Opus 5 後，我立刻注意到兩個問題：回應中大量出現冗長散文，以及一種「淺層思考」傾向（無法進行結構性思考）。

調查後發現，問題並非模型本身變差或規則有誤，而是 Claude 5 世代提供給 Opus 5 的內部系統提示已大幅改變，而舊規則並未針對這個新前提撰寫。

本文記錄了隔離原因並重新修改規則以適應新系統提示的過程。適用對象為升級至新一代模型後，感覺 CLAUDE.md 或既有規則效果變差的 Claude Code 使用者。

問題

使用相同的對話與相同的規則，切換至 Opus 5 後立刻出現以下現象：

• 情境說明變得平淡，缺乏標題或章節，呈現長篇散文。
• 原因解釋停留在單一層級（平行列出症狀，沒有深入挖掘「為什麼」）。
• 提出多個選項時，未提供評估標準。
• 前一輪建立的類別或編號，在下一輪被重新排列成不同結構。
• 模型跳過回應我的輸入，直接執行工具（任務）。

最令人沮喪的是，即使要求它「再深入思考」，它也只會給出零散的回答，仍處於淺層思考狀態。反覆修正也無法觸發改變，反而導致爭論而非有效討論。

這不只是單一回應品質的問題，而是透過對話進行深思熟慮的過程本身已經崩潰。

關鍵線索

使用相同規則的其他模型並未出現此問題（差異詳見附錄）。如果規則本身已劣化，問題應該在所有模型上都出現。既然只有模型改變，我開始假設「規則所預設的環境」已經改變，並據此進行調查。

原因：提供給 Opus 5 的系統提示變更

在 Claude Code 的 Claude 5 世代中，內部系統提示相比前幾代減少了約 80%。透過測量實際傳送給 Opus 5 的提示（關閉輸出風格注入，讓模型引用自己的提示；Claude Code v2.1 系列，2026 年 7 月），其結構如下：

1. 身份、角色宣示與安全政策 — 開場前言。
2. Harness 規格（# Harness）— 執行環境的說明，例如輸出以 Markdown 顯示。
3. 環境資訊與功能描述（# Session-specific guidance / # Memory / # Environment / # Context management）— CWD、git 狀態、模型 ID、記憶體與上下文壓縮機制。
4. 範圍紀律（# Delivering work）— 未經許可不得縮小或擴大要求的範圍。
5. 修正禮儀（# Corrections）— 保持修正簡潔，不加入道歉或前言。

兩個具體特徵直接與症狀相關：

• 特徵 1：完全沒有關於回應風格的指示。 沒有關於散文 vs 結構、使用標題或表格、簡潔性的規則——前幾代中大量的格式規則已完全消失。
• 特徵 2：新增了「先行動」自主政策。 原文為：「當你有足夠資訊可以行動時，就行動。」以及「如果你在權衡選擇，請給出建議，而非詳盡調查。」

重新審視這些特徵與症狀的對應關係，一切就說得通了。由於沒有風格規則，模型的原始輸出傾向——平淡的散文——便浮現出來。「建議優先於調查」的政策則鼓勵省略評估標準。

你可能會想：「如果規則空白，那我的自訂規則不就成為唯一權威，效果應該更好？」實際上正好相反。這片空白並非留給使用者的空間，而是 交由模型在訓練時內化的預設行為來填補。 「精簡提示」假設新一代模型無需詳細指示就能遵循內化行為。這片空白不會被你的規則填滿，而是被模型預先訓練的預設值填滿。而 Opus 5 的預設就是簡潔的散文，並在確認前就行動。

我的舊規則使用了一般性指示，例如「結構化地分析情境」、「為多個選項加入評估標準」、「先回應再行動」。這些規則當初是在假設它們會與風格豐富的系統提示一起被閱讀的情況下撰寫的。雖然當時足夠，但無論在針對性（指名原文）還是傳遞方式（在行動前傳達給模型）上都太弱，無法覆蓋訓練好的預設值。這就是症狀的本質。

Anthropic 本身在變更日誌（v2.1.154）中將此縮減稱為「精簡系統提示」，反映了設計哲學的轉變：「新一代模型已透過訓練內化行為，因此詳細指示可能會造成摩擦或矛盾。」詳細說明請參閱 Claude Code 系統提示減少 80% — Fable 5 世代的提示設計哲學。原始資料請參考 Claude Code 變更日誌 與 Prompting Claude Fable 5（官方指南）。

簡而言之，症狀由「規則 × 實際傳送給該模型的提示」的組合決定。只看規則是找不到原因的。第一個教訓是：模型更新同時也是系統提示更新。

措施 1：找出矛盾並透過指名原文來覆蓋

首先，我將所有規則與新的系統提示進行交叉比對，找出哪些地方說了相反的話。對於旨在覆蓋系統政策的規則，我將其改寫為 明確引用原文並宣告優先順序。

先說說沒有效的方法：加入「撰寫多個選項並附帶評估標準」這類一般性陳述是無效的。

當它與系統的「給出建議，而非詳盡調查」並列時，沒有線索顯示哪個優先。透過指名衝突，優先順序就清楚了。

對於提示中完全沒有的東西，例如風格規則，指示的作用是「填補空白」，而非覆蓋。

我也修改了觸發條件的寫法。像「對於重要變更」或「如果判斷為生產環境」這類條件，一旦模型不這樣分類情境就會失敗。我將觸發條件改為可觀察的事實，例如「收到中斷」或「使用者的話語包含修正」。

措施 2：描述期望的行為，而非禁止事項

舊規則是「禁止事項」的堆積。禁止有助於偵測違規，但沒有傳達該做什麼。當禁止與新的系統政策衝突時，模型會找到漏洞：「在避免禁止的同時遵循系統政策」。我將負面限制轉換為期望行為的描述。

• 修改前：「如果測試未完成，不要建議提交。」
• 修改後：「建議提交時，請在主體文字中包含從終端使用者角度執行產品的結果。」

我根據以下標準檢查改寫後的規則，特別注意與系統提示衝突的表達：

1. 規則是否自包含？（範圍、範例與標準集中在一處）
2. 觸發條件是否為可觀察的事實？
3. 是否與內部系統提示矛盾？
4. 是否描述期望行為？（不只是禁止清單）
5. 判斷標準是否只有一個？（不是情境清單）
6. 強調標記（IMPORTANT）是否只用於真正不能省略的事項？
7. 是否以期望的最終狀態撰寫？（不是強制模板或步驟優先）
8. 事後能否判斷是否遵守？

我將強調標記（IMPORTANT）縮減到僅用於安全與核准關卡。一份文件如果什麼都強調，就跟什麼都沒強調一樣。

措施 3：選擇傳遞指示的「層級」

問題不僅在於文字本身。Claude Code 至少有四條路徑可以將指示傳遞給模型，而且它們的效果差異很大。

由於 API 是無狀態的，所有路徑的內容都會 在每次請求（每輪對話）時傳送給模型。 差異在於「內容何時被確定」以及「在提示中的位置 = 離正在進行的行動有多近」。

令人驚訝的是，根據文件說明「取代系統提示」的 output style，根據對話記錄顯示，在每一輪中都是以附件形式傳遞。

我在這個 output style 中寫了兩類指示：風格（措施 1：結構化寫作，加入標準）與 流程（先回應使用者再開始工作）。結果好壞參半。

風格指示有所改善，但流程問題——跳過回應直接開始工作——並未透過 output style 解決。我最終透過使用 UserPromptSubmit 鉤子在每次使用者發言後立即注入一行文字來阻止這個習慣：「在執行工具之前，請在主體文字中撰寫對這段話語的回應（回答，或確認與計劃）。」

成本約為每次發言 50 個 token。即使 100 次發言也只花費 5,000 個 token，相對於 200K 上下文來說微不足道。我學到的一般規則很簡單：「簡短、每次、在行動前立即」傳遞的指示效果最好。 許多無效的指示不是內容不好，而是它們在行動當下不在手邊。

結果

以下是目前確認的結果：

• 情境與因果說明中出現了標題/章節的趨勢。（不過，對話初期有時仍會出現平淡輸出；需要持續觀察。）
• 「不回應就工作」的習慣無法單靠 output style 修正，但在引入每次發言注入後停止了（目前正在觀察長期效果）。

總結

• 模型更新同時也是系統提示更新。 如果回應趨勢突然改變，請先閱讀系統端的變更，再新增規則。
• 與系統政策競爭的規則必須指名原文並宣告優先順序。 一般性補充在面對矛盾時會失敗。
• 觸發條件應基於觀察，並描述期望行為而非禁止。 自我分類的觸發條件與禁止清單在模型變更時容易失敗。
• 為指示選擇正確的層級。 在行動前簡短且頻繁注入的指示，遠比放在上下文開頭的大型規則可靠。

參考 1：措施 1 中實際使用的規則

以下是我用來覆蓋系統提示的規則摘錄（請根據你的環境調整；我將這些放在 output style 中）。某些原始用語（例如散文政策）在特定模型的提示中不存在（見附錄）。在那些模型中，它們扮演填補空白的定義角色。

1# 報告與分解格式
2
3本指令優先於 Claude Code 系統提示中的以下描述：
4「簡單的問題得到散文式的直接回答，而非標題與章節」/
5「僅對短的可列舉事實使用表格」/
6「不要讓讀者交叉參考你之前發明的標籤或編號」/
7「如果你在權衡選擇，請給出建議，而非詳盡調查」/
8「你正在自主運作...無需詢問即可繼續」/
9「你在工具呼叫之間寫的文字可能不會顯示給使用者」
10
11## 寫作風格
12
13在解釋情境、原因或提出多個選項時，請以能傳達內容結構的方式寫作。根據內容適當使用標題、項目符號或表格。對於一句話的問題，以散文回答。
14
15- 先總結想法，最後再進行結構化。不要先放模板再填入內容。
16- 解釋原因時，從觀察到的事件至少追溯兩層「為什麼」，並描述每一層所指涉的內容。不要停留在平行列出症狀。
17- 提出多個選項時，先寫出建議與理由，然後是影響決策的標準以及每個選項的評估。如果無法確定標準，就不要提供選項；而是寫出需要調查哪些事項來填補標準。標準的比較可以用表格撰寫。
18- 一旦建立類別與編號，在執行相同任務的後續輪次中應使用相同編號。如果需要變更，請先寫出變更了什麼。
19
20## 對話與流程
21
22- 系統的「使用者並非即時觀看」是預設值，而非事實。如果在這個對話中至少收到一次中轉發言、中斷或修正，請從那時起將使用者視為正在觀看：將工作分解為小區塊，每輪結束時務必在主體文字中報告，並在提出問題的輪次中停下來等待回應。
23- 在這個環境中，只有輪次結束時的主體文字會被顯示。請將所有要傳達的資訊放在輪次結尾。
24- 當有模糊之處、需要核准的操作或目標不明確時，提問是正當的手段。

參考 2：為什麼 Fable 5 / Opus 4.7 沒有出現此問題？

本文主要討論 Opus 5，以下是其他模型未出現問題的原因：

• Opus 4.7 很簡單：它被排除在「精簡提示」的應用之外（根據變更日誌），因此仍使用舊規則所設計的長篇舊提示。它與舊規則保持同步。
• Fable 5 則是意外發現。我原本假設由於同屬一個世代，它應該有相同的提示，但測量結果顯示 Fable 5 獲得的提示與 Opus 5 不同。

以下是在相同條件下（無頭模式，關閉輸出風格）各模型引用自己提示的比較：

Fable 5 的 # Communicating with the user 章節包含了規範，例如「結論優先，優先考慮可讀性，為讀者寫作」。除了「給出建議，而非詳盡調查」之外，它還包含了散文政策「簡單的問題得到散文式的直接回答，而非標題與章節」。由於提示本身包含了這些寫作規範，輸出格式較不容易崩潰，而且根據我的觀察，它保持了對使用者規則的遵循。

總結來說，問題在 Opus 5 上特別嚴重，是因為三個因素同時發生：

1. 它獲得了完全沒有寫作風格規則的提示，暴露了原始輸出傾向。
2. 諸如「資訊足夠時就行動」和「建議優先於調查」等政策鼓勵立即行動與省略標準。
3. 舊規則仍基於舊的詳細提示，並未塑形來填補這個新的空白。