# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Akshay 🚀 (@akshay_pachaar) · 平台：X (Twitter) · 日期：2026-04-20

> 原始來源：https://x.com/akshay_pachaar/status/2045910818450182526

## 中文摘要

# 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 基礎通知，這樣你就不用盯著它工作了。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776644882537-iaHGQ7xuBagAAJyjWjpg.jpg)

# 五種努力程度，以及為什麼 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 來繞過它。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776644882744-iaHGR80yKbQAArzVtjpg.jpg)

# 自適應思考取代了固定預算

如果你之前在 Opus 4.6 上使用帶有 `budget_tokens` 的 Extended Thinking，現在已經沒有了。Opus 4.7 改為使用自適應思考（adaptive thinking）。

這兩者的差異很重要。在固定預算下，你預先分配了固定數量的思考 token，無論模型是否需要，它都會使用這些 token。

而在自適應思考中，模型會在每個步驟自行決定何時思考以及思考多少。

簡單的查詢會得到快速回應，複雜的推理步驟會進行深度思考，而那些從思考中獲益甚微的步驟則會完全跳過。

在長期的 Agent 執行過程中，與一刀切的思考預算相比，這能帶來更快速的回應與更低的 token 用量。

遷移過程很簡單：

```python
# 之前 (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 和工具呼叫之間進行思考與行動。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776644882895-iaHGRfzEdaIAAdPTzjpg.jpg)

# 會讓你吃虧的行為改變

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）效應：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776644882528-iaHGRhSkgakAED0Mdjpg.jpg)

你在每個回合都有五種選擇：

- Continue：意味著發送另一則訊息。當視窗中的所有內容仍然相關時，請使用此選項。

- Rewind (雙擊 Esc)：跳回之前的訊息，從那裡重新 Prompt。失敗的嘗試會從 context 中移除，這通常比輸入「那樣沒用，試試 X」更好，因為你可以保留有用的檔案讀取記錄，同時捨棄失敗的方法。

- /compact (加上提示)：總結工作階段並繼續。這是會有損耗的，但開銷很低，你可以透過指令來引導它，例如 `/compact 專注於 auth 重構，捨棄測試除錯部分`。

- /clear：開始一個全新的工作階段。你自己寫下重要的內容，這樣可以獲得零腐敗與完全的控制權。

- Subagents：委派會產生大量中間輸出的工作。子 Agent 會擁有自己全新的 context window，只有最終結果會回傳。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776644882573-iaHGRhvG0agAAyH1djpg.jpg)

心智測試很簡單：你之後還需要工具的輸出嗎，還是只需要結論？如果只需要結論，請使用子 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）歸結為在回答前強制調查：「永遠不要對你尚未開啟的程式碼進行推測。如果使用者引用了特定檔案，你必須在回答前讀取該檔案。」

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776644882525-iaHGRjMIPa4AEloYpjpg.jpg)

# 遷移檢查清單

如果你要從 Opus 4.6 遷移到 4.7，請更新以下內容：

1. 將 `thinking: {type: "enabled", budget_tokens: N}` 替換為 `thinking: {type: "adaptive"}`，切換至自適應思考。

1. 將努力程度設定為 xhigh（這是程式撰寫工作的新預設值），並在 xhigh 或 max 努力程度下將最大輸出 token 設定為 64k。

1. 更新程式碼審查 Prompt，將「發現」與「篩選」分開，以保留召回率。

1. 透過將 context 前置到第一則訊息來減少使用者回合數，並增加明確的子 Agent 指導，讓模型知道何時該展開任務。

1. 明確指定設計偏好，而不是依賴通用的指令來覆蓋預設風格。

1. 棄用預填回應（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 用量，看看與你過去的多回合模式有何不同。

差異將說明一切。

---

參考資料：

- https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7

- https://x.com/trq212/status/2044548257058328723?s=20

---

以上就是本次內容！

如果你喜歡這篇文章：

找到我 → @akshay_pachaar ✔️

我每天都會分享關於 AI、機器學習與 vibe coding 最佳實踐的教學與見解。

## 標籤

功能更新, LLM, Anthropic, Claude