# Grok 4.6 – 一份實戰指南

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 原作者：eric zakariasson (@ericzakariasson) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥🔥🔥🔥 · 日期：2026-08-13

> 原始來源：https://x.com/ericzakariasson/status/2087566447178547494

## 證據與延伸閱讀

- [Grok 4.6 – 一份實戰指南](https://x.com/ericzakariasson/status/2087566447178547494)

## 中文摘要

# Grok 4.6 – 一份實戰指南

Grok 4.6 上線了！我花了幾週時間，把它當成日常工作中的主要工具，處理一般的程式開發與知識工作，也特別用它做了幾個專案，想看看它在哪些地方能撐得住。

它各方面都做得不錯。最讓我印象深刻的，不是某一項能力有多大的躍進，而是它溝通的方式，以及它的速度。

## 高資訊密度的溝通

它很適合一起協作，並肩工作起來相當順手。摘要裡有大量真正有用的資訊，而不是把工作要求重新複述一遍；執行期間的簡短更新，也足以讓我知道現在是否需要介入。

在進行小幅變更時，它會保持安靜；等到開始處理大量檔案時，才會開始描述進度。要把這種分寸拿捏好，比你想像中需要更多調整。不過它偶爾還是會告訴我一些其實不需要知道的事情，這部分我們還在持續改善。

## 令人愉快的速度

4.5 其實也很快。4.6 不只快，還明顯更聰明，而這兩者結合起來，讓我更傾向採用同步的工作方式。與其一開始塞入大量 context，然後等待結果，我現在會先交代一個小任務，看看結果，再繼續往下做。只要開口要求，同一個 session 也能接著進入較長期的任務。

我會根據當月最好的模型擅長什麼，在同步與非同步之間切換。非同步工作能在我離開電腦時完成更多事情，但我會失去脈絡，最後只能在沒有前情的情況下，直接檢查一大份 diff。4.6 讓我重新偏向同步工作；如果我在意結果，這正是我比較希望採用的方式。

我也用 Remotion 為這兩個專案製作了一支 launch video！那幾週大多是一般的日常工作。它替我瀏覽網站，包括透過點擊 provider 的主控台來建立 API key。它也替正在執行的應用程式進行功能與視覺 QA。它把我的收件匣整理到只剩下幾個真正需要回覆的討論串，這種感覺永遠都很好。它還幫我草擬 Cursor SDK Bridge 和 /rename-chat 的 launch 貼文。

## 簡短提示詞，嚴格驗證

那幾週裡，我花了一部分時間比較不同的 prompting 風格。長提示詞與短提示詞之間的差異，以及像「work very hard」這類特定措辭是否會改變結果。我發現，措辭幾乎完全沒有影響。

長度確實有影響，但方式和我原本想的不一樣。長提示詞能換來更高的具體性，所以如果你確切知道自己想要什麼，就把它寫下來。短提示詞則會把更多決策交給模型自行判斷。過去，這種取捨會讓人傾向把所有事情都寫清楚。但 4.6 的判斷品味已經夠好了，通常只要一個短提示詞，再加上清楚的偏好，就能得到不錯的結果。

我給它一份詳細的 feedback widget 規格，包含工作階段擷取、伺服器端處理器和雲端 Agent 派送；它完整地端到端處理了整個專案，而且結構很合理。除非你要求它拆分元件，否則它確實會在不同元件中重複相同內容。手上有長規格時，長規格依然完全有效。

我做的其中一個專案是試算表應用程式，並且各自把同一個任務交給兩個模型兩次。第一次執行時，我提供了一份兩頁的規格，涵蓋我能想到的每個工具列項目、鍵盤快速鍵與公式。第二次則只給了三句話。

```text
Build a polished Sheets/Excel-style app in Next.js and an AI chat that can analyze the sheet. Use the Cursor SDK for all AI features. Preload a realistic sample workbook so it looks good immediately.

```

兩個應用程式最後幾乎一模一樣。真正改變結果的，是多加了一句話：

```text
Verify the function and design after implementation, and keep on iterating and verifying until it's production ready.

```

那幾週裡，我找到最具槓桿效果的事情，就是這一行！加上這句後，模型會開啟應用程式，點擊實際的使用者操作路徑，確認巢狀公式是否正確計算，並修正它發現的問題。如果沒有穩定的瀏覽器操作能力，這些都無法運作，也就不可能形成這個迴圈。

當輸出比較難以檢查時，同樣的原則也成立。在 3D 場景上說「改善材質」完全沒有進展；但改成「擷取目前畫面、列出其中有哪些問題，然後只修正那些問題」，就立刻有效。

從這裡開始的每一次比較，都會在彼此隔離的 workspace 中，使用相同的提示詞交給兩個模型執行，因此後面的內容不是我對上個月結果的記憶。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/d3a47211318fdeff.jpg)
> Grok 4.5 介面中整合 Gridforge 試算表與右側 Gridforge AI 側欄的對照圖

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">左側視窗標題顯示「Grok 4.5」，下方為 Gridforge 試算表介面，包含工作表名稱「Northwind Analytics – FY2026」、上方工具列（包含 AI 按鈕）、試算表儲存格內容（顯示 ARR 為 $5,136,000.00、MRR 為 $428,000.00 等財務指標）、左下角分頁標籤（Overview, Revenue, Funnel, Cohorts 等），以及右側的「Gridforge AI」側欄（標示「Cursor SDK - workbook-aware」），側欄內提供「Analyze workbook」、「Suggest formulas」、「Create chart idea」、「Presentation outline」等按鈕，以及輸入框文字「Ask about ARR, funnel conversion, cohorts, or request formula/chart/presentation help. Answers use the Cursor SDK when configured and cite workbook cells.」與底部輸入框。右側視窗標題顯示「Grok 4.6」，畫面為空白白色區域。</div></details>

你也不需要告訴它要努力工作，或持續推進直到完成。它自己就會繼續執行一段不短的時間。更重要的是，你要說清楚「完成」代表什麼，否則它會替你決定。

## 進一步挑戰

我從小玩了多到不太合理的《世紀帝國 II》，累積了幾千個小時。所以我第一個想嘗試的專案，就是重現這款遊戲。我要求它製作一款瀏覽器策略遊戲，包含經濟系統、建造、戰鬥、戰爭迷霧、目標，以及一個新玩家不看說明也能讀懂的 HUD。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/c0901aa492a18fee.jpg)
> Grok 4.5 與 Grok 4.6 介面與遊戲畫面比較

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">左側畫面標題為 Grok 4.5，上方顯示資源數值：木材 250、糧食 220、石材 120、人口 4/10，右上角顯示「HOMESTEAD AGE」。左側欄位為 OBJECTIVES（目標），包含：
- Gather wood near the Hall (已勾選)
- Build a Cottage for population (已勾選)
- Raise a Watch Barracks (已勾選)
- Train Spear-Guards (已勾選)
- Destroy the Raider Camp across the ford
下方中央為遊戲地圖，右下角為小地圖與操作提示（WASD / Drag pan、Scroll zoom、LMB select、RMB command、B build）。

右側畫面標題為 Grok 4.6，右上角播放控制列顯示暫停、播放倍速、時間 00:09 與 fps。上方顯示資源數值：木材 130、糧食 160、石材 80、礦石 60、人口 6/10。右側欄位為 OBJECTIVES（目標），包含：
- Stock the stores (Harvest 150 timber and 100 grain [lifetime gathered])
- Raise the village (Complete 2 Cottages and a Yard.)
- Arm the vale (Field 6 Wardens or Slingers and research Bronze Edges.)
- Break the host (Raze the Cinder Outpost beyond the river.)
中央為等距視角遊戲畫面，帶有文字提示「Left-click a laborer or drag a box around your people.」。下方欄位左側為小地圖與「Vale map - click to pan」，中央為「NO SELECTION」與「Focus Hearthhall」按鈕，右側為「COMMANDS」（Select people or a hall to issue orders.）。底部顯示快捷鍵提示（LMB select、drag box、RMB command、WASD/arrows pan、wheel zoom、F attack-move、B build、X stop、H hearth、Space pause）。</div></details>

4.5 做出了一個可運作的扁平原型。4.6 第一次嘗試就做出了等距 3D 世界，HUD 和小地圖也已經就位。和真正的遊戲接近多了！

延續這趟懷舊之旅，接下來我做的是 MSN Messenger。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/be2e8a6e551a7930.jpg)
> Grok 4.5 與 Grok 4.6 介面中的即時通訊軟體對話視窗與選單比較

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">左側視窗標題列顯示「Grok 4.5」，下方為舊版風格的即時通訊軟體介面。
左側聯絡人清單標題為「Alex Rivera - MSN Messenger」，聯絡人包括 Jessica P.、Mike O.、Sam O.、Taylor R.、Morgan Lee、Riley D.。
中央對話視窗標題為「Jessica P. - Instant Message」，對話記錄顯示 Alex Rivera 傳送多則訊息與圖示，對話框上方彈出選單包含：
- Floating Hearts
- Bouncy Buddy
- Dancing Frog
右側聯絡人頭像區顯示 Jessica P. 狀態。

右側視窗標題列顯示「Grok 4.6」，下方為即時通訊軟體介面。
左側聯絡人清單標題為「MSN Messenger」，使用者名稱為 Emily Park，下方聯絡人分類包含：
- Friends (4/4)：Jake Morales、Sarah Kim、Mike O'Donnell、Lisa Nguyen
- Family (0/1)：Nana Park
- School (1/3)：Rachel Foster、Chris Patel
下方搜尋列顯示「Find a contact or a number...」。
右側對話視窗標題為「Jake Morales - Conversation」，對話框上方彈出選單包含：
- Knock knock
- Smooch
- Heart attack
- Hello!
- Butterfly
- Strike!
底端文字輸入框右側有「Send」按鈕，下方帶有「Get more cool winks, emoticons and display pictures... MSN Messenger」文字。
下方作業系統工作列顯示「start」、「MSN Messenger」、「Jake Morales - Conversa...」，右下角時間為「9:43 PM」。</div></details>

兩個模型顯然都知道參考對象，也都做得不錯。4.6 只是更精緻，甚至細到分開的對話視窗與揮手動畫都有呈現。

我經常使用 Excalidraw，而它又是開放原始碼專案，因此很適合用來觀察模型處理實際程式碼庫的能力，而不是只面對一個空資料夾。我要求兩個模型加入簡報模式：儲存命名檢視、重新排序，並將它們以導覽式流程呈現。提示詞刻意沒有說明該如何實作。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/de8febacab0bf552.jpg)
> Grok 4.5 與 Grok 4.6 介面中的 Presentation 功能對比

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">左側：
Grok 4.5
畫布上有三個圓角矩形圖形。
左上角標有「Grok 4.5」。
下方提示：「Add a presentation view first」。

右側：
Grok 4.6
左上角標有「Grok 4.6」。
右側開啟 Presentation 面板：
- Presentation
- Save named-camera views and walk through them in sequence.
- [+ Save current view] 按鈕
- [▶ Start presentation] 按鈕
- 下方列出兩個已儲存的檢視區塊：
  - View 1（包含播放、重新命名、刪除等操作圖示）
  - View 2（包含播放、重新命名、刪除等操作圖示）
畫布右下角顯示：「Saved 'View 2'」。</div></details>

兩者最後大致落在相同的位置；提示詞這麼模糊，能有這樣的成果已經相當令人印象深刻！4.6 只是在第一次執行時更注意細節，實際上也就代表我不需要那麼多次指出問題。

這也是跳過驗證會造成問題的地方。早期的一次執行中，摘要看起來已經完成，但實際上新增檢視並沒有正常運作。只要做一輪「執行它並展示給我看」，就找出了錯誤的匯入。

## 日常工作

我不是每天都製作簡報和報告，但很多人確實會，因此我想看看它如何處理這類工作。我讓兩個模型使用相同的虛構季度資料，並要求它們製作一份董事會簡報。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/ec660e8dabb919bb.jpg)
> Grok 4.6 與 Grok 4.5 分別展現了董事會簡報中風險決策分析與年度財務預測的生成呈現能力。

<details class="chart-data"><summary>展開數據表（1）Grok 4.5</summary><table><thead><tr><th>項目</th><th>數值</th></tr></thead><tbody><tr><td>10 · Updated Full-Year FY2026 Forecast</td><td></td></tr><tr><td>Revenue: Prior guide=$112M, Updated FY2026E=$118M</td><td>Ending ARR: Prior guide $138M, Updated FY2026E=$142M · Op Income: Prior guide -$18M, Updated FY2026E=-$11M</td></tr><tr><td>Revenue ($M)</td><td>Prior guide 112.0 · Updated 118.0 · Δ +6.0</td></tr><tr><td>Ending ARR ($M)</td><td>Prior guide 138.0 · Updated 142.0 · Δ +4.0</td></tr><tr><td>Gross margin</td><td>Prior guide 74.5% · Updated 75.8% · Δ +1.3 pp</td></tr><tr><td>Op. income ($M)</td><td>Prior guide (18.0) · Updated (11.2) · Δ +6.8</td></tr><tr><td>Net income ($M)</td><td>Prior guide — · Updated (9.4) · Δ —</td></tr><tr><td>Revenue</td><td>Q1A 25.1 · Q2A 28.4 · Q3A 30.9 · Q4F 33.6 · FY2026E 118.0</td></tr><tr><td>Ending ARR</td><td>Q1A 108.2 · Q2A 118.6 · Q3A 128.4 · Q4F 142.0 · FY2026E 142.0</td></tr><tr><td>Op. income</td><td>Q1A (4.5) · Q2A (3.6) · Q3A (2.3) · Q4F (0.8) · FY2026E (11.2)</td></tr></tbody></table></details><details class="chart-data"><summary>展開數據表（2）Grok 4.6</summary><table><thead><tr><th>項目</th><th>數值</th></tr></thead><tbody><tr><td>NORTHSTAR CLOUD · Q3 FY2026 BOARD PACK,Risks, opportunities, and decisions,RISKS: Enterprise cycle risk, Usage concentration, Commercial GRR 82% / NRR 92%, AI platform execution, Competitive bundling, FX / EMEA 27%,OPPORTUNITIES: AI anomaly module, AWS Marketplace, List-price action, Public sector, Expansion capacity,DECISIONS: 1. Approve +$2.40M Q4 S&amp;M - VOTE, 2. Affirm no FY26 / H1 FY27 primary raise, 3. Commercial strategy for FY27 plan, 4. Authorize FY27 planning case</td><td></td></tr></tbody></table></details>

兩者都具備足夠能力，差距主要在呈現方式，而不是分析能力。4.5 大多只是把數字排在投影片上；4.6 則真正花力氣處理結構與層次，因此讀起來像某個人做出來的簡報，而不是資料傾倒。

## 以程式碼製作影片

Remotion 是以程式碼製作影片：每一個畫格都是 React 元件，根據目前的畫格編號進行渲染，整部影片則透過 headless Chromium 和 FFmpeg 編譯成 MP4。你的影片會存在 git 裡。這是一種真的很有趣的工作方式！但把這種工作交給模型也很奇怪，因為你無法只靠確認它能執行，就判斷它是否成功。

這個主題值得多花一點篇幅，因為我最近花了很多時間在這上面。我要求它製作一支 60 到 90 秒、介紹 X TypeScript SDK 的 launch film，並把文件提供給它參考。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/ae777b5795bc9274.jpg)
> Grok 4.5 至 Grok 4.6 的功能與程式碼範例展示

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">左側畫面（Grok 4.5）：
左上方標題：Grok 4.5
中央標題：From install to end-to-end in minutes.
下方四個步驟：
01
Install
@xdevplatform/sdk

02
Authenticate
Bearer - OAuth 1/2

03
Call the API
Typed Client methods

04
Ship
Paginate - stream - iterate

下方文字：
Install - authenticate - call - paginate or stream

右側畫面（Grok 4.6）：
左上方標題：Grok 4.6
上方小標：X xdk
區塊標題：STREAMING
程式碼區塊：
```javascript
const stream = await client.stream.postsSample({
  tweetFields: ['id', 'text', 'created_at'],
});

stream.on('data', (event) =&gt; {
  console.log(event);
});
```
下方資料標籤：
DATA { data, includes }
DATA { data, includes }
KEEPALIVE heartbeat
DATA { data }
DATA { data, includes }

下方文字：
1% sampled public posts - event-driven stream
- Connect to sampled posts. Listen for data, errors, and keep-alives.</div></details>

我評估這些影片時，會看它有沒有故事線，以及節奏是否穩定。大多數模型在這裡都會以相同方式失敗：使用全大寫標題、加上框線文字，然後所有內容一次同時出現在畫面上。兩支影片都避開了其中大部分問題，而 4.6 看起來更有吸引力。

我連續幾天讓不同模型處理這項工作後，發現影片是我看過差距最大的領域。在 Web 應用程式上感覺能力相當的兩個模型，在這裡可能根本不在同一個層級。

## 需要引導的地方

幾乎所有需要我介入引導的地方，最後都能回到同一件事：模型有多容易驗證自己的工作。

網站是比較簡單的案例。DOM 是文字，因此模型可以讀取頁面、擷取螢幕畫面，並與原本的預期進行比較。這就是為什麼驗證迴圈在 UI 工作上能運作得這麼好。

3D 比較困難，因為有一整個維度無法透過閱讀來檢查。影片更難，因為時間是額外的維度，而檢查工作代表要擷取一連串畫格，並推理它們之間的變化。物理也有相同形式的問題。模型很清楚世界應該如何運作，但要確認世界實際上是否真的那樣運作，並不是一張螢幕截圖能回答的。

實際上的解法，是提供一個讓模型觀察的方法，或者接受由你自己來檢查。

## 為什麼它是我的預設選擇

專精型模型確實有真正的價值，也就是那些在某一件特定事情上表現得非凡的模型。但我的大部分工作並不只集中在某一件事情上。日常工作中，我想要的是一個我熟悉的模型：我已經建立起對它行為的直覺，可靠到可以把工作交給它，也充分了解它的缺點，能夠不假思索地避開那些缺點。

對我來說，4.6 正好變成了這樣的模型。在程式開發方面，它能處理互動與視覺工作，讓我可以一邊看著它執行、一邊做出反應，也能在真正的程式碼庫中完成長時間的工作。在知識工作方面，它能處理收件匣、瀏覽器 QA，以及沒有 API 可用、只能透過點擊操作的任務。它不可能在其中任何一項工作上都是想像中最好的模型，但它每一項都做得不錯，而且我知道該期待什麼。

當輸出結果是以外觀作為評判標準時，我仍然會參與其中。動態效果、3D 與最後的精修，需要參考資料與螢幕截圖迴圈，而不是單純的文字描述。我也會把驗收條件寫下來，不會只相信一份聲稱「已完成」的摘要。

## 試試看

Grok 4.6 現在已經可以在 Cursor、SpaceXAI API、OpenRouter，以及任何你取得 token 的地方使用！

試用看看，並告訴我你的想法。不論是好是壞，都歡迎留下回饋，因為這正是我們判斷下一步該往哪裡改進的依據。

很期待聽聽你最後用它做出了什麼！

## 標籤

功能更新, 新產品, 教學資源, Grok, SpaceXAI
