AI Coding 發展到現在，大家已經不太需要討論「AI 能不能寫程式」，真正開始影響實際使用策略的問題，反而是成本。但要比較不同 Coding Model 的成本並不容易，單純比較每百萬 Token 的價格沒有太大意義，因為不同模型完成同一個任務時，使用的 Token 數量、執行時間、成功率與需要人工介入的程度都不同。真正有價值的比較方式，是讓不同模型執行同一個足夠複雜的工程任務，再比較最後的結果。
DHH 最近在 Lex Fridman Podcast 分享了一個很有意思的案例。他讓 AI 將 Python 的終端文字特效程式庫 TerminalTextEffects 重寫成 Rust。這不是單純要求產生一份功能類似的實作，而是需要維持原本的行為與輸出，並透過測試驗證相容性。後續他又讓不同模型嘗試相同任務，結果如下。
| 模型 | 結果 | 完成時間 | 成本 |
|---|---|---|---|
| Fable | 成功 | 約 45 分鐘 | 約 US$550 |
| GPT-Sol | 成功 | 約 1.5 小時 | 約 US$46 |
| Grok 4.6 | 成功 | 約 1.5 小時 | 約 US$55 |
| DeepSeek V4 Pro | 成功 | 約 2.5～2.75 小時 | 約 US$23 |
| GPT-Luna | 失敗 | — | — |
| DeepSeek V4 Flash | 失敗 | — | — |
Fable 是其中最快完成任務的模型，大約 45 分鐘就完成，但成本接近 US$550。GPT-Sol 與 Grok 4.6 大約需要一倍的時間，成本卻只有 Fable 的十分之一左右。DeepSeek V4 Pro 更進一步把成本降低到約 US$23，代價則是執行時間增加到兩個半小時以上。
如果這是一個需要工程師坐在螢幕前等待結果的互動式任務，45 分鐘與兩個半小時的差異可能很重要。但如果它是一個可以非同步執行的 Agent Task，甚至是在 CI/CD Pipeline 裡面執行，時間的重要性就可能大幅降低。此時多花兩個小時換取二十倍以上的成本差異，很可能是一筆合理的交易。
Token 價格不是最重要的成本指標
這組測試還帶出另一個很重要的問題：GPT-Luna 與 DeepSeek V4 Flash 都屬於成本較低的模型，但最後沒有成功完成任務。因此只比較模型的 Input Token 與 Output Token 單價，其實很容易得到錯誤的結論。對工程工作而言，更值得關注的指標應該是：
Cost per Successful Task
假設模型 A 執行一次只需要 US$5，但成功率只有 30%，而模型 B 一次需要 US$30，卻幾乎可以穩定完成工作，那麼模型 B 很可能才是實際成本較低的選擇。而且這裡甚至還沒有把工程師的時間算進去。一個 Agent 執行兩個小時，中間完全不需要人工介入，最後產生可以直接 Review 的 Pull Request，與另一個只需要 30 分鐘，但工程師必須不斷修正方向、補 Context、重新執行的 Agent，兩者的實際成本完全不同。
因此更完整的成本模型至少應該包含：模型使用成本、成功率、執行時間與人工介入成本。這些因素加在一起，才比較接近真正的 AI Coding 成本。
Coding Model 可能存在能力門檻
這個案例也讓我重新思考「輕模型」與「高階模型」之間的差異。我們很容易把模型能力想像成線性的關係，例如最強模型是 100 分，中階模型 90 分，輕模型 80 分。如果只是一般的文字處理工作，這種理解可能還算合理，但 Agent Coding 不一定如此。
在長時間、多步驟的工程任務中，模型需要持續理解 Context、規劃下一步、修改程式、執行測試、分析錯誤，再根據結果修正自己的做法。其中任何一個環節持續出錯，都可能導致整個任務無法收斂。因此它比較像存在一道 能力門檻：模型只要超過這個門檻，就可能有能力自行完成整個任務；但如果低於這個門檻，結果不一定只是「慢一點」或「品質差一點」，而可能是根本做不完。
這也是為什麼便宜模型不一定真的便宜。如果一個模型的 Token 成本只有另一個模型的一半，但它無法完成任務，那麼它的 Cost per Successful Task 並不是另一個模型的一半，而是沒有意義。因此選擇 Coding Model 時，我現在更在意的問題不是：
哪一個模型最強？
而是：
哪一個模型是剛好跨過這個任務能力門檻的最低成本選擇？
最強模型不一定是最合理的預設模型
DHH 的測試中，Fable 的結果其實非常好。它最快完成任務，而且如果把這件事情交給一個不熟悉 Rust 的工程師自行研究、實作與驗證，US$550 未必算昂貴。所以這個案例並不能簡單解讀成「Fable 太貴，不值得使用」。
真正值得注意的是另一件事：Fable 值得 US$550，不代表每個任務都需要 Fable。如果 GPT-Sol 花約 US$46 也能完成相同任務，而我並不在乎多等待 45 分鐘，那麼在這個特定情境下，Sol 就可能是更合理的選擇。
這也是我自己使用 AI Coding 工具後越來越明顯的感受：很多工作並不需要最強模型。如果一個中階模型已經可以穩定、完整地完成任務，那麼繼續往上使用更昂貴的 Frontier Model，得到的可能只是速度提升或成功率從 95% 提升到 99%。這些提升當然有價值，但它們是否值得數倍甚至十倍的成本，取決於任務本身。高階模型真正有價值的地方，應該是用在那些只有它才能穩定跨過能力門檻的任務，而不是成為所有工作的固定預設。
Model Routing 不只是依照任務大小選模型
這個案例另外一個值得注意的地方，是後續模型執行任務時，並不是完全從零開始。前面的高階模型已經產生了相當完整的 Plan，後續模型可以基於既有規劃繼續執行。這讓 Model Routing 有了另一種可能。一般談到 Model Routing，最直覺的做法通常是：
簡單問題交給便宜模型，困難問題交給昂貴模型
但在 Coding Agent 裡，其實可以切得更細：同一個任務的不同階段，也可以使用不同模型。例如 Planning 階段需要理解大量 Context、辨識風險、建立 Architecture 與拆解工作，這個階段可以交給能力最強的模型。當 Plan 已經足夠清楚之後，大量 Implementation 工作可能不再需要同等級的推理能力，此時就可以交給成本較低的模型執行。完成之後，再使用另一個模型進行 Code Review 或 Security Review。一個可能的 Workflow 會變成：
- Planning → 高階模型
- Implementation → 中階模型
- Testing / Fix → 中階模型
- Code Review → 不同供應商的高階模型
- Security Review → 適合安全分析的模型
- Documentation → 輕模型
這比從 Session 開始到結束始終使用同一個 Frontier Model，更接近工程上的最佳化問題。如果一個昂貴模型最擅長的是理解複雜需求與建立正確的執行方向，就沒有必要繼續支付相同價格，讓它完成數百次相對機械性的 Code Modification。反過來說，如果 Planning 本身就是最容易讓 Agent 走錯方向的階段，也沒有必要為了節省 Token 成本，而讓能力不足的模型花大量時間自行探索。Model Routing 真正的價值，不只是「選便宜模型」，而是把昂貴模型的能力用在最值得花錢的地方。
找到模型的能力邊界，比追求單一最強模型更重要
要做好 Model Routing，前提是透過大量練習與實驗，逐漸找出每個模型的能力邊界；選對執行者，和選對任務一樣重要。我目前的分工是：Claude 專門處理純 Coding，Codex 用於 Coding、蒐集資訊與撰文，Gemini 則負責其餘各種雜事。
Gemini 的使用額度相對充裕，可以放心使用最新模型；Claude 和 Codex 我則以中階模型為主，分別使用 Sonnet 5 High 與 Terra Medium。這樣的配置下，每一家都能專注處理自己擅長的事情。即使我是使用最便宜的方案，Weekly Limit 也還沒有低於 70% 過。
網路上常見有人批評模型「很笨」。Context Engineering 是否做好，當然會影響結果，但另一個常被忽略的問題是：是否選對模型，也是否把任務交給了它具備的能力範圍。以我的經驗來說，Gemini 處理 Google 相關工作時，準確度「必定」高於另外兩家。這是經過多次實驗後得到的結論：同樣的 Prompt，無論是操作 Kubernetes 或 GCE，Gemini 幾乎都能一次到位；即使把 Gemini 的產出餵給 Claude 與 Codex，它們也會認為 Gemini 的考量更全面。
目前三大模型供應商確實沒有任何一家可以通吃所有工作。與其執著於單一模型的總體排名，更實際的做法是理解各自的長處、持續驗證它們的邊界，然後把合適的工作交給合適的模型。
AI Coding 開始變成工程最佳化問題
過去大家很習慣問：
現在最強的 Coding Model 是哪一個？
這個問題當然還是有意義，但隨著模型能力逐漸跨過許多日常工程任務的最低門檻，它的重要性可能會慢慢下降。接下來真正值得解決的問題可能會變成：
這個 Workflow 的每一個 Stage，應該 Route 到哪一個 Model？
而且長期來看，這甚至不應該由工程師手動決定。Agent Orchestrator 可以根據任務複雜度、Context 長度、歷史成功率、預估 Token 消耗、時間限制與模型價格，自動選擇最適合的模型。當模型執行失敗時，再升級到下一個能力等級，例如：
輕模型 → 中階模型 → Frontier Model
甚至 Planning 與 Review 可以直接使用 Frontier Model，而中間大量 Implementation 自動 Route 到成本較低的模型。到了這個階段，我們最佳化的就不再是單一 Prompt，也不只是單一模型，而是整個 AI Software Development Pipeline。
DHH 這次測試最值得注意的地方，因此不只是 Fable 花了 US$550，而 DeepSeek 只需要 US$23。它真正呈現的是一件更有意思的事情：
AI Coding 不需要永遠使用最強的模型，而是應該為每一個工作階段找到「能力足夠，而且成本最低」的模型
最強模型應該處理只有它能穩定完成的事情。剩下的工作，交給已經足夠好的模型。當 AI Coding 開始大量進入真正的工程流程後，我認為這會比單純追逐「目前 Coding Benchmark 第一名是誰」重要得多。
沒有留言:
張貼留言