你和設計師在同一個 Figma 檔案裡看新介面。以前你看到的大多是 frame、按鈕、文字、元件和原型連線；它們說明介面長什麼樣、按下去會到哪裡。
code layer 改變的是這個日常畫面：有些互動本身就是一段能跑的 UI code，直接躺在 Figma 畫布上。設計師可以複製它、改一個版本、拿來比較不同互動方向；工程師和產品經理也能在同一張畫布上看到「它真的動起來會怎樣」。
這很方便，因為過去設計稿、互動原型、動畫和工程實驗常常分散在不同工具裡。但方便也會帶來一個新問題：當畫布上的東西已經能跑、看起來很像產品時，誰來判斷它只是探索，還是已經可以交給工程實作？
Figma 在 2026 年 Config 公告了 code layers（把可執行或可編輯的程式碼當成畫布上的設計材料）、Figma Motion、shader fills/effects（用程式即時算出的視覺效果或材質）、generative plugins、Weave tools（把 AI 影像處理包成可重複使用的工具）和更有脈絡的 Figma agent。這裡的 AI agent，指的是會讀取畫布脈絡、依照提示連續完成多個設計或整理動作的 AI，不只是回答一句話的聊天機器人。多家科技媒體也都把重點放在同一件事：Figma 正把設計、程式碼、動畫和 AI 工作流放進同一個協作畫布。
這篇微課不判斷你該不該立刻導入 Figma 新功能，而是提供一個交接判準：把「探索畫布」和「交付規格」分開。
先分清：畫布可以很自由，交付不能很模糊
Figma 官方把 code layers 描述成把 code 當成新的設計材料。重點不是「Figma 幫你匯出一點 CSS」，而是 code 也可以像圖片、元件或文字一樣，成為畫布上可討論、可複製、可比較的材料。你可以把設計層轉成互動 code layer、複製多個方向一起比較，也可以把 code 裡的流程抽回可編輯的設計層。Motion 則讓動畫時間軸、關鍵影格和匯出格式留在 Figma 裡；shader 和 generative plugins 讓人用提示建立視覺效果或自訂工具。
這些能力很適合探索，因為團隊可以更快看到「如果這樣做會怎樣」。設計師、產品經理和工程師不必等到每個細節都定稿，才開始討論互動方向。
可是，探索階段越像成品，交接風險就越容易被低估。因為畫布上的效果能跑，不代表：
- 這段程式碼符合產品架構；
- 動畫在所有裝置和瀏覽器都穩定；
- AI 產生的外掛或效果可以被團隊維護；
- 工程師知道哪些地方是設計意圖，哪些只是臨時實驗。
所以團隊要先約定：Figma 畫布可以承載很多材料，但正式交付仍然需要清楚的驗收欄位。
用一張表區分探索畫布和交付規格
下次看到一個很完整的 Figma 原型時，可以先用這張表分層，而不是直接問「能不能交給工程」。
| 檢查面向 | 探索畫布可以接受 | 交付規格必須補齊 |
|---|---|---|
| 程式碼 | code layer 用來比較互動方向、確認想法可行 | 說明哪些程式碼只是原型，哪些邏輯要由正式工程重寫或接手 |
| 動畫 | Motion 可先展示節奏、轉場、3D 變化和情緒感 | 列出時間、觸發條件、無障礙替代方案與效能限制 |
| AI 產生內容 | agent 可協助產生效果、外掛或多個版本 | 標記哪些內容由 AI 產生，並由負責人檢查可維護性、授權和品牌一致性 |
| 外部工具連結 | 可接 Notion、Slack、GitHub 等工具取得脈絡 | 確認資料來源、權限邊界，以及哪些文件不能被自動讀取或帶入 |
| 最終責任 | 團隊可以一起評論和試方向 | 指定負責這件事的人，決定交付範圍、修改紀錄和退回條件 |
這張表的目的不是讓流程變慢，而是防止大家把「看起來很完整」誤會成「已經可交付」。設計畫布越強，越需要把探索和交付的邊界寫清楚。
可以怎麼導入：先把它當成隔離測試區
比較穩的做法，是先把這類新畫布能力當成「隔離的測試環境」。也就是說，你可以在裡面嘗試互動、動畫和 AI 產生的效果，但不要讓它直接取代正式產品程式碼或正式設計系統。
小團隊可以先設三條規則。
第一，所有 code layer 都要標成「探索」、「待工程重寫」或「可作為參考」。不要只把程式碼丟給工程師，讓對方猜哪些可用、哪些只是展示。
第二，所有 Motion 或 shader 效果都要補一行「失敗時怎麼辦」。例如低效能裝置上是否要關閉、螢幕閱讀器是否需要另一種說明、動畫卡住時頁面是否仍可操作。
第三，AI 產生的外掛、效果或素材要有人負責驗收。這裡的負責人不是「會用 Figma 的人」而已，而是能判斷品牌、授權、維護成本和工程交接是否可接受的人。
什麼情況不要急著切換
即使 Figma 的新功能很有吸引力，下面幾種情況也不適合急著把整個流程搬過去。
- 你的團隊還沒有清楚的交付模板：先補「規格欄位」，不要先追新工具。
- 工程和設計對「原型 code 可不可以進正式產品」沒有共識：先把責任切清楚。
- 產品有高無障礙、效能或安全要求：動畫、shader 和外部工具連結都要先做限制測試。
- 設計系統本來就很混亂：AI 只會更快產生更多變體，不會自動替你整理標準。
這不是保守，而是把新工具放在它最適合的位置：先用來探索、比較、溝通，再由團隊決定哪些內容能進交付。
這堂微課的結論
Figma 把程式碼、動畫、shader、外掛和 AI agent 放進同一個畫布，對設計協作是很大的變化。它可能讓早期探索更快，也讓產品經理、設計師和工程師更早看到同一個方向。
但交接品質不會自動變好。真正省時間的不是畫布看起來更像成品，而是團隊能清楚說出：哪些只是探索、哪些可以交付、哪些需要重寫、哪些需要人工確認。
如果你要試 Figma 這批新能力，先不要把問題問成「要不要換工具」。更好的問題是：我們能不能在同一張畫布上探索，同時保留一份不含糊的交付規格？
用日常來理解
- 共享畫布讓互動、動畫和 AI 效果看起來更接近成品，團隊很容易被完整感吸引。
- 團隊先把探索區和交付區分開，避免把「能展示」誤會成「能上線」。
- 每個效果都被放回驗收欄位：程式碼、動畫、權限、責任人和失敗時的替代方案。
- 最後交給工程的是整理後的規格包，不是需要對方猜測邊界的漂亮原型。
AI 整理卡
依這篇情境，請 AI 幫你整理
複製到你自己的 AI 聊天工具，讓它把這篇微課轉成你的個人版檢查清單。BMC 不會看到你貼給 AI 的內容。
參考來源
- Figma Blog：Config 2026: New Materials, New Tools and a More Expressive Canvas — https://www.figma.com/blog/config-2026-recap/
- TechCrunch：Figma adds code layers, support for animations, more AI features in new update — https://techcrunch.com/2026/06/24/figma-adds-code-layers-support-for-animations-more-ai-features-in-new-update/
- The Verge：Figma now has AI motion graphics and shader tools — https://www.theverge.com/tech/955831/figma-code-design-tools-config-2026-announcements
