Grok Build 把 xAI 變成寫碼代理

Grok Build 是 xAI 的第一個 coding agent，我把它拆成可直接拿去測工具的評估方法。

我這陣子看 AI 寫碼工具，真的越看越煩。大部分產品都很像在跟你裝熟：你丟一個問題，它先稱讚你；你說要改架構，它也說好；你問它能不能幫忙處理整個 repo，它就開始講一堆漂亮話，最後還是只會吐一段看起來像樣的程式碼。問題不是它會不會寫，而是它到底懂不懂「在真實專案裡做事」這件事。

所以我看到 xAI 的 Grok Build 時，第一個反應不是哇好猛，而是：終於有人願意把 Grok 從聊天框往工作流裡推了。這種東西我看過太多半成品，差別就在於它是 demo 還是能進 repo。Grok Build 這次被講成 xAI 的第一個 coding agent，意思很直接，就是它不想只當會講話的模型了。

我下面不想跟你講什麼空泛的 agent 未來，我只想拆一件事：這種「coding agent」的說法，實際上在測什麼、常常死在哪、你要怎麼把它拿來評估自己的工具選型。順便，我也會給你一份能直接複製的模板，省得你每次都從零開始想怎麼測。

xAI 這次不是在賣聊天，是在賣做事

“AI coding agents are on the rise, and xAI is the latest to join the race with Grok Build.”

翻譯一下就是：xAI 不再只想讓 Grok 當回答機，它想讓 Grok 進到開發流程裡幫你幹活。這聽起來很像行銷話術，但我覺得差別其實很硬。聊天模型的任務是回答；coding agent 的任務是處理。前者你問它「怎麼做」，後者你要它「先看、再判斷、再改、最後留下可 review 的結果」。

我以前最受不了這類產品的一點，就是它們很愛把「能產生 code」偷換成「能完成工作」。這兩件事差很多。會寫一段 function，不代表會理解依賴關係；能改一個檔案，不代表知道這個改動會不會炸測試；能講出一個 plan，不代表真的能把 plan 變成乾淨的 diff。這些才是 agent 真正要扛的。

實操上，我會把這類消息先翻成三個問題：它能不能跨檔案？它能不能保留 context？它能不能在你不盯著它的時候，還維持基本的工程判斷？如果這三題答不清楚，那不管它叫 agent、copilot 還是 assistant，本質上都還是比較會聊天的 autocomplete。

• 看產品時先問：它是在回答，還是在執行。
• 能不能跨檔案、保留 context、產出可 review 的 diff，這三個比 demo 重要。

真正有用的 agent，不是永遠說好

我很討厭一種 AI 風格：你提什麼它都說好。你說要大改，它說好；你說要保守，它也說好。這種東西拿來陪你腦暴還行，拿來寫碼就很危險。因為工程裡最值錢的不是附和，而是能不能看出你哪裡想歪了。

這也是我會拿 Grok Build 來觀察的地方。它如果只是把 prompt 包裝得更像「工作流」，那沒什麼了不起。真正的 coding agent 應該能做兩件事：第一，先問清楚範圍；第二，對你的方案提出反駁或縮小。尤其是後者，很多人嘴上說想要 agent，其實只是想要一個不會頂嘴的實習生。但實習生至少還會問你「這樣真的可以嗎」。

我之前拿過一個 AI 工具去整理 legacy service，結果它很熱心地把一個檔案拆成五個，名字改得像隨機產生器，測試也跟著漂移。從語法上看它沒錯，從維運角度看它很糟。這就是 agent 跟 code generator 的分水嶺：前者要懂風險，後者只負責生成。

實操寫法很簡單。你不要拿最容易的題目測它，因為那只會驗證它會不會抄模板。你要故意給它一個有陷阱的任務，例如：改 API 但不能動 public contract、修 bug 但要維持 test pattern、重構 helper 但不能改 import 路徑。看它會不會先提醒你 blast radius，而不是直接衝進去亂改。

• 好 agent 會先縮小問題，不會急著擴張問題。
• 壞 agent 會把一個小修補寫成你不想 review 的大工程。

「第一個 coding agent」這句話，重點其實是試水溫

PCMag 把 Grok Build 寫成 xAI 的第一個 AI coding agent，這個「第一個」我覺得很重要。因為第一版通常不是答案，而是公司在摸索自己到底要站哪一邊：是做展示用的酷東西，還是做每天都能碰的工具。兩者差超多。

第一個版本最容易暴露公司對開發者痛點的理解程度。它如果只會秀單點能力，通常代表產品思維還停在模型層；如果它開始處理 review、diff、scope control、失敗回復這些麻煩事，才比較像真的想進工作流。你可以把這種產品想成進廚房，不是進舞台。台上漂亮沒用，能不能洗菜、切菜、收尾，才是重點。

我看這類產品時，會順手拿它去比 GitHub Copilot、Claude Code，還有 OpenAI Codex 這些已經被很多人拿來試的工具。不是因為品牌很香，而是因為工作流才是比較基準。你最後不是在選誰的 demo 比較會講話，而是在選誰比較不會把你的 repo 弄髒。

實操上，我會把「第一個」解讀成試用版，不是定論。你要看的是它有沒有把最麻煩的工程細節先處理掉，而不是只把介面做得很像 agent。這種差別，通常要真的丟進 repo 才看得出來。

repo 不吃這套，模型再強也沒用

每次看到 coding agent 宣傳，我腦中都會浮現同一個畫面：一個乾淨得要命的 toy repo，幾個漂亮檔案，幾個簡單測試，然後 agent 在那邊大顯神威。問題是，真實專案根本不是這樣。真實 repo 充滿歷史包袱、半完成 migration、怪命名、過期測試、以及只有某個離職工程師才知道的詭異路徑。

所以 Grok Build 真正要證明的，不是它會不會寫 code，而是它會不會在你的 repo 裡維持形狀。它知道該讀哪些檔案嗎？它會不會尊重現有 pattern？它會不會因為想表現而順手重寫一堆你根本沒叫它碰的東西？如果答案不漂亮，那它就是在增加 cleanup work，不是在幫忙。

我踩過最典型的坑，就是 AI 幫我產出一段「看起來很合理」的 patch，結果 import 錯、config 假設錯、測試也被它修成沒意義。這種東西在展示時完全看不出來，只有 merge 的時候你才會想罵人。這也是為什麼我現在看 agent，只看它能不能在 repo 裡活下來，不看它會不會寫一段漂亮的 code。

• repo-aware agent：會讀現有結構、尊重團隊慣例、保留測試模式。
• repo-blind agent：把每個專案都當成全新教學範例。

實操寫法：拿你最醜、但最真實的 repo 來測，不要拿新專案。最好是有既有 conventions、又有一個你平常不想碰的 edge case。看它是幫你維持形狀，還是直接 bulldoze 掉。

我會先問這幾題，再決定要不要信它

如果 Grok Build 要真的進工作流，我會先問幾個很無聊、但很致命的問題。它到底用了哪些 context？每一步能不能看？我能不能中途停掉？它產出的 diff 是不是乾淨？失敗了會不會自己修正，還是只會重試到你受不了？這些都不性感，但這些就是成敗。

很多 AI coding 產品最愛偷懶的地方，就是只展示 happy path。看起來像有魔法，實際上是把風險丟給使用者。你一開始可能覺得很爽，直到第一個壞 patch 進了 shared branch，整個團隊開始不信它。信任一掉，工具就會變成擺設。

我會把評估標準縮成四個字：可追、可控。可追是你知道它為什麼改；可控是你知道它改到哪裡停。只要這兩件事做不到，再聰明的 agent 都只是高級玩具。開發者不是不想要自動化，我們是不想要不可預測的自動化。

實操上，你可以先寫好自己的底線清單。像我自己會看四件事：diff 要不能太髒、範圍要能控制、理由要能看懂、壞掉時要能快速拒絕。這些如果做不到，我就不管它多會講故事。

我會怎麼測 Grok Build，不浪費一整週

如果明天要我評估 Grok Build，我絕對不會從 greenfield app 開始。那種測法太假了。我要的是一個一小時內能看出差異的流程，而且要在真實 codebase 裡做。像是更新 API contract、修一個 flaky test、或是搬一個 helper 但不能搞爛 import path。這種題目才會逼出它的真面目。

我也會把它跟你平常可能已經在用的工具放一起看，像 GitHub Copilot、OpenAI Codex、甚至 Claude Code。不是因為名字比較大，而是因為 workflow 才是核心。你要看它能不能連續幾輪都還有用，能不能在走歪後拉回來，能不能講 tradeoff 而不是只會講漂亮話。

我最在意的是它像不像 collaborator，而不是 vending machine。vending machine 你丟錢它吐 code；collaborator 會提醒你這樣做會不會把後面搞爛。這個標準很土，但它真的比「看起來很 AI」重要太多。

實操寫法：直接做一個一小時 eval。挑三個任務，各自代表不同痛點：一個 refactor、一個 bug fix、一個 test change。每個任務都記錄 accuracy、diff quality、還有你最後要補多少 cleanup。cleanup 比 help 還大，就不用再自欺欺人了。

可抄的模板

# AI coding agent eval template

## Goal
Describe the exact task you want the agent to complete.

## Repo context
- Language/framework:
- Package manager:
- Test command:
- Files likely involved:

## Task
Write the change request in one paragraph.

## Constraints
- Do not change public APIs unless required.
- Keep diffs small.
- Preserve existing style and naming.
- Update tests if behavior changes.
- Explain any tradeoffs before editing.

## Questions the agent should answer first
1. What files do you think are relevant?
2. What risks do you see?
3. What is the smallest safe change?

## What good output looks like
- Clear plan before edits
- Small, reviewable diff
- Tests updated or added
- Notes on edge cases and follow-up work

## Red flags
- Rewrites unrelated files
- Ignores existing conventions
- Makes broad changes without asking
- Produces code that looks right but is hard to review

## Scorecard
- Repo understanding: 1-5
- Diff quality: 1-5
- Scope control: 1-5
- Test awareness: 1-5
- Cleanup required: 1-5

## Decision
- Adopt
- Pilot
- Reject

## Notes
Capture the agent’s best and worst behaviors here.

這份模板我就是拿來逼工具露出本性。不是看它能不能寫出一段漂亮答案，而是看它會不會在真實 repo 裡做出可 review 的改動。你直接複製去用就行，不用再自己發明評分表。

原始來源是 PCMag 這篇 https://www.pcmag.com/news/elon-musks-xai-launches-grok-build-its-first-ai-coding-agent，我拆的是它的產品訊號；上面這套評估方法、判斷框架和模板，主要是我自己整理出來的。