Opus 5 讓你降成本不降品質

以前我只看模型夠不夠強，現在我先看它能不能降成本還不把品質搞爛。

我用大模型一陣子了，最煩的就是每次升級都像在賭。要嘛模型很聰明，帳單也很聰明；要嘛便宜是便宜，但你得自己補一堆 guardrail，免得它答非所問。這種事我看多了，demo 都很漂亮，真正上線後，token 成本、延遲、fallback、prompt 漂移一起來，整個人就只剩下想把儀表板關掉。

這次讓我停下來看的，是 Claude Opus 5 的說法：品質先別掉，成本先下來。我是從這篇中文整理和 Anthropic 官方頁面開始追的：Zhihu 原文，以及 Anthropic 官方網站。我不是把它當研究論文讀，我是把它當一個訊號：這次講的不是更大顆的模型，而是更好塞進產品裡的模型。

我先不買「更強」這張票

Claude Opus 5 的核心賣點，是在維持高品質的前提下，把使用成本壓下來。

翻譯一下就是，這次的重點不是再做一個只適合拿來拍 benchmark 截圖的東西，而是讓你在真實產品裡比較敢用。這差很多。因為多數團隊卡住的點，從來不是「有沒有最強模型」，而是「我敢不敢把它設成預設」。

我自己踩過這個坑。以前只要模型一貴，產品經理就開始問：這個功能一定要叫旗艦模型嗎？客服問答能不能便宜一點？摘要是不是可以縮短？最後整個團隊都在做成本腦內審核，功能還沒上，先把自己嚇死。

實操上，我會把模型升級當成單位經濟問題，不先當成技術浪漫問題。你要看的不是「每 token 多便宜」，而是「每個成功任務到底花多少」。

• 先算 cost per successful task
• 再看真實 prompt 長度下的 latency
• 最後看 fallback 觸發率有沒有下降

如果新模型讓成功率持平，成本下降，那才叫升級。只是在簡報上看起來漂亮，我不會動。

真實世界的 prompt 都很髒

模型發表文最愛拿乾淨輸入來秀，這件事我早就看膩了。真實產品裡的 prompt 哪有那麼乖？系統提示詞通常是半年來東補西補的，工具 schema 是從不同 repo 拼來的，使用者還會故意把問題寫得像在跟客服吵架。這種場景才是模型真正要活下去的地方。

我看到這篇整理時，最有感的不是它把 Opus 5 講得多厲害，而是它把這個版本放在一個很實用的框架裡看：不是只看能力，而是看它能不能真的進工作流。這點我很買單，因為我在意的是它面對爛輸入時會不會崩。

白話講，就是你不要拿整理過的範例測它，要拿你現在 production 裡最難看的那些 prompt 測它。

我自己會做一份小型 torture set，通常長這樣：

• 半句話就結束的需求
• 缺欄位的 tool call
• 前後互相打架的 follow-up
• 長上下文裡藏著一個很晚才出現的限制

實作時，我會先拿現有流量抽 50 到 100 筆，直接跑新舊模型比對。不要先看漂亮案例，先看那些會讓你皺眉的案例。模型如果連這種都能撐住，我才會繼續往下談。

降價有用，前提是你真的改預設

很多人看到價格下降就很興奮，然後什麼都不改，這我真的看不懂。你如果只是把 spreadsheet 上的數字改掉，架構不動、路由不動、fallback 不動，那你省下來的錢只會變成心理安慰。

真正有用的情況，是這個降價讓你能把更多任務往上搬一層。原本覺得太貴不敢用的地方，現在可以直接用旗艦模型；原本要拆成兩段處理的流程，現在可以縮成一段。這種改法通常比加一個新功能更有感，因為它會直接減少分支和 bug。

我以前做內部助理時就遇過這種事。原本太貴的模型，一旦成本降下來，就能拿去做 drafting、summarizing、tool planning。結果不是只有品質提升，連 glue code 都少了很多。少掉那些奇怪的 if else，晚上也少接幾次事故電話。

實操上，我會這樣切：

• 便宜但夠強的模型先做第一輪生成
• 超簡單任務交給小模型做分類和路由
• 高風險任務才叫更貴的 fallback 出來

你要做的不是追新名詞，而是重新決定哪個模型該當預設。只要預設一變，整個產品的成本結構就會跟著變。

安全討論已經不是旁白

這次的整理也提到 Anthropic 跟美國政府互動的時點，還有整個產業最近被安全事件拉高的敏感度。這種背景我不會拿來炒作，但我也不會假裝它不重要。現在模型選型早就不是單純工程師喜不喜歡，還牽涉產品風險、合規風險，甚至品牌風險。

所以我現在看一個旗艦模型，第一個問題不是 benchmark，而是 failure mode。它拒答會不會太保守？正常工作流會不會被它搞得像在過安檢？它是真的比較安全，還是只是比較愛說不？這些東西最後都會反映在客服單量上。

也就是說，你要測的不只是答案好不好，還有拒答的形狀對不對。太保守的模型，常常會把正常任務也弄成半拒絕狀態，使用者只會覺得你產品變笨了。

我會把安全 regression 直接放進評估流程：

• 應該正常回答的問題
• 應該拒絕的問題
• 需要先問清楚的模糊問題
• 未經確認不能執行的工具動作

如果新模型讓拒答風格整個變掉，我希望自己先知道，不要等使用者先罵。尤其是旗艦模型，貴不代表可以亂來。

把它當路由問題，不要當英雄故事

我很討厭一種習慣：把一顆 flagship 模型當成萬能主角。這種做法最後通常會得到一個超長 prompt、一張超大帳單，外加一堆人假裝這樣很正常。比較好的做法，是把模型放進路由系統裡，讓它做它擅長的事。

如果 Opus 5 的定位真的是「品質還在、成本更好」，那它的價值不是讓你膜拜，而是讓你敢把更多工作交給它。像是 synthesis、複雜規劃、混亂上下文、multi-step tool use 這些地方，旗艦模型本來就比較值得。

實作上，我會直接把任務切成三層：

• 低複雜度：分類、擷取、路由
• 中複雜度：草稿、摘要、改寫
• 高複雜度：推理、規劃、多步驟工具使用

然後把模型對應到層級。若 Opus 5 真的夠強又夠便宜，它就往中高複雜度預設靠。這才是實際收益，不是「我們用了最新模型」這種空話。

我只信自己的 logs，不信漂亮圖

我被 benchmark 騙過太多次了，所以現在看到圖表都會先冷靜一下。benchmark 有參考價值沒錯，但它不會告訴你使用者會不會亂問、工具會不會延遲、某個壞答案會不會一路炸到客服。真實世界的痛點，通常都藏在 logs 裡。

這篇整理把 Opus 5 放在一個很有壓力的產業背景裡看，我覺得合理。但對我來說，最後還是只有一個問題：它有沒有減少我產品裡真正的摩擦？

所以我不會直接喊換。我會先做 controlled migration，拿同一批流量去比，然後留 rollback。這才是上線，不是朝聖。

實操時我會看這幾個指標：

• 抽 100 到 500 筆真實 request
• 用內部 rubric 評分答案品質
• 量 latency 和 retry rate
• 看使用者可見失敗，不只看模型輸出

如果 Opus 5 在你的 logs 裡贏了，那就上；如果只是 demo 贏了，我會繼續用原本那套，省得自己找麻煩。

可抄的模板

# Claude Opus 5 rollout template for a real product

## Goal
Adopt Opus 5 only if it keeps quality stable while reducing total model cost.

## Decision rule
Ship the new model when all three are true:
- cost per successful task goes down
- latency stays within your acceptable range
- user-visible quality does not drop on real traffic

## Evaluation set
Use 50-100 real production prompts, including:
- clean requests
- messy requests
- contradictory follow-ups
- long-context prompts
- tool-use prompts with missing or partial fields

## Scoring rubric
Rate each response from 1-5 on:
- correctness
- completeness
- instruction following
- refusal behavior
- tool-call quality
- latency

## Routing policy
- low complexity: extract, classify, route
- medium complexity: draft, summarize, rewrite
- high complexity: reason, plan, multi-step tool use

## Rollout plan
1. Shadow test on real traffic
2. Compare old and new outputs side by side
3. Measure cost, latency, and failure rate
4. Roll out to 10%
5. Roll out to 50%
6. Roll out to 100% only if metrics hold

## Safety checks
Add regression cases for:
- normal requests that should be answered
- requests that should be refused
- ambiguous prompts that need clarification
- tool actions that require confirmation

## Rollback trigger
Revert if any of these happen:
- quality drops on core tasks
- refusal rate rises unexpectedly
- latency spikes beyond threshold
- support tickets increase after rollout

## Notes
Keep the old model available for at least one release cycle so rollback stays cheap and boring.

這段模板就是我會直接拿去做 Opus 5 評估的版本。它故意寫得很無聊，因為無聊才代表你真的有機會把模型換上去，而不是把自己送進事故處理群組。

原始來源是 這篇 Zhihu 整理，它再指向 Anthropic 官方頁面。上面關於 rollout、路由、評估和模板的部分，是我根據這個脈絡做的實作版整理，不是原文逐字複製。