Figma Make 接到 codebase：選元件改 padding，commit 打進你 git branch

Figma Make 過去長得像高級 prototype tool——你描述一個畫面，它生一份 React 出來給你看，看完關掉、回畫布上重畫。這版改了一個前提：Make 接上你 team 真正用的那份 codebase。

意思是這樣：打開 Make 的 desktop beta，連到公司 GitHub 上那個 production repo，把畫面拉出來。選一個 div、把 padding 從 12 拖到 16、把按鈕文字從 "Save" 改成 "Apply"——agent 找對應的 React component，改的是真 source。改完不會直接上線，改動躺在你本地 commit 裡，要不要開 PR、什麼時候 push 到 main，跟工程同事手動操作一樣，由你決定。

寫這篇的 Iris Lin（product designer）跟 Jesse Lumarie（software engineer），把「設計師到底要不要碰 code」的爭論直接跳過，給了一句：「Design vs code is a false dichotomy。」工具不該逼你二選一，該讓你在每個當下選對的那一層。

Iris 跟 Jesse 開場拋了一個比喻：今天寫 code 的處境，很像十年前做設計的處境。Figma 剛出現之前，design 是離線、單人、檔案來回 email 的工作。今天 code 也卡在類似的狀態——很多人用 agent 寫 code，前線模型輸出的品質一天天往上跑，但你工作的環境還停在 2016：IDE、終端機、Slack 截圖貼 diff。「對很多人來說，IDE 跟 terminal 從來不是『家』。」這是他們的原話。

文章把 Figma 的角色講得很直白：「You should be free to use the best tool for what's needed。」設計畫布、prototype playground、production code——三個本來綁在三套工具上的場景，這次合進同一個視窗。Make 處理的範圍很精準：「我要改一個按鈕的 padding」從「開 IDE、找檔案、敲 className」變成「在畫面上選一下、滑桿拉一下、commit 自動生」。

下面四節，照官方文章順序走，每節挑你能立刻判斷怎麼用的點來講。

Direct edit 是這版最具象的功能。連上 codebase 之後，Make 拉出你的畫面，每個元件都是可選的——不像看截圖那樣只能凝視，而是當成 Figma 一樣可以點、可以拖。選一個 button，改 background、改 padding、改字級、改 layout——agent 在後台找到那個 button 對應的 React component，編輯該檔案，畫面當下就反映改動。

文章把這條路的判斷準則寫得很乾脆：「Use direct edits for changes you know you want to make。」你心裡知道要動哪一個 token、哪一個尺寸——這條路最快。

Annotations 走另一條路：要改的是行為而非屬性——modal 打開有 fade-in、列表 hover 要 highlight、step 1 完成後要 expand 出 step 2——這些拖滑桿表達不了。Annotations 讓你在畫面上圈一塊區域，旁邊寫一段描述：「點這個 button 之後，這三個 card 一起往上滑、上方出現 toast。」Agent 把畫面上下文、被圈住的元素、你寫的描述一起讀，把 interaction logic 寫進 code。Iris 跟 Jesse 的原話：「Annotations give the agent contextual information, and can reference many elements at once。」"reference many elements" 是關鍵——你用一條描述就能涵蓋多個畫面上的點，不必拆成五個 prompt。

這節最值得設計師看——它回答「設計師改 code 怎麼不變成黑天鵝事件」這個問題。原話：「Shipping production code should happen intentionally, through your team's development process。」這版 Make 把「動 code 的入口」搬進你習慣的工具裡，git 那一層的紀律完全照舊。

你在 Make 裡改的東西，全部以 local commit 形式存在你本地 branch 上，沒開 PR 之前完全沒上到 main。Branch、revert commit、看 commit history 這些 git 基本操作 Make 都支援——engineering team 看到的，就是「有個設計師開了一個 branch、推了幾個 commit、發了一個 PR」。Review 流程跟工程師自己寫的 PR 一樣。

對設計師的意義：你能改 production 的 code，但有 git 這層 safety net 在。改錯了 revert、方向錯就丟那條 branch、想試三個方向就開三條 branch——這些操作在 Make 裡都點得到。

這部分把 Make 跟 Figma Design canvas 串起來。情境：你在 Make 改了畫面，想拿給整個 design team review——但 review 平台在 Figma Design，大家習慣在那邊留 comment、riff variation。原本這條路是「截圖貼回 Figma」，現在改成：在 Make 裡複製整個 screen、page、或 component，回到 Figma canvas 貼上——貼進去是 layers，可以選、可以改、可以開新 frame 試變體。團隊決定後，Figma 偵測到 design 那邊的更新，提示你帶回 Make，agent 套回 code。

文章措辭很直接：「The canvas and the codebase, in the same place。」這個迴圈成立的話，design 的議題（aesthetic、layout、整體感）跟 code 的議題（real data 跑起來會壞、互動條件、performance）之間，可以選當下需要的那一層解。原話更狠：「There's no right place to start。」題目是什麼，就從哪邊開始。

文章還順帶點到一個小段：share branch 可以分享給 teammate——對方拿到 branch 後 check out、看你改了什麼、從那邊接著做。分享的單位從 design file 進化成 git branch，這對 designer–developer 協作是另一個轉折。

原文用一個「Make note」框出來：beta 的範圍很窄，幾個前提要先看清楚。

平台： Mac desktop only。Beta 桌機版才有，Windows、瀏覽器版這次都沒到。要從 figma.com 下載 Beta desktop app（跟一般 desktop app 不同）。

權限： 你必須先有公司 codebase 的存取權。Iris 跟 Jesse 的原話翻過來是「這版 best suited for 已經有 codebase access 的設計師」。設定流程之後會再簡化，這版先服務「已經能 clone 公司 repo」的人。

Pricing： beta 期間「won't consume credits during beta」，AI credits 價格之後公布。

範圍： direct editing、annotations、chat、PR creation 都包含在這次 limited beta 裡。要 sign up 等選中才會收到 email，waitlist 不保證入選。

這幾個前提加起來，目標客群清楚：在已經有 codebase 跟設計系統的公司裡，設計師想往 code 那一端再走一段。學生跟剛轉職的人短期內接觸不到——但方向值得記在心裡。

這版 Make 拿掉的東西很具體：設計師到 production 的距離。過去要動一行 padding，你的選項是 Slack 截圖、Linear 開票、等下個 sprint。這版讓你直接在畫面上拖一下，commit 進你自己 branch、PR 開不開你決定。中間的 traffic（票、流程、等待）被收掉。

對 Figma 自己的定位也是訊號。原本 Make 像「比 prototype 更具體的 prototype 工具」，這版把腳踩進 production code。Figma 從一個 design tool 變成「design + prototype + code 都在這裡」的 platform——「The whole point of Figma as a platform is to give you access to the right tool at the right moment。」

對設計師個人的意義分兩段：已經在 ship product 的人，下一輪 review 可能會多一個欄位叫「branch 名字」；還在學的人，Figma 的元件思維、design system 的結構、git 的最基本三招（branch / commit / revert），是接下來幾年最該打底的。剩下的 agent 會幫你做。