用 Mistral Vibe CLI 做設計。

Mistral Vibe CLI 究竟是什麼

Mistral Vibe CLI 是 Mistral AI 為終端推出的開源（Apache-2.0）編碼代理。它提供一個互動式對話介面，配有檔案操作、程式碼搜尋、版本控制和命令執行等工具，並會自動掃描你專案的檔案結構和 Git 狀態，為代理提供相關上下文。它由 Mistral 的 Devstral 編碼模型驅動——根據自然語言任務進行規劃和驗證，而不只是補全程式碼行。

對設計工作而言，有兩個特性尤為突出。它執行在 Mistral 開放權重的 Devstral 家族上（Devstral 2 以及更小的 Devstral Small 2），因此你既可以讓代理對接雲端的 Mistral API，也可以對接本地模型——這對於注重隱私或離線的設計工作很有用。它還支援 Agent Client Protocol，因此同一個代理可以驅動編輯器和各類工具，而不只是一個終端會話。

• 配置檔案: Vibe CLI 通過 config.toml 檔案配置（專案級 ./.vibe/config.toml，並以 ~/.vibe/config.toml 作為回退）。這是個很實用的地方，可以把你的服務商、模型選擇和專案設定都寫進去。
• 內建工具 + MCP: 它自帶檔案、搜尋、版本控制和命令執行工具，並支援 MCP 伺服器（在 [[mcp_servers]] 區段下配置），以引入外部上下文，比如一個即時的 Figma 檔案。
• BYOK 或本地: 用 Mistral 控制台的 Mistral API 金鑰進行認證，或把它指向本地/相容模型，讓它完全離線工作。

• 廠商：Mistral AI
• 憑據：Mistral 控制台的 Mistral API 金鑰（BYOK），或本地/相容模型
• 許可證：Apache-2.0，開源

為什麼開放權重的編碼代理適合做設計

Vibe CLI 在設計上的優勢來自它開放權重的模型家族和廣泛的協議覆蓋——但與每一個代理一樣，審美仍然得由你來提供。

• Devstral 編碼模型: Vibe 執行在 Mistral 的 Devstral 家族上，這是為代理式、多檔案工作打造的編碼調優模型——因此代理是在一個真實的前端程式碼庫中跨檔案編輯，而不是產出孤立的程式碼片段。
• 開放權重且對本地友好: Devstral Small 2 足夠小，可以跑在消費級硬體上，因此設計工作可以完全保持在本地和離線狀態——參考素材和程式碼永遠不必離開你的機器。
• config.toml 中的約定 + 上下文: 專案配置和你自己的指令會把代理引向你的 tokens、元件和真實規範，於是它是面向一個品牌工作，而不是套用預設外觀。

這條教訓和每個代理給出的如出一轍：Vibe CLI 預設並不具備審美。當你給它約束時——一個設計系統、一個審美 skill 和具體的參考素材——它才能產出好的設計。Open Design 恰好把這些輸入打包好了，這也是兩者能契合的原因（下文詳述）。

從零配置 Vibe CLI 做設計工作

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

# 1. 安裝 Mistral Vibe CLI
uv tool install mistral-vibe
# 或：pip install mistral-vibe

# 2. 執行配置嚮導以註冊你的 API 金鑰
vibe --setup     # 將配置儲存到 ~/.vibe/config.toml 和 ~/.vibe/.env
#    或直接設定：  export MISTRAL_API_KEY=...

# 3. 在你的專案中啟動 Vibe
cd your-project
vibe

# 4. 接入 Figma MCP 伺服器（可選，用於設計交付）
#    在你的 config.toml 中新增一個 [[mcp_servers]] 條目

• 把你的設計規則寫進去: 把你的 tokens、基礎元素和規範約定放在代理能讀到的地方，並讓 Vibe 指向它們，這樣產出就會匹配一個品牌，而不是退回到千篇一律的外觀。
• 加上瀏覽器驗證: 接入一個 Playwright 或瀏覽器 MCP，讓 Vibe 在真實瀏覽器中渲染，並跨斷點檢查產出，而不只是確認構建通過。

從參考素材到 UI 的工作流

用 Vibe CLI 做設計時收益最高的閉環，是把一份清晰的參考素材變成可用的響應式 UI，並反覆迭代直到匹配為止——藉助代理自身的工具來渲染、檢查並修正它自己的產出。

1. 從你手頭最清晰的參考素材出發——並描述多種狀態（桌面和移動端、懸停、空態、載入中），而不只是一張主視覺。
2. 提示詞要具體；含糊的提示即便配上強大的模型也只會產出千篇一律的 UI。
3. 把你的設計系統和規範約定放在 Vibe 能讀到的地方，並告訴它 tokens 和標準基礎元素在哪裡。
4. 執行一個開發伺服器，讓 Vibe 在真實瀏覽器中渲染，並調整到各個斷點來檢查結果。
5. 通過讓 Vibe 把它的實現回頭對照參考素材來迭代——而不只是確認它能構建通過。

用 @ 引用檔案（Vibe 會自動補全檔案路徑），用 / 呼叫斜槓命令，然後給出具體的約束：

vibe
# 在提示詞裡：
> @design-spec.md @tokens.css
  Implement this design in React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens.
  Match spacing, layout, and hierarchy; make it responsive.
  Run the dev server, render it in the browser, and iterate until
  it matches the references across breakpoints.

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

config.toml、MCP 和 ACP

有三個擴充套件點讓 Vibe CLI 適合做持續性的設計工作，而且這三個都能幹淨地對應到一套開放的設計工作流上。

• config.toml: 專案規則以及服務商/模型設定都存放在 config.toml 中（專案級，並以 ~/.vibe 作為回退）。它是代理如何接入你專案的持久化歸宿，每次執行都會被讀取。
• MCP 伺服器: 在你的 config.toml 中配置 MCP 伺服器（[[mcp_servers]]，支援 HTTP、可流式 HTTP 和 stdio 傳輸）——這是引入設計上下文和外部工具的可移植方式，其中最相關的就是 Figma MCP 伺服器，並且這些在各類代理間通用，不只限於 Vibe。
• Agent Client Protocol: Vibe 支援 ACP，因此同一個代理可以從編輯器和其他 ACP 客戶端來驅動。Open Design 正是這樣整合它的——通過 vibe-acp 二進位制檔案經由 ACP 接入。

這些都是可移植、跨代理的能力——恰恰是 Open Design 旨在編排的那類東西，而不是在每個專案裡重新造一遍。

做設計時 Vibe CLI 對比 Codex、Claude Code、Cursor 和 Gemini CLI

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

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

陷阱，以及如何避開「AI 味」外觀

對 AI 生成設計最常見的抱怨，就是它看起來千篇一律——柔和的漸變、漂浮的面板、過大的圓角、誇張的陰影，以及那種「一看就是 AI 做的」的 Inter 字型加紫色調調。其他被反映的問題還包括移動端佈局錯亂，以及指令文字洩漏進 UI 文案。這些都不是 Vibe CLI 獨有的；只要任何代理在缺乏精選設計上下文的情況下執行，就會出現這些問題。

• 加上一個審美 skill: 一個精選的設計 skill 會迫使代理給出一個真正的方向，而不是套用預設外觀。
• 在真實瀏覽器中驗證: 讓 Vibe 跨斷點渲染並自查，這樣佈局就不會在移動端悄無聲息地崩掉。
• 提供 tokens 和參考素材: 真實的設計 tokens 和參考截圖，是對產出質量影響最大的單一槓桿。
• 把規則寫進配置和上下文: 把「不要主視覺卡片、最多兩種字型、品牌優先的層級」這類風格規則放在代理每次執行都能讀到的地方。

注意，每一項緩解措施都是在給代理一份精選的設計上下文。逐個專案手工維護這份上下文，正是 Open Design 替你省掉的苦工。

在 Open Design 中用 Vibe CLI 做設計

Open Design 正是上面這套工作流一直在呼喚的那個開源設計層。它把 Mistral Vibe CLI 當作一等介面卡——通過 vibe-acp 二進位制檔案經由 ACP 來驅動它——併為它配上精選的 skill 與設計系統庫、一條結構化的渲染管線，以及一個本地桌面 UI。於是，讓 Vibe 變好用的那份設計上下文從第一次執行起就已就位，而不必每次手工拼湊。兩者都是開源且本地優先的，這讓這對搭配水到渠成。

1. 安裝 Open Design 並選擇 Mistral Vibe CLI 作為你的代理。
2. 用你的 Mistral API 金鑰（BYOK）進行認證，或把 Vibe 指向本地模型——憑據留在你的機器上，絕不經我們代理轉發。
3. 挑選一個設計系統和一個 skill，然後以一致的審美生成演示稿、原型和落地頁。
4. 每一個產物和 DESIGN.md 檔案都存在你自己的倉庫裡，而不是某個託管雲端。

同一個 Vibe CLI 代理，同一把金鑰——外加一套圍繞它的真實、可移植、開源的設計工作流。它本地優先且採用 Apache-2.0，因此你的工作內容和憑據沒有任何一項會離開你的機器。

常見問題

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

   能——只要上下文裡有一個審美 skill、一個設計系統和真實的參考素材，Vibe CLI 就能產出生產級的響應式 UI，而它的 Devstral 模型會在一個真實的前端程式碼庫中跨檔案編輯。缺了這份上下文，它往往會退回到千篇一律的外觀，而這正是 Open Design 要補上的缺口。

2. 02 我該如何認證 Vibe CLI？ +

   執行 vibe --setup 啟動配置嚮導來註冊一個 Mistral API 金鑰（來自 Mistral 控制台），或在你的環境中設定 MISTRAL_API_KEY。它也可以對接本地或相容模型，完全離線執行。無論哪種方式，Open Design 都絕不會代理轉發你的憑據。

3. 03 Vibe CLI 具體好在哪裡、為什麼適合做設計？ +

   它是一個 Apache-2.0、原生支援 ACP 的代理，由 Mistral 開放權重的 Devstral 編碼模型驅動——因此你可以在本地執行它來處理注重隱私的工作，並在一個真實的程式碼庫中跨檔案編輯。但審美仍然來自你提供的設計系統、skill 和參考素材。

4. 04 做前端設計，選 Vibe CLI 還是 Claude Code？ +

   兩者都很強。Claude Code 以具體的、理解程式碼庫的設計決策著稱；Vibe CLI 的優勢在於可在本地執行的開放權重 Devstral 技術棧以及 Apache-2.0 許可證。很多團隊兩者都用——Open Design 讓你可以切換代理而無需改變你的設計工作流。

5. 05 我該如何把 Vibe CLI 連線到 Figma？ +

   在你的 config.toml 中以 [[mcp_servers]] 條目的形式新增 Figma MCP 伺服器。Vibe 隨後就能拉取真實的設計上下文——元件、變數、佈局資料——從而讓生成的程式碼匹配原始檔，而不是近似地湊出來。

6. 06 Open Design 與 Mistral AI 有關聯嗎？ +

   沒有。Mistral Vibe CLI 是 Mistral AI 的產品；Open Design 是一個獨立的開源專案，以一等介面卡的形式支援它，並通過 ACP 來驅動。Mistral 是 Mistral AI 的商標。

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

   安全——Open Design 本地優先且採用 Apache-2.0。你的檔案、產物和 DESIGN.md 都留在你自己的倉庫裡，你的 Mistral 憑據由你的代理直接使用，絕不經由 Open Design 的伺服器轉發。