Grok 4.5 讓一個提示詞跑完整個工作流

以前我總覺得模型只會講漂亮話，現在我只看它能不能用一個提示詞把工作做完。

我這陣子看模型發表頁看得很煩，真的。每次都寫得像宇宙要重開機：最強、最好、最會 coding、最會 agent，結果一進實作就開始飄。你叫它修 bug，它先跟你聊架構哲學；你叫它跑流程，它前兩步很像人，第三步就開始亂接工具，最後把 token 花得像不用錢。這種東西我看多了，胃都麻了。

所以我看到 x.ai 的 Grok 4.5 發表頁時，先跳過那些形容詞，直接盯三件事：coding、agentic tasks、還有它一直提的 office work。這三個點才是開發者會真的碰到的工作。它如果真能把一個模糊需求一路推到可交付成果，那我才會想繼續看下去。

它想賣的其實是工作完成率

Grok 4.5 被描述成 xAI 的 smartest model，主打 coding、agentic tasks，還有 knowledge work。

翻譯一下就是：它不是想當聊天玩具，它想當幹活的那台。coding 很直白，agentic tasks 是多步驟執行，knowledge work 則是研究、整理、文件、簡報、表格這些很煩但每天都在發生的事。這種定位我比較買單，因為它至少把戰場講清楚了。

我以前做內部工具時最常踩坑的，就是模型第一輪很漂亮，第二輪開始失憶，第三輪直接把任務帶歪。那種模型看起來很會，實際上只適合 demo。Grok 4.5 這次的說法比較像在賭一件事：它能不能把任務的形狀維持住，直到真的交件。

實操寫法很簡單：你不要拿單輪問答評估它。你要給它一個有起點、有中間狀態、有結尾的任務，像修 bug、改檔案、補文件、再驗證一次。它如果能一路保持上下文，才算有點料。

我更在意它挑哪些 benchmark

發表頁裡面列的測試集很有意思，像 DeepSWE 1.0、DeepSWE 1.1、SWE Marathon、Terminal Bench 2.1、SWE Bench Pro。這些名字不是拿來裝飾的，它們直接告訴我：這模型不是只想證明自己會聊天，而是想證明自己能碰程式、碰終端機、碰多步驟代理任務。這點我覺得比空泛的「最強」有用多了。

頁面也有放一些數字，例如 Terminal Bench 2.1 的 83.3%、SWE Bench Pro 的 64.7%、SWE Marathon 的 29.0% resolution rate。我要先講清楚，benchmark 不等於真實工作表現，這點我不會替任何模型洗地。但數字至少能告訴我：它們把火力放在哪裡。

白話一點說，x.ai 這次不是在賣一個萬用聊天框，而是在賣比較像工程助手的東西。這差很多。因為如果我要挑一個模型接 repo、接 shell、接內部流程，我要看的不是它會不會答題，是它能不能穩穩走完一串操作。

• 你做的是改 code，就看軟體工程 benchmark。
• 你做的是工具呼叫和 shell 流程，就看 terminal 和 agent benchmark。
• 你自己的任務如果都過不了，外面的榜單再漂亮也只是牆上貼紙。

實操寫法：自己做一份小測驗集。放一個 bug fix、一個 refactor、一個文件更新、一個研究整理、再加一個多步驟 agent 任務。這五題如果都能過，再回頭看 benchmark 才有意義。

訓練資料和 RL 才是我會看的地方

我通常比起看行銷標題，更愛看訓練描述。這份發表頁提到他們用大量 NVIDIA GB300 GPU，做了很重的資料過濾、去重、品質評分，還有領域導向的資料挑選。這句話我會多看兩眼，因為它透露的是模型怎麼被養出來，不是怎麼被包裝出來。

它還提到用了大量 reinforcement learning，特別是多步驟軟體工程和技術任務，搭配自動與模型式評分。這很重要。你要模型會規劃、會修正、會重試，就得真的拿這些 loop 去訓練，不然它只會講得像有把握，實際一碰到第三步就開始翻車。

也就是說，Grok 4.5 如果真有差，差的可能不是「更大」，而是「更會把事做完」。這種差異我很在意。因為 planning 很便宜，能不能撐住才貴。你做 agent 系統時最怕的就是它前面都對，最後卡在一個很無聊的狀態錯誤。

我自己做過幾個內部自動化專案，最討厭的就是模型一開始很像樣，後面開始漏狀態、漏約束、漏自己剛剛講過的事。那不是聰明不聰明的問題，是它撐不撐得住流程。

實操寫法：評估模型時不要只看正確率。你要測 persistence。丟一個會失敗、會中斷、要恢復的任務給它，看它能不能把流程撐回來。撐不住，就別拿去接 production。

一個提示詞把 app 生出來，才像真的在做事

發表頁最有感的地方，是它展示了從單一提示詞做出太陽系模擬器，還用了 Three.js、HUD 風格介面、還有比較完整的視覺效果。這種 demo 很容易讓人翻白眼，因為大家都看過漂亮截圖。但我看的是另一件事：它是不是能把模糊需求，拉成一個有結構的成品骨架。

這就是開發者最常暗爽的地方。大家嘴上說不要模型亂寫，心裡其實都想要它先幫你把前 80% 搞定。只要它能把檔案結構、UI、狀態、基本互動一起串起來，你就省掉很多空白頁時間。不是因為它完美，而是因為你終於不用從零開始瞪著編輯器發呆。

我會把這種能力叫做 builder 能力。helper 只會回答，builder 會把東西組起來。這差很多。當模型能把設計意圖一路帶到實作、狀態和錯誤處理，它才真的開始像工作夥伴，不像客服機器人。

• 先要求完整 app 骨架，不要只要單一 component。
• 提示詞裡直接寫明 framework、檔案數量、交付格式。
• 檢查它有沒有把 UI、邏輯、資料流一起保住。

實操寫法：你要它做的不是「幫我寫一段前端」，而是「幫我生出一個可跑的最小產品骨架」。把成功條件寫死，模型才不會拿漂亮廢話混過去。

速度和 token 效率，才是會算帳的人在意的地方

x.ai 這次也很直接地講了效能：Grok 4.5 服務速度是 80 TPS，而且在同樣任務上，token efficiency 大概是其他領先模型的兩倍，還能用不到一半的步數完成任務。這些數字我不會當神諭，但我會當帳單看。因為最後真的會付錢的人，通常不是最愛看排行榜的人，而是最愛看成本的人。

大家都很愛聊模型聰不聰明，直到 usage bill 來了，才突然發現 latency、token 數、step 數都很重要。如果一個模型能用更少 token、更少工具步驟把事情做完，那它就不只是比較會講話，而是真的比較省事。這種省事，會直接反映在產品體驗和營運成本上。

換句話說，Grok 4.5 這次不是只賣腦力，也在賣經濟性。這種賣法比較誠實。我寧可要一個少講廢話、穩定、便宜、速度快的模型，也不要一個每次都像在寫散文的高分選手。很多系統不需要詩意，它們需要吞吐量。

我以前就卡過這種問題：agent loop 一直繞，工具一直呼叫，結果每次都把 token 燒爆。那時候你才知道，模型會不會省字，根本不是小事，是能不能上線的事。

實操寫法：你自己的 stack 至少量三個指標，平均輸出 token、工具步數、端到端 latency。只要其中一個明顯下降，而且品質沒掉，你就有理由認真考慮換模型。

辦公室工作這段，才是它想進真實流程

發表頁裡還有一段我覺得很實際：Grok 4.5 被放進 Grok Build 當預設模型，還強調它能做複雜 Excel 模型、網路研究、多工作表操作、留註記給未來參考，甚至產出更好的 PowerPoint 和 Word 文件，還支援原生 shapes 和更清楚的文字。這不是邊角料，這是它想往日常工作裡鑽。

白話一點說，它在搶的是 coding 和 knowledge work 中間那塊很髒的地帶。很多團隊平常不是只有寫 code，還要查資料、整理表格、做簡報、寫文件、交接註記。這些工作碎得很，最吃上下文。如果模型能在這些格式之間不掉鏈子，它才真的有機會進工作流。

我其實滿吃這套，因為這才像真實世界。開發者一天到晚不是只在寫程式，還要寫 memo、補 deck、整理 research、修 spreadsheet。模型如果能把這些事情接得住，它就不是玩具，而是能幫你少加班的工具。

實操寫法：不要測單一檔案格式，直接測工作流。像是先叫它查資料，再把結果整理成表格，最後變成 5 頁簡報大綱。這比叫它「寫一段說明」更接近你真正在做的事。

可抄的模板

# Grok 4.5 評測與 rollout 模板：coding + agent + office work

你可以直接把這份 prompt 丟給模型，測它到底會不會做事。

## Prompt
你是資深工程師和執行者。

任務：
[用一句話描述真實任務。]

背景：
- Repo 或 workspace：[連結 / 路徑]
- 主要目標：[成功長什麼樣]
- 限制：[框架、語言、預算、時間、風格]
- 可用輸入：[檔案、文件、連結、API]
- 需要輸出：[程式碼、patch、說明、文件、簡報、試算表]

規則：
1. 分小步做。
2. 如果需要假設，先講假設再動手。
3. 優先做最小但正確的變更。
4. 保留原始意圖。
5. 如果用了工具，說明每一步為什麼需要。
6. 完成就停，不要一直腦補延伸需求。

執行格式：
- Plan：3 到 5 個 bullet
- Action：你改了什麼、產出了什麼
- Verification：你怎麼確認
- Risks：還可能錯在哪
- Next step：只有真的需要才寫

完成定義：
- 任務真的完成了。
- 產出可以直接用，不用整包重寫。
- 說明內容和實際變更一致。

## 評分規則
每項 1 到 5 分：
- 任務完成度
- 步驟紀律
- 正確性
- token 效率
- 面對模糊需求的恢復能力
- 最終輸出的可用性

## coding 測試題
找出 bug 並修掉，再解釋原因：
function median(a){a.sort();return a[a.length/2]}

## agent 測試題
研究 [topic] 的前三個選項，做成表格並推薦一個。
要包含來源、取捨、以及一個要問 stakeholder 的後續問題。

## office 測試題
做一份 5 頁的季度業務回顧大綱，包含：
- revenue
- margins
- pipeline
- risks
- next-quarter priorities

再把它整理成：
- spreadsheet summary
- slide outline
- short executive memo

## Review checklist
- 有沒有保住任務目標？
- 有沒有亂跑去做不必要的事？
- 有沒有真的交出可用成果？
- 說明有沒有清楚到可以信任？
- 有沒有在 token 和步驟上保持效率？

如果我要把 Grok 4.5 接進產品，我會先拿這份模板跑一輪，然後再依照自己的 stack 收緊格式。重點從來不是膜拜模型，而是把它丟進你真正會遇到的工作形狀裡，看它到底能不能撐住。

來源是 x.ai 的 Grok 4.5 發表頁：https://x.ai/news/grok-4-5。我上面拆的是原文主張、benchmark 與產品敘事；模板、評估方法和中文解讀是我自己整理出來的。