設計師的 Vibe Coding 入門：用 Figma Make 把設計稿變成真實 App

Figma 發布 Figma Make 之後，一個問題開始在設計師社群頻繁出現：我還需要等工程師嗎？這個問題背後，是一場關於設計師角色的集體焦慮與期待。這篇文章不打算告訴你 vibe coding 如何改變世界，而是要幫你搞清楚一件很實際的事：你在哪些情況下該自己動手，在哪些情況下不該。我會從 4 個真實情境出發，搭配工具選型框架和 prompt 策略，讓你看完之後知道第一步從哪裡踏出。

TL;DR

• Figma Make 最適合：利害關係人 demo、互動原型、design system 驗證，不適合 dev-handoff
• 4 個情境決策框架：幫你判斷「交付工程師 vs 自己 vibe code」
• 設計師工具選型：Figma Make 起手 → Lovable 做 MVP → Bolt 快速驗證 → v0 前端元件
• 風險揭露：版權責任在你、複雜度增加後品質會下降、vibe code 的 app 未經工程師審查不要上 production

先搞清楚：Figma Make 能做什麼，不能做什麼

Figma Make 在 2025 年 5 月 7 日的 Config 2025 大會以 open beta 形式推出，目前向付費方案 Full seat 用戶開放。它的核心功能是：接受自然語言 prompt 或現有 Figma frame 輸入，輸出一個可運行的 React app。對設計師來說，最吸引人的地方是它能讀取你的 Figma Design Library，自動套用既有的品牌設定——字型、色彩 token、元件，都不需要重新描述。

但是，Figma Make 輸出的 code 能不能直接交給工程師接手？答案是：不行，而且差很多。

UX Collective 的實測報告指出，Figma Make 生成的程式碼結構混亂，極度依賴無意義的 <div> 標籤，缺乏語意化 HTML（如 <header>、<nav>）。這會嚴重損害無障礙設計和 SEO 表現。METR 2025 年 7 月的研究甚至發現，有 AI 輔助時，資深開發者完成任務反而多花 19% 的時間，大部分用於 prompting、等待 AI 輸出，以及 review 生成的 code。Figma 官方也明確說明，Figma Make 的定位是快速原型，不是 production-ready 的開發工具，且不適合在既有 codebase 上迭代。

Figma Make 真正適合的 3 個場景：

1. 利害關係人 demo（把靜態設計稿變成可點擊的原型）
2. 設計決策快速驗證（看 token 套在真實 UI 上的效果）
3. 使用者測試（讓受測者真的點擊而非假裝）

定價：需要 Figma 付費方案的 Full seat 才能完整使用 Figma Make。Figma Professional 方案年繳為 $12/editor/月，月繳為 $15/editor/月。Figma Make 目前包含在 Full seat 中，無需額外付費。

4 個情境決策框架：設計師什麼時候該 vibe code？

在決定要不要 vibe code 之前，先問自己：「這個輸出的目的是什麼？」

情境	建議	適合工具	原因
利害關係人 demo	自己 vibe code	Figma Make、Lovable	快速產出可互動原型，取代傳統靜態簡報，加速回饋循環
設計系統 token 驗證	自己 vibe code	Figma Make、Anima	確認色彩、間距 token 在真實 UI 的呈現效果，比截圖更有說服力
內部工具 MVP	視複雜度決定	Lovable、Bolt	如果需要資料庫和後端，Lovable 可以零程式碼完成；如果只是前端表單，Bolt 夠用
產品功能迭代	交給工程師	Cursor（由工程師操作）	需要維護 codebase 品質、考慮邊緣情況和技術債，純視覺工具的輸出會增加後續維護成本

核心判斷標準：如果這個輸出不需要進入 production 環境，或者可以在演示結束後丟掉，那就值得自己 vibe code。如果你預期工程師之後要接手，那麼讓工程師從一開始就參與，通常比清理 AI 生成的 code 更有效率。

工具選型指南：Figma Make vs Lovable vs Bolt vs v0 vs Cursor

在選工具之前，先回答 3 個問題：

1. 我需要後端功能嗎？（資料庫、用戶登入、API 串接）
2. 輸出物要給誰看？（自己測試 / 利害關係人 / 用戶 / 工程師）
3. 我願意花多少時間在工具學習曲線上？

根據這三個問題，這是我建議的設計師工具地圖：

Figma Make — 設計師最自然的起點

直接內建於 Figma 生態系，無需切換思維模式。你已經有設計稿，Make 幫你把它跑起來。最適合早期概念探索和快速原型（Muzli 的 2026 三層架構中的 Layer 1：探索層）。限制是 code 品質偏低，不適合 dev-handoff。

Lovable — 最適合做完整 MVP

如果你的目標是「發布一個真實可用的 app」，Lovable 是目前對非工程師最友善的全端工具。它內建資料庫、用戶認證和後端，用白話文 prompt 就能完成大部分功能。起價 $25/月。設計系統需要手動描述（不像 Figma Make 可以自動讀取 Library）。

Bolt — 最快的 browser-native 原型

不需要安裝任何東西，直接在瀏覽器裡把 prompt 轉成預覽畫面。追求「5 分鐘內看到結果」的驗證節奏，Bolt 最順手。但處理完整後端和複雜邏輯有上限，$20-30/月。

v0（Vercel）— 前端元件的最佳工具

如果你的目標是生成高品質的 React + Tailwind 介面元件（dashboard、landing page、UI kit），v0 的輸出品質在現有工具中算高的。但它不是完整的 app 建置工具，沒有 backend / DB 生成能力，適合已熟悉 React 生態的設計師。

Cursor — 不建議設計師從這裡開始

Cursor 本質是工程師的 AI 輔助 IDE，不是無程式碼工具。使用它需要真實的程式知識：理解檔案結構、語言語法，以及判斷 AI 生成 code 是否正確的能力。如果你是零程式基礎的設計師，Cursor 的學習曲線會讓你在一週內放棄。先從 Figma Make 或 Lovable 建立信心，再評估要不要往 Cursor 走。

三層工作流架構（依據 Muzli 2026 研究整理）：

• Layer 1 探索：Figma Make、Bolt
• Layer 2 MVP：Lovable、v0
• Layer 3 工程化：Cursor（需工程師配合）

實戰：用 Figma Make 把設計稿變成可點擊的 App

這是我根據 Figma 官方文件整理的基本操作流程：

Step 1：準備你的 Figma frame

在進入 Figma Make 之前，先確認你的設計稿已綁定 Design Library。Figma Make 可以讀取你的 Style（色彩、字型）和 Component library，讓輸出的 UI 自動套用品牌設定。如果你的設計稿是孤立的 frame，沒有連結 Library，Make 就會自己推測你想要的視覺風格，結果通常不如預期。

Step 2：啟動 Figma Make，寫第一個 prompt

在 Figma 草稿區右上角點擊「Make」，建立新的 Figma Make 檔案。接著點擊聊天框的「+」選擇「Import from Figma」，或直接將你的設計 frames 複製貼上到 AI 對話框（目前支援貼上最多 3 個 frames）。

第一個 prompt 的建議寫法：

• 描述這個 app 的用途和目標用戶
• 說明你希望哪些元素保持和設計稿一致
• 指定互動行為（例如：點擊按鈕後跳到哪個頁面）

範例：「這是一個給 PM 用的週報追蹤工具。請依照貼上的設計框架建立首頁，保持現有的色彩和字型系統，左側是導覽列，右側是任務清單，點擊任務項目可以展開詳情。」

Step 3：迭代修改

Figma Make 支援兩種修改方式。一是繼續在對話框輸入指令（「把標題字體加大一級」「把卡片陰影改深一點」）；二是使用 Edit tool，直接點選預覽畫面中的特定元素進行修改，這對視覺調整來說更直覺。

Step 4：Publish 或 GitHub push

滿意後，可以直接 Publish 到公開 URL，生成一個可分享的連結供利害關係人測試，或 embed 到 Notion、簡報中。如果需要進一步開發，可以 Push 到 GitHub（需要有 GitHub 帳號）。

設計師的 Prompt 策略：從視覺語言切換到 AI 語言

這是設計師在 vibe coding 初期最常遇到的障礙：設計師習慣用視覺溝通，但 AI 需要文字指令。兩種語言之間有明顯的認知落差。

根據 Anima 的設計系統整合研究，以下 3 個原則可以大幅提升 prompt 品質：

原則 1：用元件名稱，不用視覺描述

不好的 prompt	好的 prompt
做一個藍色的按鈕	使用 Button/Primary，不要創建新的按鈕變體
字要大一點	標題使用 Heading/H2（24px，SemiBold）
加一點空間	使用 spacing-4（16px）的 padding

原則 2：先描述整體氛圍（Vibe），再疊加互動複雜度

不要一次把所有需求塞進一個 prompt。先讓 AI 建立整體基調，再逐步加入互動行為。

好的順序：「設計一個讓人感到平靜的記帳儀表板，柔和色調、圓角卡片、淺灰背景」→ 滿意後再說：「為每個分類卡片加上點擊展開的動畫，展開後顯示該月明細」

原則 3：說明使用情境，不只說外觀

「這是給老年人使用的 app，字體要足夠大，按鈕要容易點擊，避免太小的互動元素」比「字要大、按鈕要大」給 AI 更多判斷依據。

常見 prompt 錯誤：

• 「做一個現代感的 dashboard」→ AI 會自己發揮，結果往往不符合你的品牌
• 「讓它更好看」→ AI 不知道你的「好看」標準是什麼
• 一次要求 10 個修改 → AI 可能只做部分，或顧此失彼

3 件你發布前必須知道的風險

我認為這段是這篇文章最重要的部分，因為大部分設計師 vibe coding 教學都略過了它。

風險 1：版權責任完全在你，不在 Figma

Figma Make 官方文件明確說明：「用戶自行負責確保內容版權」。AI 在生成原型時，可能引入來自網路的第三方字型、套件或圖片，而你作為發布者必須自行確認這些內容是否有合法授權。在你按下 Publish 之前，確認一下你的 app 中有沒有你不確定來源的視覺元素。

風險 2：複雜度越高，品質下降越明顯

vibe coding 工具目前有一個普遍的限制：隨著功能複雜度上升，AI 的 code 一致性會逐漸退化。當你的 app 開始有多個頁面、多種狀態、複雜的資料邏輯，AI 開始「忘記」之前的設計決策，新增的元素和舊元素開始不一致。

這不是某個工具的問題，而是目前所有 AI 代碼生成工具的共同限制。實務建議：把 vibe code 限制在範疇較小的功能（一個頁面、一個功能流程），不要試圖用 vibe coding 建立一個完整複雜的系統。

風險 3：沒有工程師審查，不要把 vibe code 上 production

安全專家警告（The New Stack, 2026），未經嚴格審查的 AI 生成 code 進入正式環境，可能引發嚴重的安全問題。AI 為了完成功能，可能會引入有安全漏洞的舊有函式庫模式，或生成看似可用但實際上有漏洞的認證邏輯。

如果你的 vibe code 只是用於演示或使用者測試，風險相對可控。但如果涉及真實用戶資料、支付流程或登入機制，一定要讓工程師做 code review 才能上線。

你現在可以做什麼

設計師不需要成為工程師，但你現在可以選擇在哪些情況下自己動手。Figma Make 給了你這個選擇權，用得好是加速器，用錯了是技術債。

先從一個利害關係人 demo 開始：找一個你下週要做的簡報，試著用 Figma Make 把設計稿跑起來，讓對方真的點擊而不只是看截圖。感受這個工具的邊界，再決定你要走多遠。

如果你有工程師的 vibe coding 需求，可以參考 vibe coding 完整工程師指南 了解更進階的工作流。