Claude Code降智的真正原因 | Anthropic覆盤 | 3個bug | 推理強度改動 | 緩存優化錯誤 | 系統提示詞長度限制 | 反思原因 | AI審查AI代碼 | 敬畏工程複雜性

大家好,這裏是最佳拍檔,我是大飛 過去一個多月,相信所有Cloud Code的重度使用者都產生了一個強烈的共鳴 有人說他突然變笨降智了,有人說他寫出來的代碼根本跑不通 還有人說他明明剛纔還在聊複雜的邏輯,下一句就完全失憶了 可是令所有人意想不到的是,這起持續了一個多月 讓無數開發者懷疑人生的質量事故 最後不是被黑客攻破了,不是模型被惡意降級 也不是底層算力出了什麼災難性的故障 而是三個完全獨立,看似不起眼的產品層的小改動 在不同時間點悄悄上線,最終疊加在一起 製造了一場橫跨整個開發者社區的集體混亂 Unstable官方最終發佈了一篇事後覆盤 大飛我看完這篇覆盤的第一感受是,它不僅是一次簡單的故障通報 更是一堂關於AI產品研發、測試、發佈、運維的公開課 它告訴我們,今天的AI系統已經複雜到 哪怕底層模型紋絲不動,API完全穩定 僅僅是硬層的一個參數,一段緩存邏輯或者是一句提示詞 都足以讓用戶會有模型能力斷崖式下跌的感覺 接下來我們就來回顧一下這起Cloud Code的質量事故 我們先從第一個問題說起 2026年3月4日 AnswerBig團隊做了一個看起來非常合理、非常爲用戶着想的動作 把Cloud Code的默認推理強度從高下調到了中 什麼是推理強度呢? 簡單來說這是AI模型在完成任務時 控制投入的計算量、思考深度和推理步驟多少的一個參數 強度越高,模型輸出結果的質量通常也會越高 但是對應的代價是響應的時間更長,消耗的token更多 反過來強度調低,速度變快,消耗變少 但是思考的深度會下降,複雜任務的表現會明顯變弱 那麼AnswerBig團隊爲什麼要做這個下調呢? 原因很直接,當時有大量的用戶反饋 在高推理強度模式下,遇到了極端漫長的等待時間 有時候界面直接卡死,看起來像是程序崩潰了 對於一款主打生產力的編程工具來說 卡頓無響應絕對是一個致命的體驗問題 所以團隊的邏輯就是把默認強度降到中 而且內部測試顯示 中模式在絕大多數常規的任務上只是比高稍微弱了那麼一點點 但延遲會顯著的降低,也不會出現UI卡死的情況 這在團隊看來是一次性價比極高的體驗優化 但是他們完全低估了一件事情 那就是程序員群體對於AI工具智能水平的敏感度 遠遠高於對於延遲的敏感度 上線之後,用戶的反饋和團隊的預期完全相反 大量開發者明確的表示 我們寧可多等幾秒,十幾秒 也要得到更聰明、更可靠、更少反攻的輸出 你是把速度提上來了 但是輸出變笨了,錯誤變多了 我們反而要花更多的時間去修正和調試 整體的效率反而更低了 很多人直接的感受是 工具的能力強烈退化了 已經沒法用來處理複雜的工程任務了 這次改動帶來的影響持續了一個多月 直到2026年4月7日 ISOBIC才正式回滾了這個調整 目前的設置是 OPUS 4.7版本默認使用超高X-High的強度 其他模型默認恢復爲高強度 如果說第一個問題是產品決策的偏差 那麼第二個問題就是整場事故中 最隱蔽、最有技術含量 也是最致命的一個缺陷 由於緩存優化引入的嚴重bug 這個問題上線於2026年3月26日 團隊當時的設計目標同樣非常合理 通過優化繪畫的緩存來降低延遲與成本 具體邏輯是 如果一個用戶的繪畫閒置超過一個小時 當用戶重新恢復對話時 系統會自動清理掉舊的思考記錄 只保留必要的上下文 這樣做的好處是 減少恢復繪畫時需要傳輸與處理的token數量 既可以加快加載速度 又節省用戶的用量額度 同時降低服務器的負載 按照正常設計 這個清理操作應該只執行一次 也就是在閒置超時後 第一次恢復對話的時候清理一次 之後就恢復正常的緩存邏輯 但是現實是 代碼實現出現了一個致命的錯誤 清理操作沒有被限制爲一次 而是變成了觸發預知之後 每一輪對話都執行清理 這會導致什麼結果呢 一旦某個繪畫曾經閒置超過一小時之後 你每發一次問題 Cloud都會把之前所有的思考過程全部去掉 只保留最近一輪的推理記錄 它能看到自己剛剛做了什麼 但是完全不記得爲什麼要這麼做 前面的邏輯鏈條和整體任務的目標都給忘了 放到實際的編程場景中 你會發現 它的工作剛剛做到一半 就會突然開始重複操作 工具調用莫名其妙 邏輯前後矛盾 甚至忘記你最開始的需求 用戶最直觀的感受就是 健忘重複思路斷裂 越用越亂 更糟的是 因爲思考記錄被持續丟棄 每一次請求都相當於緩存未命中 模型必須重新計算 重新生成推理內容 直接導致用戶的用量額度消耗速度 遠快於正常情況 很多訂閱用戶發現 自己的額度莫名其妙就見底了 卻不知道是緩存bug 在背後偷走了token 這個bug有多難發現呢 Anthropic官方在副盤裏承認 它花了整整兩週時間才被定位 原因有兩個 第一 它必須滿足特定的觸發條件 繪畫必須先前置超過一小時 日常高頻使用的繪畫根本不會觸發 第二個 當時內部有兩個完全不相關的實驗 恰好掩蓋了它的復現路徑 導致內部測試的時候 很難穩定的復現問題 最讓人意外的是 這個缺陷通過了人工代碼審查 單元測試 端到端測試 以及內部的狗糧測試 所有的環節沒有被任何一道防線攔住 直到用戶反饋越來越集中和具體 工程團隊才順着失憶 重複 用量異常這些關鍵詞 最終鎖定了緩存清理邏輯的錯誤 最終在2026年4月10日 徹底修復了這個bug 接下來是第三個問題 也是最反直覺 最容易被忽視的一個改動 系統提示詞裏多了一句長度限制 時間來到了2026年4月16日 伴隨着OPUS 4.7版本的發佈 團隊爲了控制模型天生的囉嗦傾向 在系統提示詞裏 悄悄加了一條規則 工具調用之間的文本不超過25個詞 最終回覆不超過100個詞 除非任務確實需要更多的細節 團隊的初衷完全可以理解 因爲OPUS 4.7的能力更強 輸出更詳細 但是也更容易長篇大論 對於追求簡潔的用戶來說 冗餘信息會影響閱讀的效率 而且這個改動在內部已經測試了好幾周 跑了一套標準評估級 沒有發現任何性能迴歸 但是上線之後 用更全面 更貼近於真實場景的評估套件一測 問題立刻暴露了 編碼質量直接下降了3% 大家可能覺得3%不是什麼多大的數字 但是對於一款專業級的AI編程工具來說 這3%實際上代表了能力的大幅下降 尤其是在複雜工程任務裏 一句不能多說的限制 會直接壓縮模型的規劃空間 推理步驟和解釋能力 讓它沒辦法完整展示思考過程 也沒辦法把複雜的邏輯講清楚 對於程序員來說 AI寫代碼不只是要結果 更要看思路 看判斷 看爲什麼這麼實現 長度一限制 相當於把模型的思考草稿給撕掉了 只剩下了乾巴巴的代碼 質量自然就會下滑 2026年4月20日 這條系統提示被正式的迴歸 到這裏 三個問題就全部的修復完畢了 3月4日的推理強度下調 3月26日的緩存bug 4月16日的提示詞長度限制 分別在4月7日 4月10日 4月20日依次解決 但是整個事故 從3月初開始 到4月20日完全收尾 持續了近一個半月 講到這裏 你可能和我一樣好奇 爲什麼這三個問題 能夠逃過所有的測試防線呢 爲什麼代碼審查 自動化測試 內部試用全都沒有攔住呢 Anthropic在覆盤裏給出的反思 可以說比bug本身更有價值 第一層原因也是最經典的一個陷阱 內部員工使用的版本 和公開用戶版本存在差異 很多科技公司都會犯這個錯誤 內部的測試環境 參數配置以及功能開關 和線上實際給用戶用的不完全一樣 團隊以爲自己在充分試用 是在吃狗糧 但其實用的是一個安全版 或者是調試版 而bug恰恰藏在那個微小的差異裏 等到大規模上線 真實用戶的場景 行爲 設備 和網絡環境千差萬別 問題才集中的爆發 第二層原因 評估套件的覆蓋面不夠廣 內部跑的標準評估集 只能夠覆蓋常規的場景 和簡單的任務 沒有辦法模擬用戶 真實工作中的各種情況 就像第三個問題 內部評估沒有測出質量下降 但是換上更全面的評估集 3%的下滑立刻顯現 這說明 AI產品的評估體系 必須和產品一起持續迭代和擴展 不能夠一套評估用到底 第三層原因 早期用戶的反饋 很難和正常的波動區分開 AI模型本身就有一定的輸出隨機性 用戶的主觀感受 也會受到心情 任務難度和使用習慣 等多種因素的影響 當問題剛出現的時候 零星的所謂變悶了 不好用了這樣的反饋 很容易被當成正常的性能波動 而不是系統性故障 等到反饋形成規模的時候 問題已經影響了大量的用戶 這三層原因疊加在一起 就形成了一個可怕的盲區 每一道防線單獨看起來都很合理 很完善 但是組合在一起 就是擋不住那些隱蔽的 場景化的非典型的缺陷 這對於所有AI產品團隊來說 都是一次警示 複雜度越高 越不能依賴單一的防線 在官方副盤裏 還有一個非常有意思 甚至可以說是里程碑式的細節 那就是用AI審查AI的代碼 事故之後 團隊用Opus 4.7模型 對出問題的那個緩存優化PR 做了一次回測式的代碼審查 結果非常震撼 Opus 4.7能夠準確發現 那個緩存清理邏輯的bug 而上一代的Opus 4.6則做不到 這至少證明兩件事 第一 模型能力的提升是實質性的 新一代模型在理解複雜系統交互 邏輯分支 邊界條件和狀態流轉方面 有肉眼可見的進步 第二 用更強的AI模型 來審查AI產品自身的代碼 正在從一個概念 變成真實可用的工程實踐 AnswerBig現在已經在內部 全面推行了這種 AI輔助式的code reveal 並且計劃把優化後的審查工具 開放給用戶 我們可以想象一個未來 AI系統越來越複雜 人類工程師越來越難以覆蓋 所有的邊界情況 用更高能力的模型 去審查較低版本模型 參與構建的系統 會成爲行業的標準流程 面對這樣一起影響廣泛的事件 AnswerBig事後 也拿出了一整套改進措施 我給大家完整梳理一下 首先 強制統一內部測試版本 與公開線上版本 確保員工用到的 就是用戶真實使用的環境 從而消除環境差異帶來的盲區 其次 強化評估體系 以後每次系統提示詞變更 都必須針對每一個模型 跑全面完整的評估 而不是隻跑內部標準級 最大限度避免隱性的質量下滑 第三 建立進泡期與灰度發佈的機制 新功能新改動 不再一次性全量上線 而是先小範圍的放量 充分進泡 觀察指標與反饋 確認穩定之後 再逐步擴大 給問題足夠多的暴露時間 第四 升級CodeReview工具 增強上下文理解能力 支持引入更多代碼倉庫 作爲審查背景 同時結合AI的能力 提升審查的覆蓋度與精準度 第五 主動透明溝通 官方主動開通了 AtCloud Devs的社交賬號 用來解釋每一次產品決策背後的邏輯 參數調整的原因 以及功能變更的目標 對於AI產品來說 用戶對爲什麼突然不一樣了的焦慮 是持續存在的 主動透明遠勝於被動回應 最後也是最直接的用戶補償 所有訂閱用戶的用量限額被重置 用實際行動來彌補用戶 坦白來說 在整個AI行業裏 如此詳細的官方覆盤還是非常少見的 大多數公司遇到類似的問題 要麼沉默拖延 要麼用系統優化 復升級之類的套話來敷衍用戶 很少有人願意把三個bug的細節 完整的公開給用戶 講完整起事故 我想再和大家分享一些 關於這起事故的幾個啓示 第一個啓示 我們越來越依靠AI來完成關鍵的工作 但是AI產品的質量波動 會直接影響我們的產出與判斷 你可能用一款變笨了的工具 工作了一整天 最後發現質量下滑 卻誤以爲是自己的狀態不好 或者是提示詞沒寫好 任務太難 你不會第一時間想到 也許是工具背後出了一個小問題 所以作爲使用者 我們必須建立自己的質量極限感知 你要清楚知道 這款工具正常的水平是什麼樣的 能做到什麼程度 一旦偏離了極限 你能夠快速的察覺 及時切換模型 第二個啓示 模型能力只是AI產品的一部分 產品的工程質量 往往更影響日常的體驗 這起事故中 cloud底層的模型沒有變 但是因爲默認參數 緩存邏輯 提示詞 這三個產品層面的改動 用戶感知到的智能水平就劇烈波動 這告訴我們 評價一款AI產品 不能只看模型參數和宣傳的能力 更要看產品工程的穩定性 模型再強 工程拉垮 體驗照樣崩盤 第三個啓示 小改動可能引發大事故 AI產品的發佈管控必須極度謹慎 三個問題 沒有一個是顛覆性的架構重構 都是小範圍局部化的改動 但是疊加之後 造成了大規模的體驗惡化 這提醒所有的研發團隊 AI系統的偶合度極高 任何一處微調 都可能在複雜的場景裏 觸發連鎖反應 必須敬畏複雜度 嚴控發佈流程 總結一下 這期Cloud Code的質量事故 表面上看 是三個bug導致的體驗下滑 本質上 其實是一次 AI產品研發 測試 發佈全流程的典型案例 它告訴我們 AI時代的產品工程 面臨着和傳統軟件 完全不同的挑戰 更高的複雜度 更強的用戶敏感度 更隱蔽的缺陷 以及更難以感知的質量波動 未來 AI會深入更多的行業 和更多的崗位 類似的產品質量事故 大概率還會出現 所以 我們依然要保持 對於工程的敬畏之心 不要認爲 有了AI 就能夠解決所有的問題 那麼 除了這次的事故之外 大家還有沒有遇到過 AI工具突然變笨 失意 或者不好用的情況呢 你是怎麼判斷 是自己的問題 還是工具本身的問題呢 歡迎在評論區留言 感謝觀看 我們下期再見