Claude 寫程式，Gemini 審查，ChatGPT 當橡皮鴨

單一供應商的 AI 在紙上看起來比較省事，實際上出貨的卻是脆弱性。RakuAI 由一個多供應商的代理迴圈打造——而且打造成任何供應商的模型都能驅動它。開發流程正是產品論點的鏡像。

週六早晨，一杯咖啡，趁工作流程再次改變之前把它寫下來。當我告訴別人我正在和自主編碼代理一起打造引擎時，第一個問題總是「用哪個代理」。誠實的答案是「好幾個，各司其職，而且分工方式很重要」。這篇文章就是那個較長的答案。

目前的開發工作流程至少牽涉三家不同的 AI 供應商，各自扮演迴圈中不同的部分。原因不是忠誠度也不是挑剔。而是每個模型確實各自擅長不同形狀的工作，硬要讓一個模型包辦一切，產出的程式碼品質會有可測量的下降。

今天的角色分工

Claude 撰寫大部分的執行環境程式碼。 跨大型程式碼庫的長上下文推理、動手修改前先做規劃、在一顆腦袋裡同時保持大量狀態。這是我放在議題佇列上處理實質子系統工作的模型。當一個議題寫著「實作 OpenXR 合成層管理器與動作空間」時，落地那個 PR 的就是 Claude。

Gemini 審查大部分的 PR。 不同的訓練，不同的盲點。當 Claude 落地一個 PR，Gemini 會讀差異並提出質疑。Gemini 提出的那類評論，和我手動審查會提出的那類評論並不一樣。有些是雜訊。有些很有用。訊噪比好到讓我信任 Gemini 作為每一份差異的第一輪審查。

ChatGPT 是我推敲想法的地方。 當我卡在一個架構決策上、還不知道該往哪個方向走時，我會對著 ChatGPT 把想法說出來。在這個角色裡，模型不寫程式碼。它逼問我的假設，提出三種替代的思考框架，並讓我跟它爭論。這是如果我有一位資深同儕，那位同儕會扮演的角色。我目前沒有這樣的人。ChatGPT 就是那個模擬。

Copilot 在編輯器裡。 這是自動完成的角色。當我親手寫程式碼時（頻率比大家想的低，但確實會發生），Copilot 是我在 IDE 裡看到建議的那個模型。它擅長局部上下文、接下來四行的那種工作。

這就是工作流程。四個模型，四種角色。每一個在自己的角色上都比其他模型做得更好。

為什麼多供應商很重要

三個理由。

每家供應商的能力天花板不一樣。 如果我用一個模型包辦所有角色，那個模型的每一個弱點都會變成開發流程的弱點。Claude 非常擅長撰寫。找出自己寫的程式碼中的錯誤就沒那麼擅長。Gemini 非常擅長找錯誤，但它不是我會放心讓它在無人監督下規劃重構的模型。ChatGPT 對開放式的架構問題想得很好，但它在真實子系統裡寫的程式碼不是我想出貨的東西。每一個都是某個位置上的最佳工具。

審查的獨立性是結構性的。 我最終確立的最重要一條規則是：撰寫 PR 的模型不能是審查該 PR 的模型。自我審查不是審查。讓另一家供應商的模型做第一輪審查，帶來的是架構上的獨立、訓練資料上的獨立、失效模式上的獨立。Gemini 在 Claude 的程式碼裡抓到的錯誤，是真實的、不然就會落地的錯誤。

不被任何單一供應商鎖定。 這個引擎正被打造成能接受任何雲端 LLM 的指揮（上個月在 XRAssistantService 的工作中談過）。打造這個引擎的開發工作流程也應該符合這個姿態。我不希望這個執行環境的工程，取決於某一家供應商在未來五年持續保持競爭力。沒有一家做得到。現在強的那些，之後會以不同的方式強。在開發層採用多供應商工作流程，能讓工程保持可攜。

誠實面對成本

有幾項。

協調的額外負擔是真實的。 在任務進行中切換供應商會帶來認知負擔。解法是讓每個任務留在單一供應商的車道內，讓交接發生在任務之間，而不是任務之內。

帳單會累積。 同時養四個模型訂閱並不便宜。這筆成本相當可觀，目前是我個人在支付。它的回報可以用已出貨的子系統來衡量，所以現階段這筆帳算得過來。但不會永遠如此。

供應商之間的品質漂移是真實的問題。 當 Gemini 在某類 Claude 一直在做的任務上變強了，正確的答案是把那類任務移給 Gemini。錯誤的答案是因為工作流程文件上寫的是舊做法就繼續照舊。工作流程文件每隔幾週就得修訂，因為模型版圖在工作流程底下不斷移動。

供應商彼此不知道對方的存在。 當 Claude 寫下一段將由 Gemini 審查的程式碼時，Claude 並不知道這件事。當 ChatGPT 和我爭論一個架構決策時，最終由 Claude 完成的實作看不到那場爭論。供應商之間的整合存在於我的腦子裡。那是一個很脆弱的整合所在，如果我要打造基礎設施幫助其他人跑這套工作流程，這是我最想修好的事情之一。

那執行環境那一邊呢？

這就是開發工作流程的故事與引擎的故事交會的地方。

兩週前落地到執行環境的 XRAssistantService，在設計上就是模型無關的。原因和這套開發工作流程採用多供應商的原因一模一樣。這個介面的打造方式，讓這些實驗室的任何模型都能透過執行環境驅動一段 AR 體驗。在任何一段體驗中，哪家實驗室的模型最擅長某項任務，就由它來提供那項任務的意圖。

這是更大的賭注：「這個產品建立在某家供應商的某個模型上」的時代很短。我們正在進入的時代是「這個產品圍繞著模型形狀的能力打造，而在任何時刻由哪個具體模型填入哪個能力插槽，只是一個組態選擇」。引擎必須為此做好準備。打造引擎的開發工作流程也應該反映這一點。

我希望開發者與實驗室從中看到什麼

如果你是編碼代理的供應商而且正在讀這篇文章，我會建議你最佳化的指標是「這個代理的 PR 有多常通過競爭對手供應商代理的審查而存活下來」。自我一致性不是門檻。跨供應商審查存活率才是門檻。在這個指標上表現好的代理，才會是被拿來做正經工作的代理。

如果你是開發者，正考慮在一個正經的程式碼庫上採用 AI 輔助工作流程，不要挑一個模型就停下來。挑一個來寫。挑另一個來審查。用第三個來推敲懸而未決的架構決策。成本溢價是真實的，但品質差距更大。

如果你是企業主管，正在思考開發組織裡的 AI，多供應商模式才是能規模化的那一種。單一供應商的導入在紙上看起來比較容易。實務上它產生的是脆弱性，技術上和策略上皆然。

安靜的週六。引擎度過了一個三十五個提交的週末。其中大多數提交在六個月後將無人記得。但產出它們的工作流程不會。