Figma MCP 工作流實驗：讓畫布跟上 code 的速度

設計團隊用 agentic coding tool 出 feature 的速度愈來愈快，問題也跟著浮現：很多在 build 階段才出現的狀態 — encoding error、render loading、empty selection、各種 edge case — 從來沒進過 Figma 畫布。設計師沒看見、沒設計，最後就以工程師臨時湊出來的樣子上線。

Figma 官方 4 月 30 日這篇 Workflow Lab，由 Designer Advocate Brett McMillin 示範了一個用 Figma MCP server 把這個落差封起來的實驗工作流：agent 讀 code、把 build 過程裡浮現的所有狀態寫回 canvas 變成可編輯的 frame，設計師再一個個處理。整個流程結束後，原本只有 4 個 frame 的 canvas 變成 14 個，設計師第一次完整看到產品形狀。這篇拆解整個工作流，給轉職設計師理解 MCP 在 design–dev 協作裡到底解了什麼問題、自己現在能做什麼準備。

虛構案例 Astra 是一個 AI 影片剪輯平台，每週出新 feature。設計師原本畫了一個簡單的 export video 流程：選 sequence、選格式、確認設定、匯出，總共 4 個 frame，足以給工程師起手。但程式進到實作後，問題開始長出來：encoding 失敗怎麼辦？正在 render 的 loading 要顯示什麼？沒選任何片段時的 empty state 要長怎樣？格式不支援的 edge case 怎麼處理？

這些都是設計決策，但都沒在原本的 4 個 frame 裡。Brett 在文中點得很直白：「When the canvas only captures part of the picture, designers can only work on part of the product.」這就是工作流的關鍵問題 — canvas 跟 build 脫鉤後，設計師能設計到的範圍永遠只有一半，剩下那半在 code 裡長出來、沒人補設計，最後就以「能用」的樣子被推上線。

Astra 的設計師打開 Figma，啟動 agent。Agent 透過 Figma MCP 讀 export flow 的 code，找出工程師實作過的每一個狀態，再用 use_figma 工具，依 Astra 設計系統的 component 為每個狀態生成一個可編輯的 frame，直接放回 canvas。

原本 4 個 frame 的 canvas，瞬間變成 14 個 frame。這 14 個裡面，10 個是設計師「沒在原稿出現過」的決策點 — 這些畫面在原始 spec 看不到，原因很簡單：它們要等 code 跟真實資料碰撞才會浮現。設計師現在第一次看到產品在 build 後的完整形狀，包含每個 error、loading、empty、edge case 的實際樣貌。

有了完整的 14 個狀態後，設計師開始一個個補：encoding error 加上「發生什麼事 / 怎麼解 / 怎麼回去」的引導訊息；render loading 加上 progress 指示器跟剩餘時間；empty selection 加上 copy 跟性格化的引導文案來推 feature adoption。

Brett 強調這個工作流最有價值的地方：以前要靠「discovery session」才能挖出來的 design moment，現在 build 進到哪、canvas 就跟到哪。團隊省下開會討論需求的時間，全部投到實際設計跟實作。對轉職設計師來說，理解這個轉變比學工具細節重要 — 設計師的工作從「事先 spec 完整流程」往「持續修補 build 浮現的決策點」移動。

檢視到 export confirmation 畫面時，設計師發現一個怪事：code 上的版本顏色跟 Figma 不太一樣，spacing 也偏緊。design system 似乎漂了。設計師啟動 /sync-figma-token skill，agent 用 use_figma 工具去比對 code 用的 token 跟 Figma library 裡的 variable，自動偵測落差並同步。

token 對齊後問題還沒完 — button hierarchy 變了、套用的 font style 不對、code 裡多了一個 secondary button。設計師讓 agent 用 generate_figma_design 工具把 coded 版本「重畫」成一個 Figma frame，放在原 design 旁邊，標註出每個差異點。產出的東西像設計師跟工程師對齊用的共用 reference，走的是設計討論流程，不會被丟進 bug ticket 裡 — 設計師可以針對每個改動問：「這個 secondary button 是優化還是疏忽？要 design 改、code 改、還是中間取折衷？」對話從追究改成共同決策。

所有狀態跑過一輪後，設計師注意到 export success 畫面只是純功能性 —「Export complete. View file.」結束。能用，但 Astra 的品牌精神是「easy + fun to use」，匯出完成的瞬間應該是個值得慶祝的 brand moment。

工程師快速做了一個「render 完播放預覽 clip」的 playful transition，把關鍵 keyframe 從 code 送到 canvas。設計師接手 explore 三個方向：bold expressive 一版、minimal elegant 一版、unexpected delightful 一版。三個方向不到一小時跑完，沒有任何一個綁進 token 或 commit 進 code。設計師最後挑了 bold expressive，這時才往設計系統走 — 拆 token、拆 component、寫 spec。

Brett 用這段對比 canvas 跟 code 的本質差異：「In code, every direction is an engineering investment. Hard to throw away, easy to settle on 'good enough.' On the canvas, ideas stay cheap.」canvas 適合便宜地丟想法，code 適合把選定的想法穩穩做出來，兩邊各司其職。

Brett 在文末提出整個工作流真正的轉變 — source of truth 的概念變了。

過去團隊講 source of truth，總是指向一個 artifact：canvas、codebase、PRD 三選一。但只要團隊跑得夠快，三者必然會 diverge。Figma MCP server 端出來的解法走另一條路：讓三個 artifact 互相寫得進對方 — canvas 寫 code、code 寫回 canvas、設計師的判斷在兩端來回流動。Source of truth 從一個檔案，變成一個會呼吸的連結系統。

對轉職中的設計師來說，這篇文真正的重點落在 design–dev 協作的心智模型。工具細節（use_figma、generate_figma_design）會改、會被取代，但模型一旦建立就能持續用：spec 從設計師單向交付給工程師的東西，變成持續長大的共用畫面；canvas 變成一個會跟著 build 一起更新的「設計現場」。誰能掌握這個現場，誰就能在 AI 加速 ship 的時代繼續做設計決策。

Figma 從去年開始把 MCP server 當成主軸推，從「Agents, meet the Figma canvas」、「TL;DR on MCP」一路到這篇 Workflow Lab，論述愈來愈具體 — agent 在中間翻譯，設計師判斷在兩端決策。這條路線的關鍵在於它把「設計師看不見 build 的狀態」這個老問題端上檯面，逼整個產業面對。以前團隊只能靠流程跟個人勤勞補這個洞，現在 agent 可以把它自動化補起來。

對學 Figma 的人，這篇文最大的訊號落在基本功上。component、variables、Auto Layout、design system 這些東西，是 agent 能不能正確 generate frame 的前提 — agent 需要 design system 當參考才能畫出可編輯的 frame，不然只能生出無法維護的 raw layer。MCP 時代會放大「會用 Figma 當底層思考工具」的人的優勢，也會放大不會用的人的劣勢。基本功還沒練的人，現在補起來剛好。