用於設計的 Gemini CLI。

Gemini CLI 究竟是什麼

Gemini CLI 是 Google 為終端機推出的開源（Apache-2.0）AI 代理。它能讀取你的儲存庫、編輯檔案、執行 shell 指令、抓取網頁，並能以 Google 搜尋為答案提供佐證——它從自然語言任務出發來規劃並驗證工作，而不只是補全程式碼行。同一套引擎也驅動著 VS Code 內的 Gemini Code Assist 代理。

對設計工作而言，有兩項特性格外突出。它的模型原生支援多模態，因此你可以遞給它一張螢幕截圖，它便能就實際版面進行推理。而它的上下文視窗最高可達 1M token，大到足以一次容納你的整套設計系統、元件庫與參考集，而不必把它們摘要省略掉。

• 上下文檔案: Gemini CLI 會讀取一個 GEMINI.md 檔案來取得持久的專案上下文——這正是用來編入設計慣例、tokens 與審查檢查清單的天然之處。個人與團隊設定則疊加於其上。
• 內建工具 + MCP: 它開箱即附帶檔案、shell、web-fetch 與 Google 搜尋工具，並支援 MCP 伺服器（在 ~/.gemini/settings.json 中設定），以加入像即時 Figma 檔案這類的外部上下文。
• 免費上手: 以個人 Google 帳號登入即可獲得相當慷慨的 Gemini 請求免費額度；你也可以自備 Gemini API key 或使用 Vertex AI。

• 供應商：Google
• 憑證：Google 帳號（免費額度），或來自 AI Studio 的 Gemini API key（BYOK），或 Vertex AI
• 授權：Apache-2.0，開源

為何多模態模型與龐大上下文契合設計

Gemini CLI 的設計優勢來自兩項模型特性——但一如每個代理，品味仍得由你來供給。

• 強大的多模態理解: 因為 Gemini 模型原生支援多模態，代理能很好地讀懂參考螢幕截圖——把它渲染的成果與圖像對照比較，而不是從一段文字描述去揣測。
• 1M token 的上下文視窗: 龐大的上下文意味著整套設計系統、tokens 與眾多參考狀態能一次塞進去，於是代理會重用你真正的基本元素，而不是憑空發明一次性的樣式。
• GEMINI.md 中的慣例: 一份 GEMINI.md（再加上 Figma MCP 伺服器）會把代理導向你的 tokens、元件與真實規格，讓它針對一個品牌工作，而不是套用預設外觀。

這個道理和每個代理教給我們的一樣：Gemini CLI 預設並不具備品味。當你給它約束時，它才能產出優秀的設計——一套設計系統、一個美學 skill，以及具體的參考。Open Design 正是把這些輸入打包起來，這也是兩者契合的原因（下文詳述）。

從零開始為設計工作設定 Gemini CLI

以下是從一台乾淨的機器，到一個能建構並驗證 UI 的 Gemini CLI，完整的設定路徑。

# 1. Install Gemini CLI (Node 20+)
npm install -g @google/gemini-cli
# or run without installing: npx https://github.com/google-gemini/gemini-cli

# 2. Start it in your project and authenticate on first run
cd your-project
gemini            # sign in with your Google account, or set GEMINI_API_KEY

# 3. Generate project context
/init             # scaffolds a GEMINI.md for this project

# 4. Wire the Figma MCP server (optional, for design handoff)
#    add it under "mcpServers" in ~/.gemini/settings.json

• 編入你的設計規則: 把你的 tokens、基本元素與慣例放進 GEMINI.md，並讓 Gemini 指向它們，使產出符合一個品牌，而不是退回到千篇一律的外觀。
• 加入瀏覽器驗證: 接上一個 Playwright 或瀏覽器 MCP，讓 Gemini 在真實瀏覽器中渲染，並跨各種斷點檢查其產出，而不只是確認建構通過。

螢幕截圖轉 UI 的工作流

Gemini CLI 槓桿效益最高的設計迴圈，是把一張參考圖轉成可運作的響應式 UI，並反覆迭代直到吻合——借助多模態模型把產出與參考對照比較。

1. 從你手上最清晰的視覺參考出發——並納入多種狀態（桌面與行動裝置、hover、空狀態、載入中），而不只是一張主視覺。
2. 在提示中要具體；即使有強大的模型，含糊的提示仍會產出千篇一律的 UI。
3. 把你的設計系統與慣例保存在 GEMINI.md 中，並告訴 Gemini tokens 與權威基本元素位於何處。
4. 啟動一個 dev server，讓 Gemini 在真實瀏覽器中渲染，並調整尺寸至各斷點來檢查結果。
5. 讓 Gemini 把它的實作與螢幕截圖對照比較來迭代——而不只是確認它能建構成功。

用 @ 引用一張圖把它附加到提示中，接著給出具體的約束：

gemini
# in the prompt:
> @reference-desktop.png @reference-mobile.png
  Implement this design in React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens from GEMINI.md.
  Match spacing, layout, and hierarchy; make it responsive.
  Render it in the browser and iterate until it matches the references
  across breakpoints.

讓提示保持小而聚焦，提交好的迭代並還原壞的迭代（還原時告知 Gemini），如此每一輪都建立在乾淨的基礎之上。

GEMINI.md、MCP 與擴充功能

三個擴充點讓 Gemini CLI 足以勝任持續性的設計工作，而這三者都能乾淨俐落地對應到一套開放的設計工作流。

• GEMINI.md 上下文: 專案規則存放於儲存庫根目錄的 GEMINI.md 中（並有全域與團隊層級）。它是你設計慣例的長久歸宿，每次執行都會被讀取。
• MCP 伺服器: 在 ~/.gemini/settings.json 下設定 MCP 伺服器——這是引入設計上下文與外部工具的可攜方式，其中最切題的便是 Figma MCP 伺服器，且這些能力可跨代理通用，不限於 Gemini。
• 擴充功能與內建工具: Gemini CLI 的擴充功能，以及它內建的 Google 搜尋、檔案、shell 與 web-fetch 工具，讓它無需離開終端機就能蒐集參考並執行驗證迴圈。

這些都是可攜、跨代理的能力——正是 Open Design 生來要去編排的那類東西，而非在每個專案中重新打造。

用於設計時的 Gemini CLI vs Codex vs Claude Code vs Cursor

設計工作沒有唯一的贏家——每個代理各有不同的強項，而資深團隊會把它們疊起來用。一份公允的總結：

社群反覆得出的結論是：品味來自人類——少了 skills、參考與約束，它們全都會退回千篇一律的美學。那才是真正要解決的問題——而它的形狀屬於設計工具，而非模型。

陷阱，以及如何避開「AI 廉價感」的外觀

對 AI 生成設計最常見的抱怨，就是它看起來千篇一律——柔和的漸層、漂浮的面板、過大的圓角、戲劇化的陰影，那種 Inter 字型加紫色的調調，「一看就知道是 AI 做的」。其他被回報的問題還包括行動裝置版面破版，以及指示文字外洩到 UI 文案裡。這些都不是 Gemini CLI 獨有的；它們是任何代理在缺乏精選設計上下文下執行時必然發生的結果。

• 加入一個美學 skill: 一個精選的設計 skill 會迫使代理選定一個真實的方向，而不是套用預設外觀。
• 在真實瀏覽器中驗證: 運用多模態模型跨各斷點渲染並自我檢查，讓版面不會在行動裝置上悄悄破版。
• 提供 tokens 與參考: 真實的設計 tokens 與參考螢幕截圖，是對產出品質影響最大的單一槓桿。
• 把規則編入 GEMINI.md: 把「不要主視覺卡片、最多兩種字型、品牌優先的層級」這類風格規則，放在代理每次執行都會讀到的地方。

請留意，每一項對策都在於給代理一套精選的設計上下文。逐專案手工維護那份上下文，正是 Open Design 替你免去的苦工。

在 Open Design 中以 Gemini CLI 設計

Open Design 正是上述工作流一再呼喚的那個開源設計層。它把 Gemini CLI 當作一級的轉接器，並以一套精選的 skill 與設計系統函式庫、一條結構化的渲染管線，以及一個本機桌面 UI 將它包裹起來——於是讓 Gemini 變強的那份設計上下文，從第一次執行起就已就位，無需每次手工拼湊。兩者皆為開源且 local-first，這讓這場搭配渾然天成。

1. 安裝 Open Design 並選擇 Gemini CLI 作為你的代理。
2. 以你的 Google 帳號或 Gemini API key（BYOK）驗證——憑證留在你的機器上，絕不經由我們代理轉送。
3. 挑一套設計系統與一個 skill，接著以一致的品味產出簡報、原型與著陸頁。
4. 每一份產物與 DESIGN.md 檔案都存在你自己的儲存庫裡，而非託管的雲端。

同一個 Gemini CLI 代理、同一把 key——外加一套真正可攜、開源的設計工作流環繞其上。它是 local-first 且 Apache-2.0 的，因此關於你的工作或你的憑證，沒有任何東西會離開你的機器。

常見問題

1. 01 Gemini CLI 真的能做設計工作嗎？ +

   可以——只要上下文中有一個美學 skill、一套設計系統與真實的參考圖，Gemini CLI 就能產出可上線品質的響應式 UI，而它強大的多模態模型會對照參考來驗證產出。缺了那份上下文，它往往會退回千篇一律的外觀，這正是 Open Design 補上的落差。

2. 02 用 Gemini CLI 做設計需要付費嗎？ +

   不需要——以 Google 帳號登入即可獲得相當慷慨的免費額度，你也可以自備 Gemini API key（BYOK）或使用 Vertex AI。無論哪種方式，Open Design 都不會代理轉送你的憑證。

3. 03 Gemini CLI 在設計上具體好在哪？ +

   兩點：它的模型具備強大的多模態能力，因此能很好地讀懂參考螢幕截圖；而它 1M token 的上下文能一次容納整套設計系統與參考集。兩者都有幫助——但品味仍然來自你供給的設計系統、skill 與參考。

4. 04 前端設計該用 Gemini CLI 還是 Claude Code？ +

   兩者都很強。Claude Code 以具體、理解程式碼庫的設計決策著稱；Gemini CLI 的優勢則在於多模態理解，外加龐大的上下文與免費額度。許多團隊兩者並用——Open Design 讓你切換代理而無需改動你的設計工作流。

5. 05 我要如何把 Gemini CLI 連到 Figma？ +

   在 ~/.gemini/settings.json 的 mcpServers 下加入 Figma MCP 伺服器。Gemini 接著便能拉取真實的設計上下文——元件、變數、版面資料——讓生成的程式碼吻合來源，而非近似地揣摩。

6. 06 Open Design 與 Google 有從屬關係嗎？ +

   沒有。Gemini CLI 是 Google 的產品；Open Design 是一個獨立的開源專案，以一級轉接器的形式支援它。Gemini 是 Google 的商標。

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

   安全——Open Design 是 local-first 且 Apache-2.0 的。你的檔案、產物與 DESIGN.md 都留在你自己的儲存庫裡，而你的 Google 憑證由你的代理直接使用，絕不經由 Open Design 的伺服器轉送。