Anthropic 説明 Claude Code 近期品質問題成因及修復措施

過去一個月，我們一直在調查有關部分用戶認為 Claude 回應質素下降的報告。追查後發現，這些情況源於三項分別影響 Claude Code、Claude Agent SDK 和 Claude Cowork 的改動。API 未受影響。

截至4月20日（v2.1.116），三個問題均已解決。

在這篇文章中，我們會説明調查結果、修正措施，以及我們會如何改進，以大幅降低類似問題再次發生的可能性。

我們非常重視有關表現下降的報告。我們絕不會刻意降低模型的表現，並已即時確認 API 和推理層並未受影響。

經調查後，我們找出三個不同的問題：

1. 3月4日，我們將 Claude Code 的預設推理力度由 high 調低至 medium，以減少部分用戶在 high 模式下遇到的極長延遲，情況嚴重時甚至令用戶介面看似凍結。這項取捨並不恰當。用戶告訴我們，他們希望預設採用較高智能，並在簡單任務中選擇較低推理力度；因此，我們於4月7日撤回這項改動。這影響了 Sonnet 4.6 和 Opus 4.6。
2. 3月26日，我們推出一項改動，清除閒置超過一小時的工作階段中 Claude 先前的思考內容，以減少用戶恢復這些工作階段時的延遲。一個錯誤導致這項操作在該工作階段的每一輪對話中都會重複執行，而非只執行一次，令 Claude 看起來容易忘記事情，而且反覆作答。我們於4月10日修正了問題。這影響了 Sonnet 4.6 和 Opus 4.6。
3. 4月16日，我們加入一項系統提示詞指示，以減少回應冗長程度。這項指示與其他提示詞改動一同使用時，影響了編碼質素，因此於4月20日撤回。這影響了 Sonnet 4.6、Opus 4.6 和 Opus 4.7。

由於每項改動在不同時間影響不同流量羣組，整體效果看起來像是廣泛而不一致的表現下降。我們在3月初開始調查相關報告，但起初很難分辨這些情況與用戶回饋的正常波動；而且，我們的內部使用情況和評測起初都未能重現所發現的問題。

這並非用戶應該從 Claude Code 獲得的體驗。截至4月23日，所有訂閲用戶的使用量限制將會重設。

Claude Code 預設推理力度的改動

2月，我們在 Claude Code 中推出 Opus 4.6 時，將預設推理力度設為 high。

不久後，我們收到用戶回饋，指 Claude Opus 4.6 在高推理力度模式下偶爾會思考過久，令用戶介面看似凍結，並令這些用戶承受過長的延遲和過高的 token 用量。

一般而言，模型思考時間越長，輸出質素越好。Claude Code 透過推理力度級別，讓用戶設定這種取捨——選擇更多思考，還是較低延遲和較少觸及使用量限制。為模型校準推理力度級別時，我們會考慮這種取捨，在測試時運算曲線上選取合適的位置，為用戶提供最佳的選項範圍。在產品層面，我們會從這條曲線上選擇一個位置作為預設值，並將該值作為 effort 參數傳送至 Messages API；其他選項則可透過 /effort 使用。

在我們的內部評測和測試中，中等推理力度在大部分任務上的智能表現稍低，但延遲顯著較低。它也沒有出現思考過程偶爾延遲極長的同類問題，並有助用戶更充分運用使用量上限。因此，我們推出調整，將中等推理力度設為預設值，並透過產品內對話框説明原因。

推出後不久，用戶開始反映 Claude Code 感覺沒那麼聰明。我們推出多輪設計調整，讓目前的推理力度設定更清晰，提醒用戶可以更改預設值，包括在啟動時顯示通知、加入行內推理力度選擇器，以及恢復 ultrathink；但大多數用戶仍沿用中等推理力度的預設值。

收到更多客戶意見後，我們於 April 7 撤回這項決定。現在所有用戶使用 Opus 4.7 時，預設推理力度為 xhigh；使用其他所有模型時，預設推理力度為 high。

一項會丟棄先前推理內容的快取最佳化

Claude 推理處理任務時，相關推理通常會保留在對話記錄中，讓 Claude 在之後每一輪對話中，都能瞭解自己為何作出相關修改及呼叫工具。

On March 26，我們推出一項原本旨在提升此功能效率的改動。我們使用提示詞快取，讓用戶連續發出的 API 呼叫成本更低、速度更快。Claude 發出 API 請求時，會將輸入 token 寫入快取；閒置一段時間後，提示詞便會從快取中移除，騰出空間給其他提示詞。我們會謹慎管理快取使用率（詳情請參閲我們的做法）。

設計原本應該很簡單：如果工作階段閒置超過一小時，我們可以清除舊的思考區段，降低用戶恢復該工作階段的成本。由於該請求本來就會快取未命中，我們可以從請求中刪除不必要的訊息，減少傳送至 API 的未快取 token 數量。之後便會恢復傳送完整推理記錄。為此，我們使用了 clear_thinking_20251015 API 標頭以及 keep:1。

實作中有一個錯誤。它沒有隻清除一次推理記錄，而是在該工作階段餘下的每一輪都清除。工作階段一旦曾超過閒置門檻，該程序其後發出的每個請求都會要求 API 只保留最新一段推理內容，並丟棄之前所有內容。情況因而進一步惡化：如果 Claude 正在使用工具時收到後續訊息，便會在錯誤旗標下開始新一輪，連當前回合的推理內容也會被丟棄。Claude 仍會繼續執行，但愈來愈不記得自己為何選擇採取當前行動。用戶反映的健忘、重複及不尋常的工具選擇等問題，正是這個情況的表現。

由於後續請求中的思考區塊會持續被丟棄，這些請求亦會導致快取未命中。我們認為，這正是另一些用戶反映使用量上限消耗速度較預期快的原因。

兩項無關的實驗令我們起初難以重現問題：一項是僅供內部使用、與訊息佇列有關的伺服器端實驗；另一項是與此無關、涉及思考內容顯示方式的改動，它在大多數 CLI 工作階段中掩蓋了這個錯誤，因此即使測試外部版本，我們也未能發現。

這個錯誤出現在 Claude Code 的上下文管理、Anthropic API 和延伸思考三者交會之處。由此引入的改動通過了多輪人工和自動化程式碼審查，以及單元測試、端對端測試、自動化驗證和內部實測。再加上問題只會在特殊情況下發生（工作階段狀態過時），而且難以重現，我們花了一個多星期才找出並確認根本原因。

調查期間，我們使用 Opus 4.7，針對涉事的拉取請求回溯測試了 Code Review。提供足以掌握完整上下文的程式碼儲存庫後，Opus 4.7 找出了錯誤，Opus 4.6 則沒有。為免再次發生同類問題，我們現正加入支援，讓程式碼審查可將更多程式碼儲存庫納入上下文。

我們於 4 月 10 日在 v2.1.101 修正了這個錯誤。

透過修改系統提示詞減少冗長回應

我們最新的模型 Claude Opus 4.7 相較上一代有一個顯著的行為特點：正如我們在推出時所寫，它傾向提供相當冗長的回應。這令它處理難題時更聰明，但同時也會產生更多輸出 token。

在推出 Opus 4.7 前幾星期，我們開始為 Claude Code 作好調校準備。每個模型的行為都略有不同，因此每次推出新版本前，我們都會花時間為該模型最佳化執行框架和產品。

我們有多種方法可以減少冗長回應，包括模型訓練、提示詞設計，以及改善產品內的思考體驗。我們最終採用了所有這些方法，但在系統提示詞中新增的一項內容，對 Claude Code 的智能造成了超乎預期的影響：

「長度限制：工具呼叫之間的文字不得超過 25 個詞。最終回應不得超過 100 個詞，除非任務需要更詳細的內容。」

經過數星期的內部測試，而且我們執行的評測組合未有發現退步後，我們對這項改動充滿信心，並於 4 月 16 日隨 Opus 4.7 一併推出。

調查期間，我們使用更廣泛的評測組合進行了更多消融測試（移除系統提示詞中的行，以瞭解每行的影響）。其中一項評測顯示，Opus 4.6 和 4.7 的表現均下跌 3%。我們立即撤回該提示詞，並在 4 月 20 日的版本中作出更新。

未來的改進

為避免這些問題再次發生，我們會作出幾項改變：確保更多內部員工使用與用戶完全相同的 Claude Code 公開版本，而非我們用來測試新功能的版本；改善我們內部使用的 Code Review 工具，並向客戶推出改良版本。

我們亦會加強對系統提示詞改動的管控。每次修改 Claude Code 的系統提示詞，我們都會針對各個模型執行涵蓋範圍更廣的評測，並繼續進行消融測試，以瞭解每行的影響。我們亦已建立新工具，讓提示詞改動更容易審查和稽核。此外，我們已在 CLAUDE.md 加入指引，確保針對特定模型的改動只會套用於目標模型。對於任何可能影響智能表現的改動，我們都會安排穩定觀察期、採用更廣泛的評測組合，並逐步推出，以便及早發現問題。

我們最近在 X 開設了 @ClaudeDevs，讓我們可以深入解釋產品決策及其背後的考量。我們亦會在 GitHub 的集中討論串中分享相同的更新。

最後，我們想感謝用戶：使用 /feedback 命令向我們反映問題（或在網上發佈具體且可重現的例子）的人，最終讓我們得以找出並修正這些問題。今天，我們會為所有訂閲用戶重設使用上限。

我們非常感謝大家提供意見，也感謝大家耐心等候。