幾個月來，我一直沉浸在 AI 輔助編碼的泥潭中，當 Grok 4 發佈時，我忍不住將它與 Claude 4 Opus 進行了一番較量。在大約 2.8 萬行的 Rust 程式碼庫中，我使用了相同的 15 個複雜任務，包括競爭條件、死鎖和多檔案重構，並將它們進行了一番較量。
總結一下？ Grok 4 是一款強大的工具，可辨識基於tokio的複雜非同步 Rust 專案中那些複雜且難以發現的錯誤，例如死鎖。它的單任務成本明顯更低，但偶爾會忽略自訂指令。 Claude 4 Opus 雖然價格更高，但更順從可靠，尤其是在你需要它遵循特定規則的時候。
注意： Grok 的速率限制令人沮喪地低。
測試方法和技術設置
我把這兩種模型都運用到我實際參與的 Rust 專案中，專注於我真正關心的事情：尋找 bug、清理程式碼以及正確使用工具。為了公平起見，兩種模型的提示都是一樣的。
立即在 Forge 上體驗 Grok 4！將其速度和漏洞搜尋能力與 Claude 4 Opus 進行比較。 立即註冊 Forge ！
測試環境規範
硬體配置：
-
MacBook Pro M2 Pro，16GB RAM
-
網路：500Mbps連接
-
開發環境：VS Code，在整合終端上執行 Forge 進行 AI 交互
API配置：
任務規範：
-
涉及並發問題、程式碼重構和修復的 15 項任務
-
混合小型上下文（低於 128k 個標記）和大型上下文（最多 200k 個標記）
-
設計模式、函式庫使用和在測試中使用漂亮斷言等的自訂規則。
克勞德 4 工作
-
上下文視窗：200,000 個令牌
-
投入成本：約 3 美元/100 萬個代幣
-
輸出成本：~15 美元/100 萬代幣
-
工具呼叫：原生支援
Grok 4
-
上下文視窗：128,000 個代幣（有效，超出後成本加倍）
-
輸入成本：約 3 美元/100 萬個代幣（128,000 個代幣後翻倍）
-
輸出成本：~15 美元/100 萬個代幣（128000 個代幣後翻倍）
-
工具呼叫：原生支援
圖 1：15 項任務的速度和成本比較
績效分析：量化結果
執行指標
| 公制 | Claude 4 Opus | Grok 4 | 註 |
|---|---|---|---|
| 平均回應時間 | 13–24 秒 | 9–15 秒 | Grok 每次請求速度提高 2 倍 |
| 單次成功 | 8/15 | 9/15 | 後續均達 15/15 |
| 每項任務的平均成本 | 13 美元 | 4.5 美元 | Grok 對於小型環境更便宜 |
| 工具呼叫準確率 | ~99% (1614/1630) | ~99% (1785/1803) | 兩者接近完美 |
| XML 工具呼叫準確率 | 83% | 78% | Opus 略勝一籌 |
| 錯誤偵測 | 錯過競爭條件/死鎖 | 全部偵測到 | Grok 在並發性方面更強大 |
| 遵守規則 | 優秀 | 良好（2/15 中忽略） | Opus 更好地遵循自定義規則 |
測驗樣本：15 個任務，重複 3 次以確保一致性
信賴度：高，基於人工驗證
速度與效率：Grok 的優勢與陷阱
Grok 4 的速度始終更快，9-15 秒，而 Opus 則需要 13-24 秒。這使得快速迭代感覺更快捷。但之後，我每隔幾個請求就會碰到 xAI 的速率限制。這讓原本應該快速的測試環節變成了一場停停等待的惡夢。我什至無法獲得清晰的計時資料，因為我一直受到限制。
成本明細：規模節省…
Grok 4 平均每個任務花費 4.50 美元，而 Opus 則達到 13 美元。對於小型任務來說，這是一個巨大的優勢。但 Grok 的價格在 12.8 萬個代幣後會翻倍。 Opus 的價格維持不變。
Grok 的實際定價結構如下：
圖 3：Grok 4 針對 128k 令牌以下上下文的標準定價
當您啟用「更高上下文定價」（對於更大的上下文自動啟動）時，成本將翻倍：
<
圖 4：Grok 4 對超過 128k 個令牌的上下文的定價 - 注意雙倍的費率
準確性和功能：Grok 的優勢（和不足）
Grok 4 讓我印象深刻，它發現了基於 tokio::RwLock 的設定中存在一個死鎖，而 Opus 完全沒有註意到。在一個任務中，Grok 發現了一個微妙的執行緒遺失，導致恐慌鉤子無法在 Rust 非同步區塊中執行。而 Opus 卻忽略了這一點。
兩者的工具呼叫準確率都達到了 99%，幾乎每次都能選擇到正確的工具並給出有效的參數。但切換到基於 XML 的設定後，準確率下降：Opus 的準確率為 83%，Grok 的準確率為 78%。雖然穩定，但並非完美無缺。
規則遵循才是事情變得有趣的地方。我的自訂規則（使用 Anthropic 的評估控制台花了幾個月的時間調整）與 Opus 完美相容。 Grok 在 15 個任務中兩次忽略了這些規則。可能是因為我專門針對 Claude 模型優化了這些規則，但這種情況仍然會打斷我的工作流程。
在單次提示完成率方面，Grok 以 9/15 的成績略勝 Opus 的 8/15。在後續指令方面，兩人都取得了優異的成績，表明他們都很有能力，但 Grok 可能一開始就「上手」得更快。
挫折和現實世界的影響
Grok 的速率限制簡直令人抓狂。我發送了一個請求，得到了不錯的回應，但接下來的幾分鐘就陷入了困境。這徹底扼殺了我的測試動力。
在模型行為方面，Opus 感覺更“順從”，嚴格遵守規則，不做任何偏差。 Grok 則更大膽，有時會為了追求更好的方法而忽略約束。這種創造力有助於尋找錯誤，但可能會導致團隊環境中的範圍蔓延。
結論
綜上所述，我傾向於使用 Grok 4 來處理複雜任務，純粹是為了節省成本、提高速度，以及它對複雜 bug 的敏銳洞察力。它一次完成了更多任務，而且執行成本更低，即使它的速率限制讓我抓狂。 Opus 可靠且始終遵循規則，因此，當您需要可預測的結果且無法承受意外時，它是更安全的選擇。
最終，Grok 4 的價值滿足了我的特定需求，但請務必親自測試這兩款工具。根據你所建構的內容，它們各有優勢。
在 Forge 上試用 Grok 4
我們已在 Forge 上啟用 Grok 4！如果您想體驗我們之前提到的速度和 bug 查找功能，不妨註冊Forge試用一下。您可以直接將其與 Claude 4 Opus 進行比較，看看哪個型號更適合您的特定編碼任務。
相關文章
Claude Sonnet 4 與 Gemini 2.5 Pro
原文出處：https://dev.to/forgecode/claude-4-opus-vs-grok-4-which-model-dominates-complex-coding-tasks-2h74
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式