AI 商業案例｜2026/09/23：5 人軟體維護工作室怎麼用 Claude Opus 5.5？日常開發先跑 Opus，查找交小模型，卡兩次才升 Fable｜文章

這是一個 SasaDaily 假設案例。一家 5 人軟體維護工作室每週同時處理 Bug、小功能、Log 查找、Code Review 與少數大型改版，如果所有工作都直接開最貴模型，AI 雖然快，成本卻很難控制。團隊改成三層分工：Search／Log Reading 交給較便宜模型，日常 Feature、Debug 與 Review 預設使用 Claude Opus 5.5，只有 Opus 5.5 High 在同一問題卡兩次才升 Claude Fable 5.1；所有 Merge、Production Deploy 與客戶範圍變更仍由人批准。真正要優化的不是 Token 單價，而是每個完成任務的

這是一個 SasaDaily 假設案例。

不是 Anthropic 公布的真實客戶成效。

假設有一家：

5 人軟體維護工作室。

平常替幾家中小企業維護：

官網。

會員系統。

後台。

API。

內部工具。

每星期進來的工作非常雜。

可能是：

找一個 Error Log。

改一個欄位。

修一個 Bug。

加一個小功能。

做 Code Review。

也可能突然出現：

跨 API、Frontend、Database 的大型問題。

如果全部工作一進來就直接使用：

最貴、最強的模型，

確實很簡單。

但月底很容易發現：

AI 做得很快，帳也長得很快。

這家公司真正要管理的不是「要不要用 AI」

AI Coding 已經是日常工具。

真正的問題變成：

哪一件工作，值得用哪一級模型？

所以團隊不再規定：

「全部用最強模型。」

而是先把工作拆成三層。

第一層：查找型工作

例如：

搜尋 Function 在哪裡。

讀 Log。

找 Error Code。

查某個 Package 文件。

列出哪些 Files 引用了某個名稱。

這類任務主要需要：

找到東西。

不一定需要最強的推理。

因此先交給：

較便宜的小模型

或專門的 Search Subagent。

第二層：真正的日常開發

例如：

修一個 Bug。

修改幾個互相相關的 Files。

增加小功能。

Code Review。

依照既有 Pattern 修改 API。

這一層預設使用：

Claude Opus 5.5。

第三層：真正卡住的工作

例如：

跨多個 Service 的 Architecture Problem。

沒有既有 Pattern。

需要長時間無人監督。

牽涉多個 Subagents。

或者：

Opus 5.5 High 已經在同一問題失敗兩次。

這時才升級：

Claude Fable 5.1。

真正的規則不是：

「最難模型優先。」

而是：

「剛好夠用的模型優先。」

早上第一張 Ticket：只是查 Log

例如客戶回報：

「昨天晚上付款頁偶爾出現 Error。」

工程師第一件事不是叫 Fable 5.1：

「把整個系統查一遍。」

而是先讓便宜模型處理：

昨天特定時段 Log。

找出：

Error Pattern。

出現次數。

相關 Endpoint。

可能牽涉的 File。

最後只回給主工程師：

真正需要看的 3～5 個位置。

如果只是：

第三方 API Timeout，

甚至可能不需要高階模型介入。

為什麼查 Log 不要一開始就用 Opus？

不是因為 Opus 做不到。

而是：

這一步真正的 Bottleneck

不是：

複雜 Reasoning。

而是：

大量閱讀＋搜尋。

Anthropic 對 Claude Code 的成本建議也很明確：

Search。

Lookup。

Log Reading

這類 Subagent，

可以考慮較便宜模型。

真正需要：

Code Editing。

Debugging。

Feature Work

再交給 Opus 5.5。

這就是：

Model Routing。

第二張 Ticket：客戶要新增一個小功能

例如客戶說：

「後台訂單頁新增一個『待人工確認』狀態。」

這就不是單純 Search。

可能同時要改：

Database Enum。

Backend Validation。

API Response。

Frontend Badge。

Tests。

團隊把它交給：

Opus 5.5 Medium。

先讓模型：

找全部相關 Call Sites。

整理修改範圍。

再一次修改。

跑 Test。

為什麼先用 Medium？

Anthropic 對 Opus 5.5 的建議是：

日常、

範圍清楚、

有人監督的工作，

Medium 通常是一個合理起點。

因為工程師正在旁邊看。

如果 Claude：

跑錯方向。

漏一層。

工程師可以立刻介入。

不需要每一件工作都先支付：

最高 Effort

的 Thinking Cost。

但「省 Thinking」不是最高目標

假設 Medium 修改完：

Backend Test 通過。

工程師卻發現：

Frontend 還在送舊 Field。

這時有兩種可能。

第一種：

只是沒有一個完整 End-to-end Test。

那就先補：

Validation。

Test。

第二種：

模型確實沒有往更深的 Dependency 找。

這時再把：

Effort

提升到：

High。

不要第一秒就：

換 Fable。

Anthropic 自己也提醒：Retry 很貴

因為 AI Agent 工作不是一次 Request。

而是一個 Loop。

看 Code。

↓

用 Tool。

↓

看結果。

↓

再修改。

↓

再跑 Test。

每多一輪，

前面的 Context

還要再跟著送一次。

所以：

「便宜做錯三次」

可能比：

「稍微多想一次直接做完」

更貴。

團隊真正追蹤的是：

完成這一張 Ticket 花多少。

不是：

某一次 Request 有多便宜。

第三張 Ticket：大型跨系統 Bug

假設問題變成：

會員續約後，

Payment Service 已成功扣款，

但：

CRM 狀態沒有更新。

Email 又重複寄兩次。

這時可能牽涉：

Payment Webhook。

Queue。

Database Transaction。

CRM Integration。

Email Worker。

Retry Logic。

工程師先讓：

Opus 5.5 High

處理。

如果：

第一次找到部分問題。

修完仍失敗。

第二次又卡在：

相同 Root Cause，

這家公司設定一條很簡單的規則：

不要再跑第三次。

直接升級：

Fable 5.1。

為什麼設定「兩次」？

這不是 Anthropic 的硬性技術限制。

而是一個 Workflow Rule。

Anthropic 自己在 Opus 5.5 成本指南中也提出類似建議：

如果 Opus 5.5 High

在同一問題：

卡兩次，

就升級更強模型。

問題解掉後：

再切回 Opus 5.5。

原因很簡單。

最貴的不一定是：

高價模型。

有時候真正最貴的是：

一直讓不適合的模型重試。

解掉最難的部分後，不要整個 Project 都留在 Fable

例如 Fable 5.1 最後發現：

Queue Retry

和：

Webhook Idempotency

互相衝突。

Root Cause 已經找到了。

接下來只是：

修改三個 Files。

補 Tests。

整理 PR。

那就可以：

切回 Opus 5.5。

不要因為：

Fable 解掉一個難題，

接下來所有：

Rename。

Tests。

Documentation。

都繼續用最貴模型。

這就是這家公司最核心的：

Escalate → Solve → Step Down。

QA 也不再只問「AI 說完成了嗎？」

模型完成修改之後，

一定要有：

真正可以驗證的東西。

例如：

Unit Tests。

Integration Tests。

Build。

Lint。

API Test。

這家公司規定：

沒有 Test Evidence，

不進：

Human Review。

因為：

AI 自己說：

Done

不是 Verification。

AI 能自己跑 Test，反而可能更省錢

看起來：

多跑一次 Test

也是 Token。

也是 Turn。

但如果 Test 能在模型第一次改錯時：

立刻 Fail，

它可以當場修正。

比起：

AI 說完成。

人工隔天才發現錯。

重新開 Session。

重新載入 Context。

重新解釋一次。

通常更划算。

所以：

Verification 本身不是浪費。

沒有 Verification 造成的：

重做

才可能更貴。

最後一道線：Merge 還是由人決定

即使：

Opus 5.5 Code Review 沒找到問題。

Tests 全綠。

QA 也通過。

這家公司仍然不讓 AI：

自動 Merge Production Branch。

工程師必須確認：

實際改了哪些 Files？

是不是超出原 Ticket Scope？

Migration 有沒有風險？

Rollback 怎麼做？

客戶原本要求的功能有沒有被偷偷擴大？

最後：

Human Merge。

Production Deploy 也不交給模型自行決定

Deploy 前還要確認：

Backup。

Migration Window。

Environment。

Monitoring。

Rollback。

客戶可接受的 Downtime。

因為：

程式碼正確

和：

現在適合上 Production

是兩個不同問題。

AI 可以協助：

建立 Deployment Checklist。

整理 Change Summary。

產生 Rollback Draft。

但：

真正按下 Deploy

仍然要由人批准。

這家公司每天真正看的不是 Token Price

每張 Ticket 完成後，

團隊只記幾個東西：

用了哪個 Model。

Effort。

跑幾個 Turns。

有沒有 Retry。

Human Review 花多久。

最後一次是否通過。

以及：

整件工作的 Estimated Cost。

真正 KPI 是：

Cost per Completed Ticket。

不是：

Cost per Million Tokens。

假設一星期有 30 張 Ticket

以下只是：

SasaDaily 假設測算。

假設工作室一週收到：

30 張技術工作。

其中：

12 張是 Search／Log／Lookup。

14 張是一般 Bug／Feature／Review。

4 張比較複雜。

如果以前做法是：

30 張全部直接使用最高階模型，

Model Cost 先假設：

每週約 150 美元。

現在改成：

12 張簡單任務先走低成本模型。

14 張使用 Opus 5.5。

4 張先 Opus 5.5 High。

真正解不掉的少數問題才升 Fable。

假設最後每週 AI Usage Cost：

降到：

95 美元。

單看 AI 成本：

每週少：

55 美元。

四週約：

220 美元。

這全部都是：

示範算式。

不是 Anthropic 客戶成效。

但如果工程師 Review 變久，220 美元根本不重要

假設便宜模型讓：

每週多出 5 小時人工修錯。

就算 AI 少花：

220 美元，

整體也可能：

更貴。

所以這家公司另外記：

Human Review Time。

例如導入前：

每張平均 Review：

20 分鐘。

導入後：

15 分鐘。

那才是真的改善。

如果變成：

30 分鐘，

就代表：

Model Routing

切得太低。

最容易犯的錯就是：為了省 AI 成本，把成本轉嫁給工程師

AI 帳單非常容易看。

工程師時間卻常被忽略。

例如：

小模型便宜 0.50 美元。

但 Senior Engineer

多花 20 分鐘：

修它。

那 0.50 美元的節省，

幾乎沒有意義。

因此這家公司最後比較的是：

AI Cost

＋

Human Review Time

＋

Retry

＋

Failure Risk。

這才是完整 ROI。

Opus 5.5 為什麼適合放在中間？

Anthropic 對 Opus 5.5 的定位，

本來就很接近這一層。

官方表示：

Input／Output Token Price

比 Opus 5 低：

20%。

Cache Read

低：

60%。

而 Typical Workloads

估計總成本約降低：

40%。

同時，

Anthropic 建議將它作為：

有人監督的日常 Feature Work、

Debugging

與：

Code Review

主力模型。

所以它不是：

最便宜模型。

也不是：

所有情況都應該用的最高階模型。

比較像：

日常主力。

Fable 5.1 則是「問題比 Token Price 重要」時才上

例如：

週末 Migration。

大型架構重構。

數小時無人監督。

多個 Subagents。

非常陌生的問題。

這種時候：

工程失敗的成本

可能遠高於：

Model Cost。

這時才值得：

付更多錢。

這和一般公司用人其實很像。

不是每一張單據：

都交給公司最資深的人處理。

但真正的重大例外：

要能快速升級。

團隊甚至可以每週只檢查一次「升級案例」

星期五只看：

哪些 Ticket 從 Opus 升 Fable？

原因是什麼？

如果一星期 30 張裡：

20 張都升級，

那不是：

「Fable 很強。」

而可能代表：

Opus 5.5 根本不適合這批工作。

或者：

Task Scope 寫得太差。

Tests 不完整。

Context 不夠。

Workflow 本身有問題。

相反地，

如果整個月一次都沒有升級，

也可以問：

是不是：

根本沒有必要保留這麼昂貴的 Escalation Path？

最小導入方式不是一次改整個工程團隊

如果小公司現在已經在用 Claude Code，

不要第一天就建立：

複雜 Router。

Dashboard。

自動 Cost Allocation。

最小測試可以只有：

一週。

挑三類 Task：

Search。

Daily Coding。

Hard Problem。

先規定：

Search → 小模型。

Daily → Opus 5.5 Medium。

Hard → Opus 5.5 High。

High 同題失敗兩次：

→ Fable 5.1。

然後記：

完成率。

Turns。

Retry。

Review Time。

Estimated Cost。

一週之後再決定：

這套分工到底有沒有價值。

這個案例真正省的不是「模型變便宜」

Claude Opus 5.5 本身的確降價。

但如果公司依然：

所有工作都用同一模型。

所有 Task 都開最高 Effort。

失敗就一直 Retry。

Search 也用最高階模型。

沒有 Test。

沒有 Human Gate。

那：

模型便宜 20%，

只是讓一個原本不合理的 Workflow：

便宜一點繼續跑。

真正的改善是：

把工作分級。

簡單工作：

不要過度配置。

正常工作：

用主力模型。

難題：

快速升級。

做完：

再降回來。

AI 真正進入企業之後，

成本管理最後會愈來愈像：

人力配置。

不是：

「誰最強就全部給誰做。」

而是：

「什麼工作，需要什麼能力才剛好。」

如果你也想知道自己的工作裡，哪一步最適合先交給 AI，留言「流程」。

今天，和 AI 一起進步一點。

每天學會一個 AI 技巧。

每天節省一點時間。

每天提升一點能力。

SasaDaily，陪你一起成長。