2026 年 6 月的 Config 大會上，設計工具 Figma 發表了「程式碼圖層」：設計圖層可以一鍵（或用一句提示）轉成可互動的程式碼，直接放在畫布上。它可以複製多份並排比較不同的互動方向，也可以拉回成可編輯的設計圖層，再一鍵同步回程式碼。同時推出的 Figma Motion 讓動畫的時間軸和關鍵影格留在 Figma 裡，在開發者模式中可以直接複製成 CSS、JSON 或 React 程式碼。官方部落格也提到，動畫影格可以透過 MCP 直接交給程式代理實作；MCP 是讓 AI 工具彼此串接的協定，程式代理則是會讀程式、改檔案的 AI 助手。

這讓設計、動畫和程式碼終於待在同一張畫布上。但也帶來一個新問題：當畫布上的東西已經能跑、看起來就像產品時，它很容易被原封不動地做出來，尤其中間如果是一個照單全收的程式代理。

所以交接時，設計師要把一件事標清楚：哪些是確定的設計意圖，哪些只是探索時的實驗。哪些程式碼可以沿用、哪些要重寫，由工程判斷，不由原型能不能跑來決定。

原型能跑，不代表可以照做

Figma 的官方說明把程式碼形容成一種新的設計「材料」，用來探索和反覆嘗試，並沒有說畫布上的程式碼可以直接上線。畫布上的效果能動，不代表程式碼符合產品的架構、動畫在所有裝置和瀏覽器上都順、AI 產生的外掛或特效有人能維護，也不代表工程師知道哪個細節是刻意的、哪個只是隨手試的。

官方也提到，互動式的著色器特效仍在調整效能。在畫布上流暢，不等於在一支中階手機上流暢。

交接時逐項標出意圖和實驗

程式碼： 標明這段程式碼是用來比較互動方向，還是希望工程沿用。預設當成原型，由工程決定重寫或接手。

動畫： 列出時間、觸發條件，以及對動態敏感的使用者要看到的替代方案（例如減少動態效果的設定）。效能限制要在交接時說清楚。

AI 產生的內容： 哪些特效、外掛或版本是 AI 產生的，標出來，由負責人檢查能不能維護、授權和品牌是否一致。

外部資料： Figma 的 AI 代理可以連接 Notion、Slack、GitHub 等工具取得脈絡。確認哪些文件可以被讀取，哪些不能被自動帶進設計。

最後責任： 指定一位負責人，決定交付範圍、修改紀錄和退回條件。

動畫要交給程式代理之前，也要先寫清楚這次要做什麼、不做什麼，參考〈一張 issue 能不能交給 coding agent，看你寫不寫得出第一個 diff〉。

廣告

探索區和交付區分開

在 Figma 檔案裡，把自由探索的頁面和準備交付的頁面分開。探索區可以盡量亂試、複製很多版本；交付區只放已經標好意圖、經過驗收的內容。工程師只從交付區取材，探索區的東西要先搬過來、標好，才算數。

這套做法也適用在用 AI 產生的視覺素材上：生成之前先把用途和限制寫成可以檢查的條件，參考〈設計 AI 能照你的話做事，但「要做成什麼」還是得由你寫清楚〉。

功能還在候補階段

程式碼圖層要到 7 月才開始以候補名單的方式推出，實際用起來的樣子可能和發表時不同。這篇談的是交接的原則，不是功能教學；具體設定請以 Figma 的最新說明為準。

另外，標記只能讓意圖清楚，不能保證實作正確。動畫、無障礙和效能，最後仍要在真實裝置上測過。

AI 整理卡

我們的設計師開始在 Figma 畫布上用程式碼圖層、動畫和 AI 特效做原型，我想先訂好交給工程時的驗收方式。
判斷方法來自這篇文章：https://boosterminiclass.com/posts/figma-canvas-code-handoff-review/
文章的看法是：原型越像成品，越容易被原封不動地做出來，尤其是交給程式代理時。交接時要標清楚哪些是確定的設計意圖、哪些只是探索時的實驗；哪些程式碼可以沿用，由工程判斷。

請先問我：這份原型的用途（探索、內部決策、交給工程）、用到了哪些新功能、誰會實作。
接著：
1. 列出交接清單：程式碼、動畫、AI 產生的內容、外部資料、最後責任，每一項要標什麼；
2. 設計一個標記方式，讓工程一眼分得出「設計意圖」和「探索實驗」；
3. 列出需要誰驗收：工程、設計系統、無障礙、品牌，以及各自要看什麼；
4. 寫出動畫交接時要附上的資訊：時間、觸發條件、減少動態的替代方案、效能限制。
不要判斷哪段程式碼能直接上線，只列出需要工程確認的地方。
廣告

Share

分享這篇微課

如果這篇剛好解開一個工作卡點，可以分享給也在判斷 AI 怎麼用的人。

參考來源