Go + React 跑下來，幾個 AI coding model 的體感差在哪

上禮拜在把一個 Go 後端加上 React 前端的專案拆模組時，我同時開了三個視窗，讓不同的 AI model 幫我改 API endpoint 和 state。那幾天的 API token 帳單很精彩，但更精彩的是不同模型在開發現場給我的體感落差。

這篇不是跑分測試，也不是什麼權威的模型能力排行榜，純粹是我真的拿來寫 Go + React 專案之後的開發肉搏心得。

評估的標準很直接：模型能不能看懂既有的專案架構、改檔時會不會手殘、在多步驟任務裡能不能保持目標不歪掉、修 bug 時會不會補東漏西，以及最關鍵的——最後需要我花多少時間來收拾殘局。

速度快當然好，但如果模型把任務做歪，最後付出的代價不是 token 單價，而是我自己的加班時間。

開箱實測：七個模型在開發現場的體感排序

先上一張整理好的總表，下面我們再逐一拆開來聊。

排名	模型	實際體感	適合任務	主要風險
1	Claude Opus 4.7	快而且穩定，推進感很強	規劃、架構討論、中大型功能重構	任務一長容易失焦，token 燒得飛快
2	Claude Opus 4.6	穩健、可預測性高	架構收斂、保守實作、防禦性寫法	推進速度比 4.7 慢一些
3	Sonnet 系列	反應極快，日常開發主力	小任務、修 bug、UI 微調、明確規格實作	條件限制太多時偶爾會漏掉細節
4	ChatGPT 5.5 xhigh	慢，但想得很周全	全局規劃、架構取捨、風險分析	等待感非常明顯，不適合急用
5	ChatGPT 5.4 xhigh	慢但穩定，性價比不錯	長上下文分析、程式碼比對、日常任務	一樣是慢，會讓人想切分頁
6	Gemini 3 Pro	前端還可以，後端經常翻車	UI 結構調整、視覺樣式、元件切分	Go 資料流與系統邊界容易寫錯，信任度低
7	GLM 5.4 / 5.5	便宜，但返工成本太高	低風險草稿、發散思考、寫小腳本	實作常常寫錯，最後得花人工重新驗證

1. Claude Opus 4.7：大局觀極佳的規劃型選手

Opus 4.7 寫起來的體感就是快又準。很適合在動工前丟整包 spec 給它，用來做大方向的規劃、任務拆解與架構討論。處理有上下文的中大型改動時，它的理解能力非常強。

不過，它的問題是當你讓它連續跑太多任務時，它會慢慢失焦。當任務開始跨多個檔案、要同時改 Gin 的 API endpoint、React 的 Hook 狀態、最後還要更新靜態檔案時，它寫到後面偶爾會把一開始設定的約束條件給丟掉。

另一個現實考量是 token 帳單。用它來做架構討論、複雜 bug 的第一輪定位真的很劃算，能幫忙省下大量通靈時間。但如果不加思考拿它來掃一些無腦的日常小修改，那就太討債了，成本跟回報完全不成比例。

2. Claude Opus 4.6：令人安心的資深工程師

Opus 4.6 給我的感覺同樣是快跟穩。跟 4.7 相比，它實作起來的風格更偏向保守，但也因為這樣，它在多任務跑久之後的失焦問題控制得比較好。

只要不是極端複雜的任務，4.6 的可預期性都讓人很放心。它非常擅長把發散的討論收斂成具體可執行的設計。

如果硬要對比，4.7 的推進感像是個衝勁十足的架構師，帶你快速嘗試各種方案；而 4.6 的節奏比較像經驗老道的後端工程師，幫你寫出穩健的程式碼。如果想降低跑偏的機率，選 4.6 通常不會出錯。

3. Sonnet 系列：快狠準的日常救火隊

Sonnet 的定位在我的 workflow 裡非常明確：就是快，而且日常超好用。

因為它速度夠快，只要給它明確、邊界清晰的任務，例如修改某個 React 元件的 state、調一下 CSS 樣式、或是改小段 API 的參數，它通常能在一瞬間改好。不過如果你的 Prompt 裡塞了太多條條框框的限制，它偶爾會漏掉一兩個細節。

我通常不會把整個系統的架構交給 Sonnet 去無腦決定，但我會用它來處理明確的局部任務。只要規格開得夠清楚，不牽涉太多抽象層的重構，Sonnet 絕對是日常寫 code 效率最高的神器。

4. ChatGPT 5.5 xhigh：深思熟慮的分析大師

ChatGPT 5.5 xhigh 給我的第一體感是慢，但它想得真的很完整。

它比較像那種動筆前會把所有相依性都梳理一遍的工程師。在做全局規劃、架構取捨跟風險評估時，它給出的建議往往非常全面。不過它的缺點也真的很硬，就是慢。習慣了 Claude 那種即時反饋的速度後，看著 5.5 xhigh 一行行吐字，真的會忍不住切去瀏覽器別的分頁。

但有時候慢工出細活並非壞事。當你需要完整的測試策略、跨檔案的影響分析，或是長鏈路的邏輯驗證時，5.5 xhigh 給出的防禦性寫法能幫你省去後面很多排錯時間。

5. ChatGPT 5.4 xhigh：性價比極高的備用選擇

ChatGPT 5.4 xhigh 同樣走慢、穩、全的路線，但它的 token 消耗成本顯著低於 5.5。

以日常開發來說，它的分析完整度比 Sonnet 好很多，只可惜速度一樣是硬傷。如果你要快速調 UI 畫面或改小 bug，Sonnet 還是實用很多；但如果是要把整包既有的 context 吃進去，做程式碼的重構分析，5.4 xhigh 的穩定性就非常划算。

簡單說，如果你能忍受它的慢速，它其實是個很稱職的後端幫手。

6. Gemini 3 Pro：前端還行，後端請繞道

Gemini 3 Pro 的表現蠻分裂的。

如果拿來做前端任務，像是切 React 元件的 layout、微調一些 CSS 效果、或是拆分簡單的 UI component，它給出的方向其實還過得去。但一旦涉及到後端，體感就開始崩塌。

在處理 Go 的併發、資料流、系統邊界或是複雜的 DB query 時，它很容易寫出一些看似合理但實際上有坑的 code。這導致我對它的信任度很低，必須全程睜大眼睛盯著，否則一不注意就會踩坑。

7. GLM 5.4 / 5.5：便宜，但隱形成本太高

GLM 系列的體感目前在開發現場是不太合格的。

雖然它的 token 單價真的很便宜，但如果模型改出來的 code 錯誤百出，便宜就成了最大的陷阱。因為它會讓你產生省錢的錯錯覺，實際上卻把成本轉移到了人類開發者身上——你必須花大把時間重新看 diff、重新驗證、重新除錯。

在 coding workflow 中，最怕的不是模型跑得慢，而是它「假裝寫對了，但其實邏輯是歪的」。這種隱形 bug 找起來最耗時間。目前我只會把它拿來做一些低風險的腦力激盪，絕對不會放它去改核心的專案程式碼。

那 Opus 4.8 呢？

因為目前還沒有實際訂閱，這部分打算之後有機會再開箱。

如果它能保留 Opus 既有的強大架構規劃能力，同時提升多步驟任務的專注度並降低 token 消耗，那對大型專案的重構會非常有幫助。在實際踩坑之前，就先不瞎編心得了。

多 Agent 並行，真的有比較省時間跟成本嗎？

現在大家很愛聊「多 Agent 協作」或「子代理並行」，聽起來很炫，但實際帶進專案開發時，會發現成本往往不是表面上算得那麼簡單。

首先是 Context 的重置成本。每個子代理要改 code，都得先把相關的架構脈絡、API schema 吃進去。你不能指望把一份巨大的 context 直接無痛分給十個子代理，結果就是每個人都在重複消耗讀取 token。當專案規模變大時，這筆 token 費用累積的速度非常驚人。

另外，如果沒有把任務的邊界切乾淨、沒設定好檔案 ownership，或者開發時沒有走獨立的 worktree 分支，多個子代理很容易互踩腳趾。例如 Agent A 改了 React state 的 hook，Agent B 剛好也去改了同一個元件的 props，最後在 git merge 時直接打架。到頭來，主控代理或人類自己得花好幾倍的時間去 merge 程式碼、做排衝突的驗證。

這也意味著，多 Agent 的運作要順暢，背後需要非常嚴謹的任務派發機制。

目前看來，多 Agent 最適合的場景是「完全獨立且不重疊」的單元任務：例如一邊寫測試腳本、另一邊整理 API 文件，或者讓一個 Agent 去做多個方案的調研。如果想拿來協作同一條核心的 API 資料流，還是老老實實用單一強模型比較不容易翻車。

最後的實戰分工策略

在實際的 Go + React 開發中，我目前的搭配是：

Opus 4.7 / 4.6：負責前期的系統設計、規格拆解，以及複雜功能重構時的架構討論。
ChatGPT 5.5 / 5.4：負責寫防禦性寫法分析、測試案例規劃、以及需要長上下文對比的任務。
Sonnet：負責日常快修、寫 React UI、調樣式、改 endpoint 參數等邊界清晰的小任務。

AI coding 不是去找一個萬能的模型，而是像帶團隊一樣，把對的任務發給適合的模型。這也是目前我們在開發現場，能把開發效率最大化、同時帳單又最漂亮的玩法。