1. 為什么設(shè)計稿與代碼之間總有一道人工翻譯的墻做前端或者全棧的朋友大概都有過這種體驗產(chǎn)品經(jīng)理甩過來一個設(shè)計稿鏈接說“就按這個做”然后你打開一看圖層命名全是 Frame 427、Rectangle 18、Group 233光是理清哪個圖層對應(yīng)哪個組件就要花掉小半天。更別提改稿階段設(shè)計側(cè)微調(diào)了一個間距、換了一個圓角你這邊得手動去代碼里翻對應(yīng)的樣式改完還要截圖比對來回確認。這個過程中最耗時的不是寫代碼本身而是“人肉解析設(shè)計稿”這個環(huán)節(jié)。Figma 作為目前主流的界面設(shè)計工具本身提供了插件體系和 REST API理論上可以讓機器直接讀取設(shè)計稿的結(jié)構(gòu)化數(shù)據(jù)。但現(xiàn)實情況是很多團隊用的免費版賬號在 API 調(diào)用上有額度限制或者干脆沒有開放某些接口權(quán)限。于是就有了一個很實際的需求能不能在不購買付費套餐的前提下讓本地的 AI Agent 直接讀懂 Figma 設(shè)計稿甚至反過來修改它Local Figma Agent MCP 就是沖著這個場景來的。它本質(zhì)上是一個運行在本地的 MCP 服務(wù)通過 Figma 桌面端提供的插件運行環(huán)境把設(shè)計稿的節(jié)點樹、樣式屬性、組件信息暴露給本地的 Agent 進程。Agent 拿到這些結(jié)構(gòu)化數(shù)據(jù)之后就可以做代碼生成、樣式比對、批量重命名、甚至反向修改設(shè)計稿的操作。整個過程不依賴 Figma 的云端付費 API走的是本地插件通道所以免費賬號也能跑通。這篇文章適合三類人看一是前端開發(fā)者想減少設(shè)計稿到代碼的手動翻譯成本二是設(shè)計系統(tǒng)維護者需要批量處理圖層命名和組件規(guī)范三是對 MCP 協(xié)議和 Agent 工具鏈感興趣的工程師想了解本地 Agent 如何與設(shè)計工具打通。我會從原理、環(huán)境搭建、核心操作、踩坑經(jīng)驗幾個維度展開盡量把每個環(huán)節(jié)的“為什么”講清楚讓你看完能直接上手復(fù)現(xiàn)。2. Local Figma Agent MCP 到底在做什么拆解本地插件通道的工作機制2.1 MCP 協(xié)議在這里扮演什么角色MCP 全稱 Model Context Protocol你可以把它理解成一套“Agent 和外部工具之間的通用插頭標準”。在沒有這套標準之前Agent 想調(diào)用一個外部能力得針對每個工具單獨寫適配代碼今天接 Figma 寫一套明天接數(shù)據(jù)庫又寫一套維護成本很高。MCP 的思路是定義統(tǒng)一的通信格式Agent 側(cè)作為客戶端工具側(cè)作為服務(wù)端雙方通過標準化的請求和響應(yīng)來交互。Local Figma Agent MCP 就是把這個服務(wù)端跑在本地。它啟動之后會監(jiān)聽一個本地端口Agent 通過這個端口發(fā)送指令比如“獲取當前選中節(jié)點的屬性”“列出所有文本圖層的字體信息”“把某個節(jié)點的填充色改成指定值”。服務(wù)端收到指令后轉(zhuǎn)譯成 Figma 插件 API 能理解的調(diào)用執(zhí)行完再把結(jié)果回傳給 Agent。整個鏈路都在本機完成不經(jīng)過外部服務(wù)器所以響應(yīng)速度快也不受賬號套餐的 API 額度限制。這里有個關(guān)鍵點需要理解Figma 插件 API 和 Figma REST API 是兩套不同的東西。REST API 是走網(wǎng)絡(luò)的受套餐和權(quán)限約束插件 API 是運行在 Figma 桌面端或瀏覽器端插件沙箱里的只要插件被加載就能訪問當前文檔的節(jié)點樹。Local Figma Agent MCP 走的是后者所以才能繞開付費限制。當然這也意味著它只能操作“當前打開的那個文檔”沒法在后臺批量處理一堆文件這是它的能力邊界。2.2 本地插件通道的數(shù)據(jù)流轉(zhuǎn)過程把整個數(shù)據(jù)流轉(zhuǎn)拆開看大概是這么幾步。第一步你在 Figma 桌面端加載 Local Figma Agent MCP 對應(yīng)的插件插件啟動后會建立一個本地通信通道通常是一個 WebSocket 或者本地 HTTP 服務(wù)。第二步你在本地啟動 Agent 進程它作為 MCP 客戶端去連接這個通道。第三步Agent 發(fā)送指令插件在 Figma 沙箱內(nèi)執(zhí)行對應(yīng)的 API 調(diào)用拿到節(jié)點數(shù)據(jù)。第四步數(shù)據(jù)經(jīng)過序列化后回傳給 AgentAgent 再決定下一步做什么。這個過程中最容易被忽略的是“節(jié)點樹的序列化”。Figma 的節(jié)點樹可能非常深一個頁面里嵌套幾十層 Group 是常事。如果一次性把整棵樹拉過來數(shù)據(jù)量會很大Agent 處理起來也慢。所以實際使用中通常的做法是先拉頂層節(jié)點按需展開。比如先獲取當前選中的節(jié)點或者按名稱過濾出特定類型的節(jié)點再逐層深入。這個策略和爬蟲的“按需抓取”是一個道理避免一次性加載過多無用數(shù)據(jù)。另一個細節(jié)是樣式屬性的讀取。Figma 里一個矩形的填充可能來自樣式庫、可能來自本地樣式、也可能是直接設(shè)置的色值。插件 API 能區(qū)分這些來源但 Agent 拿到數(shù)據(jù)后需要自己判斷優(yōu)先級。比如做代碼生成時如果填充來自共享樣式那生成的代碼應(yīng)該引用對應(yīng)的設(shè)計令牌而不是硬編碼色值。這個判斷邏輯需要在 Agent 側(cè)實現(xiàn)MCP 服務(wù)本身只負責把原始數(shù)據(jù)吐出來。2.3 不買付費套餐能用到什么程度免費賬號在 Figma 里的限制主要是協(xié)作人數(shù)、版本歷史和部分云端 API 額度。Local Figma Agent MCP 走本地插件通道所以協(xié)作和版本歷史這些限制不影響它。它能做的事情包括讀取當前文檔的完整節(jié)點樹、讀取和修改節(jié)點屬性、創(chuàng)建和刪除節(jié)點、批量重命名、導出節(jié)點為圖片或 SVG?；旧喜寮?API 能做的它都能通過 Agent 來觸發(fā)。做不到的事情也要說清楚它沒法訪問你沒有打開的文件沒法跨文件批量操作沒法讀取團隊庫的完整元數(shù)據(jù)部分庫信息在插件 API 里是受限的。所以如果你的需求是“每天晚上自動掃描團隊所有設(shè)計稿并生成報告”那這個方案不合適還是得走云端 API。但如果你的需求是“在當前打開的設(shè)計稿里讓 Agent 幫我批量改圖層名、提取樣式、生成組件代碼”那它完全夠用。3. 從零搭起本地 Agent 與 Figma 的通信鏈路3.1 環(huán)境準備別急著裝插件先把這幾樣確認好動手之前先把基礎(chǔ)環(huán)境理清楚。你需要的東西不多但每一樣都有坑。首先是 Figma 桌面端注意是桌面端不是瀏覽器端。雖然瀏覽器端也能跑插件但本地通信通道在桌面端更穩(wěn)定而且桌面端對本地文件系統(tǒng)的訪問權(quán)限更寬松后續(xù)如果要導出文件會方便很多。版本方面建議保持最新老版本插件 API 可能有差異。然后是 Node.js 環(huán)境。Local Figma Agent MCP 的服務(wù)端和插件構(gòu)建腳本通常依賴 Node 工具鏈建議用 LTS 版本別用太新的實驗版避免依賴包兼容問題。裝完之后確認 npm 或 pnpm 能正常工作。如果你習慣用 yarn 也行但要注意鎖文件的一致性別混用。第三樣是 Agent 運行環(huán)境。這個取決于你用哪個 Agent 框架有的用 Python有的用 Node。關(guān)鍵是確認你的 Agent 支持 MCP 客戶端功能。如果不支持就得自己寫一層適配把 MCP 的請求格式轉(zhuǎn)成 Agent 能理解的工具調(diào)用格式。這一步是很多人在搭建時卡住的地方因為文檔里往往默認你已經(jīng)有一個支持 MCP 的 Agent 了。最后確認一下端口占用情況。本地 MCP 服務(wù)通常會監(jiān)聽一個固定端口比如 3000 或者 8080 附近的某個值。如果這個端口被其他服務(wù)占了啟動時會報錯。建議提前用命令行查一下端口占用或者直接在配置里改成一個不常用的端口省得后面排查。3.2 插件側(cè)的加載與調(diào)試為什么你的插件面板是空的插件加載這一步最常見的現(xiàn)象是“面板打開了但一片空白”或者“提示連接失敗”。先說空白的情況。這通常是因為插件的 UI 線程和主線程通信出了問題。Figma 插件分兩部分一部分是運行在沙箱里的主邏輯能訪問 Figma API另一部分是 UI 面板運行在 iframe 里負責展示界面。兩者通過 postMessage 通信。如果 UI 面板加載了但沒收到主邏輯的數(shù)據(jù)就會空白。排查方法是打開 Figma 的插件開發(fā)控制臺看有沒有報錯。常見錯誤包括UI 的 HTML 文件路徑寫錯了、構(gòu)建產(chǎn)物沒有正確輸出、或者跨域限制導致 iframe 里的腳本加載失敗。如果是用構(gòu)建工具打包的確認一下輸出目錄和插件 manifest 里配置的路徑是否一致。這個坑我踩過好幾次每次都是路徑問題。連接失敗的情況多半是本地 MCP 服務(wù)沒啟動或者端口對不上。插件側(cè)一般會有一個配置項讓你填本地服務(wù)的地址和端口確認這個配置和服務(wù)端實際監(jiān)聽的一致。另外注意有些系統(tǒng)對本地回環(huán)地址的訪問有額外限制如果填的是 localhost 不通可以試試換成 127.0.0.1反過來也一樣。這個細節(jié)很小但確實會卡住人。3.3 Agent 側(cè)的配置把 MCP 服務(wù)注冊成可用工具Agent 側(cè)要做的核心事情是把 Local Figma Agent MCP 注冊成一個可調(diào)用的工具。不同 Agent 框架的注冊方式不一樣但思路是相通的你需要告訴 Agent“有一個叫 figma-local 的工具它的能力描述是什么怎么連接它”。能力描述很重要它決定了 Agent 在什么情況下會主動調(diào)用這個工具。描述寫得太模糊Agent 可能該調(diào)用的時候不調(diào)用寫得太寬泛又可能在不相關(guān)的場景下亂調(diào)用。一個實用的做法是在工具描述里明確列出幾個典型操作比如“讀取當前選中節(jié)點的屬性”“按名稱查找節(jié)點”“修改節(jié)點填充色”“批量重命名圖層”。這樣 Agent 在遇到類似需求時更容易匹配到這個工具。同時在 Agent 的系統(tǒng)提示里也可以加一句引導比如“當用戶提到設(shè)計稿、Figma、圖層、組件時優(yōu)先考慮使用 figma-local 工具”。這種引導不是必須的但實測能明顯提升調(diào)用準確率。配置完成后先做一個最簡單的連通性測試讓 Agent 調(diào)用工具獲取當前選中節(jié)點的名稱。如果返回了正確的名稱說明鏈路通了。如果報錯根據(jù)錯誤信息逐段排查是 Agent 沒找到工具還是工具連不上服務(wù)還是服務(wù)連不上插件。分段定位比整體調(diào)試效率高得多。4. 讓 Agent 真正讀懂設(shè)計稿節(jié)點解析與語義提取的實操細節(jié)4.1 節(jié)點樹的讀取策略一次性拉取還是按需展開前面提到過節(jié)點樹可能很深一次性拉取不現(xiàn)實。實際操作用的是“分層讀取”策略。第一步獲取當前頁面的頂層節(jié)點列表通常數(shù)量不多幾十個以內(nèi)。第二步根據(jù) Agent 的任務(wù)目標決定展開哪些子樹。比如任務(wù)是“找出所有按鈕組件”那就按名稱或類型過濾只展開可能是按鈕的節(jié)點。第三步對目標節(jié)點讀取詳細屬性包括尺寸、位置、填充、描邊、圓角、字體等。這個策略的好處是數(shù)據(jù)量可控Agent 的處理速度快。壞處是需要多輪交互如果 Agent 的規(guī)劃能力不強可能會漏掉一些節(jié)點。為了減少遺漏可以在工具側(cè)提供一個“遞歸查找”的接口讓 Agent 指定一個過濾條件服務(wù)端在 Figma 沙箱內(nèi)遞歸遍歷只返回匹配的節(jié)點。這樣把遍歷邏輯放在服務(wù)端Agent 只需要發(fā)一次請求效率更高。過濾條件的寫法很關(guān)鍵。Figma 節(jié)點有 type 屬性比如 FRAME、TEXT、RECTANGLE、COMPONENT、INSTANCE 等。按 type 過濾是最常用的。另外還可以按 name 做模糊匹配按是否可見過濾按是否有特定插件數(shù)據(jù)過濾。組合使用這些條件能比較精準地定位到目標節(jié)點。我一般會建議在工具描述里把這些過濾能力寫清楚方便 Agent 自己組合。4.2 樣式信息的語義化從原始屬性到設(shè)計令牌拿到節(jié)點的原始屬性只是第一步真正有價值的是把這些屬性語義化。舉個例子一個矩形的填充色是 #1A73E8這是原始數(shù)據(jù)。但如果這個色值來自一個叫“Primary/Blue/500”的共享樣式那語義就是“主色藍 500”。Agent 在做代碼生成時應(yīng)該優(yōu)先使用語義化的設(shè)計令牌而不是硬編碼色值。這樣后續(xù)設(shè)計令牌變更時代碼只需要改一處。實現(xiàn)這個語義化需要在讀取節(jié)點屬性時同時讀取它引用的樣式 ID然后再去樣式表里查這個 ID 對應(yīng)的名稱。Figma 插件 API 提供了獲取本地樣式和共享樣式的方法。需要注意的是共享樣式的讀取在某些權(quán)限下可能受限如果讀不到就退而求其次用本地樣式或者直接用原始值加一個標記提示 Agent 這里可能需要人工確認。字體信息也是類似的處理。一個文本節(jié)點的字體可能是“Inter Regular 14px”但設(shè)計系統(tǒng)里可能定義的是“Body/Regular”這樣的令牌。Agent 需要根據(jù)字體名稱、字重、字號去匹配設(shè)計令牌表。這個匹配邏輯可以放在 Agent 側(cè)也可以放在 MCP 服務(wù)側(cè)提供一個“解析樣式令牌”的工具。放在服務(wù)側(cè)的好處是復(fù)用性強多個 Agent 都能用放在 Agent 側(cè)的好處是靈活可以根據(jù)不同項目的令牌規(guī)范調(diào)整。4.3 組件與實例的識別區(qū)分主組件和派生實例Figma 里組件和實例的關(guān)系類似于面向?qū)ο罄锏念惡蛯ο?。主組件定義結(jié)構(gòu)和默認樣式實例繼承主組件但可以覆蓋部分屬性。Agent 在處理設(shè)計稿時必須能區(qū)分這兩者否則生成的代碼會出問題。比如一個按鈕的主組件改了圓角所有實例都會跟著變但如果某個實例單獨覆蓋了圓角那它就不受主組件影響。讀取節(jié)點時INSTANCE 類型的節(jié)點會有一個 componentId 指向主組件。Agent 可以通過這個 ID 去獲取主組件的屬性然后對比實例的覆蓋屬性判斷哪些是繼承的、哪些是覆蓋的。這個信息對代碼生成很重要繼承的屬性可以抽成公共樣式覆蓋的屬性需要單獨處理。如果 Agent 不區(qū)分這些生成的代碼就會把所有屬性都寫死失去組件化的意義。另外組件的命名規(guī)范也影響 Agent 的理解。如果主組件叫“Button/Primary/Large”Agent 很容易推斷出這是一個大號主按鈕。如果叫“Frame 427”那就只能靠屬性推斷準確率會下降。所以我在實際項目中會建議設(shè)計側(cè)盡量規(guī)范命名這不僅對人友好對 Agent 也友好。如果命名已經(jīng)亂了可以先讓 Agent 做一輪批量重命名把命名規(guī)范起來再去做后續(xù)的代碼生成。5. 反向操作讓 Agent 修改設(shè)計稿的邊界與注意事項5.1 哪些修改是安全的哪些容易出問題讓 Agent 修改設(shè)計稿聽起來很美好但實際操作中要區(qū)分場景。安全的修改包括批量重命名圖層、統(tǒng)一修改填充色或描邊色、調(diào)整間距和圓角、替換文本內(nèi)容、顯示或隱藏特定圖層。這些操作的影響范圍明確出錯了也容易回滾。不安全的修改包括刪除節(jié)點、改變節(jié)點層級結(jié)構(gòu)、替換主組件、修改自動布局的關(guān)鍵參數(shù)。這些操作一旦出錯可能破壞整個設(shè)計稿的結(jié)構(gòu)恢復(fù)起來很麻煩。我的建議是在讓 Agent 做任何修改之前先手動保存一個版本或者復(fù)制一份文檔出來操作。Figma 的版本歷史在免費版里有限制別指望靠它回滾。復(fù)制文檔是最穩(wěn)妥的改壞了直接刪掉副本就行。另外修改操作最好分批進行改完一批檢查一批別一次性讓 Agent 跑完所有修改出了問題都不知道是哪一步導致的。還有一個細節(jié)是自動布局。Figma 的自動布局Auto Layout有一套自己的約束邏輯Agent 修改子節(jié)點尺寸或間距時可能會觸發(fā)自動布局的重新計算導致意料之外的位移。如果設(shè)計稿大量使用自動布局建議 Agent 在修改前先讀取布局配置修改后驗證布局是否還符合預(yù)期。這個驗證步驟不能省否則改完一看全亂了。5.2 批量重命名的實戰(zhàn)策略批量重命名是 Agent 修改設(shè)計稿里最高頻、也最實用的操作。一個典型場景是設(shè)計稿從其他工具導入圖層名全是默認的“Rectangle 1”“Group 2”需要按規(guī)范重命名。Agent 可以根據(jù)節(jié)點的類型、尺寸、位置、內(nèi)容來推斷合理的名稱。比如一個 375x812 的 Frame 可能是手機屏幕一個包含文本且寬度較小的節(jié)點可能是按鈕。具體策略可以分幾步。第一步按類型分組FRAME 歸 FRAMETEXT 歸 TEXTCOMPONENT 歸 COMPONENT。第二步對每組內(nèi)的節(jié)點根據(jù)尺寸和位置排序推斷層級關(guān)系。第三步結(jié)合文本內(nèi)容或已有命名生成候選名稱。第四步批量應(yīng)用重命名并輸出一份變更日志方便人工復(fù)核。這個流程里變更日志很重要因為 Agent 的推斷不可能百分之百準確人工復(fù)核是必要的兜底。重命名時還要注意命名沖突。如果兩個節(jié)點被推斷成同一個名稱后續(xù)引用會出問題。解決辦法是在名稱后加序號或者用更細粒度的特征來區(qū)分。比如兩個都是按鈕一個寬度 120一個寬度 200可以命名為“Button/Small”和“Button/Large”。這個邏輯可以在 Agent 側(cè)實現(xiàn)也可以做成 MCP 服務(wù)的一個工具讓 Agent 調(diào)用。5.3 修改后的驗證怎么確認 Agent 沒把設(shè)計稿改壞修改完成后的驗證環(huán)節(jié)很多人會忽略但它恰恰是最重要的。驗證分兩個層面結(jié)構(gòu)驗證和視覺驗證。結(jié)構(gòu)驗證是檢查節(jié)點樹是否完整有沒有節(jié)點丟失層級關(guān)系是否還正確。這個可以通過對比修改前后的節(jié)點數(shù)量和層級深度來快速判斷。如果修改前有 500 個節(jié)點修改后只剩 480 個那肯定有問題得排查哪里丟了。視覺驗證是導出修改后的關(guān)鍵頁面截圖和修改前的截圖做比對。如果只是重命名視覺上應(yīng)該完全一致如果有樣式修改視覺差異應(yīng)該符合預(yù)期。這個比對可以人工做也可以讓 Agent 做。Agent 做的話需要能讀取圖片并做像素級或結(jié)構(gòu)級比對。像素級比對對渲染差異很敏感結(jié)構(gòu)級比對更實用比如比對兩個截圖的布局網(wǎng)格是否一致。我自己的習慣是每次讓 Agent 做批量修改后都會讓它輸出一份“修改摘要”包括修改了哪些節(jié)點、改了什么、預(yù)期效果是什么。然后我拿著這份摘要去抽查幾個關(guān)鍵節(jié)點確認無誤后再繼續(xù)下一步。這個習慣幫我避免了好幾次潛在的事故尤其是涉及組件和自動布局的修改。6. 踩坑記錄那些文檔里不會寫的實際問題6.1 插件沙箱的權(quán)限限制與繞行思路Figma 插件沙箱對某些 API 的調(diào)用是有限制的比如網(wǎng)絡(luò)請求、本地文件系統(tǒng)訪問、部分跨文檔操作。Local Figma Agent MCP 走本地通信通道本身不涉及網(wǎng)絡(luò)請求所以網(wǎng)絡(luò)限制不影響它。但文件系統(tǒng)訪問受限會影響導出功能。如果你想讓 Agent 把設(shè)計稿導出成圖片或 SVG 并保存到本地插件沙箱可能不允許直接寫文件。繞行思路是插件側(cè)把導出的數(shù)據(jù)通過本地通道傳給 MCP 服務(wù)由服務(wù)側(cè)負責寫文件。服務(wù)側(cè)運行在 Node 環(huán)境里沒有沙箱限制可以自由讀寫本地文件。這個分工很關(guān)鍵插件負責和 Figma 交互服務(wù)負責和本地系統(tǒng)交互Agent 負責決策和調(diào)度。三層各司其職邊界清晰出問題也容易定位是哪一層的毛病。另一個權(quán)限限制是跨文檔操作。插件只能訪問當前打開的文檔沒法在后臺打開另一個文檔并操作它。如果你的需求涉及多個文檔只能手動切換或者用 Figma 的 REST API但那就回到付費額度的問題了。這個限制目前沒有太好的繞行方案只能接受。所以在規(guī)劃任務(wù)時盡量把同一文檔的操作集中在一起減少切換成本。6.2 大文檔下的性能瓶頸與優(yōu)化設(shè)計稿節(jié)點數(shù)量超過幾千個時性能問題會很明顯。插件 API 的調(diào)用本身有開銷每次讀取節(jié)點屬性都要跨沙箱邊界累積起來很慢。如果 Agent 還在一輪輪地發(fā)請求整體耗時可能從幾秒變成幾分鐘。優(yōu)化思路有幾個一是減少請求次數(shù)把多個讀取操作合并成一個批量請求二是緩存已讀取的節(jié)點數(shù)據(jù)避免重復(fù)讀取三是限制遍歷深度非必要不展開深層子樹。批量請求的實現(xiàn)方式是在 MCP 服務(wù)側(cè)提供一個“批量讀取”接口接受一個節(jié)點 ID 列表一次性返回所有節(jié)點的屬性。這樣 Agent 只需要發(fā)一次請求服務(wù)側(cè)在 Figma 沙箱內(nèi)循環(huán)讀取雖然總開銷差不多但省去了多次通信的往返時間。實測下來批量讀取比逐個讀取能快三到五倍節(jié)點越多差距越明顯。緩存策略也要注意失效問題。如果 Agent 讀取了節(jié)點數(shù)據(jù)然后修改了某個節(jié)點緩存里的數(shù)據(jù)就過期了。簡單的做法是修改后清空相關(guān)節(jié)點的緩存或者干脆每次修改后重新讀取。復(fù)雜一點的做法是維護一個版本號每次修改遞增讀取時檢查版本號決定是否用緩存。這個看具體場景如果修改不頻繁簡單清空就夠了。6.3 Agent 誤操作后的回滾方案Agent 誤操作是難免的關(guān)鍵是怎么快速回滾。前面說過最穩(wěn)妥的方式是操作前復(fù)制文檔。但復(fù)制文檔有個問題復(fù)制出來的文檔和原文檔是獨立的Agent 操作的是副本你確認無誤后還得把改動同步回原文檔。如果改動很多同步本身也是工作量。所以這個方案適合改動量大、風險高的場景日常小改動沒必要這么重。輕量級的回滾方案是利用 Figma 的撤銷功能。插件 API 觸發(fā)的修改在 Figma 里是可以撤銷的只要在同一個會話里。所以如果 Agent 改錯了立刻在 Figma 里按撤銷快捷鍵通常能恢復(fù)。但要注意撤銷棧有深度限制如果 Agent 連續(xù)做了很多步修改可能撤不回去。所以還是建議分批操作每批做完確認一下確認無誤再繼續(xù)。還有一個兜底方案是讓 Agent 在修改前先記錄原始值。比如要改一個節(jié)點的填充色先讀取當前色值存下來修改后如果發(fā)現(xiàn)問題可以用存下來的原始值改回去。這個方案需要 Agent 有“記錄-修改-回滾”的完整邏輯實現(xiàn)起來稍微復(fù)雜但對關(guān)鍵操作很值得。我一般會在涉及組件和布局的修改上用這個方案普通的重命名和樣式微調(diào)就不必了。7. 把 Agent 接入日常設(shè)計開發(fā)流程的幾種玩法7.1 設(shè)計稿轉(zhuǎn)代碼從節(jié)點樹到組件代碼的映射這是最直接的玩法。Agent 讀取設(shè)計稿的節(jié)點樹識別出組件和布局生成對應(yīng)的前端代碼。映射規(guī)則可以自定義比如 FRAME 映射成 divTEXT 映射成 span 或 pINSTANCE 映射成組件引用。樣式方面填充色映射成 background-color描邊映射成 border圓角映射成 border-radius自動布局映射成 flex 或 grid。這個過程中最麻煩的是布局推斷。Figma 的自動布局和 CSS 的 flex 不是一一對應(yīng)的有些自動布局的配置在 CSS 里需要額外的處理。比如 Figma 里的“間距自動”在 CSS 里可能是 gap也可能是 margin取決于具體場景。Agent 需要根據(jù)節(jié)點的實際布局結(jié)果來反推最合適的 CSS 寫法而不是機械地翻譯屬性。這個推斷邏輯需要一些啟發(fā)式規(guī)則準確率不可能百分之百但能省掉大部分手動工作。生成的代碼質(zhì)量還取決于設(shè)計稿的規(guī)范程度。如果設(shè)計稿用了規(guī)范的組件和命名生成的代碼結(jié)構(gòu)會很清晰如果全是散亂的 Frame 和 Rectangle生成的代碼就是一堆嵌套 div可讀性很差。所以這個玩法的前提是設(shè)計稿本身有一定的規(guī)范性。如果設(shè)計稿不規(guī)范可以先做一輪規(guī)范化處理再生成代碼。7.2 設(shè)計規(guī)范檢查讓 Agent 當你的設(shè)計 lint 工具設(shè)計稿里經(jīng)常會出現(xiàn)不規(guī)范的地方用了不在設(shè)計系統(tǒng)里的色值、字體大小不在預(yù)設(shè)范圍內(nèi)、間距不是 4 的倍數(shù)、組件實例被解綁了等等。這些檢查人工做很費時讓 Agent 做就很合適。Agent 遍歷節(jié)點樹對每個節(jié)點檢查預(yù)設(shè)的規(guī)則輸出違規(guī)列表。規(guī)則可以配置比如“所有填充色必須來自共享樣式”“所有字號必須是 12/14/16/20/24 之一”“所有間距必須是 4 的倍數(shù)”。這個玩法的價值在于它把設(shè)計規(guī)范的執(zhí)行從“事后人工檢查”變成了“隨時自動檢查”。設(shè)計側(cè)改完稿跑一下 Agent立刻知道哪里不合規(guī)改完再跑直到通過。這比等到開發(fā)階段才發(fā)現(xiàn)問題要高效得多。而且規(guī)則可以隨設(shè)計系統(tǒng)演進不斷更新Agent 的檢查邏輯也跟著更新保持一致性。實現(xiàn)上檢查規(guī)則可以寫成配置文件Agent 讀取配置后逐條執(zhí)行。每條規(guī)則對應(yīng)一個檢查函數(shù)輸入是節(jié)點屬性輸出是是否通過和違規(guī)詳情。這個架構(gòu)很靈活新增規(guī)則只需要加一個函數(shù)和一條配置。我見過一些團隊把這種檢查集成到 CI 里設(shè)計稿更新后自動跑結(jié)果發(fā)到群里效果不錯。7.3 設(shè)計稿差異比對改版前后的自動化 diff產(chǎn)品迭代時設(shè)計稿經(jīng)常改版。改版前后有哪些差異人工比對很費眼。Agent 可以做自動化 diff讀取兩個版本的節(jié)點樹按節(jié)點 ID 或名稱匹配找出新增、刪除、修改的節(jié)點輸出差異報告。這個報告可以細化到屬性級別比如“按鈕的主色從 #1A73E8 改成了 #1B74E9”“卡片圓角從 8px 改成了 12px”。這個玩法的難點在于節(jié)點匹配。如果改版時節(jié)點 ID 變了就得靠名稱和位置來匹配準確率會下降。所以最好在設(shè)計側(cè)約定改版時盡量保留節(jié)點 ID或者至少保留名稱。如果做不到Agent 的 diff 結(jié)果就需要人工復(fù)核但即便如此也比純?nèi)斯け葘旌芏唷２町悎蟾娴妮敵龈袷娇梢院莒`活簡單的就是文本列表復(fù)雜點的可以生成 HTML 報告帶截圖對比。截圖對比需要導出節(jié)點圖片然后并排展示。這個在 MCP 服務(wù)側(cè)實現(xiàn)比較方便因為服務(wù)側(cè)可以寫文件生成 HTML 報告后直接在瀏覽器打開看。我一般會生成一個簡單的 HTML左邊是改前截圖右邊是改后截圖下面列出屬性差異一目了然。8. 關(guān)于這套方案的能力邊界與后續(xù)擴展方向用了一段時間下來我的整體感受是Local Figma Agent MCP 這套方案在“單文檔、中等規(guī)模、規(guī)范化設(shè)計稿”的場景下表現(xiàn)很好能實實在在省掉大量重復(fù)勞動。但它不是萬能的跨文檔批量處理、超大文檔的性能、非規(guī)范設(shè)計稿的理解準確率這些方面還有明顯的天花板。所以我的建議是先在小范圍試點跑通一個具體場景比如“批量重命名”或“設(shè)計規(guī)范檢查”確認效果后再逐步擴大使用范圍。擴展方向上我覺得有幾個值得探索的點。一是把 MCP 服務(wù)和 CI 流程結(jié)合設(shè)計稿更新后自動跑檢查和 diff結(jié)果推送到協(xié)作工具。二是把 Agent 的修改能力做成“建議模式”Agent 只輸出修改建議人工確認后再執(zhí)行降低誤操作風險。三是積累一套針對自己團隊設(shè)計系統(tǒng)的規(guī)則庫和提示詞模板讓 Agent 的理解準確率隨著使用不斷優(yōu)化。這些方向都不需要額外的付費成本靠本地工具鏈就能實現(xiàn)。最后說一個實際體會這套方案的價值不在于“完全替代人工”而在于“把人工從重復(fù)勞動里解放出來”。Agent 做批量處理人做關(guān)鍵決策和復(fù)核這個分工目前是最務(wù)實的。指望 Agent 全自動搞定一切現(xiàn)階段還不現(xiàn)實但讓它承擔百分之七八十的機械工作完全可行。我在實際項目里就是這么用的效率提升很明顯而且隨著規(guī)則和提示詞的積累Agent 的表現(xiàn)會越來越好。