Figma Make 現在能改你的 production code：5/28 發佈的本機程式碼 beta 解析

AI TOOLS · 2026 · MAY 28

▲ Figma Make 在 production code 上做直接編輯，左下角的 Apply 按鈕負責把修改推回 codebase。圖／Figma 官方

CHAPTER 01 · WHAT IS IT

Figma 這週把 Make 的天花板拆了

5 月 28 日凌晨，Figma 官方發了一篇部落格，標題寫 Figma Make, now on your local code。看起來只是個 beta 公告，但對設計圈的意義比表面大。

過去 Figma Make 是個生原型的沙盒。你 prompt 一段話，它生出可互動的 React 雛形，但跑的是它自己的環境，跟你公司的 codebase 完全沒關係。這次的更新把這層牆拆了——Make 現在能連到你的 GitHub repo，把你真實的 production code 拉進來跑，然後讓設計師直接在 UI 上動手。

改完一段 padding、換完一個字型、調完一個顏色，這些變動會由 AI agent 找到對應的程式碼修掉，存成 local commit。你想 ship 的時候，從 Make 介面開 branch、發 PR，工程團隊在 GitHub 上看到一個跟其他 PR 沒兩樣的東西，照原本流程 review。

換句話說，設計師多了一條官方加持的 production code commit path，而且全程不用碰 terminal。

CHAPTER 02 · WHY IT MATTERS

這次比過往幾次 Make 更新都關鍵

過去一年 Figma Make 改過很多東西。3 月加 Make Kits 讓你接設計系統，4 月加 attachments 讓你丟 PRD 跟 CSV，5 月初放出 custom skills 讓你寫 markdown 指令。這些都很實用，但本質都還停在「Make 怎麼生得更準」的層級。

這次的轉變不一樣。Figma 不再只是把生成端做得更好，而是把輸出端接上了真實世界。沙盒裡跑得多漂亮都是別人家的事；當你的修改能變成 PR 出現在公司 repo 裡，這件事的性質就完全變了。

我自己第一個反應是，這跟去年 Figma 在 Config 把 Make 公開那次的訊息量是同一級的。差別在那時 Figma 說的是「設計師可以做出可互動的東西了」，這次說的是「設計師可以 ship UI 改動了」。前者是新玩具，後者是工作邊界的位移。

官方在文章裡引了一句很狠的話：「IDE 跟 terminal 對很多人來說根本不像家。」這句話的潛台詞是，過去十年設計師一直被推著去學 IDE，但其實該被推著走的是工具本身。Figma 這次的動作就是要把「家」搬到設計師熟悉的介面裡，code 在後面跑，設計師繼續看著 UI 工作。

CHAPTER 03 · HOW IT WORKS

三種改法，覆蓋從像素到互動

這次 beta 給了三條動 code 的路徑，依需要的精確度由細到粗排：

▲ 直接編輯模式：選一個元素，旁邊跳出屬性面板，改完 agent 自動找 code 修。圖／Figma 官方

三種模式之間沒有牆。實際用起來大概是：先用 chat 跑一個大方向，再用標註指出「這塊要做 hover 效果」，最後用直接編輯把 spacing 拉到剛剛好。一條工作流走完，PR 開出去。

背後的 Git 流程也整個搬進 Make 介面。Branch 從 Make 開、commit 在 Make 裡跑、PR 從 Make 直接發到 GitHub，整段過程 terminal 不用打開。每次 prompt 改了 code 都會自動存成 local commit，可以回頭看歷史，這點跟 Cursor 的 checkpoint 邏輯類似。

還有一個容易被忽略的點：Make 跟 Figma Design 之間可以雙向 paste。你在 Make 改出來的畫面，可以複製貼進 Figma Design 當圖層用，給團隊評論；對方在 Design 裡的修改，Make 又能讀回來套用到 code 上。Figma 把這個叫 close the loop，畫布跟程式碼在同一個地方。

CHAPTER 04 · GETTING STARTED

怎麼拿到 beta 名額

這次是 closed beta，沒有「下載就能用」這種好事。流程大概是這樣：

Beta 期間最甜的一點：Figma 明說不會吃 AI credit。考慮到 Make 平常生一個畫面動輒幾百個 credit，這段時間等於免費讓你壓榨它的能耐。GA 之後會公布定價，但目前還沒消息。

CHAPTER 05 · IN PRACTICE

設計師實際能拿來幹嘛

講白話一點，這東西最直接的場景是「設計師自己 ship UI 微調」。你在設計稿改了 8px 的 padding、把按鈕 radius 從 8 拉到 12、把錯誤訊息的紅色從 #E53 換成 #DC2626，這些改動過去要寫成設計交付規格、丟給工程師、等下個 sprint 才會出現在 production。現在你能在 Figma Make 裡選元素、改完、開 PR、給工程師 review、merge。整段時間從幾天壓到幾分鐘。

對工程師團隊，這代表 UI 微調的 ownership 開始往設計這邊滑。過去設計師會說「這個 padding 不對」，工程師回「下週改」，然後雙方都很煩。現在設計師自己 commit、自己 PR，工程師只負責 review。Code review 還在工程那邊，但「動手改」這件事的入口換人了。

對個人 side project 或 indie maker，這條路徑更乾淨——自己改、自己 PR、自己 merge，連協作流程都跳過。我自己腦袋裡馬上想到的應用是維護 landing page 跟簡單的 dashboard：那些不是核心功能但每週都要動兩三下的東西，最適合走這條。

另一個我覺得會被低估的用法：互動效果的快速 prototype。過去 motion／hover／transition 的設計很難交付，你錄個 mov 給工程師看，他做出來八成走味。現在你能直接標註「這個 card hover 時往上浮 4px、加 shadow、180ms ease-out」，agent 幫你寫進 production code，你看到的就是用戶會看到的。互動設計師的痛點被打到了。

CHAPTER 06 · LIMITS

三個你該先知道的眉角

官方文章在尾巴埋了一句話：「目前比較適合已經拿到公司 codebase 存取權的設計師。」翻譯一下：這不是給「完全不會 code」的人用的。你還是要懂 Git 基礎、要知道 branch／commit／PR 是什麼、要能跟工程團隊溝通 review 流程。Figma 把 terminal 拿走了，但沒把版本控制的思維拿走。

第二個眉角是 one-way sync。我看了幾家國外開發者部落格的拆解，這個風險很真實——目前的同步是單向的，code 只從 Make 流向 GitHub，反過來不會。意思是說，如果工程師同時在 IDE 裡改了一段 code，然後你從 Make push 你的版本上去，他的改動會被覆蓋。團隊裡如果工程師也會碰前端 code 的，要先說好 ownership 怎麼切。

第三個是平台限制。目前只支援 Mac 的 Beta desktop app，Windows 跟 Linux 還沒消息。Git 提供者方面，GitHub 是原生支援、能完整 push 跟開 PR；GitLab 跟 Bitbucket 只能透過 SSH 部分支援，push 可以但 PR 創建在 Make 裡做不了，要自己回提供者介面開。企業若用 corporate-approved browser 或 hardware key 做認證的，可能直接卡在登入這關。

CHAPTER 07 · COMPARED TO

跟 Cursor、v0、Stitch 比起來

設計轉 code 這塊現在很擠。Anthropic 把 Claude Code 推進設計流程、Cursor 跟 VS Code 加 Figma MCP、v0 從零生 React 元件、Google Stitch 把設計灌進 coding agent。每家都在搶同一塊地。

Figma 的差異化我看下來是兩件事。第一是 PR workflow 完整保留。Cursor／Copilot 是工程師在 IDE 裡跟 AI 對話、改完直接 push；v0 給你新 component 但跟你 repo 還沒有關係；Figma Make 走的是設計師→PR→engineering review 這條最像現實團隊運作的路。對有 compliance、有 security review、有「我們要能 audit 每一行 code 從哪來」需求的公司，這條路才能進公司流程。

第二是設計畫布跟 code 雙向同步。其他工具都是單方向——要嘛從設計生 code（v0、Make 過去版本），要嘛從 code 生設計（Claude Code to Figma 的功能）。Figma 這次想做的是 Make 跟 Figma Design 之間左右滑動，整個工作流不出 Figma。短時間內這還是它最大的護城河。

當然，這也代表你越深用 Figma 生態，越難搬家。Figma 收編 Adobe 那場交易破局之後，我自己一直覺得 Figma 接下來的策略就是這個——把所有「圍繞設計」的工作都做進去，讓你沒有理由再開別的工具。Make 接 production code 是這個策略的最新一塊拼圖。

官方介紹影片

▲ Figma 官方 5/28 發佈的 Figma Make, now on your local code 公告影片，完整展示三種編輯模式跟 Git 流程。

CHAPTER 08 · TAKEAWAYS

設計師的邊界又往前推了一寸

這幾年問我「設計師到底要不要學寫 code」的人沒少過。我以前的標準答案是：學會看 code、能跟工程師對話、知道 token 跟 component 的概念就夠了。現在這個答案要改。

不是「設計師都要變成全端工程師」，而是 Git 這層基礎能力要拉起來。Branch、commit、PR、merge conflict 怎麼解——這些過去是工程師領域的詞彙，現在會變成設計師工具列的一部分。Figma Make 接 production code 把 terminal 拿走了，但你的職涯履歷上要不要寫得進「能獨立提交 UI 改動 PR」，看你接下來這一年。

對教學端，我自己也在思考接下來課程要不要納入這塊。半年前我會說 Git 對設計師是 nice-to-have，現在它正在變成 must-have。AI 工具把工程的執行門檻拉低了，但工程的思維結構反而變得更重要——你不能再把 version control、environment、deploy pipeline 當成「工程師的事」。

Figma 這次的動作不是一個產品功能，是一個信號。設計師跟工程師之間那道牆——過去十年大家都在試著打通它——這次又被推倒了一片。下一片牆會是什麼，我蠻好奇。

延伸閱讀

常見問題

Q：Figma Make 接 local code 跟 Cursor 寫 code 有什麼差別？

Cursor 是工程師導向的工具，設計師要進去要會基本的 IDE 操作。Figma Make 接 local code 是設計師導向，你在 UI 上點選元素改屬性，agent 幫你找到對應 code 改掉，全程不用看到 terminal。兩者解決的是同一件事的不同入口。

Q：完全不會 code 也能用嗎？

官方說目前比較適合已經有 codebase 存取權的設計師。你不用會寫 React，但要懂 Git 基礎概念（branch、commit、PR）、要能跟工程團隊溝通 review 流程。完全沒接觸過版本控制的話，會卡在 step 0。

Q：Windows 用戶有救嗎？

目前 beta 只支援 Mac 的 Figma Beta desktop app。官方說「之後會擴展到其他平台」但沒給時程。Windows 用戶現在能做的是先填 waitlist 等通知。

Q：GitLab 跟 Bitbucket 能用嗎？

部分支援。可以透過 SSH clone repo、可以 push branch，但 PR 創建在 Make 介面裡做不了，要回 GitLab／Bitbucket 自己開。GitHub 是 closed beta 唯一原生支援的 provider。

Q：Beta 期間真的不收 credit？

是。Figma 明說 beta 期間 direct editing、annotations、chat、PR creation 這些新功能都不消耗 credit。GA 之後會公布 AI credit 定價，但目前沒消息。如果你拿到名額，這段時間值得用力測試。

Q：對設計團隊跟工程團隊的關係會有什麼影響？

UI 微調的 ownership 會往設計這邊滑。過去設計師交付規格、工程師執行；現在設計師可以直接 commit。但 code review 還在工程那邊，所以這不是「工程被取代」，而是「設計能直接動手」的版本。團隊裡建議事先講好哪些區塊設計師有完整 ownership、哪些還是工程師主導，避免覆蓋衝突。

Q：跟 Figma 的 Code Connect、MCP server 有什麼關係？

那兩個是讓外部 AI 工具（Cursor、Claude Code、Codex）能讀到 Figma 設計檔當 context。這次的 local code 功能反過來——把 Figma 變成能動 production code 的客戶端。同一條策略線的兩端，一端進來、一端出去。

SUBSCRIPTION · AIWAKEN

AI 覺醒設計應用攻略

AI 工具每週都在更新，我幫你過濾雜訊，只整理對設計師真正有用的應用。

✦ AI 工具實測與工作流

✦ 設計師角度 Prompt 技巧

✦ 每週 AI × 設計新知

了解訂閱方案 →