當我們在開發基於大型語言模型（LLM）的 AI 產品時，往往容易將注意力集中在模型權重（Model Weights）或 API 版本上。然而，Anthropic 最近針對 Claude Code 經歷六週品質下滑所發布的事後分析（Postmortem）提醒了所有工程師：即便底層模型沒變，產品層級（Product-layer）的微小調整，也可能在複雜的交互中產生劇烈的負面連鎖反應。
這次事故的特殊之處在於，使用者回報的症狀各異且混亂，這是因為在三到四月間，三個互不相關的產品變更在不同時間點、針對不同流量分片（Traffic Slice）上線，導致問題交織在一起，難以單一診斷。
第一個問題是推理強度（Reasoning Effort）的權衡失誤。為了改善 UI 延遲，防止使用者在模型長時間思考時感覺介面凍結，Anthropic 將預設的推理強度從 High 調降至 Medium。對工程師來說，這是一個典型的延遲與品質的權衡（Trade-off），但結果證明這是一個錯誤的決定。使用者明顯感覺到 AI 變得不再聰明，即便後來增加了可見的設定選項，大多數使用者仍停留在較低的預設值上。這告訴我們，對於開發工具類 AI，使用者對品質的容忍度遠低於對延遲的容忍度。
第二個問題涉及快取機制（Caching）的 Bug。為了優化成本與效能，開發團隊希望在 Session 閒置超過一小時後清除舊的思考片段（Thinking Sections），因為這些內容在重新啟動時通常會導致快取失效（Cache Miss）。然而，程式碼出現 Bug，導致清除動作在之後的每一次對話中都會觸發，而不是僅在閒置後觸發一次。這導致模型在執行任務時，會逐漸遺忘自己為什麼選擇目前的解決方案。對於處理長文本（Context）的工程師來說，這是一種嚴重的記憶喪失，不僅降低品質，還會因為頻繁的快取失效而快速消耗使用者的速率限制（Rate Limit）。
第三個問題是系統提示詞（System Prompt）的過度限制。在更新模型版本時，團隊加入了一項指令，要求模型在呼叫工具（Tool Calls）之間將文字控制在 25 字以內，最終回覆則在 100 字以內。雖然內部測試沒有發現明顯退化，但實際部署後發現整體品質下降了約 3%。這揭露了 AI 產品的一個痛點：過於嚴格的簡潔指令會導致模型跳過必要的重新閱讀或自我驗證步驟，讓 AI 傾向於給出看似自信但實際上不準確的答案。
這次事件對 AI 工程實務有三個核心啟發。
首先是評估體系（Evaluation Suite）的局限性。Anthropic 的內部評估未能捕捉到這 3% 的品質下降，這說明了目前的 AI 評估指標可能過於粗糙，無法偵測微小但關鍵的行為偏移。
其次是內部測試（Dogfooding）的環境差異。內部員工使用的版本與公開版本不一致，且快取 Bug 僅在特定狀態（閒置 Session）下才會觸發，這意味著 AI 產品的測試必須涵蓋更多真實且邊緣的狀態路徑。
最後是透明度與溝通。當系統提示詞或預設參數變動時，這實際上改變了產品的行為基線。如果開發者依賴舊的基準測試（Benchmarks）來評估效能，而產品端悄悄更換了提示詞，會讓使用者產生被欺騙的感覺。
為了防止類似問題，Anthropic 採取了包括強制內部員工使用公開版本、擴大每項提示詞變更的評估範圍、引入漸進式部署（Gradual Rollout）以及對系統提示詞進行版本管理等措施。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。