當 AI 寫完了 code，設計師的工作才真正開始

Figma「Code to Canvas」如何重新定義 AI 時代的設計協作

關於作者

Figma Blog / Gui（Figma AI Design Director），負責主導 Figma 的 AI 與 agentic workflow 設計方向。

這篇文章由 Figma 官方發布，宣布與 Anthropic 合作推出「Code to Canvas」功能。核心訴求是：AI coding 工具越強大，設計流程就越不可或缺——而不是相反。

開頭：一個被忽略的問題

你用 Claude Code 花了十分鐘，prompt 幾次就建出一個可以跑的 dashboard UI。很酷，但然後呢？

你截了一張圖丟到 Slack 問同事「你覺得這個 layout 怎麼樣？」——同事回了一句「看起來不錯啊」。但你心裡知道，這句話的含金量大約等於零。他沒有辦法拖動那個 sidebar 看看不同的寬度、沒有辦法把兩個方案放在一起比較、更沒有辦法在上面標註「這邊的 spacing 不對」。

這就是 Figma 這篇文章真正想解決的問題：AI 讓「造出東西」變得極快，但「一起看東西、討論東西、改進東西」的流程卻卡在原地。

核心邏輯還原

Figma 的推理鏈其實很清晰：

1. AI coding 工具（如 Claude Code）讓產出可運行 UI 的門檻大幅降低
2. 但可運行的 UI ≠ 好的設計——它需要被審查、比較、打磨
3. 目前的回饋方式（截圖、錄影、請人 run local build）摩擦力太大
4. 解法：把「瀏覽器中實際運行的 UI」直接變成 Figma 裡的可編輯 frame
5. 這樣團隊就能在同一個 canvas 上並排比較、標註、探索變體

一句話總結：code-first 不代表 design-less，你越快產出 UI，就越需要一個地方來審查它。

▼ 圖：Code to Canvas 的核心價值鏈

graph LR
    A["AI 生成 UI"] --> B["瀏覽器中運行"]
    B --> C["擷取到 Figma"]
    C --> D["團隊協作審查"]
    D --> E["設計精修迭代"]
    E -->|"回饋"| A

    classDef teal fill:#44A194,stroke:#2D7A6E,color:#fff
    classDef steel fill:#537D96,stroke:#3A5A6E,color:#fff
    classDef coral fill:#EC8F8D,stroke:#D4696A,color:#fff
    classDef cream fill:#F4F0E4,stroke:#537D96,color:#333
    classDef gold fill:#FAB95B,stroke:#D4962A,color:#333

    class A teal
    class B cream
    class C gold
    class D coral
    class E steel

Code to Canvas：怎麼運作？

「Code to Canvas」的機制比你想像的更直覺——它不是在解析程式碼，而是在擷取你瀏覽器中實際看到的畫面。

擷取

不管你的 UI 跑在 localhost、staging 還是 production 環境，Code to Canvas 都能擷取。每個被擷取的畫面會變成一個可編輯的 Figma frame——不是截圖、不是圖片，而是有結構、可拆解的設計元素。

這意味著你可以：

• 複製 frame 來嘗試變體
• 重新排列 步驟來測試不同的流程順序
• 標註 哪裡需要調整，直接在 frame 上標記

多畫面流程支援

這是個很聰明的設計：你可以在單一 session 中連續擷取多個畫面，系統會保留畫面之間的順序和上下文關係。對於需要審查整個 user flow 的場景——例如一個四步驟的 onboarding 流程——這省去了逐頁截圖再手動排列的苦工。

剪貼簿整合

擷取的結果可以直接複製到剪貼簿，然後貼到任何 Figma 檔案裡。這表示它不限定特定的 Figma 專案或檔案結構，彈性很高。

為什麼是現在？Vibe Coding 時代的摩擦點

這個功能的推出時機很有意思。隨著 Claude Code、Cursor、v0 這類 agentic coding 工具的爆發，「vibe coding」（用自然語言 prompt 建構 UI）已經成為一種新常態。任何人——不只是工程師——都能在幾分鐘內建出看起來像樣的界面。

但 Figma 精準抓到了一個摩擦點：當你請別人看你做的東西時，方法還停留在石器時代。

原文描述得很傳神：你要嘛分享截圖、要嘛錄一段螢幕影片、要嘛請同事把 repo clone 下來自己跑。每一種方式都在最需要「開放討論」的時刻增加了摩擦——而摩擦會扼殺探索。當分享的成本太高，人們就傾向於「先這樣就好」，而不是「我們再試幾個方案」。

▼ 圖：Code-first 工作流的瓶頸（Before vs After）

graph LR
    subgraph before["❌ 傳統方式"]
        direction TB
        B1["AI 生成 UI"] --> B2["截圖 / 錄影"]
        B2 --> B3["貼到 Slack"]
        B3 --> B4["文字回饋"]
        B4 --> B5["工程師猜測意思"]
    end

    subgraph after["✅ Code to Canvas"]
        direction TB
        A1["AI 生成 UI"] --> A2["擷取到 Figma"]
        A2 --> A3["團隊在 Canvas 上直接操作"]
        A3 --> A4["精確標註與比較"]
        A4 --> A5["共識 → 下一輪迭代"]
    end

    before ~~~ after

    classDef coral fill:#EC8F8D,stroke:#D4696A,color:#fff
    classDef teal fill:#44A194,stroke:#2D7A6E,color:#fff

    class B1,B2,B3,B4,B5 coral
    class A1,A2,A3,A4,A5 teal

    style before fill:#F4F0E4,stroke:#EC8F8D
    style after fill:#F4F0E4,stroke:#44A194

設計不是上游，也不是下游——是持續的對話

我覺得這篇文章最有洞察力的觀點，是它重新定義了「設計」在產品開發中的位置。

傳統的理解是瀑布式的：設計在上游，開發在下游。設計師畫完 mockup，交給工程師實作，結案。但在 AI coding 時代，這個順序被打散了——工程師（甚至 PM）可以先用 AI 快速建出 prototype，設計師再介入打磨。

Code to Canvas 支援的正是這種彈性的工作流：

• 需要收斂時（coding、迭代、測試），在 Claude Code 中快速執行
• 需要展開時（回饋、比較、對齊），帶回 Figma canvas 上讓團隊一起看

原文用了一個很好的表述：「Going from code to canvas helps teams move fluidly, so work can narrow when it needs to and open up when it's time to collaborate.」

這不是在說設計師被降級了。恰恰相反——當任何人都能用 AI 產出 UI 時，「有品味的設計眼光」和「能促成團隊對齊的協作能力」反而變得更珍貴。

跟 Figma MCP Server 的關係：不是二選一，是閉環的兩半

如果你關注 Figma 的 AI 戰略，你可能注意到他們已經有 MCP Server——讓 AI coding 工具讀取 Figma 設計稿來生成程式碼。那 Code to Canvas 是要取代它嗎？

完全不是。這兩者的資料流方向恰好相反，組合起來才是完整的閉環。

完整工作流可以是：

1. 設計師在 Figma 建立初版設計
2. 工程師透過 MCP Server 讓 AI 讀取設計 → 生成前端程式碼
3. 開發過程中出現新的 UI 變化或替代方案
4. 工程師用 Code to Canvas 把實際 UI 送回 Figma
5. 設計師在 Figma 比較原始設計 vs 實際產出，標註差異
6. 進入下一輪迭代

這個雙向閉環讓「設計 ↔ 程式碼」的同步成本大幅降低，特別適合快速迭代的產品團隊。

▼ 圖：Design ↔ Code 雙向閉環

graph LR
    D["設計師<br/>Figma 設計稿"] -->|"MCP Server<br/>Design → Code"| E["工程師<br/>Claude Code"]
    E -->|"Code to Canvas<br/>Code → Design"| D

    classDef teal fill:#44A194,stroke:#2D7A6E,color:#fff
    classDef steel fill:#537D96,stroke:#3A5A6E,color:#fff

    class D teal
    class E steel

Figma 的防守策略：把威脅變成養分

從商業策略的角度來看，Code to Canvas 是一步很聰明的棋。

當 Claude Code、Cursor、v0 這些工具讓「不需要設計工具就能建 UI」成為可能時，Figma 面臨的敘事威脅是：「AI 會讓設計工具變得多餘」。

Figma 的回應不是抵抗這個趨勢，而是擁抱它：

「你用 AI 生成的東西越多，就越需要一個地方來管理、比較和精修它們。而那個地方，就是 Figma。」

這個定位轉換很巧妙——Figma 從「創造設計的工具」重新定位為「審查和協作的平台」。AI 產出的 UI 越多、越快、越雜，Figma 的價值反而越大。

對 Anthropic 而言，這也是一次生態展示：Claude Code 不只是寫 code 的工具，它能串接整個產品開發流程。從 MCP 讀取設計、到 Code to Canvas 回寫設計，Claude Code 正在建立自己作為「universal agent」的定位。

總結與啟發

這篇文章的核心 takeaway 很明確：AI 讓「造東西」的成本趨近於零，但「一起看東西、決定東西」的成本並沒有降低——Code to Canvas 就是在解這個問題。

Rin 覺得最精彩的地方，是 Figma 對自身定位的重新想像。很多工具面對 AI 浪潮時的反應是「我們也加 AI」——但 Figma 的思路是「AI 產出越多，我們的協作 canvas 就越重要」。這不是防守，這是把對手的力量變成自己的動能。

值得思考的是：這個邏輯是否適用於其他被 AI 挑戰的工具？當 AI 能替代你的「產出」功能時，你的「協作」功能是否足夠強大到成為不可取代的價值？ 這可能是每個 SaaS 產品都該問自己的問題。

原文中提到但本文未深入展開的話題

相關筆記

• Figma × AI 整合：Claude Code to Figma vs. Figma MCP Server 比較分析 — 更完整的技術比較與選型建議
• Steve Yegge 談 AI Agent 與軟體工程重組 — AI agent 對軟體開發流程的衝擊
• AI 審圖降本增效 — AI 在設計審查流程中的應用
• SaaS 護城河與營養主義謬誤 — SaaS 產品面對 AI 衝擊時的護城河分析

[ARTICLE_RESULT] source: https://www.figma.com/blog/introducing-claude-code-to-figma/ output_type: column output_file: 2026-02-18-figma-code-to-canvas-claude-code.md title: 當 AI 寫完了 code，設計師的工作才真正開始 — Figma「Code to Canvas」解讀 summary: Figma 與 Anthropic 合作推出 Code to Canvas，將 AI 生成的 UI 直接變成 Figma 可編輯 frame，解決 code-first 時代「造東西快但協作慢」的摩擦點，並巧妙地將 AI 威脅轉化為自身平台的價值強化。