Claude Opus 4.6 → 4.7 升版後 clarification 少了 40%：這是 feature 不是 bug，但你的 pipeline 準備好了嗎
模型升版這件事，我們團隊有個不成文規定：不看 changelog 就不升版。
不是因為特別謹慎，是因為被踩過。去年把某個 wrapper service 底層模型升了一版，沒確認 system prompt 有沒有變，結果 response 格式悄悄改了——原本穩定回一個 JSON，升版後多了 preamble，我們的 parser 直接吐 500。那次影響了三個下游服務，debug 花了半天，git blame 全指向「就那次升版」。
從那之後，每次升模型，我都會先 diff system prompt。
Simon Willison 最近做了件蠻有用的事，把 Anthropic 歷版的 system prompt 抽出來建了個 git 歷史，可以直接看 diff。Opus 4.6 → 4.7 有幾個地方讓我注意到：新增了「有工具可以解歧義時，先呼叫工具，不要先問使用者」的邏輯；任務做到完整答案，不要中途停；回覆更精簡；還有個新的 tool_search 機制。
前兩點對我們的 agentic pipeline 影響是直接的。
升版之前我會做的事
我們現在有個很土砲但有效的流程：
- staging 環境 pin 住舊版模型
- 跑一批 golden test cases（大概 50 個典型 input/output 對）
- 計算 semantic similarity（cosine，threshold 0.85）
- pass rate 掉超過 5% 就 flag 出來人工看
這個 pipeline 不是為了攔截「壞」升版，是為了把差異顯性化。模型升版不是非對即錯的問題，是行為漂移的問題。讓工程師知道哪裡漂了，比讓他們猜要有用得多。
4.6 → 4.7 的測試結果：semantic similarity 整體掉了約 3%，沒超門檻，但有幾個 case 明顯不一樣——主要集中在「模型會直接 call tool 而不是先問 clarifying question」這件事上。
說穿了就是：之前有些 case 我們設計讓 Claude 先確認意圖再執行，4.7 改成「有 tool 就用 tool 解歧義」，那些 case 直接跳過問答跑 tool 了。
這是好事還是壞事
取決於你的 pipeline 怎麼設計。
如果 tool 的副作用很低（查 db、fetch API），先用 tool 解歧義快多了，使用者也不用等一來一往。
但如果 tool 會觸發 side effect（發通知、寫資料），「少問直接做」就是個風險。
我們有個 case 是讓 Claude 判斷要不要寄出 alert email。4.6 它會先問「確定要發嗎」，4.7 直接就發了——因為「發 email」是個 tool，有 ambiguity 的時候它優先 call tool 解決。
這個 behavior 改變在 system prompt diff 裡是看得到的，但你要先知道去看。
回滾策略的實際樣子
我們的做法是 model version 跟 feature flag 綁在一起：
features:
model_version: "claude-opus-4.6"
# per-service override:
email_alert_service:
model_version: "claude-opus-4.6" # pin 舊版，等 workflow 調整好再升
search_service:
model_version: "claude-opus-4.7" # 這個 service 沒有副作用，先升
回滾不是整個 system 打回去，是 per-service 控制。低風險的服務先享受新版（4.7 的回覆更精簡對 UX 是正面的），高風險的先留在舊版做調整。
調整方式也不是改 code，是修 system prompt：在高副作用的 tool 描述上加 explicit instruction，告訴模型這個 tool 執行前一定要 confirm。有點繞，但比把邏輯 hardcode 在 application layer 好維護。
可觀測性要加的 metric
除了 golden test，production 我們加了幾個 metric 盯著：
llm_clarification_count：Claude 主動問 clarifying question 的次數llm_tool_before_ask_count：直接呼叫 tool 沒有先問的次數- `llm_respons
e_token_p95`：回覆長度的 p95
升版後前兩週，把這些 metric 的 alert 門檻調緊一點，異常立刻 flag。
4.6 → 4.7 升版後，llm_clarification_count 掉了大概 40%，llm_tool_before_ask_count 升了差不多同比例。這個數字跟 system prompt 說的邏輯對得上。不是 bug，是 designed behavior，只是要確保你的 workflow 準備好接這個行為。
模型升版不是 infra 升版
infra 升版（k8s 版本、DB 版本）通常有明確的 migration guide，breaking change 列得清楚。模型升版不是，它的 changelog 是 system prompt diff 加上一些你要自己去感知的行為變化。
說穿了就是：把模型升版當成一個需要 diff + test + canary + rollback plan 的 deployment 來管，才是正確的對待方式。不是換個 string 這麼簡單的事。
4.7 整體值得升，tool_search 和回覆精簡的方向符合我們的目標。但升版的方式決定你踩坑的機率，這個部分沒有捷徑。
作者：CtrlC