為 AI 協作而生的設計系統（下）：從 Figma Make 到 Vercel 的設計與部署實驗

1. Figma Make 和 GitHub 的協作方式

這次主要是在看一件事：Figma Make 產生的程式碼，能不能真的進 GitHub，然後再接到 Cursor 的開發流程。

我的做法是讓 Figma Make 直接輸出前端程式碼到 GitHub 主分支，後端則用 Cursor 開另一條分支處理，最後再用 PR 合併。

大致分工是：

• Figma Make 處理畫面與排版
• Cursor 處理 API 和資料邏輯
• GitHub 做版本控制

我另外開了一個新的 repository，把 Figma Make 的專案同步進去。

這次主要在看幾件事：

• Figma Make 產生的元件能不能進 GitHub 並維持 SSOT
• variables 和 design tokens 是否還能一致
• 元件重不重複得了
• 設計變更能不能順利進開發流程

整體結構上，Figma Make 留在主分支處理畫面，後端在另一條分支，最後再整合到可部署的版本。

2. 用 Cursor 做一個極簡後端

因為這只是流程驗證，所以後端做得很簡單。

Cursor 主要做幾件事：抓匯率、抓加密貨幣價格、基本 rate limit、回傳整理好的 JSON。

它可以直接讀 Figma Make 同步下來的前端結構，再補 API 進去。

這次刻意只做到 MVP 等級，幾個 endpoint，加上穩定的資料格式。

接著從 UI 反推資料需求，例如：

• 匯率卡片
• 15 日走勢圖
• 買賣訊號儀表
• 波動區間
• 資產配置

再把這些對應到外部資料來源，例如 CoinGecko 和 ExchangeRate API。

這一步比較關鍵的是，把 UI 和資料之間的對照關係建立起來，讓每個元件知道自己拿什麼資料。

3. 部署到 Vercel

前後端都放到 GitHub 之後，因為沒有登入系統，也沒有資料庫，所以直接用 Vercel 做部署。

這一步主要不是在測效能，而是在確認整條流程能不能真的走完：Figma Make → GitHub → Cursor → Vercel。

結果比預期順。第一次 deploy 成功後，後面修改也可以很快重新部署。

4. 測試設計更新流程

部署完成後，開始測試設計變更會不會影響流程。

我在 Figma Make 做了一些小調整：

• 把字體從 Pixel Sans 換成 Ubuntu Mono，讓數字更好讀
• 調整 modal 排版，避免手機鍵盤遮住內容
• 修圓角和對比

確認後同步回 GitHub，開 PR，再 merge 到會觸發 Vercel 的分支。

整體流程是可以運作的，但在 Figma Make 裡做調整的價值沒有想像中高。

一個明顯問題是 Figma Make 產生的設計檔會有些細節誤差，而且目前幾乎是單向輸出。當把原始設計丟回去時，它常常抓不到細節，有時候直接用截圖反而更準。

在這次實驗裡，我開始覺得直接用 Cursor 改 UI code 會更快。

Cursor 的優勢很明顯：

• prompt 迭代快
• localhost 可以直接看到結果
• 修改成本低
• token 用量更省

這次大概 70 次 prompt 就用完 Figma Make 的 3000 token。

5. 總結

整體流程是可以跑通的：Figma Make → GitHub → Cursor → Vercel。

問題不在架構，而是在 Figma Make 和設計工具之間還有一段斷層。

AI 生成的 UI code 一旦離開 Figma Make，就很難再回到設計層做細調，最後會變成設計和程式碼各走各的路。

現在看起來，Figma Make 比較像是另一個生成工具，而 Cursor 反而更接近真正的開發中心。

如果未來 Figma 能把 Make 和設計工具真正打通，設計師才有可能在同一個環境裡完成設計、調整，甚至直接部署。

但目前來看，Figma Design 和 Figma Make 是兩個不同的產品線。當 Cursor 這類工具越來越成熟時，Figma Design 的角色可能會逐漸收斂成視覺與協作工具，而不是實際開發流程的一部分。