我們已追蹤近期有關 Claude Code 品質問題的報告，發現源於三項獨立的變更。以下是事件經過以及我們將採取的改進措施。
過去一個月，我們一直在調查有關 Claude 回應品質下降的用戶報告。我們已將這些報告追溯至三項獨立的變更，這些變更分別影響了 Claude Code、Claude Agent SDK 和 Claude Cowork。API 並未受到影響。
截至 4 月 20 日（v2.1.116），所有這三個問題都已解決。
在本篇文章中，我們將解釋我們發現了什麼、我們修復了什麼，以及我們將如何改進，以確保類似問題未來發生的可能性大大降低。
我們非常認真看待有關品質下降的報告。我們從未故意降低模型的效能，並且能夠立即確認我們的 API 和推理層並未受到影響。
經過調查，我們確定了三個不同的問題：
由於每項變更都在不同的時間表上影響了不同的流量區塊，因此匯總效果看起來像是廣泛且不一致的品質下降。雖然我們在三月初開始調查這些報告，但起初難以將其與用戶回饋中的正常波動區分開來，而且我們的內部使用和評估最初也未能重現已識別的問題。
當我們於二月在 Claude Code 中發布 Opus 4.6 時，我們將預設的推理層級設定為「高」。
不久之後，我們收到用戶回饋，表示 Claude Opus 4.6 在高層級模式下偶爾會思考過久，導致使用者介面看似凍結，並為這些用戶帶來不成比例的延遲和代幣使用量。
一般而言，模型思考的時間越長，輸出品質越好。層級是 Claude Code 讓用戶設定這種權衡的方式——更多的思考對比較低的延遲和較少的用量限制觸及。當我們校準模型的層級時，我們會考慮這種權衡，以便在測試時間計算曲線中選擇能為用戶提供最佳選項範圍的點。在產品層面，我們接著選擇沿著這條曲線的哪個點作為我們的預設值，這就是我們發送到 Messages API 作為層級參數的值；然後我們可透過 /effort 提供其他選項。
在我們的內部評估和測試中，中層級對於大多數任務而言，智慧程度略低，但延遲顯著減少。它也沒有出現偶爾出現的思考時間過長的問題，並且有助於最大化用戶的用量限制。因此，我們推出了一項變更，將中層級設為預設層級，並透過產品內對話框解釋了其原理。
推出後不久，用戶開始回報 Claude Code 的智慧程度似乎降低了。我們發布了多項設計迭代，以使目前的層級設定更清晰，來提醒用戶他們可以更改預設值（啟動時的通知、內嵌的層級選擇器，以及恢復 ultrathink 功能），但大多數用戶仍保留中層級的預設值。
在聽取更多客戶的回饋後，我們於 4 月 7 日撤銷了這項決定。所有用戶現在預設使用 Opus 4.7 的 xhigh 層級，以及所有其他模型的 high 層級。
當 Claude 處理一項任務時，其推理過程通常會保留在對話歷史記錄中，以便在後續的每個回合中，Claude 都能看到它為何進行了編輯和工具調用。
在 3 月 26 日，我們發布了一項旨在提高此功能的效率的改進。我們使用提示快取來降低用戶連續 API 調用的成本和速度。Claude 在發出 API 請求時將輸入代幣寫入快取，然後在一段時間不活動後，提示會從快取中移除，為其他提示騰出空間。快取利用率是我們仔細管理的（更多關於我們的方法）。
設計應該很簡單：如果一個會話閒置超過一小時，我們可以透過清除舊的思考部分來降低用戶恢復該會話的成本。由於請求無論如何都會是快取未命中，我們可以從請求中修剪不必要的訊息，以減少發送到 API 的未快取代幣數量。然後我們將恢復發送完整的推理歷史記錄。為此，我們使用了 clear_thinking_20251015 API 標頭以及 keep:1。
實施中存在一個錯誤。它沒有只清除一次思考歷史記錄，而是對該會話的其餘時間的每個回合都進行清除。一旦會話超過閒置閾值一次，該過程其餘時間的每個請求都會指示 API 只保留最近的推理區塊並丟棄之前的內容。這會疊加：如果你在 Claude 正在使用工具的過程中發送後續訊息，該訊息會在損壞的標誌下啟動一個新回合，因此即使是當前回合的推理也會被丟棄。Claude 會繼續執行，但越來越失去對為何選擇這樣做的記憶。
由於這會持續從後續請求中丟棄思考區塊，因此這些請求也會導致快取未命中。我們相信這就是導致有關用量限制比預期消耗更快的分開報告的原因。
兩項不相關的實驗使我們最初難以重現此問題：一項與訊息佇列相關的內部專用伺服器端實驗；以及我們顯示思考過程的方式的獨立變更，這在大多數 CLI 會話中抑制了此錯誤，因此即使測試外部建置時我們也沒有發現它。
此錯誤位於 Claude Code 的上下文管理、Anthropic API 和擴展思考的交叉點。它引入的變更通過了多個人工和自動程式碼審查，以及單元測試、端對端測試、自動驗證和內部測試。結合其僅在邊緣情況（過時的會話）下發生以及難以重現的問題，我們花了一週多的時間才發現並確認根本原因。
作為調查的一部分，我們使用 Opus 4.7 回溯測試了針對有問題的拉取請求的程式碼審查。在提供收集完整上下文所需的程式碼儲存庫後，Opus 4.7 發現了錯誤，而 Opus 4.6 沒有。為防止此類情況再次發生，我們現在正在為程式碼審查增加對額外儲存庫作為上下文的支持。
我們於 4 月 10 日在 v2.1.101 中修復了此錯誤。
我們最新的模型 Claude Opus 4.7 相較於其前代產品，有一個顯著的行為特徵：正如我們在發布時所寫的那樣，它傾向於非常冗長。這使得它在處理難題時更聰明，但它也會產生更多的輸出代幣。
在我們發布 Opus 4.7 前幾週，我們開始為 Claude Code 進行調優以做準備。每個模型行為略有不同，我們會在每次發布前花時間優化其工具和產品。
我們有許多工具可以減少冗長性：模型訓練、提示，以及改進產品中的思考使用者體驗。最終我們使用了所有這些方法，但系統提示詞中的一項新增功能對 Claude Code 的智慧產生了不成比例的影響：
經過數週的內部測試，並且我們運行的一系列評估沒有出現回歸，我們對此變更感到自信，並於 4 月 16 日與 Opus 4.7 一同發布。
作為調查的一部分，我們使用更廣泛的評估進行了更多消融實驗（從系統提示詞中刪除行以了解每行的影響）。其中一項評估顯示 Opus 4.6 和 4.7 都下降了 3%。我們在 4 月 20 日的發布中立即撤銷了該提示詞。
我們將採取幾項不同的措施來避免這些問題：我們將確保更多內部員工使用與公開版本完全相同的 Claude Code 版本（而不是我們用於測試新功能的版本）；我們將改進我們內部使用的程式碼審查工具，並將此改進版本發布給客戶。
我們也將對系統提示詞的變更實施更嚴格的控制。我們將對 Claude Code 的每次系統提示詞變更運行一系列廣泛的每模型評估，繼續進行消融實驗以了解每行的影響，並且我們已經構建了新的工具來使提示詞變更更容易審查和審計。我們還在 CLAUDE.md 中增加了指導，以確保模型特定的變更僅限於其目標模型。對於任何可能與智慧權衡的變更，我們將增加觀察期、更廣泛的評估套件和逐步推出，以便我們能及早發現問題。
我們最近在 X 上創建了 @ClaudeDevs，以便有空間深入解釋產品決策及其背後的原理。我們將在 GitHub 上的集中式討論串中分享相同的更新。
我們非常感謝您的回饋和耐心。
產品更新、操作指南、社群亮點等。每月寄送至您的收件匣。