Claude Opus 4.7 並非 4.6 的直接替代品
AI 語音朗讀 · Edge TTS
Claude Opus 4.7 並非 4.6 的直接替代品
全新的 xhigh 努力程度（effort level）、自適應思考（adaptive thinking）以及 1M context window，改變了你使用 Claude 最強模型時的 Prompt 撰寫、任務委派與工作階段管理方式。
你剛剛升級到了 Claude Opus 4.7。你的 Prompt 還是一樣，你的 harness 也還是一樣。
但你的 token 帳單翻倍了，而且程式碼審查的召回率（recall）卻下降了。發生了什麼事？
Opus 4.7 並非 Opus 4.6 的直接替代品。它的思考方式不同、指令遵循更為字面化、產生的子 Agent 更少，並且在使用者每次輸入後會進行更積極的推理。
過去有效的模式，現在只會讓你消耗更多 token，卻沒有帶來相應的品質提升。解決方法並不複雜，但你需要理解其中的變化，並據此調整你的工作流程。
讓我們來看看具體該怎麼做。
委派思維（The Delegation Mindset）
Opus 4.7 帶來的最大轉變在於你如何定義自己的角色。請將 Claude 視為一位你可以委派任務的資深工程師，而不是一個你需要逐行指導的結對程式設計師（pair programmer）。
在互動式工作階段中，使用者的每一次輸入都會觸發推理開銷。在 4.6 版本中，你可以將指令分散在多個回合中，而不會有太大的代價。
但在 4.7 版本中，這種模式會導致 token 用量暴增，因為模型在你發送的每則訊息後都會進行深度推理。無論該回合是否需要，你都必須為每一次的推理付費。
三個具體的改變可以解決這個問題：
首先，在第一回合就明確指定任務。包含意圖、限制條件、驗收標準以及相關的檔案路徑。分散在多個回合的模糊 Prompt 會同時降低 token 效率與輸出品質。
其次，批次處理你的問題。每一則使用者訊息都會增加推理開銷，因此請給予模型足夠的 context，讓它能持續運作而無需頻繁確認。
第三，對受信任的任務使用 auto mode。對於已經提供完整 context 的長期任務，auto mode (Shift+Tab) 可以透過減少不必要的確認來縮短週期時間。此功能目前在 Claude Code Max 使用者的研究預覽版中提供。
你也可以要求 Claude 在完成任務時播放音效。它會建立自己的 hook 基礎通知，這樣你就不用盯著它工作了。
五種努力程度，以及為什麼 xhigh 是新的預設值
Opus 4.7 引入了 xhigh，這是介於 high 與 max 之間的新努力程度。現在它已成為 Claude Code 的預設值。
如果你是從未手動設定過努力程度的現有使用者，你已經被自動升級為 xhigh。
以下是五個等級的區分：
low：適用於對延遲敏感、範圍嚴格受限的工作。模型不會過度發揮，但在相同的努力程度下，其表現仍優於 Opus 4.6。
medium：適用於對成本敏感的任務，你願意用智慧換取速度。
high：平衡了智慧與成本。對於並行工作階段或預算有限且品質要求不會大幅下降的工作來說，這是一個不錯的選擇。
xhigh：這是預設值，也是程式撰寫與 Agent 任務的最佳甜蜜點。你可以在不產生 max 等級那種失控的 token 用量的情況下，獲得強大的自主性與智慧。
max：在真正困難的問題上能榨出額外的效能，但邊際效益遞減。它更容易過度思考，因此請謹慎使用，僅在評估上限測試或極度依賴智慧的工作中使用。
一個實用的小技巧：你可以在任務進行中切換努力程度。在複雜的設計階段從 xhigh 開始，在簡單的實作階段降至 high，並在棘手的除錯階段調高至 max。這能讓你精細地控制 token 的花費。
Opus 4.7 比 4.6 更嚴格地遵守努力程度設定，所以如果某個在 low 或 medium 等級下的任務感覺思考不足，請直接提高努力程度，而不是試圖透過 Prompt 來繞過它。
自適應思考取代了固定預算
如果你之前在 Opus 4.6 上使用帶有 budget_tokens 的 Extended Thinking，現在已經沒有了。Opus 4.7 改為使用自適應思考（adaptive thinking）。
這兩者的差異很重要。在固定預算下，你預先分配了固定數量的思考 token，無論模型是否需要，它都會使用這些 token。
而在自適應思考中，模型會在每個步驟自行決定何時思考以及思考多少。
簡單的查詢會得到快速回應，複雜的推理步驟會進行深度思考，而那些從思考中獲益甚微的步驟則會完全跳過。
在長期的 Agent 執行過程中，與一刀切的思考預算相比，這能帶來更快速的回應與更低的 token 用量。
遷移過程很簡單：
# 之前 (Opus 4.6 使用 extended thinking)
client.messages.create(
model="claude-opus-4-6",
max_tokens=64000,
thinking={"type": "enabled", "budget_tokens": 32000},
messages=[{"role": "user", "content": "..."}],
)
# 之後 (Opus 4.7 使用 adaptive thinking)
client.messages.create(
model="claude-opus-4-7",
max_tokens=64000,
thinking={"type": "adaptive"},
output_config={"effort": "xhigh"},
messages=[{"role": "user", "content": "..."}],
)
你仍然可以透過 Prompt 來引導思考率。若要獲得更多思考，請嘗試：「在回應前請仔細且逐步地思考；這個問題看起來比想像中更難。」
若要減少思考，請使用：「優先考慮快速回應，而不是深度思考。有疑問時，請直接回應。」
如果你在 max 或 xhigh 的努力程度下執行，請設定較大的最大輸出 token 預算（從 64k 開始），這樣模型才有足夠的空間在子 Agent 和工具呼叫之間進行思考與行動。
會讓你吃虧的行為改變
Opus 4.7 附帶了幾個預設的行為改變，如果你已經針對 4.6 調整過 Prompt 或 harness，這些改變會讓你措手不及。讓我們逐一檢視。
回應長度
Opus 4.7 會根據任務複雜度來校準回應長度。簡單的查詢會得到簡短的答案，開放式的分析則會得到詳盡的內容。
如果你的使用案例取決於特定的長度或風格，請明確說明。提供你想要的語氣範例，比使用「不要做這個」之類的負面指令更有效。
更少的工具呼叫
模型呼叫工具的頻率降低，而推理的比例增加。在許多情況下，這能產生更好的結果。
但如果你需要更積極地使用工具來進行搜尋或讀取檔案，請明確指導何時以及為何應該使用工具。將努力程度提高到 high 或 xhigh 也會增加工具的使用頻率。
更少的子 Agent
Opus 4.7 在委派給子 Agent 時更加審慎。如果你的工作流程受益於並行展開（fan-out），請清楚說明：
「對於你可以直接在單次回應中完成的工作，請勿產生子 Agent。當需要跨項目展開或讀取多個檔案時，請在同一回合中產生多個子 Agent。」
更字面化的指令遵循
這是最容易導致現有設定失效的改變。Opus 4.7 對 Prompt 的解讀更為字面化，特別是在較低的努力程度下。
它不會默默地將一個項目的指令推廣到另一個項目，也不會推斷你未提出的要求。優點是精確度更高且減少無效的嘗試。
缺點是，如果你需要廣泛應用某項指令，你必須明確說明範圍。例如：「將此格式應用於每個章節，而不僅僅是第一個。」
語氣轉變
Opus 4.7 更加直接且有主見，與 4.6 較溫暖的風格相比，它減少了前置的確認性語句，使用的表情符號也較少。如果你的產品依賴特定的語氣，請根據新的基準重新評估你的風格 Prompt。
程式碼審查
Opus 4.7 在發現 Bug 方面有顯著提升。根據 Anthropic 基於真實 PR 的最困難 Bug 搜尋評估，它的召回率提高了 11 個百分點，精確度也更高。
但問題在於：如果你的審查 harness 寫著「僅報告高嚴重性問題」或「保持保守」，Opus 4.7 會比 4.6 更忠實地遵循該指令。
它可能會徹底調查程式碼、識別出 Bug，然後因為判斷該 Bug 低於你設定的門檻而不報告。精確度上升了，但測量的召回率卻下降了。
解決方法是將「發現」與「篩選」分開：
報告你發現的每一個問題，包括你不確定或認為嚴重性較低的問題。在此階段不要為了重要性或信心程度進行篩選。你的目標是覆蓋率：呈現一個後來被過濾掉的發現，總比默默漏掉一個真正的 Bug 要好。對於每個發現，請包含你的信心程度與預估嚴重性，以便後續的篩選器可以進行排序。
如果你需要單次篩選，請具體說明門檻在哪裡，而不是使用定性術語。例如：「報告任何可能導致錯誤行為、測試失敗或誤導性結果的 Bug；僅省略純粹的風格或命名偏好。」
使用 1M Context 進行工作階段管理
Claude Code 現在擁有 100 萬個 token 的 context window。這足以在單一工作階段中從零開始建立一個全端應用程式。
但更多的 context 並不總是意味著更好的結果。Context 腐敗（context rot）是真實存在的。
隨著 context 增加，注意力會分散在更多的 token 上。較舊、不相關的內容開始干擾當前任務，且隨著 context window 被填滿，模型的智慧程度會下降。
「迷失在中間」（Lost in the middle）效應：
你在每個回合都有五種選擇：
Continue：意味著發送另一則訊息。當視窗中的所有內容仍然相關時，請使用此選項。
Rewind (雙擊 Esc)：跳回之前的訊息，從那裡重新 Prompt。失敗的嘗試會從 context 中移除，這通常比輸入「那樣沒用，試試 X」更好，因為你可以保留有用的檔案讀取記錄，同時捨棄失敗的方法。
/compact (加上提示)：總結工作階段並繼續。這是會有損耗的，但開銷很低，你可以透過指令來引導它，例如
/compact 專注於 auth 重構，捨棄測試除錯部分。/clear：開始一個全新的工作階段。你自己寫下重要的內容，這樣可以獲得零腐敗與完全的控制權。
Subagents：委派會產生大量中間輸出的工作。子 Agent 會擁有自己全新的 context window，只有最終結果會回傳。
心智測試很簡單：你之後還需要工具的輸出嗎，還是只需要結論？如果只需要結論，請使用子 Agent。
什麼導致了糟糕的自動壓縮（auto-compaction）
當你接近 context 上限時，自動壓縮就會觸發。問題在於，這正是模型因 context 腐敗而處於最不聰明狀態的時候。
常見的失敗情況如下：在長時間的除錯工作階段後觸發自動壓縮，並總結了調查過程。你的下一則訊息引用了從摘要中被刪除的內容。
有了 100 萬的 context，你有更多時間主動進行壓縮，並附上重要的描述。不要等到自動壓縮啟動。
仍然重要的 Prompting 技術
幾種基礎的 Prompting 技術在 Opus 4.7 上仍然有效，你不應該僅因為模型變聰明了就放棄它們。
使用 XML 標籤來建構複雜的 Prompt。將指令、context、範例與輸入包裹在各自的標籤（
<instructions>,<context>,<input>）中，以減少誤解。在系統 Prompt 中給 Claude 一個角色。即使是一句話也能聚焦行為與語氣。
使用 3-5 個包裹在
<example>標籤中的範例，涵蓋邊緣案例，並確保變化足夠多，以免模型學到非預期的模式。將長篇資料放在 Prompt 的開頭，置於你的查詢之前。在處理複雜的多文件輸入時，將查詢放在最後可以將回應品質提升高達 30%。
以引號作為回應的基礎。對於長文件任務，請要求 Claude 在執行任務前引用相關部分。
控制工具使用
Opus 4.7 預設呼叫工具的頻率較低。若要增加工具使用，請提高努力程度或增加明確的指導：「當 [工具] 能增進你對問題的理解時，請使用它。」
並行工具呼叫是一個值得善用的優勢。模型會同時執行多次搜尋、一次讀取多個檔案，並並行執行 bash 指令。
你可以透過 XML 標籤中的明確指導，將並行執行率提升至接近 100%。
減輕過度思考
在較高的努力程度下，Opus 4.7 可能會進行廣泛的思考，導致思考 token 膨脹。加入此 Prompt 可讓它保持專注：
「當你決定如何處理問題時，請選擇一種方法並堅持下去。除非遇到直接與你的推理相矛盾的新資訊，否則請避免重新審視決策。」
Agent 系統：狀態、安全與多視窗工作流程
對於長期性的 Agent 工作，Opus 4.7 在跨擴展工作階段的狀態追蹤方面表現出色。一些模式可以讓它更有效率。
多 context window 工作流程讓你使用第一個 context window 來建立框架（撰寫測試、建立設定腳本），然後使用未來的視窗來迭代待辦事項清單。讓模型以結構化格式（如 tests.json）建立測試，並以 init.sh 等腳本建立設定，這樣新的 context window 就能從上一個視窗中斷的地方繼續。
狀態管理在格式與資料匹配時效果最好。對於測試結果與任務狀態等結構化資料使用 JSON，對於進度筆記使用自由格式文字，並使用 git 進行可還原的檢查點。
平衡自主性與安全性需要一些指導。如果沒有這些指導，Opus 4.7 可能會採取難以還原的行動，例如刪除檔案或強制推送（force-push）。
加入一個可還原性（reversibility）的 Prompt 來進行控管：
「鼓勵你採取本地、可還原的行動，例如編輯檔案或執行測試，但對於難以還原或影響共享系統的行動，請在執行前詢問使用者。」
減少過度工程（overengineering）也值得明確執行。Opus 4.7 可能會建立額外的檔案、添加不必要的抽象層，或建立未被要求的靈活性。
加入類似這樣的指導：「僅進行直接要求或明顯必要的變更。Bug 修復不需要清理周圍的程式碼。」
最小化幻覺（hallucinations）歸結為在回答前強制調查：「永遠不要對你尚未開啟的程式碼進行推測。如果使用者引用了特定檔案，你必須在回答前讀取該檔案。」
遷移檢查清單
如果你要從 Opus 4.6 遷移到 4.7，請更新以下內容：
將
thinking: {type: "enabled", budget_tokens: N}替換為thinking: {type: "adaptive"}，切換至自適應思考。將努力程度設定為 xhigh（這是程式撰寫工作的新預設值），並在 xhigh 或 max 努力程度下將最大輸出 token 設定為 64k。
更新程式碼審查 Prompt，將「發現」與「篩選」分開，以保留召回率。
透過將 context 前置到第一則訊息來減少使用者回合數，並增加明確的子 Agent 指導，讓模型知道何時該展開任務。
明確指定設計偏好，而不是依賴通用的指令來覆蓋預設風格。
棄用預填回應（prefilled responses）。從 Claude 4.6 模型開始，最後一個助理回合的預填回應已被棄用，而在 Mythos Preview 上它們會回傳 400 錯誤。
電腦使用（Computer use）
電腦使用功能支援最高 2576px 或 3.75MP 的解析度。發送 1080p 的圖片能提供效能與成本的最佳平衡。
對於成本敏感的工作負載，720p 或 1366x768 是不錯的低成本選項。
總結
Opus 4.7 回報的是前期的明確規範，懲罰的是漸進式、多回合的 Prompting。該模型比 4.6 更強大、更字面化，也更具自主性。
給它一個明確規範的任務，將努力程度設為 xhigh，然後讓它執行。能從此模型中獲得最大效益的開發者，是那些停止逐行指導、開始像對待資深工程師那樣進行委派的人。
今天就試試看：處理你的下一個程式撰寫任務，寫一個包含意圖、限制條件與驗收標準的單一詳細 Prompt，並以 xhigh 的努力程度在一個回合內發送。比較結果與 token 用量，看看與你過去的多回合模式有何不同。
差異將說明一切。
參考資料：
以上就是本次內容！
如果你喜歡這篇文章：
找到我 → @akshay_pachaar ✔️
我每天都會分享關於 AI、機器學習與 vibe coding 最佳實踐的教學與見解。