AI 時代的設計與工程協作：我們團隊的實作方式

最近越來越多專案，第一個「打開」設計稿的不是工程師，而是 AI agent。Claude Code、Cursor 和 Codex 這類工具，都具備直接讀取設計檔、產出對應程式碼的能力，設計檔案的品質，會直接反映在 AI 產出的結果上。趁這個機會，我想分享團隊內部在設計與開發銜接上的做法，給有類似需求的團隊參考。

我們自己做設計時，會準備哪些東西

先說工具。目前我們所有設計專案都是在 Figma 上進行，對外部設計合作夥伴也是以 Figma 的使用為必要條件。當然，偶爾還是會收到 Illustrator、Photoshop、甚至只有 JPG 的設計稿，多半來自比較熟悉印刷流程的設計團隊。這類檔案在印刷上沒有問題，但拿來開發網頁，間距、色碼、字級這些需要的數值都取不出來：工程師只能靠肉眼量測、來回確認，AI 也讀不到任何結構化的資訊，光是整理到能開工的狀態，就得先多花一輪成本。在 Figma 的基礎上，我們每個專案會產出三樣東西：

設計文件
記錄資訊架構、互動狀態、RWD 的處理原則，以及各種 edge case：表單驗證失敗長什麼樣、清單沒有資料時顯示什麼。很多設計交付是沒有任何說明的，這些細節全靠工程師自行想像，做完再來回修改。這份文件在 AI 開發流程裡還有另一個用途，後面會再提到。

Design System
色彩、字級、間距都定義成清楚的變數，按鈕、卡片、表單這些常用元件建成 components（組件），並且有一致的命名。差別在於檔案有沒有「語意」：同樣一顆藍色按鈕，命名為 button/primary 的元件，和一個叫 Rectangle 152 的色塊，對 AI 來說是完全不同的東西。

重點頁面設計稿，含桌機、平板、手機三個版本
不是每一頁都出三版，而是把關鍵頁面的三個斷點定義清楚，其餘頁面依循 design system 的規則延伸。常見的做法是只出桌機版，行動版讓工程師自由發揮，結果通常是驗收階段的大量來回；先把斷點行為定義好，整體反而省時間。

設計檔案到了開發端，我們怎麼運用

前面準備的這些東西，進到開發階段都派得上用場。我們目前的做法有五個：

用 MCP 讓 AI 直接讀設計檔
Figma 官方有 Dev Mode MCP server，Claude Code 可以直接讀取節點結構、變數和樣式，而不是只能看截圖推測版面。設計檔整理得越完整，AI 取得的資料越乾淨，還原度也越高，前面整理 design system 的工夫，在這個環節會直接反映在效率上。

Design Token 進版本控制
把 Figma variables 輸出成 JSON 或 CSS variables，設計與程式共用同一份定義。AI 生成頁面時引用同一套 token，不會出現每頁顏色、間距各走各的狀況。

Components 對應
Design system 裡的 components，用於讓工程師可以對應所有的元件。AI 的工作因此從每頁重刻，變成組裝現有元件；實務上，讓 AI 從既有選項中挑選，穩定度遠高於讓它自由發揮。

用生圖引擎補素材
Higgsfield 的 MCP、Codex 裡的 GPT-image-2，都可以直接在開發流程中呼叫。Banner、示意圖、情境照先用 AI 產出初版，開發不用停下來等圖，設計師後續再針對關鍵畫面精修。另外我們也會善用佔位圖（placeholder）的做法：先在版面上留好佔位圖，把生圖的 prompt 直接寫在圖上，AI 在開發過程中讀到 prompt，就能自動生成並替換成正式圖片。

讓 Agent 也參與驗收
用 Playwright 這類工具讓 AI 對實作頁面截圖、自行與設計稿比對，自動找出跑版和設定不相符的部分，設計的還原度就有了可以確認的依據。

題外話：自己寫 Figma 外掛

流程跑順之後，偶爾還是會碰到 Figma 原生功能做不到的事，像是把 variables 一鍵輸出成專案要的 token 格式、掃出檔案裡還沒照規範命名的圖層，或是把生圖 prompt 批次寫進佔位圖；外掛本身就是網頁技術（HTML 加 JavaScript），對前端團隊幾乎沒有門檻，所以我們也開始把幾支內部外掛當作流程的一部分在維護，算是這套做法的延伸應用。

設計文件、Design System、多斷點設計稿，本來就是我們做專案的標準流程；只是以前整理這些，省下的是工程師來回確認的時間，現在則直接決定 AI 能讀懂多少、做到多少，以及團隊整體的開發效率能提升多少。我們自己的經驗是，前期把設計檔案顧好，後面開發和驗收的每個環節都會輕鬆很多。如果你的團隊也正在把 AI 導入開發流程，在設計整合上遇到不少困擾，歡迎私訊我們交流喔！