Figma 設計轉 React 程式碼：AI Copilot 實務工作流

把 Figma 畫面交給 AI，確實能很快產生一段 React 與 CSS；但「看起來像」不等於能直接合併到正式產品。原題提到的 Frontend Copilot，可理解為協助前端實作的 AI coding agent。它最有價值的角色不是憑一張截圖重新畫出介面，而是讀懂設計意圖、找到既有元件與設計 token，並在專案既有規範內完成一小段可審查的改動。

若團隊使用 Figma Dev Mode、MCP 或其他設計交接工具，AI 可以取得比截圖更完整的脈絡，例如選取範圍的結構、變數、資產與元件關係。Figma 官方也明確說明：MCP server 的工作是提供設計脈絡，不是交付可直接上線的 production-ready code；最後仍要由 AI agent 依專案的語言、框架與既有模式完成轉譯。這個界線正是「幾分鐘做出雛形」與「交付可維護 React 功能」之間的差異。

先釐清：AI 產生的是起點，不是完成品

一張靜態設計稿通常只回答了畫面長什麼樣子，沒有完整回答資料從哪裡來、按鈕會做什麼、載入或錯誤時顯示什麼、權限如何限制，以及手機尺寸下如何重新排列。若直接要求 AI「把這張 Figma 做成 React」，它往往會建立新的 button、card、icon 與色碼；視覺可能相近，卻可能繞過既有設計系統、重複元件，或把互動規則猜錯。

比較可靠的目標應該是：讓 AI 以目前程式庫為優先，重用現有元件、token、表單驗證與資料存取方式，並只處理已界定的畫面或元件。這樣產出的程式碼仍需審查，但它會成為團隊可持續維護的變更，而不是一次性的展示稿。

設計檔要先具備哪些可交接資訊？

AI 能否正確實作，往往取決於設計檔是否能回答清楚的問題。開始前，設計與前端可以先把以下資訊補齊：

元件與變體：按鈕、輸入框、卡片應使用元件實例，並清楚定義 size、state、disabled、error 等變體，而不是用多個相似圖層手工拼出畫面。
變數與 token：色彩、字級、間距、圓角與斷點應有一致名稱。只給 AI 一個十六進位色碼，無法告訴它該用哪個既有 token。
版面與響應式規則：標示桌面與手機狀態、容器寬度、內容何時換行或收合；不要期待 AI 從單一寬度猜出所有 breakpoint。
互動與例外狀態：至少交代 loading、empty、error、success、hover、focus 與權限差異。靜態 happy path 不是完整的產品規格。
內容與資料契約：真實欄位長度、可為空的值、時間與金額格式、排序規則，以及 API 尚未提供時該如何顯示，都要事先說明。

這些資訊也讓設計本身更可維護，不只是為了 AI。當元件、變數與程式碼命名可以對照時，後續的設計調整才不會在每次交接時重新解讀一次。

用 Code Connect 減少「重畫一套元件」

Figma 的 Code Connect 可將設計元件與實際 React 元件建立連結，並可把 Figma 屬性對應到 React props。以按鈕為例，設計中的文字、disabled 狀態與 Type 變體可以映射到既有的 <Button> API，而不是讓 AI 另寫一個外觀相似、行為不同的按鈕。

這不代表設定一次就萬事大吉。設計與程式碼的 props 常常不是一對一：設計裡的一個 Variant，程式碼可能是 enum、class 或不同的組合元件。因此應從最常用、最穩定的設計系統元件開始建立 mapping，並在新增元件或調整 API 時同步維護。當 AI 拿到這些 mapping，它較能找到正確的 import、元件路徑與 token；沒有 mapping 時，就要把「先搜尋並重用現有元件，找不到才提出原因」寫進工作指令。

從 Figma 到 React 的實務工作流

1. 把任務縮小到可驗收的範圍

不要一次交出整個 dashboard 並要求「完整轉換」。可以先指定一個頁首、一張表單卡片或一個清單列，連同 Figma node、目標路由、相關元件目錄與完成條件。範圍越清楚，AI 越不會任意改動無關檔案。

2. 先提供設計脈絡，再提供專案規範

在支援 MCP 的 IDE 或 agent 中，先取得選取設計的結構、變數與資產資訊；接著明確告訴 AI 專案使用的 React 版本、UI library、樣式方案、檔案組織、資料抓取方式與測試命令。若已有 Code Connect，指定它優先使用對應元件。好的提示詞不是「產生 React」，而是「以現有 components/ui 為唯一元件來源，完成此畫面並列出無法從設計推斷的行為假設」。

3. 要求小型、可閱讀的變更

讓 AI 先說明預計修改哪些檔案、重用哪些元件，再產生程式碼。對大型專案而言，最好要求它避免順手重構、避免新增重複 token，也不要在不確定資料契約時捏造 API。輸出的每一段 JSX、樣式與型別都應能在 code review 中說清楚來源與理由。

4. 同時檢查視覺、行為與可及性

實作後以桌面與手機尺寸比對設計稿，但不要只看像不像。應實測鍵盤操作、focus 順序、語意 HTML、表單 label、錯誤訊息、文字放大、深色或高對比情境，以及 loading／empty／error 狀態。Figma 能描述外觀，卻不能取代真實資料、瀏覽器行為與無障礙測試。

5. 把人工審查放在合併前

最後仍要由了解產品與程式碼的人檢查：是否使用了既有元件、是否遵守 token、是否有不必要的依賴、是否洩漏測試資料、是否通過 lint、型別檢查與測試。對有風險的流程，還要確認權限、輸入驗證、CSRF、防呆與錯誤處理。AI 可以加速實作，不應自行決定產品規則或安全邊界。

常見誤區與修正方式

誤區一：把截圖當成完整規格。截圖缺少狀態與資料語意。修正方式是補上互動說明、範例資料、空值規則與響應式畫面。

誤區二：只要求「像 Figma」。這會鼓勵 AI 用硬編碼像素與臨時 CSS 達成視覺效果。修正方式是要求使用既有 design tokens、元件 API 與 layout 規範。

誤區三：一次產生後直接合併。即使畫面正確，也可能有不可見的可及性、狀態或效能問題。修正方式是把視覺比對、互動測試與 code review 視為同一個交付流程。

誤區四：以為工具會理解所有產品背景。設計脈絡能提升準確度，但產品決策、商業規則與安全限制仍應由團隊明確提供與確認。

結語：讓 AI 接上系統，而不是取代系統

Figma 到 React 的 AI 協作，真正節省時間的地方不是把設計稿瞬間變成一堆 JSX，而是讓設計系統、程式碼庫與實作任務共享同一份脈絡。先整理元件與變數、建立必要的設計—程式碼 mapping、把任務切小，再以視覺、行為與測試驗收；這樣 AI Copilot 才能穩定縮短重複工作，同時保留可讀性、可及性與長期維護能力。