xAI 推出 Grok Build 終端機寫程式

xAI 推出 Grok Build，讓付費訂閱者能直接在終端機用 AI 寫程式。

xAI 這次把 Grok Build 做成早期 beta。對象是 SuperGrok 和 X Premium Plus 訂閱者。講白了，就是把 AI coding agent 直接塞進 terminal。

安裝方式也很直白。官方給的是一行指令。xAI 想要你少開一個新介面，直接在原本的 shell 工作流裡跑起來。這種做法很討喜，因為很多工程師本來就不想再多學一套 UI。

Grok Build 到底在做什麼

Grok Build 是 xAI 的 CLI 版 coding agent。它跑在終端機裡。你下 prompt，它會幫你看檔案、改檔案、列出 diff，還能先規劃，再執行。這種設計很實際，因為很多真實工作都發生在 repo、script、CI job 裡。

它不是只會吐幾段程式碼。xAI 的示範包含幾種很工程師的任務。像是改 headless install 文件、安裝 browser review plugin、把除錯工作拆給多個 subagents 平行處理。這些工作都很適合 agent，因為它們需要蒐集上下文、動多個檔案，還要保留可追蹤的變更紀錄。

我覺得這點蠻重要。很多 AI 工具看起來很會講，實際上只是在聊天窗裡補幾行 code。Grok Build 的方向比較像工具鏈的一部分。它想進入你每天都會打開的 terminal，不是逼你換一套工作方式。

• Plan mode 先讓你審查步驟。
• 核准後才會真的動檔案。
• 支援 AGENTS.md、plugins、hooks、skills。
• 也支援 MCP servers。
• Headless 模式用 -p 來跑腳本。
• ACP 支援可做自訂 bots 與 orchestration app。

為什麼 xAI 先攻 terminal

終端機是很聰明的切入點。IDE 助手很方便，但通常綁在單一編輯器裡。CLI agent 就不一樣了。它可以接 shell script、CI pipeline、local repo，還能塞進自動化流程。對工程團隊來說，這種彈性很有價值。

換句話說，xAI 不想只做一個聊天產品。它想讓 Grok Build 變成工作流的一環。你可以把它當成一個會看 repo 的助手，也可以把它當成能接任務的 automation 元件。這樣的定位，比單純的對話介面更貼近實戰。

另一個重點是信任問題。AI coding agent 最大的痛點，不是它會不會寫。是它會不會亂寫。xAI 把 plan mode 放進來，就是先讓你看步驟，再決定要不要執行。這招很務實。因為真正會碰 production code 的工具，不能只靠速度取勝。

“The CLI also provides full ACP support to build your own bots and agent orchestration apps.”

這句話很直白。xAI 想把 Grok Build 做成底層能力，不只是一次性的寫程式助手。對團隊來說，這代表它可能被拿去做內部工具、任務編排、甚至專案特化的 bot。

如果你問我，這種方向比花俏 demo 更有意思。因為工程團隊最後看的不是畫面，而是能不能少改幾次、少跑幾輪、少出幾次包。

和現有工具比，差在哪裡

Grok Build 進場時，市場已經很擠了。Claude Code、OpenAI Codex、GitHub Copilot 都已經在不同層級佔位。重點不再是能不能產 code，而是能不能融入團隊習慣。

xAI 的策略很明確。它沒有要你放棄既有流程。它說 Grok Build 能吃 AGENTS.md、plugins、hooks、skills，還能接 MCP servers。這代表它想先適應你的 repo，而不是叫你的 repo 適應它。

這裡可以直接做個簡單比較。Copilot 比較像 editor 內的即時助手。Claude Code 和 Grok Build 比較像接任務的 agent。xAI 再加上 parallel subagents 和 worktree 支援，就更偏向多步驟工程工作。這種工作才有機會真的省時間。

• Copilot 強在編輯器內補全。
• Claude Code 強在 terminal 工作流。
• Codex 偏向 agentic coding 任務。
• MCP 讓外部工具更好接。
• Grok Build 目前先鎖付費用戶。

如果只看定位，Grok Build 不是第一個 terminal coding agent。可是它把 plan mode、平行 subagents、ACP 一起塞進 beta，這就很有 xAI 味道。它想一次把工程師最在意的幾個點都端上來。

這波對開發者的實際意義

這次更新最值得看的是產品形狀，不是噱頭。xAI 把 Grok Build 當成 coding work 的基礎設施來做。你會看到 plan mode、headless execution、repo conventions、orchestration hooks，一起出現在第一版裡。

這代表 xAI 想讓人用它做日常工作，不是只拿來玩。對開發者來說，真正有用的 agent 要做到三件事。第一，聽得懂指令。第二，diff 要乾淨。第三，平行處理時不能丟 context。少了任何一項，體驗就會很像 demo。

我自己的判斷很簡單。這類工具最後拼的不是模型名字，而是工程細節。誰能把檔案改得穩、把步驟列得清楚、把權限控得住，誰就比較容易進到真實 repo。這也是 terminal 產品比聊天視窗更難做的地方。

背後的產業脈絡

AI coding 工具現在已經從「幫你補字」走到「幫你做事」。這個轉變很明顯。以前大家看的是 autocomplete。現在大家看的是 agent 能不能自己拆任務、自己跑工具、自己整理變更。

終端機在這裡很關鍵。因為工程世界本來就圍繞著 terminal、git、CI、script、server。誰能先把 AI 放進這條路徑，誰就更接近真實工作場景。這也是為什麼 CLI 產品一直有人做，而且一直有人願意試。

但市場也很現實。開發者不會因為你叫它 agent 就買單。它要先證明自己不煩、不亂、不會把 repo 弄髒。xAI 這次選擇先做 beta，而且先給付費訂閱者，就是在測這條路能不能走得通。

我會怎麼看這件事

如果 Grok Build 真的能把 plan mode、diff 檢查、平行 subagents 做穩，它會很適合 shell-heavy 的團隊。像是後端、平台工程、DevOps、內部工具團隊，這些人本來就離 terminal 很近。

但如果它只是把聊天機器人包成 CLI，熱度很快就會掉。開發者很挑。你只要讓它多改壞一次檔案，多誤解一次 repo 規則，大家就會回去用原本那套工具。這行很殘酷，也很合理。

所以我會把接下來的觀察重點放在三件事。它能不能穩定讀懂 project rules。它能不能讓 diff 保持可讀。它能不能把多步驟任務做完，還不把上下文搞丟。只要這三點有一個失手，工具就很難留住人。

接下來該看什麼

Grok Build 這次不是單純加一個功能，而是把 xAI 拉進 terminal coding agent 的競爭裡。接下來最值得看的，不是它會不會上新聞，而是它會不會真的被放進日常開發流程。

如果你本來就常在 shell 裡工作，這東西值得試。先看它會不會尊重你的 repo 規則，再看它能不能在平行任務裡維持品質。對工程團隊來說，這才是判斷一個 AI coding 工具有沒有留下來的標準。