Claude Code 不是變笨,是被管理壞了

Claude Code 不是變笨,是被管理壞了。

Anthropic 4/23 發了一篇很值得看的 post-mortem,正式承認過去一個月 Claude Code / Claude Agent SDK / Claude Cowork 的使用體感確實下降。

但最有趣的不是「Claude 翻車了」。

而是 Anthropic 說:API 跟 inference layer 沒問題,模型本身也沒被故意降級。真正出問題的是產品層的三個改動 — reasoning effort、context / cache 管理、system prompt。

換句話說,這次不是模型退化。

是模型外面那整套讓它工作的系統,把它管笨了。

1. 三個優化都在砍同一個地方

這次三個問題,單看每一個都很合理。

3/4,為了降低延遲,Claude Code 的 default reasoning effort 從 high 改成 medium。結果複雜 coding task 的體感下降,4/7 revert。

3/26,為了讓 idle 超過一小時的 session 恢復時不要吃掉太多 token,Anthropic 做了 cache optimization。結果一個 bug 讓系統不是只清一次舊 thinking,而是後面每一輪都繼續清。Claude 開始健忘、重複、亂選工具,4/10 修掉。

4/16,為了降低 verbosity,在 system prompt 裡加了一條類似「tool calls 之間文字不超過 25 字、final response 不超過 100 字」的限制。結果 coding quality eval 掉了,4/20 revert。

這三個改動表面不同,但都在做同一件事:

讓 Claude Code 更快、更省、更短。

問題是,在 AI agent 裡,「更省」常常不是免費的。你省下來的,可能是 latency,也可能是不小心省掉了思考深度、上下文記憶和判斷品質。

2. 儀表板上沒有「智力」這一欄

這件事最值得產品和技術管理者注意的地方,是它很像一個 KPI 管理問題。

CTO 的儀表板上通常會有 latency、token cost、request volume、error rate、availability。

但很少有一欄叫做「智力」。

• 延遲 -5%,你看得見
• 成本 -10%,你看得見
• 輸出長度 -30%,你也看得見
• 但判斷力 -3%,你不一定看得見

你可能只會在幾天或幾週後,從工程師抱怨、客服回報、Reddit、X、HN 討論裡,慢慢聞到一個味道:怎麼最近怪怪的?

這也是為什麼 AI 產品很容易被「看得到的效率指標」帶著走。

傳統軟體裡,我們很熟悉這件事:如果團隊只看 story points,就可能開始做很多低價值任務;如果只看 ticket close rate,就可能犧牲真正的問題解決。

在 AI agent 裡也一樣。

如果只看 latency、token、verbosity,最後可能會不小心把最重要但最難量化的東西磨掉:思考深度。

3. LLM 的 bug 活在分佈裡

這次 post-mortem 裡最震撼我的,不是三個 bug 本身,而是 Anthropic 承認:一開始他們的內部使用和 eval 沒有重現問題。

而且其中一個 cache bug,通過了多層 human code review、automated code review、unit test、E2E test、automated verification、dogfooding,最後還是漏了一週。

這很值得想一下。

傳統 QA 的世界裡,bug 常常是 boolean。

輸入 A,應該輸出 B。沒有輸出 B,就是壞了。

但 LLM 產品的 bug 很常不是這樣。

它比較像 distribution shift。

輸入 A,大部分時候還是會輸出一個看起來像 B 的東西。但平均品質下降一點、推理深度淺一點、上下文記憶弱一點、工具選擇怪一點。

最麻煩的是,這種 bug 不一定會噴 error。

它會偽裝成「好像還能用,只是最近比較笨」。

這對所有 AI 產品團隊都是一個提醒:傳統測試還是需要,但不夠。你還需要能測 distribution 的 eval、需要真實工作流的回歸測試,也需要把 power user 的體感當成早期警報,而不是當成網路抱怨。

4. Prompt 就是 production code

這次事件也再次提醒一件事:system prompt 已經不是一段文字了。

它是 production code。

一句看起來無害的 prompt change,可能造成品質 regression。一個 default setting,可能改變使用者對整個模型的信任。一個 context pruning 或 cache optimization,可能讓 agent 忘記自己剛剛為什麼做了那個決策。

以前我們改 code 會有 code review、unit test、integration test、staging、canary、rollback。

但很多團隊改 prompt 的方式,還停留在「我覺得這句寫得比較清楚,先上看看」。

AI 進 production 之後,這會越來越危險。

• Prompt 需要版本控管
• Context pruning 需要測試
• Default setting 需要分群 rollout
• Agent behavior 需要 regression eval
• 所有可能影響「智力」的改動,都需要 soak period 和 rollback plan

這些聽起來很工程,但它們其實是信任的基礎。

5. Harness 會成為新的基本功

這次事件讓我更確定一件事:AI 產品會長出一個新的專業領域。

不是訓練模型,也不是單純寫 prompt。

而是設計和維護 AI harness。

Harness 這個詞有點工程宅,但它其實就是模型外面那整套讓它能工作的系統:

prompt stack、tool routing、context compaction、cache policy、permission model、eval、rollout、telemetry、rollback。

過去做 SaaS,我們會在意 database schema、auth、queue、log、observability。

未來做 AI agent,還會多一層 behavior infrastructure:

• 它看得到什麼?
• 它記得多久?
• 什麼時候該多想?
• 什麼時候該問人?
• 怎麼驗證自己做對?
• 怎麼在不確定時安全失敗?

這些東西在 demo 時通常不是最炫的部分。

Demo 要的是 wow moment。

Production 要的是下週同一類任務還能穩定做好。

Claude Code 這次事件示範了:一個錯的 harness 改動,可以讓 frontier model 看起來像退化;反過來,一個好的 harness,也可以讓模型在真實工作流裡穩定發揮。

上週我寫的 Token 越省越貴,講的是使用者如果只想省 token,反而可能燒掉更多錢。這週 Anthropic 親自示範了另一面:AI 公司如果只想讓產品更快、更省、更短,也可能不小心犧牲掉使用者真正需要的品質。

這兩件事其實是同一個硬幣的兩面。

在 AI 產品的世界裡,「省」不是中性動詞。

它永遠在跟思考深度、上下文、穩定性做交換。

後記

我反而覺得 Anthropic 這次願意公開拆解問題,是一件正面的事。

出包就是出包,尤其 Claude Code 是很多工程師每天重度依賴的工具,這種體感下降會直接傷害信任。

但這篇 post-mortem 有價值,因為它把一個很多人模糊感受到的問題,拆成了可以被討論、測試、修正的系統問題。

早期大家看模型分數。 接下來大家看 agent 能不能完成任務。 再往後,大家會看整套 AI work system 是否可靠、可觀測、可回滾。

身為產品人和技術管理者,我越來越相信:AI 導入的重點不是買到最強模型。

而是設計一套讓強模型穩定發揮的制度。

模型會越來越強,但真正決定落地品質的,會是那些看起來很無聊的東西:default、prompt、context、cache、eval、rollback。

也就是那些以前我們在 software engineering 裡學過,但現在要重新套用到 AI agent 上的基本功。

The model is not the product. The system is.

PS

Anthropic 這份 post-mortem 本身寫得非常誠實,值得任何做 AI 產品的人完整讀一遍。雖然我猜很多工程師讀完的第一反應應該是:原來不是我變笨,是它真的變笨了。咦?

參考資料:

• Anthropic 官方事後報告
• Hacker News 討論串