Code to Figma
當 AI 可以直接產出 prototype 來溝通需求，Figma 還有存在的必要嗎？
我的答案是這樣：只要設計師跟工程師不是同一個人，就不可能不需要溝通工具。
那你相信你們家工程師的 UI/UX 設計能力嗎？答案應該很明顯了吧。
身為設計師，這就是我們的價值所在——把規格、流程、細節用設計師看得懂的語言講清楚，這件事 AI 還沒辦法取代設計師。
——
為什麼是 Code to Figma，不是反過來？
很多人聽到 Figma 跟 AI，第一直覺都是 Figma to Code——把設計稿丟給工程師變成程式碼。
但現實是，越來越多時候設計師會遇到的場景是：工程師早就把畫面刻出來了，設計檔卻是空的。
可能是工程師自己 vibe 出來的，可能是 PM 急著要 demo，也可能是 side project 一路長到產品化，總之我們打開 Figma 的時候，程式碼比設計檔還新。
這時候要做的不是從頭重畫，而是把現有的程式碼「回灌」到 Figma，讓我們有東西可以接著做、可以接著改、可以接著建設計系統。這就是 Code to Figma 在解的問題。
——
話說回來，不管是 Code to Figma 還是 Figma to Code，我覺得核心道理是一樣的。
不要再講什麼「設計系統已死」這種不負責任的話，越是 AI 時代，設計系統的價值反而被拉得更高。
我也經常分享，設計系統不是丟出幾個顏色跟元件就自稱有設計系統，而是你要把畫面的表現、流程、準則講清楚，那才叫「設計系統」。
UI/UX 不應該是憑美感、憑經驗、憑直覺，UI/UX 是一套自成體系的「工程學」。這套工程學不是叫設計師去寫程式，而是把 PO 嘴巴裡那些「商業邏輯」轉化成可以被軟體實作的「規格說明書」。
這正是設計師的專業，也是 AI 學不走的部分。
——
來講講實務操作。
並不是丟一句「把 HTML 畫到 Figma」就好，其實還有很多東西要交代。
要先認知到，AI 是一個很聰明但什麼都不會的新人，而且跟人類一樣很愛偷懶，所以交派工作必須很明確。
第一，先把設計系統建起來
初期一定要先把 Variables、Styles、Components 建好，這是一切的基礎，不然 AI 會毫無節制地用 Frame 從頭刻到尾，你後面看了會想哭。
你一定心想「好麻煩」，建立 Design System 真的很花時間。
但你可以選擇用開源的 MUI、Antd、Vuetify 這些別人建好的，或是打造一個屬於自己風格的系統。
對設計師來說，這也是練功的最好時機——你越早搞懂 Token、Component、Variant 的邏輯，未來跟工程師對話就越順。
（關於用 AI 建 Component，這又可以另外寫一篇了）
第二，要 AI 爬網站，不如要他爬檔案
對 AI 來說，用 Figma plugin 去爬網站資訊是很累的事情。
要先請他把設計系統的資訊全部爬下來存成檔案，後面再請他閱讀。
這些檔案資訊量非常龐大，你才會知道——如果不先讓他爬下來，過程會多費力。如果是用別人的 Library，特別要注意 Component Name 不要跟自己的撞名。
第三，制定自己的繪畫習慣準則
我會逐步寫一套自己畫 Figma 的準則告訴他，包含：
- 「預設使用 Auto Layout」
- 「預設不勾選 Clip Content」
- 「使用 icon 請從 material-symbols 選用」
- ⋯⋯各種你在意的細節
AI 是不會知道你在想什麼的，你必須講出來。
設計師最在意的「畫得乾不乾淨」「圖層整不整齊」「命名規不規範」，AI 全部都不會主動做，你不講他就不做。
甚至如果你想叫他「設計」，那你就得提供一份風格的詳細資訊。因為「工程學」不講感覺，只談「規範和準則」。
可以是參考網站、可以是描述文字、可以是你的設計系統，但絕對不是叫他無中生有，那叫抽卡，不叫設計。
第四，驗證成果
AI 做出來的東西常常會偷懶，你需要去驗證執行成果。
這時候開一個 Subagent，重新讀取規則跟目標成果，讓 Subagent 擔任 QA 去驗證實作對不對。
很多沒做好、沒做到的問題，都會在這個階段被揪出來！
——
AI 會偷懶的常見坑
順便分享一下我實際遇過的「災情」，每一個都會讓設計師看了血壓飆高：
- Auto Layout 該用 Hug 卻全部給你 Fixed，畫面一改就爆炸
- 顏色不去抓 Variables，直接 hardcode 一個
#3B82F6給你 - 明明 Library 裡就有 Button，他自己用 Frame + Text 假裝一個
- Icon 不去 material-symbols 找，自己畫一個歪七扭八的向量
- 同一個元件切了 N 個 Variant，但其實只是顏色不一樣
每一個坑，都是在你以為「AI 終於幫我做完了」之後，打開 Figma 才發現的驚喜。
所以第四步驟的 QA 驗證，真的不能省。
——
什麼時候「不要」用 Code to Figma？
也不是每個場景都適合，講幾個我覺得別硬上的情況：
- 純探索性設計：還在發想期，連方向都不確定，自己畫草稿比較快
- 沒有設計系統的新專案：你連 Token 都還沒有，AI 畫出來只會是一坨亂七八糟的 Frame
- 品牌視覺、Marketing 頁：那種要靠美感跟氛圍的東西，工程學救不了你，這時候才是設計師真正發光的地方
Code to Figma 解的是「同步」的問題，不是「創造」的問題。搞清楚這件事，才不會用錯地方。
——
再額外分享一些小技巧：
- 讀取 Browser 時，明定「HTML 結構」跟「Computed Style」這些關鍵字，會讓結果更精準。
- 如果開一個 Session 一直來回調整，Context 會越滾越大，讀取 MCP 也很浪費 Token，打 API 又會消耗請求額度。可以先產出中間產物的 Markdown 檔案，把你真正需要的資料整理成文字，再開一個新對話視窗，AI 才不會失憶要重新讀龐大的 Context。
- 目前 Figma 對於 Slot 的支援很差，需要另外寫 SKILL 強化 AI 的使用。(聽說 Q3 時，Figma Plugin 會發佈支援)
——
最後一句送給大家：
設計工具不會死，會死的是不講規範的設計師、跟不信規範的工程師。
而我們，就是那個把規範立起來的人。
#Figma #codetofigma #AI #htmltofigma #uidesign #aidesign