用於設計的 Grok Build。

Grok Build 究竟是什麼

Grok Build 是 xAI 的終端編碼 agent，以 Grok Build 之名釋出。它讀取你的倉庫、編輯檔案、執行 shell 命令，並依據自然語言任務規劃多步工程工作，而不只是補全程式碼行。它圍繞 xAI 的 Grok 模型構建——在 xAI API 上以 grok-build 模型家族的形式暴露——並通過你的 xAI 賬戶進行身份驗證，因此 agent 和模型都出自同一家廠商。

對設計工作來說，有兩個特性尤為突出。它有一個計劃模式，會先草擬一份結構化方案，供你在任何改動落地之前批准、評論或重寫——當你在迭代 UI 時，這是個很有用的關卡。而它的 Grok 模型支援影像輸入，所以你可以把一張參考截圖交給它，它會對實際佈局進行推理，而不是從一段文字描述裡瞎猜。

• 上下文檔案: Grok Build 會讀取 AGENTS.md 檔案來獲取持久的專案上下文——這正是用來編碼你的設計規範、tokens 和審查清單的自然位置。它遵循 Codex 和其他 agent 同樣使用的開放 AGENTS.md 約定。
• 工具、MCP + 子 agent: 它能編輯檔案、執行 shell 命令，並支援 MCP 伺服器來引入外部上下文，比如一個即時的 Figma 檔案；對於較大的任務，它可以委派給並行的子 agent，讓它們同時進行調研、構建和審查。
• 用你的賬戶登入: 你通過瀏覽器以 SuperGrok 或 X Premium+ 訂閱登入來完成身份驗證；你也可以帶上自己的 xAI API key 用於無頭執行和 CI 場景。

• 廠商：xAI
• 憑證：xAI SuperGrok OAuth（`grok login`），或用於無頭場景的 xAI API key（BYOK）
• 模型：xAI Grok 模型（xAI API 上的 grok-build 家族），支援影像輸入

為什麼計劃模式和能識別影像的模型契合設計

Grok Build 的設計優勢來自兩個特性——但和所有 agent 一樣，品味仍然得由你來提供。

• 能識別影像的推理: 因為 Grok 模型支援影像輸入，agent 能讀取參考截圖——把自己渲染出的產出與影像對照，而不是從一段文字描述裡瞎猜。
• 改動落地前的計劃模式: 計劃模式會草擬一份結構化方案，供你在檔案改動前批准，於是設計意圖在一開始就被審查，而不是等差異出來之後才發現。
• 寫在 AGENTS.md 裡的規範: 一份 AGENTS.md（再加上 Figma MCP 伺服器）會把 agent 指向你的 tokens、元件和真實規格，讓它針對一個品牌來工作，而不是套用預設觀感。

這條教訓和每個 agent 教給我們的一樣：Grok Build 預設並不具備品味。當你給它約束時——一個設計系統、一個審美 skill 和具體的參考——它才會產出好的設計。Open Design 恰恰把這些輸入打包好了，這正是兩者契合的原因（下文詳述）。

從零開始搭建用於設計工作的 Grok Build

下面是從一臺乾淨的機器到一個能構建並驗證 UI 的 Grok Build 的完整路徑。

# 1. 在 macOS/Linux 上安裝 Grok Build（Grok Build）
curl -fsSL https://x.ai/cli/install.sh | bash

# 2. 在你的專案裡啟動它，並在首次執行時進行身份驗證
cd your-project
grok login   # 開啟瀏覽器；用 SuperGrok / X Premium+ 登入
#   或者，對於無頭 / CI 場景，設定 xAI API key：
#   export XAI_API_KEY=xai-...

# 3. 新增專案上下文
#    在倉庫根目錄建立一個 AGENTS.md，寫入你的設計規範

# 4. 接入 Figma MCP 伺服器（可選，用於設計交付）
#    把它加到你的 MCP 伺服器配置裡

• 編碼你的設計規則: 把你的 tokens、基礎元素和規範寫進 AGENTS.md 並讓 Grok 指向它們，這樣產出就會貼合一個品牌，而不是退回到千篇一律的預設觀感。
• 加入瀏覽器驗證: 接入 Playwright 或瀏覽器 MCP，讓 Grok 在真實瀏覽器中渲染，並跨斷點檢查它的產出，而不僅僅是確認構建通過。

截圖到 UI 的工作流

用 Grok Build 時槓桿最高的設計迴圈，就是把一張參考圖變成可用的響應式 UI 並不斷迭代直到吻合——靠計劃模式就方案達成一致，靠能識別影像的模型把產出與參考對照。

1. 從你手頭最清晰的視覺參考出發——幷包含多種狀態（桌面端和移動端、hover、空態、載入態），而不只是一張主視覺。
2. 在提示裡寫具體；含糊的提示即使配上強模型也只會產出千篇一律的 UI。
3. 把你的設計系統和規範放進 AGENTS.md，並告訴 Grok tokens 和規範基礎元素在哪裡。
4. 用計劃模式審查方案，然後啟動一個 dev server，讓 Grok 在真實瀏覽器中渲染，調整到各個斷點來檢查結果。
5. 通過讓 Grok 把自己的實現與截圖對照來迭代——而不僅僅是確認它能構建。

附上你的參考圖，並給出具體約束：

grok
# 在提示裡（附上 reference-desktop.png 和 reference-mobile.png）：
> 用 React + Vite + Tailwind + TypeScript 實現這個設計。
  複用我已有的設計系統元件和 AGENTS.md 裡的 tokens。
  匹配間距、佈局和層級；做成響應式。
  先把方案給我看，然後在瀏覽器裡渲染並迭代，
  直到它在各個斷點上都與參考吻合。

讓提示保持小而聚焦，提交好的迭代、回退差的迭代（回退時告訴 Grok），這樣每一輪都能在一個乾淨的基礎上推進。

AGENTS.md、MCP 與子 agent

三個擴充套件點讓 Grok Build 適合持續的設計工作，而這三者都能幹淨地對映到一個開放的設計工作流上。

• AGENTS.md 上下文: 專案規則寫在倉庫根目錄的 AGENTS.md 裡。它是你設計規範的持久歸宿，每次執行都會被讀取——而且它是其他 agent 也能理解的同一種開放格式，所以這些規則會隨你一起遷移。
• MCP 伺服器: 配置 MCP 伺服器來引入設計上下文和外部工具，其中最相關的是 Figma MCP 伺服器——它是把真實規格喂進程式碼的可移植方式，跨 agent 通用，不只限於 Grok。
• 子 agent 與內建工具: Grok Build 能派生出並行的子 agent 來同時進行調研、構建和審查，而它的檔案、shell 和搜尋工具讓它無需離開終端就能收集參考並跑完驗證迴圈。

這些都是可移植的多 agent 能力——正是 Open Design 旨在編排、而非在每個專案裡重造的那類東西。

做設計時 Grok Build vs Codex vs Claude Code vs Cursor vs Gemini CLI

設計工作沒有唯一贏家——每個 agent 各有所長，經驗豐富的團隊會把它們疊著用。一個公允的總結：

社群反覆得出的結論是：品味來自人類——沒有 skill、參考和約束，它們全都會退回到千篇一律的審美。這才是真正要解決的問題——而它是設計工具形態的，不是模型形態的。

陷阱，以及如何避開“AI 味”觀感

對 AI 生成設計最常見的抱怨是它看起來千篇一律——柔和的漸變、懸浮的面板、過大的圓角、誇張的陰影，一股 Inter 字型加紫色的味道，“一看就是 AI 做的”。其他被反映的問題還包括移動端佈局崩壞，以及指令文字洩漏進 UI 文案。這些都不是 Grok Build 獨有的；任何 agent 在沒有精選設計上下文的情況下執行都會這樣。

• 加入一個審美 skill: 一個精選的設計 skill 會迫使 agent 承諾一個真實的方向，而不是套用預設觀感。
• 在真實瀏覽器中驗證: 跨斷點渲染並自檢，讓佈局不會在移動端悄無聲息地崩壞。
• 提供 tokens 和參考: 真實的設計 tokens 和參考截圖是對產出質量影響最大的那個槓桿。
• 把規則編碼進 AGENTS.md: 把“不要主視覺卡片、最多兩種字型、品牌優先的層級”這類規則放到 agent 每次執行都會讀取的地方。

注意，每一種緩解辦法都是在給 agent 一份精選的設計上下文。手工地、按專案維護這份上下文，正是 Open Design 替你免去的苦差事。

在 Open Design 中用 Grok Build 做設計

Open Design 正是上面那套工作流一直在呼喚的開源設計層。它把 Grok Build 當作一等介面卡，並在外圍包上一套精選的 skill 與設計系統庫、一條結構化的渲染管線，以及一個本地桌面 UI——於是讓 Grok 表現出色的那份設計上下文從第一次執行起就已就位，而不必每次都手工拼湊。Open Design 是獨立的、採用 Apache-2.0 協議，並執行在你自己的機器上，這讓二者天然契合。

1. 安裝 Open Design 並選擇 Grok Build 作為你的 agent。
2. 用你的 SuperGrok 賬戶或 xAI API key（BYOK）進行身份驗證——憑證留在你的機器上，從不經我們中轉。
3. 挑一個設計系統和一個 skill，然後以一致的品味生成演示稿、原型和落地頁。
4. 每一份產物和 DESIGN.md 檔案都存在你自己的倉庫裡，而不是託管雲端。

同一個 Grok Build agent、同一套憑證——外加在外圍包裹的一套真實、可移植、開源的設計工作流。它本地優先、採用 Apache-2.0，所以你的工作和憑證全都不會離開你的機器。

常見問題

1. 01 Grok Build 真的能做設計工作嗎？ +

   能——只要上下文裡有一個審美 skill、一個設計系統和真實的參考圖，Grok Build 就能產出生產級、響應式的 UI，而它能識別影像的 Grok 模型還能幫你把產出與參考對照驗證。沒有這份上下文，它往往會退回到千篇一律的觀感，而這正是 Open Design 要填補的缺口。

2. 02 我該如何對 Grok Build 進行身份驗證？ +

   你通過瀏覽器以 SuperGrok 或 X Premium+ 訂閱登入（`grok login`），所以無需管理 API key。對於無頭或 CI 場景，你可以改用 xAI API key。無論哪種方式，Open Design 都不會中轉你的憑證。

3. 03 Grok Build 具體好在哪裡、適合設計？ +

   兩點：它的計劃模式讓你在任何改動落地前審查方案，而它的 Grok 模型支援影像輸入，所以它能很好地讀取參考截圖。兩者都有幫助——但品味仍然來自你提供的設計系統、skill 和參考。

4. 04 前端設計該選 Grok Build 還是 Claude Code？ +

   兩者都很強。Claude Code 以具體的、理解程式碼庫的設計決策著稱；Grok Build 的優勢在於計劃模式審查和能識別影像的 xAI 模型。很多團隊兩者都用——Open Design 讓你在不改變設計工作流的前提下切換 agent。

5. 05 我該如何把 Grok Build 連線到 Figma？ +

   把 Figma MCP 伺服器加到你的 MCP 配置裡。這樣 Grok 就能拉取真實的設計上下文——元件、變數、佈局資料——於是生成的程式碼會匹配原始檔，而不是近似模仿。

6. 06 Open Design 隸屬於 xAI 嗎？ +

   不是。Grok Build 是 xAI 的產品；Open Design 是一個獨立的開源專案，以一等介面卡的方式支援它。Grok 是 xAI 的商標。

7. 07 我的檔案和憑證安全嗎？ +

   安全——Open Design 本地優先且採用 Apache-2.0。你的檔案、產物和 DESIGN.md 都留在你自己的倉庫裡，而你的 xAI 憑證由你的 agent 直接使用，絕不會經過 Open Design 的伺服器路由。