5 個 Grok 更新，把我寫 code 的方式改掉

我拆 Grok 這波更新：大模型、worktrees、API beta、語音與影片工具，哪些真能改寫開發流程。

我盯 Grok 一陣子了，老實說，它一直像那種 demo 很會講、真上線就開始掉漆的產品。回話很快，語氣很滿，像什麼都懂；但你一把它丟進真的開發流程，它就開始露餡。不是不能聊，是一進到 refactor、debug、長上下文、多人協作，整個就像每次都失憶，前十分鐘講過什麼完全不算數。我最煩的就是這種：看起來很聰明，實際上很會浪費人時間。

後來我看到 Basenor 的整理，〈5 Grok Updates You Should Know About Right Now〉，它把 2026/6/5 這波 xAI 更新一次收齊。這篇不是什麼硬核技術論文，但它把我在意的幾個點直接攤開：更大的模型、worktrees、coding API beta、voice、image-to-video。原文沒有提供觀看數或書籤數，所以我不亂掰。

我在意的不是聲量，是工作流會不會真的變順。哪些更新只是包裝，哪些是真的能讓開發少踩坑，這才是重點。

先別看行銷詞，我只看模型到底有沒有長腦

Elon Musk 提到的模型改進，指向 Grok V9-Medium 的持續訓練；它已在 1.5 兆參數完成訓練，規模是目前 v8-small 生產模型 5000 億參數的三倍。

翻譯一下就是：xAI 不是只在修外觀，它是真的在往更大一級的模型堆。參數變大不是魔法，但它通常代表上限會往上走。更重要的是，Basenor 這篇還提到 supervised fine-tuning 跟 reinforcement learning 也在跑，預計 2026 年 6 月中旬左右會公開。這點我比單純的「更大」還在意，因為大模型如果沒調好，照樣會講一堆似是而非的屁話。

我以前拿一些 assistant 模型做多步 refactor，最常見的問題不是完全答錯，而是答到一半開始漂。函式命名莫名其妙改掉、抽象層級亂升、明明要的是保守修補，卻硬要幫你「優化」成另一套架構。那種感覺很差，因為你最後不是在用 AI 幫你做事，是在幫 AI 收爛攤子。

如果 Grok V9-Medium 真如文章描述，重點不是它會不會講更漂亮，而是它在非玩具任務上會不會少犯低級錯。像是：看懂約束、維持一致、不要亂改介面、不要在長任務中失焦。這些才是開發者每天真的會碰到的地方。

• 別先看單輪回答，先看長任務穩不穩。
• 拿有約束的 code task 測，不要用玩具 prompt。
• 比對失敗模式，因為那通常比成功案例更誠實。

我會怎麼做：我會自己做一組固定測試，丟一個 refactor、一個 debug、一個架構判斷給 Grok，prompt 不變，然後拿現在用的模型一起比。你要看的是少改幾次、少補幾輪，而不是它文筆多順。這種東西沒有感覺派，只有實測派。你可以拿 OpenAI Codex、Claude 一起當對照組。

worktrees 這個功能，終於像是有開發者真的在裡面

第二則 tweet 確認 Grok 已支援 worktrees，也就是 Git 裡可以從同一個 repository 開出多個工作目錄的功能。

這個更新我反而最有感。worktrees 很無聊，但無聊得剛剛好。它不是炫技功能，是那種會直接降低混亂的東西。Basenor 的說法是，Grok 的 coding subagents 可以平行跑不同分支，而且不會踩到主程式碼庫。這句話很重要，因為它透露出來的是：做這功能的人，大概真的被 agent 互撞搞過。

我看過太多「agentic coding」最後變成災難。你叫一個 agent 修 bug，另一個補測試，第三個改文件，結果三個都在同一個 working tree 裡亂寫，像幾個小孩拿蠟筆在牆上塗。merge conflict 爆掉、半成品互相覆蓋、最後你不是在加速，是在收拾。

worktrees 的價值就在這裡：每個任務一個 checkout，但還是共用同一份 repo 歷史。白話就是，讓每個 agent 去自己的房間，不要在客廳互相踢腳。這種隔離對平行任務超重要，尤其你如果真的想讓 AI 同時做實作、測試、文件，沒有 worktree 幾乎一定亂。

我自己會把它當成「風險控管功能」，不是「效率加成功能」。因為它先解掉的是互相踩線的問題，效率才有可能往上。沒有這層隔離，agent 再聰明都只是更快地把事情搞亂。

• 每個 agent task 一個 worktree，不要共用。
• 留一個主線給人 review，另一個給實驗性修改。
• 任務結束就刪掉 worktree，別讓垃圾堆著。

實操上，我會把 implementation、tests、docs 拆成三個 worktree。先看它們能不能互不干擾，再看 merge 回主線有沒有少掉很多痛苦。若是有，這功能才算真有用；如果沒有，它就只是介面上多一個按鈕。

Grok Build 0.1 才是開發者該真的去碰的版本

xAI API 的 public beta 於 5 月 29 日開放，Grok Build 0.1 是專門做 coding 的模型，主打 agentic tasks。

這句話的意思很直接：xAI 現在有一個 coding 專用模型可以讓你接 API 了。這就把討論從「這 chatbot 很會講」拉到「我能不能把它接進自己的工具鏈」。Basenor 提到 Grok Build 0.1 有 256,000 token context window、always-on reasoning，而且支援文字與圖片輸入。價格也寫得很清楚：input 每百萬 token $1、output 每百萬 token $2。這不是花拳繡腿，這是可以開始算成本的規格。

我特別在意它被叫做 dedicated coding model。因為太多廠商喜歡把一般模型硬貼上 coding 標籤，結果一碰到 repo 結構就開始亂猜 import、亂補檔案、亂改接口。真正該看的是它能不能處理 project context、跨檔案一致性、長 prompt 的穩定度。只會寫 snippet 的模型，對真實開發幫助有限。

256,000 token 這個窗口比較像真的能幹活。你可以塞一大段 repo 內容、設計說明、bug log，不用一下就掉到上下文外。always-on reasoning 也很關鍵，至少從產品語意上看，它是朝著「一路把任務想完」去設計，不是半途切模式裝沒事。

我以前用過一些模型，處理單檔還行，一旦加上測試、再加上 patch plan，就開始崩。那種崩不是完全答錯，而是前後不一致，最後你得自己重新整理一次。這種模型如果不能扛住真實工作裡的髒東西，那再大也沒用。

我會怎麼測：第一，丟一個長 log 叫它找 bug 並提修法；第二，叫它同時改兩個相關檔案但不能破壞介面；第三，叫它自己總結改動的 tradeoff。三關都過，才值得接進流程。

voice 跟 video 不是附屬品，它們其實在擴大使用面

在這些 tweet 前一天，也就是 6 月 4 日，xAI 公開推出 Grok Voice，並把 Grok Imagine 1.5 Preview 開放到 API。

我通常對「語音＋影片」這種組合很保留。很多公司在模型推理還沒站穩時，就急著往 voice、video、multimodal 全塞，因為 demo 比正確性好賣。但 Basenor 這篇給的細節夠多，我會把它當成真的產品動作來看，而不是隨便加料。Grok Voice 已經公開，Imagine 1.5 Preview 也進 API 了。文章還提到它在 Artificial Analysis 的 Video Arena Image-to-Video 排行拿到第一，Elo 1404，還能產生同步音訊、片長拉到 15 秒。這些都是很具體的規格，不是空話。

白話一點說，xAI 想讓 Grok 不只待在文字框裡。你可以用嘴巴講、可以丟圖、可以做短影片。對開發者來說，這很重要，因為使用者本來就不是只活在 prompt box 裡。他們會切換模式、會上傳素材、會想要能直接拿去展示的輸出。

我以前做內容流程時，最煩的就是文字模型寫完腳本後，我還得搬去另一個工具做配音，再搬去別的工具做視覺，再搬去別的地方修整。每一次搬運都會掉 context，也會掉品質。如果一個模型能把 voice 跟 media generation 接在同一套 stack 裡，至少少掉幾次中間轉手。

但我不會因為 leaderboard 就過度解讀。榜單第一不等於 production 好用，這點我一直很保留。不過它至少說明一件事：xAI 不是只想做一個聊天介面，它在試著把使用面往外推。

• voice 用來快速迭代，不要拿來當最終驗證。
• video 用來先做概念草稿，再決定要不要精修。
• 來源 prompt 和輸出資產要一起存，後面才有辦法追。

實際操作上，如果你的工作裡有腳本、旁白、視覺 prototype，不妨把其中一段搬進 Grok 試試。目標不是把整套工具砍掉，而是看中間的 handoff friction 有沒有真的下降。

真正值得看的不是單點功能，是它的出貨節奏

這兩則 tweet 很容易滑過去，但它們其實在講同一件事：xAI 正在同時在模型、API、voice、video generation 幾條線上高頻出貨。

這段我覺得最容易被忽略。單一更新當然有趣，但更大的訊號是 xAI 在多條產品線一起往前推：更大模型、coding API、worktrees、voice、image-to-video。這不是慢慢打磨的節奏，這是想用速度把產品面鋪滿，讓開發者開始養成使用習慣。

我對這種策略一半喜歡、一半嫌棄。喜歡的是它有可能真的把工具變好用；嫌棄的是，快通常代表文件亂、品質不均、細節沒收乾淨。但如果你是要拿來做開發，節奏本身就是訊號：它是在變好，還是在原地換皮。

對 Tesla 車主來說，Grok 在車內或 X app 的變化可能已經開始進來。對開發者來說更直接：這不是拿來看熱鬧的，是拿來測的。Grok Build 0.1、worktrees、voice、video 這幾個點如果真的能在實務裡站住，才有資格進你的工作流。

我自己的做法會很土：不等什麼「v2 再說」，直接測現在的 API，記錄它在哪裡失敗，等大模型更新再回頭比一次。只有這樣，你才知道出貨節奏是在累積可用性，還是在堆噪音。

可抄的模板

# Grok 開發者測試模板（可直接貼進你的工作流）

## 1) 測試設定
- 模型：Grok Build 0.1 / 新版 Grok
- 測試日期：
- Repo：
- 任務類型：bug fix / refactor / feature / docs
- 提供的 context：短 / 中 / 長

## 2) Prompt 模板
你在一個 codebase 裡工作，請遵守以下限制：
- 不要修改無關檔案。
- 除非我明講，不要改 public interface。
- 如果你做了 tradeoff，先說明理由。
- 如果需要假設，先列出假設。

任務：
[在這裡描述任務]

Repo context：
[貼相關檔案、log、設計摘要]

輸出格式：
1. 簡短 plan
2. 逐檔修改內容
3. 風險
4. 驗證步驟
5. 最終摘要

## 3) worktrees 配置
- 一個 worktree 給 implementation
- 一個 worktree 給 tests
- 一個 worktree 給 docs / review notes
- 每個 agent 只能碰自己的 tree

## 4) 評分表
每項 1-5 分：
- 正確性
- context 保留度
- code quality
- conflict avoidance
- 解釋清楚程度
- 是否遵守限制

## 5) Pass / fail 問題
- 有沒有動到不相關檔案？
- 有沒有保留 repo 原本風格？
- 有沒有踩到平行工作？
- prompt 變長時有沒有失焦？
- 改動有沒有講到足夠讓人 review？

## 6) 決策規則
- correctness 和 conflict avoidance 都有 4 分以上，才繼續測。
- 如果在 merge safety 或長上下文一致性失敗，先不要導入。

上面這段是我根據 Basenor 提到的幾個痛點自己整理的。原始文章是 xAI 這波更新的整理與轉述，我這篇則是把它翻成開發者真的能拿去測的版本。原始來源：https://www.basenor.com/blogs/news/5-grok-updates-you-should-know-about-right-now。我有順手連到 xAI、git worktree、OpenAI Codex、Claude 和 Artificial Analysis，方便你自己往下查。