如何偵測 Claude 效能降低 (含真實數據)

本影片涵蓋的內容

• Claude 發布後會變笨：理論遇上零日計時器
• live nerf：Opus 5.5 從發布週開始的 30 天計時
• 如何捕捉效能降低：78 個有時答對的問題
• 它能看到什麼：7.5 點，token 數量首先變化
• 盲點：Opus 5 替換和 8 個錯誤的答案鍵

翻譯的文字記錄

從英文原文旁白翻譯。可用的音頻和字幕由 YouTube 控制。

Claude 發布後會變笨：理論遇上零日計時器

0:00 人人都知道 Claude 在發布幾週後會變笨。 所以一位開發者從發布週開始對 Opus 5.5 進行計時， 計時器顯示之前沒有人能知道。 在這段影片中，有三個問題。 你如何捕捉效能降低？ 這個計量器能看到什麼？ Anthropic 又怎麼說？ 以及儲存庫致謝中的一句話讓我大笑。

0:20 我會在結尾提到。 今天是 9 月 30 日星期三，這是 The Daily Diff。 今天有三個故事，其中最主要的是一個名為 live nerf 的 GitHub 儲存庫。

live nerf：Opus 5.5 從發布週開始的 30 天計時

0:30 數月以來，人們一直說 Anthropic 在發布後悄悄地降低了模型效能。 常見的理論是模型被壓縮，同名下有較小的模型， 或者只是思考減少了。 這個儲存庫將所有爭論稱為「感覺對感覺」。 Opus 5.5 於 9 月 22 日發布， 一週前我告訴你，它在獨立榜單上名列前茅，同時寫出比中位數模型多三倍的字數。 一週前我告訴你，它在獨立榜單上名列前茅，同時寫出比中位數模型多三倍的字數。 兩天半後，一位名為 ninja hawk 的開發者開始計時，

0:59 每天一次，持續 30 天，且日誌不可編輯。 The Hacker News 討論串達到了近 800 點，並像團隊聊天一樣分裂。 一位評論者說，在絕大多數報導的案例中，模型效能降低並非真實存在。 另一位說，人們只是習慣了新的智能水平。 而一位 Claude Code 高級用戶現在每次都關閉「評價此會話」的彈出視窗， 因為評價 Claude 似乎讓它變得更糟。 同行評審。那麼，問題一，你如何捕捉效能降低？

如何捕捉效能降低：78 個有時答對的問題

1:27 你從大約 2300 道困難的考試題開始， Opus 在第一次嘗試時答對了 93%， 這對偵測器來說是無用的，因為一個它總是答對的問題不可能下降。 97% 的問題總是答對或總是答錯， 而它有時才答對的 78 個問題則成為了測試組。 相同的提示，沒有工具，且採用精確匹配評分，沒有 AI 評審， 因為評審也會漂移。 它通過無頭 Claude Code 在 Max 訂閱上運行，

1:55 因為 API 版本每月定價約為 1600 美元。 而 Claude Code 版本是固定的，因為，用儲存庫的話說， 改變的測試框架看起來就像改變的模型。 統計數據來自 Anthropic 的 Evan Miller 撰寫的論文《為評估添加誤差條》。 統計數據來自 Anthropic 的 Evan Miller 撰寫的論文《為評估添加誤差條》。 因此 Anthropic 自己的數學現在正在審核 Anthropic，這是學術版 將服務條款引述回客戶支援。

它能看到什麼：7.5 點，token 數量首先變化

2:19 問題二，它能看到什麼？ 每十天窗口，約下降 7.5 點。 為了證明這個裝置有效，作者故意降低了 Claude 的努力程度。 中等努力減少了約四分之一的輸出，分數只下降了四點。 低等努力減少了近三分之二的輸出， 導致八點的下降。 這就是值得竊取的部分。 思考減少會在 token 數量中先顯示出來，然後才在答案中顯示出來。

2:43 所以固定你的模型版本，記錄每個任務的輸出 token 數量， 並保留一些你自己的固定問題。 如果你的代理突然寫得更短，請在查看 Reddit 之前檢查你的日誌。 這是誠實的部分。

盲點：Opus 5 替換和 8 個錯誤的答案鍵

2:54 悄悄地換上舊的 Opus 5 對這個裝置來說變化太小，無法偵測到， 而 README 也開宗明義地這麼說。 審核還發現了八個看起來錯誤的答案鍵， 所以效能降低偵測器在發現效能降低之前就發現了基準中的錯誤。

Anthropic：我們從不降低模型品質

3:08 問題三，Anthropic 怎麼說？ 去年，在收到一波投訴後，Anthropic 發布了一份事後分析報告。 它寫道，引用：「我們從不因需求、時間或伺服器負載而降低模型品質」。 它寫道，引用：「我們從不因需求、時間或伺服器負載而降低模型品質」。 同一篇文章承認有三個錯誤導致 Claude 效能下降，近三分之一的 Claude Code 用戶至少有一次連接到錯誤的伺服器。 所以這些投訴是真實的，原因也是錯誤， 這就是為什麼儲存庫警告說發布週可能是最糟糕的一週。

3:35 30 天中已經過了 6 天。 第一個可能的結果大約在 10 月 24 日揭曉， 所以誠實的答案是，包括所有確信的人在內，沒有人知道。 說到沒有人發布的數字。

數據中心保密其數據；Backblaze 公開

3:46 Lighthouse Reports 和荷蘭報紙 Trouw 發現，絕大多數的 歐洲數據中心對其電力和用水量保密， 儘管歐盟法規已要求報告三年。 在荷蘭，發布的數據中心不到四分之一。 單是微軟的一個數據中心就使用了約 1% 的荷蘭電力。 同時，Backblaze 又做了無聊的事情。 其季度硬碟統計數據涵蓋約 35 萬個硬碟， 故障率升至 1.73%，

4:16 創下了一段時間以來的新高。 三個 Seagate 型號的故障率為零。 這就是公共基準的樣子，一個季度接著一個季度， 持續了十三年。

致謝：Claude 協助建立了計量器

4:25 現在，那個致謝行。 README 承認這個儲存庫的很多內容是借助 Claude 寫成的， 而 Claude 正是被測量的模型。 所以 Claude 幫助建立了這個檢查 Claude 是否變笨的計量器。 這就是為什麼評分器是純函數。 用作者的話說，你不應該信任作者， 無論是人類還是其他形式。 如果你寧願閱讀此內容而不是聽我說，The Daily Diff 會每天早上免費發送到你的收件箱，網址在 thedaily diff.dev，連結在下方。

4:46 每天早上都會免費寄到你的收件箱，網址是 thedaily diff.dev，連結在下方。 那麼，今天對 live nerf 的判決。

判決：SHIP IT，並在 10 月 24 日前不要引用

4:51 SHIP IT。我會 SHIP IT，因為這是我見過的第一個有時間戳、公開規則手冊和明確盲點的效能降低論點。 SHIP IT。我會 SHIP IT，因為這是我見過的第一個有時間戳、公開規則手冊和明確盲點的效能降低論點。 只是在 10 月 24 日之前不要引用它。 這就是今天的 The Daily Diff。 我是 Axrisi 的 Niko。 負責任地合併。

來源

1. livenerfgithub.com
2. Validationgithub.com
3. Hacker Newsnews.ycombinator.com
4. Anthropic postmortem (Sep 2025)www.anthropic.com
5. Adding Error Bars to Evals (Evan Miller)arxiv.org
6. Inspect (UK AI Security Institute)inspect.aisi.org.uk
7. NL Timesnltimes.nl
8. Hacker Newsnews.ycombinator.com
9. Backblaze Drive Stats Q2 2026www.backblaze.com
10. Hacker Newsnews.ycombinator.com