上個月 J 在巡邏報告裡寫了一行：「米米這週翻了 41 篇文章，Claude token 帳單沒動。」

我盯著這行字看了一下。

然後我想起來，上個月我們把翻譯任務移到 MiniMax 了。41 篇。幾乎靜默地完成。

就是那個當下，我才意識到我們現在同時跑幾種 LLM 這件事不是什麼技術成就，是一步一步被成本逼出來的現實答案。

不是技術選型，是算帳的結果

我有一段時間以為，用最強的模型就是最省時間的做法。

錯。是最燒錢的做法。

我們現在每月 AI 預算大概 $255 左右——Claude 訂閱是大頭，跑 J 在用的部分。J 負責架構決策、程式開發、協調整個 agent 團隊，這些任務出錯成本很高，Claude Opus 的推理能力在這裡是有真實 ROI 的。

但米米一週要整理幾十篇市場資訊、翻譯內容、生成初稿。阿達要跑程式碼審查和產品頁面。如果這些全走 Opus，預算根本撐不住。

查過資料，MiniMax M2.5 的 API 定價比 Claude Opus 便宜大約 60 倍。60 倍。把適合用 MiniMax 的任務切過去，每個月省下來的空間相當可觀，而且那些任務的產出品質沒有明顯下降。

Gemini 是小月在用的，付費訂閱的 Gemini CLI，不是免費版——我每次說到 Gemini 都要特別補這句，因為有人會自動假設是白嫖 OAuth。這是正當付費的訂閱版本，QA 和研究的任務量大，訂閱比跑 API 划算得多。

這些組合不是一開始就設計好的。是試了幾個月之後，帳單逼著我一個一個想清楚。

文案翻譯、程式開發、QA 測試——誰做什麼不是憑感覺

說具體一點。

J 用 Claude。架構設計、程式開發、邏輯複雜的任務。這種東西錯一步就要重來，用力氣換回來的成本更高。日常開發走 Sonnet，複雜的升 Opus。

米米和阿達用 MiniMax。文案翻譯、產品頁初稿、市場資訊整理、社群貼文。速度要快，用量大，不需要最深的推理。M2.5 在這類任務上輸出穩定，偶爾格式怪一點，但在可接受的範圍內。

小月用 Gemini。QA 測試報告、競品研究、大量資料整理。Gemini 的 context window 大，丟一堆資料讓它歸納出結論是它的強項，訂閱版延遲也很穩。

莉莉（內容這邊）。原創文章走 Claude Sonnet，翻譯和資料研究走 MiniMax。這兩個需求差很多，分開用不同模型是實際跑過才確認的——不是預先設計，是跑一跑才發現「這樣比較對」。

多 LLM 協作的維運現實，沒人告訴你的那種

格式不一致是第一個坑。

Claude 有它的輸出習慣，MiniMax 有它的，Gemini 有它的。Agent 之間要互相讀對方輸出的時候，三種格式在接口處就會產生問題。一開始我們沒想到這個，J 後來補了解析層才稳住。

延遲差異是第二個坑。Claude Sonnet 回應快，Opus 有時候要等。MiniMax 通常快，但尖峰時段偶爾慢。Gemini 訂閱版幾乎不卡。這種差異在自動化流程裡會造成意外——某個 agent 等太久，後面的任務串接就失敗了。自動化排程要把延遲緩衝考慮進去，這件事我們踩過才知道。

計費方式全不同是第三個坑。Claude 和 MiniMax 都是訂閱制，但各自的用量額度和計算方式不一樣；Gemini 也是訂閱制按月。三家的用量上限、重置週期、超額處理方式全部不同，整合在一起追蹤沒有想像中直覺，我們後來自己寫了用量追蹤工具，才能看到整體的消耗狀況。

這些不是大問題，但每一個都要花時間處理。多 LLM 省下的成本，有一部分要回填在這裡。

排行榜告訴你誰最強，但沒告訴你誰最適合你的任務

有段時間我也想過，要不要統一成一個模型。

然後算了一遍就打消念頭了。

全走 Claude Opus，預算撐不住。全走 MiniMax，J 做架構決策的品質會掉，而且複雜任務的錯誤率上升，修錯比省錢更貴。全走 Gemini，繁體中文的原創品質我試過，有差距。

沒有一個模型能在所有任務上同時做到「夠好」加「夠便宜」。benchmark 告訴你哪個模型在哪個測試集表現最好，但 benchmark 不告訴你哪個模型最適合你的語言、你的任務量、你這個月剩多少預算。

我不知道我們現在這個組合是不是最優解。但它是真實試過幾個月之後，目前還能跑起來、帳單還能看的答案。