Opus 5 讓你少碰拒答

以前模型一拒答就斷線，現在 Opus 5 能把安全檢查變成可用輸出。

我最近一直在看 Anthropic 的模型更新，老實講，前幾代我用得有點煩。不是它不強，是它太容易在我最需要它出手的地方踩煞車：安全分類器一抖，回覆就變成拒答；我想做的是產品流程，它回我的是政策邊界。你如果也做過 agent、內部工具、客服輔助或 code review，大概懂那種火氣：模型明明看得懂，卻硬是把你丟回起點。

這次我被拉回來看，是因為 TechCrunch 的 Opus 5 報導，再加上 Anthropic 自己把 Automatic Fallbacks 放進文件。我不是被行銷詞打動，我是看到一個很實際的訊號：他們終於在處理「拒答後怎麼不要讓使用者整個卡死」這件事。這比模型名字聽起來多厲害，重要太多。

我在意的不是更會講，是更少卡住

“Opus 5 was much stronger at verifying its work and iterating carefully until it succeeds.”

這句話我覺得很誠實。它沒有在吹什麼花俏能力，直接講模型會不會把事情做完。翻譯一下就是：它不是只會給你一個看起來漂亮的答案，而是會自己回頭檢查、補洞、重試，直到能交差。

我自己最怕的就是那種「第一句很像對的」模型。它一開始講得很順，結果中間漏了一個條件，後面就一路錯到底。你如果拿它做 agent，錯一次常常不是錯一次，是連鎖錯。這種時候，會驗證自己、會重試、會慢一點但把事做完的模型，反而比較像能上線的東西。

我之前做過一個內部資料整理工具，模型很會寫摘要，但每次遇到多步驟抽取就開始亂補。使用者看起來有收到東西，實際上資料欄位一半是猜的。後來我才懂，能力不是只有「答得像」，而是「答得能收尾」。

實操上我會這樣用：

• 把 Opus 5 放在需要多輪修正的任務：規劃、debug、資料轉換、工具調用。
• 要求它在最後輸出前列出檢查步驟，尤其是 code 或結構化資料。
• 評估時別只看一次答對率，還要看它能不能在第二輪自己修回來。

便宜一點，才真的能拿來當預設

Anthropic 這次把 Opus 5 描述成更便宜、限制更少的選擇。這點我很買單，因為大模型真正麻煩的地方常常不是 token 費，而是你得替它補一堆流程洞。你本來以為自己在買算力，結果最後在養路由器、重試器、例外處理和客服工單。

如果一個更強的模型，還同時比較便宜、比較不容易拒答，那它就不該只是「高級選項」，而該變成預設。這會直接改掉你的架構設計：你不用為了省錢硬切到小模型，也不用因為怕拒答就先塞一堆保守提示詞把模型綁死。

我以前很常看到團隊把模型分層分到很累：A 類走便宜模型，B 類走大模型，C 類再加一層人工審核。結果真正的成本不是推理費，是維護這套分流規則的人力。模型一旦比較穩，很多這些補丁就能少一點。

實操上我會這樣調整：

• 先檢查你現在的 routing 規則是不是過度保守，動不動就降級。
• 看整體成功率，不要只看單次成本。
• 把「因拒答而重試」當成一個要量化的指標，別讓它躲在客服抱怨裡。

安全檢查還在，但不要每次都把路堵死

Anthropic 沒有假裝安全層不見了。文件和報導都提到，像 exploit 生成、滲透測試這類偏攻擊性的內容，還是會被擋；但他們也說，Opus 5 觸發這些分類器的頻率會比前一代低很多。數字我直接照文件脈絡講，重點是方向：少一點誤判，多一點可用性。

這件事我覺得很實際。安全層的存在我不反對，反而是必需品；我反對的是那種一刀切，明明是防禦性分析，卻被當成攻擊指令。你如果在做 source code review、風險掃描、內部紅隊輔助，模型應該先理解意圖，再決定要不要踩煞車。

我之前做過一個資安審查工具，團隊明明是在查防禦面問題，模型卻一直把 prompt 當成可疑攻擊流程。最後使用者學會了怎麼繞詞，結果 prompt 變得更長、更假、更難維護。那不是安全，那是把人逼去寫暗號。

實操上我會這樣設計：

• 把防禦性工作和攻擊性工作分開寫 prompt，不要混在一起。
• 一開始就講清楚用途：是分析、審查、偵錯，不是產生攻擊步驟。
• 把 classifier 觸發次數記錄下來，觀察到底是安全真的生效，還是在亂擋。

Automatic Fallbacks 才是能上線的那段

我覺得這次最值得抄的，不是模型本身，而是 Automatic Fallbacks。意思很簡單：當安全分類器擋下來時，不一定直接丟錯誤，而是可以轉去比較弱、比較保守的模型，先給使用者一個還能用的結果。

翻譯一下就是：別讓一次拒答變成整個流程死亡。這個想法很土，但很對。因為大多數產品根本不需要模型在每個瞬間都完美通過政策檢查，它們需要的是使用者不要卡住。就算答案比較保守、比較短、比較不像大模型，也比空白頁強。

我很喜歡這種做法，因為它承認一件事：拒答有時候是對的，但把拒答包成硬錯誤，通常只是 UX 很爛。你如果能把它降級成可控 fallback，產品就比較像產品，不像 demo。

我以前做過一個客服輔助工具，最痛的不是模型答錯，而是它直接不回。客服人員面對空白結果，只能重送、改寫、猜 prompt。後來我們加了 fallback，哪怕答案比較保守，至少能先把工單往前推。那種「先有東西，再慢慢修」的節奏，真的差很多。

實操上我會這樣做：

• 對使用者介面來說，fallback 預設比硬拒答更好。
• fallback 模型只做低風險任務，不要讓它偷偷升級成另一個大腦。
• 把 fallback 事件寫進 log，否則你根本不知道主模型是不是太常踩線。

我會先看三個數字，再決定要不要全切

我不會看到新模型就整套搬過去。這種事最容易翻車。真正該看的只有三個：拒答率、fallback 品質、以及它到底有沒有真的減少後續修正。這三個指標如果沒變好，再強的敘事都只是換包裝。

也就是說，評估不要做成儀式，要做成營運。你要看的是：第一次或第二次回合，能不能拿到可用答案；fallback 有沒有保住原本意圖；安全層有沒有保護系統，同時又沒把正常工作都擋掉。

我自己會把評估拆成兩層。第一層看產品：使用者有沒有卡住、客服有沒有爆、任務有沒有完成。第二層看工程：路由邏輯有沒有太複雜、例外處理有沒有越寫越厚、日誌有沒有能回頭追。這樣你才知道問題是模型、策略，還是你自己架太爛。

如果這三個數字都往好的方向走，Opus 5 才值得當預設。否則它只是另一個名字比較好記的選項。

可抄的模板

# Anthropic Opus 5 production playbook

## 1) Primary model
Use Opus 5 first for:
- multi-step reasoning
- code generation and repair
- defensive security analysis
- tool-heavy agent workflows
- tasks that need self-verification

## 2) Prompt style
State intent early and plainly:
- "This is for defensive analysis only."
- "Review the code for vulnerabilities."
- "Do not generate exploit instructions."
- "Check your work before answering."

## 3) Routing logic
1. Send the request to Opus 5.
2. If the safety layer blocks it, do not show a raw error first.
3. Route to a smaller, safer fallback model.
4. Return the fallback result if it still fits the user’s intent.
5. If the request is clearly malicious, return a policy-safe refusal.

## 4) Fallback policy
Fallback is allowed only when:
- the request is safe but over-triggered
- a partial answer is better than no answer
- the fallback can preserve the original intent

Fallback is not allowed when:
- the request is offensive security guidance
- the request is obviously malicious
- the fallback would hide a real policy violation

## 5) Logging
Log these fields:
- request id
- original prompt category
- safety trigger reason
- primary model result
- fallback model used
- usable-answer flag
- manual-correction flag

## 6) Evaluation checklist
Track weekly:
- refusal rate
- fallback rate
- usable-answer rate
- manual correction rate
- time to resolution
- user-reported dead ends

## 7) Minimal implementation sketch
request -> Opus 5
  if allowed:
    return response
  if safety-triggered and fallback enabled:
    route to smaller model
    return fallback response
  if still unsafe:
    return policy-safe refusal with a short explanation

## 8) Team rule
Treat safety failures as routing events.
Treat hard refusals as the last resort, not the default UX.

我拆這篇的原始來源是 TechCrunch，以及 Anthropic 的 Automatic Fallbacks 文件。上面關於怎麼落地、怎麼評估、怎麼寫模板，是我自己把這些材料翻成開發者能直接拿去用的版本。