Grok Build 多了一個 /goal：你給一個目標就走人，xAI 的編碼代理人自己規劃、執行、再驗證

重點一：xAI 在 6 月 22 日為終端編碼代理人 Grok Build 加入 /goal——你描述一個目標，代理人自己規劃做法、拆成進度清單、逐項執行，並在過程中自我驗證，直到任務完成且通過驗證。

重點二：/goal 帶 status／pause／resume／clear 四個子指令（看即時進度、停工保留目標、接續、整個放棄），把「目標」做成可中途插手的可操控物件；使用需 SuperGrok 或 X Premium Plus 訂閱，Grok CLI 以單行指令安裝。

重點三：這條「長程自動執行＋自我驗證」賽道不是 xAI 獨有——OpenAI Codex CLI、Claude Code、Cursor 都在做同一件事；真正在變的，是人交給代理人的「單位」從一句提示變成一個可以走開的目標。

6 月 22 日，xAI 為自家終端編碼代理人 Grok Build 加了一個叫 /goal 的模式。你在終端機裡敲下一個目標——「把這個服務的舊登入流程換成新的，並確認頁面還能正常跑」——然後敲 /goal，就可以站起來去倒杯咖啡。

螢幕上不再是一行行等你回覆的提問，而是一張代理人自己列出、會逐項打勾的進度清單；它一邊改、一邊回頭跑腳本確認自己沒改壞。你交給 AI 的東西，從「一句要它補完的提示」換成了「一個它要自己跑到完成的目標」。

過去一年，工程師談「用 AI 寫程式」談的是補完與對話；2026 年要多看一層：你交付的『單位』正在從一句話，變成一個你可以走開的目標。/goal 不是這條路的起點，但它把這件事做得夠具體，值得用它當切片，看清楚整條賽道走到哪。

/goal 到底做了什麼？

據 xAI 的官方變更日誌與多家報導，/goal 的運作是一條 「規劃 → 執行 → 驗證」 的迴圈。你給一個目標，Grok Build 先分析、提出做法，把工作拆成一張可追蹤的進度清單，然後開始逐項執行；過程中你還能持續追加指示，不必等它停下來問。

關鍵在最後那個「驗證」。xAI 說，代理人 「可能回頭審自己寫的程式、檢查網頁以確認行為、或執行腳本來測試結果」——任務沒驗證通過前，它會持續工作，而不是寫完就回報「做好了」。這一步把「自己檢查作業」放進了同一個迴圈：它不只是把程式碼吐出來，還要試著證明那段程式碼真的有效。這正是「長程自動執行」與早期「一問一答」最大的差別——後者把對不對留給你判斷，前者試著自己先判斷一次。

長程任務跑久了，需要的是能中途插手的把手。/goal 給了四個：

• /goal status：叫出即時進度面板，看它做到哪、卡在哪。
• /goal pause：停工，但保留目標與進度。
• /goal resume：從暫停處接續，不必重講一次。
• /goal clear：整個目標不要了，清掉重來。

安裝是一行 curl 指令把 Grok CLI 裝起來，使用 /goal 需要 SuperGrok 或 X Premium Plus 訂閱。這四個指令看似瑣碎，卻是「把一個會跑很久的東西交出去」時真正需要的操作面——你要看得到它在幹嘛、喊得停、也接得回來。

為什麼說「交付單位」變了，而不只是多一個功能？

把鏡頭拉遠一點看。AI 寫程式這件事，這兩年交給代理人的「單位」一直在變大：最早是逐字補完（一行 autocomplete，你打字它猜下一段），接著是一次對話一個回合（你問、它答、你再追問），現在是一個你描述完就可以走開的目標。每往上一級，代理人一次扛的工作量、以及你需要盯著它的時間，都在改變。

/goal 的四個子指令，正好把這個「目標」變成一個看得見、抓得住的東西——它有狀態（status 看得到）、可以暫停與接續（pause／resume）、也可以丟掉（clear）。一個你能掛起、能接回、能放棄的東西，已經比較像專案管理裡的一張工單，而不像一次聊天。

對工作方式的影響很具體。你和代理人之間的互動，從「一來一回的對話」變成「交付一個目標、偶爾回來看面板」。盯著它打字、逐段確認的時間少了；但把目標定義清楚（要做到什麼程度、什麼叫完成）、以及事後驗收（它說做好了，到底有沒有）的責任，反而變重了。換句話說，工程師的施力點從「過程中的微操」往「前面的定義」和「後面的把關」兩端移。

這也是這條線真正的張力所在：當代理人會自己宣稱「驗證通過」，那道驗收關卡到底站不站得住，就成了你敢不敢真的走開的前提。它說它跑過測試了——但測試夠不夠、有沒有測到你真正在意的那條路，仍然是人要回答的問題。

同一條賽道，四家怎麼做？

把「目標」交出去、讓代理人長時間自己跑並自我查核，並不是 xAI 獨有的方向。Grok Build 進場時，這條賽道上已經有好幾家在跑。 下面這張表把四家的做法擺在一起——能力月月在變，以各家官方文件為準：

工具	交給代理人的單位	怎麼操控長程任務	自我驗證	取得門檻
Grok Build /goal（xAI）	一個顯式的「目標」物件	status／pause／resume／clear 四個指令	xAI 說會審程式碼、檢查網頁、跑腳本測結果	SuperGrok 或 X Premium Plus 訂閱
OpenAI Codex CLI	一個任務／工作階段	內建 plan／exec／review 結構化迴圈	跑測試、迭代修復；官方稱可長時間無人值守執行	ChatGPT 付費方案或 API
Claude Code（Anthropic）	一個任務的 agent loop	plan mode 先規劃再執行、可中斷接續	可跑測試、依結果反覆修	Claude 訂閱或 API 計費
Cursor 背景代理人	一個背景任務（可平行多個）	在雲端 VM 上執行、面板追蹤	可用瀏覽器視覺驗證 UI 變更	Cursor 訂閱

擺在一起就看得出來：四家方向一致，差別在交付單位的形狀（一個目標、一個任務、一個 loop、一個背景作業）、操控的把手，以及在哪裡跑（本機終端，還是雲端 VM）。Cursor 把代理人推到雲端、還能平行開好幾個並用瀏覽器驗 UI；Codex CLI 與 Claude Code 走本機終端、貼著你的 repo 跑；Grok Build 的 /goal 可辨識的地方，是把「目標」做成一個帶生命週期指令的顯式物件，讓你像管一張工單那樣管它。

至於哪一種更合用，取決於你的工作流、既有訂閱、以及你願不願意把程式碼丟上雲端跑——這篇不替你選。值得記住的是：當四家都往「交一個目標、它自己跑到驗完」走，這個方向本身已經不是某一家的賣點，而是這一代編碼代理人的共同形狀。

把更長的任務交出去前，先盯哪兩件事？

第一件是自我驗證的可靠度。/goal 最吸引人的地方是「它會自己檢查」，但 xAI 給的是機制描述，不是效果保證——代理人能不能真的測對輸出，決定了你能不能放心走開。實務上，把驗證標準寫進目標（要跑哪些測試、什麼叫「行為正確」、哪些頁面一定要能開），比單純相信它一句「驗過了」更實在。代理人自評通過、但漏測了關鍵路徑，是這類長程任務最典型的失手點。

第二件是取得門檻。Grok Build 綁 SuperGrok 或 X Premium Plus 訂閱，對台灣多數以 Claude／OpenAI 系工具為主力的工程團隊來說，這是要不要把 xAI 這條線納進既有工作流的現實成本；多接一條代理人線，也意味著多一套要熟悉的指令、計費與權限邊界。

要不要把更長的任務交給代理人、交給哪一家，這篇不下結論。但有一個判準對四家都適用：先看它「自己說驗過了」這句話，你信得過幾分——這一格信任，目前還是人在補。

---

資料來源：xAI Grok Build changelog、MarkTechPost、TechTimes、KuCoin、OpenAI Developers、Anthropic Claude Code documentation、Cursor Documentation。

矽基前沿 · 工作現場線（編輯：廖玄同），《Grok Build 多了一個 /goal：你給一個目標就走人，xAI 的編碼代理人自己規劃、執行、再驗證》，矽基前沿 [Si]gnals，2026-06-29。https://signals.tw/articles/xai-grok-goal-autonomous-mode/