Grok Build 加上 /goal，自動寫碼更像樣了
xAI 在 Grok Build 加入 /goal，讓代理能在本機上規劃、執行、驗證程式任務。這篇整理它的工作流程、驗證方式、價格與 SWE-Bench 對比。
xAI 的 Grok Build 新增 /goal，讓代理能在本機上自己規劃、執行、驗證程式任務。
xAI 在 Grok Build 加上 /goal。日期是 2026 年 6 月 22 日。講白了，就是你丟一個目標，代理自己跑到有結果為止。
這招很直接，也很兇。它把 Grok Build 拉進 Claude Code 和 OpenAI Codex CLI 的戰場。差別在於，xAI 想把「自動完成」講得更滿。
真正有意思的，不是它會寫碼。很多工具都會。重點是它會不會自己驗證，然後修到能交差。這才是開發者最在意的地方。
| 指標 | 數值 | 意思 |
|---|---|---|
| /goal 上線日 | 2026-06-22 | 自動執行模式已可用 |
| SuperGrok | $30/月 | 最低入門方案 |
| X Premium Plus | $40/月 | 另一個 CLI 入口 |
| SuperGrok Heavy | $300/月 | 高用量方案 |
| Grok Build 0.1 context window | 256,000 tokens | 可跑長任務 |
| 早期 SWE-Bench Verified | 70.8% | xAI 既有成績 |
| Claude Code Opus 4.7 | 87.6% | 主要競品基準 |
/goal 到底改了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
一般 coding agent 很像聊天機器人。你下需求，它吐程式碼。你看完，再丟下一輪指令。整個流程，人的手還是卡很深。
/goal 不一樣。它把一句話變成一個有邊界的任務。裡面有進度面板，也有完成檢查。代理會自己往下做，不用你每一步都點頭。
這件事很實際。因為開發時間常常浪費在「生成」和「驗證」之間。程式能編譯，不代表功能真的對。xAI 想把驗證塞進代理內部，讓它自己先抓錯。
- /goal status 看即時進度
- /goal pause 暫停執行
- /goal resume 繼續任務
- /goal clear 取消工作
這種設計也不是完全放生。開發者還能插手。你可以看狀態、停掉、續跑，或中途加新指令。只是不用每一步都人工審核，這點差很多。
說真的，這就是代理工具的分水嶺。會改檔案不稀奇。會把任務做完，還能自己收尾，才比較像可用工具。
驗證才是重點
xAI 的說法是，/goal 會用三種方式驗證。第一種是看自己產生的程式碼。第二種是打開網頁確認執行結果。第三種是直接跑腳本。
這設計比單純回一句「done」合理多了。因為它至少有一個檢查步驟。代理不只是寫，還得證明自己沒亂來。
很多第一代 coding agent 的問題都一樣。看起來很勤快，實際上很會自信爆棚。它們常常把「有改」誤當成「有對」。/goal 想縮小這個落差。
“Coding agents are becoming the procurement front where AI labs compete to own the developer workflow.” — Mitch Ashley, VP and practice lead for software lifecycle engineering at The Futurum Group
這句話很準。現在不是比誰會吐一段漂亮 code。是比誰能吃下規劃、測試、修正這整條流程。
但我也得潑點冷水。模型自己生成，又自己驗證，會不會只是自己幫自己蓋章？如果 generator 跟 verifier 太像，檢查可能只是在重述同一個錯誤。
兩個模型分工，聽起來合理
/goal 用的是 Grok Build 0.1 和 Composer 2.5。xAI 的說法是，一個負責規劃和理解指令，另一個負責產碼和執行。
這個切法很像工程上常見的分工。規劃歸規劃，執行歸執行。理論上這樣比較穩，也比較好控流程。
問題還是在獨立性。兩個模型如果訓練訊號很像，失敗模式也可能很像。那驗證就會變成形式流程，不是真的抓 bug。
更實際的一點是，Grok Build 的程式在開發者本機跑。這代表程式碼不會在 session 裡送去 xAI 伺服器。對金融、醫療、政府團隊，這點很有感。
- xAI docs 有 CLI 和方案說明
- Codex CLI 是主要對手之一
- Claude Code 目前聲量很高
- Gemini Code Assist 也是企業選項
本機執行還有另一個好處。你不用把整個開發環境交出去。這對有法遵壓力的團隊，通常比模型分數更重要。
跟競品比，xAI 還沒追平
數字很直接。早期的 grok-code-fast-1 在 SWE-Bench Verified 拿到 70.8%。Claude Code 在 Opus 4.7 上是 87.6%。
這個差距不小。講白了，xAI 還沒在純 coding 能力上追上第一梯隊。至少從公開數字看，還差一段。
但 xAI 的論點也不是沒道理。它想強調的是長時間自主執行。代理如果能一直測、一直修、一直重跑，最後交出來的結果可能比單次 benchmark 更重要。
- Grok Build：早期成績 70.8%
- Claude Code：Opus 4.7 為 87.6%
- Context window：256,000 tokens
- 費用：$30、$40、$300 三個級距
這邏輯有道理，但還是要看真實專案。benchmark 會告訴你模型卡不卡、會不會亂補、會不會漏邊界條件。流程再好，也不能把底層弱點完全蓋掉。
另一個變數是 xAI 之後想推的 Arena Mode。如果真的上線，它會同時跑多個 agent，再挑最好的一個。這種做法有機會補單次表現不足。
開發者該看什麼
我覺得最值得觀察的，不是 demo 有多帥。是它會不會讓你少回去重開任務。代理如果常常提早宣告完成，那就只是把麻煩包裝得更漂亮。
Grok Build 最近的節奏很快。先有 beta，再來有 Composer 2.5、外掛市場，現在又加上自動執行。這表示 xAI 想把它做成日常工具，不是一次性的展示品。
如果你是團隊決策者，重點很簡單。別先問它多會講。先問它能不能在本機把任務做完，還能把驗證跑掉。能做到這件事，才算真的有用。
我自己的判斷是，/goal 是一個實際的產品進展，但還不是結論。接下來幾週的真實使用情況，會比任何宣傳文案更誠實。你要看的不是它會不會寫，而是它會不會收尾。
如果 Grok Build 真的能穩定把本機修改、測試、修正這條線跑順，xAI 就算 benchmark 還沒追平，也會先拿到工作流程的優勢。這點對開發者很現實，也很殘酷。
我的建議很簡單。拿一個你們團隊常見的小任務去測。看它能不能從規劃跑到驗證。那比看簡報準多了。