計稿自動搭建FairyGUI UI結(jié)構(gòu)：方案與踩坑記錄)
先講個真實經(jīng)歷。最近兩個月我?guī)缀醢阉心軘D出來的時間都用在了同一件事上讓 AI Agent 替我把 FairyGUI 的 UI 結(jié)構(gòu)從設(shè)計稿里“搭”出來。起因是新項目的界面量實在太大光一個主界面就三百多個節(jié)點手拼一遍得小一整天改一版需求又得半天起跳。人不是不能干但干這種活的時候腦子基本是閑置的——這就是典型的該交給 Agent 的場景。后來我把這條鏈路跑通之后從設(shè)計稿到 FairyGUI 工程里出現(xiàn)完整可發(fā)布的組件結(jié)構(gòu)基本能做到分鐘級。這篇文章就把我這段時間的完整思路、方案選型、代碼細(xì)節(jié)、踩坑記錄全部拆開講適合正在用 FairyGUI 做游戲 UI、又被海量節(jié)點壓得喘不過氣的開發(fā)者和 UI 程序。想了解“Agent 到底怎么接進(jìn)編輯器流程”的同學(xué)應(yīng)該也能從這里找到一條可落地的路徑。1. 先搞清楚手拼 FairyGUI 的痛點到底在哪不能一上來就聊 Agent得先弄清楚我們到底在抱怨什么。FairyGUI 本身是個很好的編輯器所見即所得資源依賴、控制器、關(guān)聯(lián)系統(tǒng)都很成熟。但“好”是針對界面級操作而言的一旦面對成百上千個節(jié)點它和所有圖形化編輯器一樣有一個通病單個節(jié)點的操作效率很高批量結(jié)構(gòu)的搭建效率極低。1.1 一次真實經(jīng)歷三百個節(jié)點的手工地獄前陣子我們做主城界面功能模塊特別多頂部資源欄、角色信息區(qū)、任務(wù)追蹤、活動入口、聊天框、底部導(dǎo)航、紅點層……一個面板套一個面板最后打開組件樹一看三百多個節(jié)點。我當(dāng)時干了一件特別蠢也特別典型的事先對著設(shè)計稿把背景拖進(jìn)來再一個個擺按鈕、文本框調(diào)層級、調(diào)錨點、調(diào)關(guān)聯(lián)。這些操作沒有任何智力含量但就是費時間。更可怕的是改版設(shè)計稿換了布局整個組件樹要重排關(guān)聯(lián)關(guān)系斷的斷、錯位的錯位。那一周我加了好幾天班干完只有一個感受這種活不應(yīng)該由人來干。再說個更普遍的痛點團(tuán)隊里每個人拼出來的結(jié)構(gòu)風(fēng)格都不一樣。有人喜歡把所有圖片節(jié)點平鋪在 displayList 里有人喜歡嵌套子組件命名習(xí)慣也不同這個叫btnStart那個叫startBtn。代碼里引用、查找全靠猜。這其實不是操作效率問題是工程規(guī)范問題而人恰恰是最難保證規(guī)范一致的。1.2 Agent 能做什么把“搭結(jié)構(gòu)”變成“寫描述”Agent 不是來替代 FairyGUI 編輯器的它替代的是“人手拖拽”這個動作。核心邏輯很簡單搭 UI 本質(zhì)上是在描述一棵樹——什么節(jié)點、什么類型、放在哪、多大、什么層級、跟誰關(guān)聯(lián)。這本來就是大模型最擅長處理的“結(jié)構(gòu)化輸出”問題。我舉個生活化類比。手拼 UI 就像手寫 HTML 表格一個單元格一個單元格敲Agent 接手則像你用現(xiàn)成的組件庫聲明式寫頁面——同樣是寫代碼但你在描述結(jié)構(gòu)瀏覽器負(fù)責(zé)渲染。對應(yīng)到 FairyGUI就是讓 Agent 輸出一份結(jié)構(gòu)描述再通過轉(zhuǎn)換器變成 FairyGUI 能識別的組件 XML最后進(jìn)編輯器發(fā)布。但必須說清楚它的邊界Agent 不能憑空生成美術(shù)資源。背景圖、圖標(biāo)、字體這些還是得由美術(shù)準(zhǔn)備好Agent 也不能替你搞定復(fù)雜交互邏輯控制器跳轉(zhuǎn)、列表滾動、動效播放這些業(yè)務(wù)代碼仍然要手寫。它能做的是把“靜態(tài) UI 結(jié)構(gòu)”這部分硬骨頭啃下來而這部分恰恰是工作量的大頭。2. Agent 接管 FairyGUI 的整套設(shè)計思路有了痛點第二步是設(shè)計整體方案。我見過不少同事一上來就讓大模型直接寫 FairyGUI 的工程文件寫出來要么打不開要么編輯器一刷新全亂了。原因很簡單FairyGUI 的工程文件格式是編輯器私有的不只是 XML還有資源索引、二進(jìn)制元數(shù)據(jù)、版本兼容問題。讓 LLM 直接操作這層?xùn)|西等于讓它寫一個二進(jìn)制私有格式它不是不能試但每次版本升級都會崩給你看。2.1 技術(shù)選型LLM 轉(zhuǎn)換器 編輯器 CLI 三層結(jié)構(gòu)我建議的架構(gòu)是三層分離第一層是 LLM負(fù)責(zé)理解設(shè)計稿和需求輸出一份與 FairyGUI 無關(guān)的純結(jié)構(gòu)描述第二層是一個本地轉(zhuǎn)換器把這份結(jié)構(gòu)描述翻譯成 FairyGUI 組件 XML第三層是 FairyGUI 自己的命令行發(fā)布能力把 XML 吃進(jìn)工程、生成資源包和綁定代碼。為什么要中間夾一個轉(zhuǎn)換器因為直接讓 LLM 輸出 XML 的幻覺率高得離譜。它可能編出根本不存在的屬性名或者漏掉relation關(guān)聯(lián)甚至把圖片資源名寫錯。而 LLM 輸出純 JSON 結(jié)構(gòu)時準(zhǔn)確率高很多——字段少、約束清晰再用本地代碼去映射、校驗、兜底錯誤就能被攔截在進(jìn)入工程之前。這就像讓 AI 直接寫 SQL 和讓 AI 先生成查詢條件、你再拿條件拼 SQL 的區(qū)別前者一步到位但不可控后者多一道閘門但每個環(huán)節(jié)都能驗證。我的經(jīng)驗是永遠(yuǎn)讓 LLM 輸出可校驗的中間產(chǎn)物而不是直接輸出最終產(chǎn)物。2.2 數(shù)據(jù)流一條端到端的 UI 自動化管線整條管線的數(shù)據(jù)流我用文字走一遍你在腦子里過一遍就知道大概長什么樣了。第一步設(shè)計稿和需求說明輸入給 Agent如果是圖片就配一個能看圖的多模態(tài)模型如果是文字需求直接給 Prompt。第二步Agent 輸出一份 UI 描述 JSON里面包含組件樹、節(jié)點類型、坐標(biāo)尺寸、文字內(nèi)容、圖片資源名、控制器狀態(tài)列表。第三步本地腳本對 JSON 做校驗——資源名是否存在于資源清單、坐標(biāo)是否越界、必填字段有沒有缺失。校驗沒過就帶著錯誤信息丟回給 Agent 重新生成。第四步通過一版后轉(zhuǎn)換器把 JSON 映射成 FairyGUI 組件 XML寫進(jìn)工程目錄。第五步調(diào)用 FairyGUI 編輯器的命令行發(fā)布生成.bytes資源包和 Unity/Cocos 的綁定代碼。第六步截一張預(yù)覽圖用視覺模型跟原設(shè)計稿做對比色差、布局差異、遮擋都比較一下有問題的再回流。這套鏈路看起來長但真正需要寫的代碼只有一個轉(zhuǎn)換器加一堆校驗?zāi)_本。核心耗時在 Agent 生成和人工審閱基本能做到對一個中等復(fù)雜度的面板五分鐘內(nèi)出第一版可用結(jié)構(gòu)。2.3 關(guān)鍵決策先做半自動不做全自動我最初的想法很激進(jìn)想讓 Agent 生成完直接進(jìn)工程。試了幾天就老實了這一步必須保留人工審閱環(huán)節(jié)。原因有兩個一是 Agent 偶爾會“合理但錯誤”地補全需求比如設(shè)計稿里一個沒有文字的按鈕它給編了一段文案雖然看起來沒問題但產(chǎn)品肯定不認(rèn)二是 FairyGUI 的層級疊放順序很敏感顯示列表從下到上就是渲染從下到上Agent 生成的順序偶爾會和設(shè)計稿相反一眼看過去問題不大真跑起來按鈕被背景擋住。所以最終的方案是Agent 負(fù)責(zé)生成人負(fù)責(zé)驗收確認(rèn)無誤再發(fā)布進(jìn)包。別覺得這樣效率低人審一個面板結(jié)構(gòu)只需要掃一眼樹形圖比從零開始手拼快了一個數(shù)量級。3. 核心實操從設(shè)計稿到 FairyGUI XML 的完整鏈路理論說完了上真東西。這一章我從協(xié)議、Prompt、映射、發(fā)布四個環(huán)節(jié)逐個拆確保你照著能做出來。3.1 第一步定義一份“UI 描述協(xié)議”要讓 Agent 穩(wěn)定輸出最重要的是給它一個足夠小的 JSON Schema。我定義的協(xié)議長這樣這套字段經(jīng)過幾輪迭代已經(jīng)能覆蓋 FairyGUI 里絕大多數(shù)靜態(tài) UI 場景{ $schema: http://example.com/ui-description.schema.json, type: object, required: [name, width, height, children], properties: { name: { type: string, description: 組件名與設(shè)計稿命名一致 }, width: { type: integer, description: 設(shè)計寬度單位 px }, height: { type: integer, description: 設(shè)計高度單位 px }, children: { type: array, items: { type: object, required: [type, name, x, y, width, height], properties: { type: { type: string, enum: [image, text, button, list, graph, component, loader] }, name: { type: string }, x: { type: integer, description: 相對父節(jié)點左上角的 X 坐標(biāo) }, y: { type: integer }, width: { type: integer }, height: { type: integer }, pivot: { type: array, items: { type: number }, minItems: 2, maxItems: 2, description: 軸心點如 [0.5, 0.5] 表示中心點 }, resource: { type: string, description: 圖片資源名必須來自資源清單 }, text: { type: string, description: 文本內(nèi)容僅 text/button 使用 }, fontSize: { type: integer }, color: { type: string, pattern: ^#[0-9a-fA-F]{6}$ }, controllers: { type: array, items: { type: object, required: [name, pages], properties: { name: { type: string }, pages: { type: array, items: { type: object, required: [id, title], properties: { id: { type: integer }, title: { type: string } } } } } } }, children: { type: array, description: 嵌套子節(jié)點遞歸結(jié)構(gòu) } } } } } }這套協(xié)議有幾個用心之處。第一type 字段用枚舉值從源頭堵住 Agent 發(fā)明新節(jié)點類型的可能。第二所有坐標(biāo)都是相對父節(jié)點的整數(shù)不搞 float 不搞百分比讓轉(zhuǎn)換器邏輯簡單Agent 也不容易算出小數(shù)。第三resource 字段明確標(biāo)注“必須來自資源清單”這是在為后文說的資源防幻覺做準(zhǔn)備。如果你有自己的特殊組件比如進(jìn)度條、滑動條可以在枚舉里加但一定要同時告訴 Agent 這些組件需要哪些額外字段。人話就是協(xié)議越小Agent 越穩(wěn)。3.2 第二步Prompt 怎么寫才能穩(wěn)定輸出有了 SchemaPrompt 就要把 AI 往這個 Schema 里趕。我試過幾種寫法最有效的是“角色限定 輸出格式硬約束 少樣本示例”三段式你是一名資深游戲 UI 結(jié)構(gòu)工程師熟悉 FairyGUI 的組件體系和層級規(guī)則。 現(xiàn)在需要你根據(jù)用戶提供的設(shè)計稿/需求描述輸出一份 UI 結(jié)構(gòu) JSON。 硬性要求 1. 只能使用 JSON 格式輸出不要包含任何解釋性文字。 2. 必須嚴(yán)格遵循給定的 JSON Schema不得新增字段不得修改枚舉值。 3. 所有 resource 字段的值必須從下面的資源清單中選擇禁止編造資源名。 4. 坐標(biāo)系為屏幕坐標(biāo)原點在左上角x 向右為正y 向下為正。 5. 嵌套結(jié)構(gòu)要合理同一層級的節(jié)點按渲染從底到頂?shù)捻樞蚺帕小?6. 如果設(shè)計稿中存在某個圖片或文字但資源清單中沒有對應(yīng)資源用 graph 節(jié)點占位并在輸出末尾 REMARKS 字段中說明。 資源清單 bg_main, btn_start, btn_shop, icon_coin, txt_title, panel_bag, item_bg 以下是輸出的 JSON 格式示例 { name: MainPanel, width: 1280, height: 720, children: [ ... ] } 請開始輸出。這段 Prompt 里最關(guān)鍵的是第 5 條“渲染從底到頂”因為我踩過坑Agent 默認(rèn)按照“從上往下讀設(shè)計稿”的順序排列子節(jié)點導(dǎo)致最底層的背景跑到了最上層。加上這一條之后層級順序錯誤率明顯下降。另外第 6 條也重要它給了 Agent 一條合法出路——資源缺失時用 graph 占位而不是硬編一個不存在的資源名。給 Agent 留退路比反復(fù)強調(diào)“不要亂編”有效得多。還有個小經(jīng)驗如果你接的是多模態(tài)模型最好把設(shè)計稿圖片直接喂進(jìn)去讓它對著圖輸出坐標(biāo)。但注意多模態(tài)模型的文字識別有時會把設(shè)計稿里的標(biāo)注數(shù)字當(dāng)成尺寸值這點在審閱時要重點檢查。3.3 第三步JSON 到 FairyGUI XML 的映射與生成校驗通過的 JSON 進(jìn)入轉(zhuǎn)換器這一步是把“協(xié)議描述”翻譯成“編輯器語言”。核心映射關(guān)系我整理成了一張表JSON 字段FairyGUI XML 元素/屬性說明type: imageimagesrc 屬性填資源名type: texttexttext 屬性填文案fontSize 映射 font-sizetype: buttonbutton內(nèi)部往往帶一個 title 文本節(jié)點type: listlist需要配合 item 模板 URLtype: graphgraph純占位圖形不綁資源x, yxy100,20相對父節(jié)點左上角width, heightsize200,80控件原始尺寸pivotpivot0.5,0.5軸心點附加 pivotAsAnchor 可選resourcesrcui://包名/資源名需要轉(zhuǎn)換器拼上包名前綴controllerscontroller生成 controller 節(jié)點并填充 pageschildren 里的嵌套結(jié)構(gòu)displayList內(nèi)嵌套關(guān)鍵是層級順序轉(zhuǎn)換器生成的 XML 大概是這個味道拿一個簡單的“背景 標(biāo)題 開始按鈕”做示例component size1280,720 controller namestate pages0,normal,1,selected/ displayList image namebg_main srcui://Game/bg_main size1280,720 xy0,0/ text nametxt_title font-size36 text歡迎回來 color#FFFFFF xy540,100 width200 height50 aligncenter/ button namebtn_start srcui://Game/btn_start xy540,300 width200 height80 relation targetbg_main sidealign_left width100%/ /button /displayList /component這里有兩個轉(zhuǎn)換器必須處理的細(xì)節(jié)。第一個是URL 前綴FairyGUI 里所有資源引用都是ui://包名/資源名格式JSON 里只寫資源名轉(zhuǎn)換器負(fù)責(zé)拼包名。第二個是relation 關(guān)聯(lián)JSON 協(xié)議里沒有直接體現(xiàn)我的做法是在轉(zhuǎn)換器里寫規(guī)則——如果某個節(jié)點有align需求就在 JSON 里加一個擴展字段轉(zhuǎn)換器識別后生成relation。生成完 XML 后一定先去 FairyGUI 編輯器里手動打開這個組件看一眼再發(fā)布。為什么因為轉(zhuǎn)換器只能保證語法正確不能保證視覺正確。編輯器里會直接暴露層級、坐標(biāo)、透明度這些問題比你看代碼快得多。3.4 第四步命令行發(fā)布與綁定代碼生成XML 寫進(jìn)工程目錄后接著要讓它變成引擎里能用的東西。FairyGUI 編輯器提供命令行入口可以這樣走FairyGUI-Editor.exe -publish 項目.fairy -package Game -output Assets/UI/Game具體參數(shù)名不同版本可能不一樣以你裝的編輯器版本為準(zhǔn)。但思路是一致的不進(jìn)編輯器 UI直接用命令行把 XML 編譯成引擎?zhèn)瓤杉虞d的資源包。這個能力特別適合接進(jìn) Jenkins 或本地腳本讓整條 UI 生成鏈路完全無人值守。資源包發(fā)布之后FairyGUI 會為每個組件生成綁定代碼比如 Unity 下的UI_MainPanel.cs。這里又輪到 Agent 出場了——它可以把這層包裝類的生成也接管一部分。我常讓它生成這種代碼public class MainPanelView { public GComponent root { get; private set; } public GButton btnStart { get; private set; } public GTextField txtTitle { get; private set; } public MainPanelView(GComponent root) { this.root root; this.btnStart root.GetChild(btn_start).asButton; this.txtTitle root.GetChild(txt_title).asTextField; } }這類代碼極其模式化人寫純屬浪費時間Agent 生成又快又穩(wěn)。而且只要你固定了命名規(guī)范Agent 生成出來的代碼風(fēng)格也會統(tǒng)一直接省掉代碼 review 里最無聊的部分。4. 落地時我踩過的坑和排查方法理想很豐滿現(xiàn)實里全是坑。這套流程我跑了一個多月踩的坑比預(yù)想的多得多而且很多坑特別隱蔽不實際操作根本想不到。我挑幾個影響最大的展開說。4.1 坐標(biāo)錯亂pivot、錨點、關(guān)聯(lián)三件套第一次用 Agent 生成復(fù)雜組件時我打開編輯器看到的畫面是所有按鈕都往右下角偏了半個身位文字全部跑到圖片外面。排查了半天問題出在 pivot 上。FairyGUI 的坐標(biāo)系統(tǒng)是“相對父組件左上角”但如果節(jié)點設(shè)置了 pivot它的 xy 定位就變成以 pivot 點為準(zhǔn)。Agent 從設(shè)計稿里讀到的坐標(biāo)是基于左上角的它又不理解 pivot 語義于是把pivot0.5,0.5一加整個節(jié)點就偏移了。解決方法是普通靜態(tài)節(jié)點不設(shè) pivot只有需要旋轉(zhuǎn)、縮放動效的節(jié)點才設(shè)。在協(xié)議里明確“默認(rèn)無 pivot除非特別說明”并且在轉(zhuǎn)換器里加一條強制規(guī)則——如果 JSON 里沒有 pivot 字段XML 里堅決不輸出 pivot。這個坑踩一次就夠了。4.2 Agent 幻覺資源用資源清單做硬約束這是所有坑里出現(xiàn)頻率最高的。Agent 會一本正經(jīng)地引用一個根本不存在的圖片資源名比如設(shè)計稿上有個背包按鈕它直接輸出resource: icon_bag但工程里的資源實際叫bag_icon。如果你沒加保護(hù)轉(zhuǎn)換器會生成一個 XMLFairyGUI 編譯時直接報資源缺失整包發(fā)布失敗。我前面提到的“資源清單喂給 Agent”就是干這個的。但光喂還不夠轉(zhuǎn)換器一定要做二次校驗把 Agent 輸出 JSON 里的 resource 字段全部抽取出來和本地資源清單做集合比對一旦發(fā)現(xiàn)未知資源直接中止流程并把錯誤反饋給 Agent 重試。整套過程會自動跑通常一次重試就能糾正。實測下來資源幻覺率能從三成壓到 5% 以下。4.3 控制器狀態(tài)漏生成運行時 UI 點不動還有一個低頻但特別影響體驗的問題Agent 生成的組件少了控制器。比如一個按鈕需要 normal / pressed / selected 三個狀態(tài)Agent 經(jīng)常只給一個基礎(chǔ) image 節(jié)點忘了補控制器。結(jié)果運行時按鈕點擊沒有反饋UI 看起來像死了一樣。排查這種問題不能用肉眼看 XML得用腳本把所有button類型節(jié)點揪出來檢查它是否至少有一個 controller。我在轉(zhuǎn)換器校驗環(huán)節(jié)加了一條規(guī)則button 節(jié)點必須有名為 state 的控制器且 pages 數(shù)量不少于 2否則視為校驗失敗。這樣就把這個問題從“運行時才發(fā)現(xiàn)”提前到了“生成時就被攔截”。4.4 多個 Agent 并行時的沖突Git 才是隱形殺手當(dāng)我把這套流程擴大到一個四人小組使用時又遇到新問題大家各自讓 Agent 生成面板同時往同一個工程目錄里寫 XMLgit 沖突比手寫代碼還嚴(yán)重。因為 FairyGUI 工程里有個全局文件記錄了所有資源的 GUID 和組件引用關(guān)系多人同時改這個文件幾乎必然打架。我的應(yīng)對方案是每個 UI 包拆分獨立目錄每個 Agent 任務(wù)只允許寫自己負(fù)責(zé)的包合并時禁止并行寫同一包另外把 FairyGUI 的工程文件全量納入 Git 管理XML 是文本文件可以 diff、可以 review沖突至少能看見。這個教訓(xùn)是自動化生成不是免死金牌流程規(guī)范還是得人來定。4.5 常見問題速查表最后整理一張速查表遇到問題可以快速定位現(xiàn)象可能原因處理方式組件發(fā)布后資源缺失Agent 生成不存在的資源名轉(zhuǎn)換器加資源清單比對 自動重試節(jié)點整體偏移pivot 與坐標(biāo)語義沖突XML 不主動輸出 pivot按需設(shè)置按鈕點擊無反饋缺少控制器 pages校驗 button 節(jié)點的 controller 數(shù)量渲染層級不對displayList 順序顛倒Prompt 明確“底到頂”順序 人工審閱Git 沖突頻繁多人同時改同一 UI 包包級隔離禁止并行寫同一包文字內(nèi)容被 Agent 妄改需求描述不完整在協(xié)議里增加“支持原文引用”字段XML 語法正確但編輯器打不開版本不兼容或字段拼錯先打開編輯器看報錯日志再轉(zhuǎn)換器補兼容5. 給想接手這套流程的人四個實在建議前面把思路、代碼、坑都講完了最后說幾句掏心窩子的建議。如果你真想把 Agent 接進(jìn) FairyGUI 流程別急著一步到位按下面這個節(jié)奏來。5.1 從組件級接管開始別一上來就整面板我最開始想直接生成整個主界面結(jié)果被層級、控制器、關(guān)聯(lián)三座大山壓得喘不過氣。后來我退一步先讓 Agent 只生成“單組件”——比如一個按鈕、一個列表項、一個彈窗框架。這類結(jié)構(gòu)簡單字段少校驗規(guī)則也好寫。跑了幾天發(fā)現(xiàn)效率確實高再逐步擴大到完整面板。步子太大容易扯著這點在 AI 流程里也一樣適用。5.2 建一個自己的組件模板庫Agent 生成的節(jié)點結(jié)構(gòu)雖然對但風(fēng)格不一定符合你們團(tuán)隊習(xí)慣。我的做法是把團(tuán)隊里既有的優(yōu)質(zhì)組件結(jié)構(gòu)抽成模板寫進(jìn)轉(zhuǎn)換器里。比如“標(biāo)準(zhǔn)按鈕”就是“底圖 文字 state 控制器”轉(zhuǎn)換器遇到type: button時直接用模板生成而不是讓 Agent 自由發(fā)揮。模板庫越厚Agent 的自由度就應(yīng)越小整體質(zhì)量越可控。5.3 用失敗案例反向喂給 Prompt每次 Agent 生成的組件被打回我都會把錯誤原因整理成一句話加進(jìn) Prompt。比如“列表項內(nèi)部禁止嵌套滾動容器”“所有文本節(jié)點必須提供 color”。實踐兩三個星期后Agent 的生成質(zhì)量會有肉眼可見的提升。這比換更大參數(shù)的模型管用因為問題往往出在領(lǐng)域細(xì)節(jié)而不是模型智力上。5.4 留一條手工兜底的快捷通道最后提醒一句別把手工能力丟掉。我做這套流程時仍然保留了“手動微調(diào)”的工作習(xí)慣——Agent 生成的組件進(jìn)編輯器后我會快速拖一兩個節(jié)點做微調(diào)。不是因為 Agent 不好用而是因為有些細(xì)節(jié)比如像素級對齊的視覺感受機器判斷不如人眼敏感。工具的意義是讓你把時間花在真正需要判斷力的事情上而不是幫你徹底偷懶。我現(xiàn)在的工作習(xí)慣已經(jīng)完全變了早上到公司先看設(shè)計稿更新把需求丟給 Agent它生成結(jié)構(gòu)、自動校驗、發(fā)布資源我這邊做審閱和微調(diào)。原來一天手拼兩三個面板的工作量現(xiàn)在能從容地做完一整層 UI 體系。這個方向未來還有很大空間比如把動效、狀態(tài)機的生成也納入進(jìn)來但那又是另一篇文章了。 AI Agent從設(shè)計稿自動搭建FairyGUI UI結(jié)構(gòu)：方案與踩坑記錄
先講個真實經(jīng)歷。最近兩個月我?guī)缀醢阉心軘D出來的時間都用在了同一件事上讓 AI Agent 替我把 FairyGUI 的 UI 結(jié)構(gòu)從設(shè)計稿里“搭”出來。起因是新項目的界面量實在太大光一個主界面就三百多個節(jié)點手拼一遍得小一整天改一版需求又得半天起跳。人不是不能干但干這種活的時候腦子基本是閑置的——這就是典型的該交給 Agent 的場景。后來我把這條鏈路跑通之后從設(shè)計稿到 FairyGUI 工程里出現(xiàn)完整可發(fā)布的組件結(jié)構(gòu)基本能做到分鐘級。這篇文章就把我這段時間的完整思路、方案選型、代碼細(xì)節(jié)、踩坑記錄全部拆開講適合正在用 FairyGUI 做游戲 UI、又被海量節(jié)點壓得喘不過氣的開發(fā)者和 UI 程序。想了解“Agent 到底怎么接進(jìn)編輯器流程”的同學(xué)應(yīng)該也能從這里找到一條可落地的路徑。1. 先搞清楚手拼 FairyGUI 的痛點到底在哪不能一上來就聊 Agent得先弄清楚我們到底在抱怨什么。FairyGUI 本身是個很好的編輯器所見即所得資源依賴、控制器、關(guān)聯(lián)系統(tǒng)都很成熟。但“好”是針對界面級操作而言的一旦面對成百上千個節(jié)點它和所有圖形化編輯器一樣有一個通病單個節(jié)點的操作效率很高批量結(jié)構(gòu)的搭建效率極低。1.1 一次真實經(jīng)歷三百個節(jié)點的手工地獄前陣子我們做主城界面功能模塊特別多頂部資源欄、角色信息區(qū)、任務(wù)追蹤、活動入口、聊天框、底部導(dǎo)航、紅點層……一個面板套一個面板最后打開組件樹一看三百多個節(jié)點。我當(dāng)時干了一件特別蠢也特別典型的事先對著設(shè)計稿把背景拖進(jìn)來再一個個擺按鈕、文本框調(diào)層級、調(diào)錨點、調(diào)關(guān)聯(lián)。這些操作沒有任何智力含量但就是費時間。更可怕的是改版設(shè)計稿換了布局整個組件樹要重排關(guān)聯(lián)關(guān)系斷的斷、錯位的錯位。那一周我加了好幾天班干完只有一個感受這種活不應(yīng)該由人來干。再說個更普遍的痛點團(tuán)隊里每個人拼出來的結(jié)構(gòu)風(fēng)格都不一樣。有人喜歡把所有圖片節(jié)點平鋪在 displayList 里有人喜歡嵌套子組件命名習(xí)慣也不同這個叫btnStart那個叫startBtn。代碼里引用、查找全靠猜。這其實不是操作效率問題是工程規(guī)范問題而人恰恰是最難保證規(guī)范一致的。1.2 Agent 能做什么把“搭結(jié)構(gòu)”變成“寫描述”Agent 不是來替代 FairyGUI 編輯器的它替代的是“人手拖拽”這個動作。核心邏輯很簡單搭 UI 本質(zhì)上是在描述一棵樹——什么節(jié)點、什么類型、放在哪、多大、什么層級、跟誰關(guān)聯(lián)。這本來就是大模型最擅長處理的“結(jié)構(gòu)化輸出”問題。我舉個生活化類比。手拼 UI 就像手寫 HTML 表格一個單元格一個單元格敲Agent 接手則像你用現(xiàn)成的組件庫聲明式寫頁面——同樣是寫代碼但你在描述結(jié)構(gòu)瀏覽器負(fù)責(zé)渲染。對應(yīng)到 FairyGUI就是讓 Agent 輸出一份結(jié)構(gòu)描述再通過轉(zhuǎn)換器變成 FairyGUI 能識別的組件 XML最后進(jìn)編輯器發(fā)布。但必須說清楚它的邊界Agent 不能憑空生成美術(shù)資源。背景圖、圖標(biāo)、字體這些還是得由美術(shù)準(zhǔn)備好Agent 也不能替你搞定復(fù)雜交互邏輯控制器跳轉(zhuǎn)、列表滾動、動效播放這些業(yè)務(wù)代碼仍然要手寫。它能做的是把“靜態(tài) UI 結(jié)構(gòu)”這部分硬骨頭啃下來而這部分恰恰是工作量的大頭。2. Agent 接管 FairyGUI 的整套設(shè)計思路有了痛點第二步是設(shè)計整體方案。我見過不少同事一上來就讓大模型直接寫 FairyGUI 的工程文件寫出來要么打不開要么編輯器一刷新全亂了。原因很簡單FairyGUI 的工程文件格式是編輯器私有的不只是 XML還有資源索引、二進(jìn)制元數(shù)據(jù)、版本兼容問題。讓 LLM 直接操作這層?xùn)|西等于讓它寫一個二進(jìn)制私有格式它不是不能試但每次版本升級都會崩給你看。2.1 技術(shù)選型LLM 轉(zhuǎn)換器 編輯器 CLI 三層結(jié)構(gòu)我建議的架構(gòu)是三層分離第一層是 LLM負(fù)責(zé)理解設(shè)計稿和需求輸出一份與 FairyGUI 無關(guān)的純結(jié)構(gòu)描述第二層是一個本地轉(zhuǎn)換器把這份結(jié)構(gòu)描述翻譯成 FairyGUI 組件 XML第三層是 FairyGUI 自己的命令行發(fā)布能力把 XML 吃進(jìn)工程、生成資源包和綁定代碼。為什么要中間夾一個轉(zhuǎn)換器因為直接讓 LLM 輸出 XML 的幻覺率高得離譜。它可能編出根本不存在的屬性名或者漏掉relation關(guān)聯(lián)甚至把圖片資源名寫錯。而 LLM 輸出純 JSON 結(jié)構(gòu)時準(zhǔn)確率高很多——字段少、約束清晰再用本地代碼去映射、校驗、兜底錯誤就能被攔截在進(jìn)入工程之前。這就像讓 AI 直接寫 SQL 和讓 AI 先生成查詢條件、你再拿條件拼 SQL 的區(qū)別前者一步到位但不可控后者多一道閘門但每個環(huán)節(jié)都能驗證。我的經(jīng)驗是永遠(yuǎn)讓 LLM 輸出可校驗的中間產(chǎn)物而不是直接輸出最終產(chǎn)物。2.2 數(shù)據(jù)流一條端到端的 UI 自動化管線整條管線的數(shù)據(jù)流我用文字走一遍你在腦子里過一遍就知道大概長什么樣了。第一步設(shè)計稿和需求說明輸入給 Agent如果是圖片就配一個能看圖的多模態(tài)模型如果是文字需求直接給 Prompt。第二步Agent 輸出一份 UI 描述 JSON里面包含組件樹、節(jié)點類型、坐標(biāo)尺寸、文字內(nèi)容、圖片資源名、控制器狀態(tài)列表。第三步本地腳本對 JSON 做校驗——資源名是否存在于資源清單、坐標(biāo)是否越界、必填字段有沒有缺失。校驗沒過就帶著錯誤信息丟回給 Agent 重新生成。第四步通過一版后轉(zhuǎn)換器把 JSON 映射成 FairyGUI 組件 XML寫進(jìn)工程目錄。第五步調(diào)用 FairyGUI 編輯器的命令行發(fā)布生成.bytes資源包和 Unity/Cocos 的綁定代碼。第六步截一張預(yù)覽圖用視覺模型跟原設(shè)計稿做對比色差、布局差異、遮擋都比較一下有問題的再回流。這套鏈路看起來長但真正需要寫的代碼只有一個轉(zhuǎn)換器加一堆校驗?zāi)_本。核心耗時在 Agent 生成和人工審閱基本能做到對一個中等復(fù)雜度的面板五分鐘內(nèi)出第一版可用結(jié)構(gòu)。2.3 關(guān)鍵決策先做半自動不做全自動我最初的想法很激進(jìn)想讓 Agent 生成完直接進(jìn)工程。試了幾天就老實了這一步必須保留人工審閱環(huán)節(jié)。原因有兩個一是 Agent 偶爾會“合理但錯誤”地補全需求比如設(shè)計稿里一個沒有文字的按鈕它給編了一段文案雖然看起來沒問題但產(chǎn)品肯定不認(rèn)二是 FairyGUI 的層級疊放順序很敏感顯示列表從下到上就是渲染從下到上Agent 生成的順序偶爾會和設(shè)計稿相反一眼看過去問題不大真跑起來按鈕被背景擋住。所以最終的方案是Agent 負(fù)責(zé)生成人負(fù)責(zé)驗收確認(rèn)無誤再發(fā)布進(jìn)包。別覺得這樣效率低人審一個面板結(jié)構(gòu)只需要掃一眼樹形圖比從零開始手拼快了一個數(shù)量級。3. 核心實操從設(shè)計稿到 FairyGUI XML 的完整鏈路理論說完了上真東西。這一章我從協(xié)議、Prompt、映射、發(fā)布四個環(huán)節(jié)逐個拆確保你照著能做出來。3.1 第一步定義一份“UI 描述協(xié)議”要讓 Agent 穩(wěn)定輸出最重要的是給它一個足夠小的 JSON Schema。我定義的協(xié)議長這樣這套字段經(jīng)過幾輪迭代已經(jīng)能覆蓋 FairyGUI 里絕大多數(shù)靜態(tài) UI 場景{ $schema: http://example.com/ui-description.schema.json, type: object, required: [name, width, height, children], properties: { name: { type: string, description: 組件名與設(shè)計稿命名一致 }, width: { type: integer, description: 設(shè)計寬度單位 px }, height: { type: integer, description: 設(shè)計高度單位 px }, children: { type: array, items: { type: object, required: [type, name, x, y, width, height], properties: { type: { type: string, enum: [image, text, button, list, graph, component, loader] }, name: { type: string }, x: { type: integer, description: 相對父節(jié)點左上角的 X 坐標(biāo) }, y: { type: integer }, width: { type: integer }, height: { type: integer }, pivot: { type: array, items: { type: number }, minItems: 2, maxItems: 2, description: 軸心點如 [0.5, 0.5] 表示中心點 }, resource: { type: string, description: 圖片資源名必須來自資源清單 }, text: { type: string, description: 文本內(nèi)容僅 text/button 使用 }, fontSize: { type: integer }, color: { type: string, pattern: ^#[0-9a-fA-F]{6}$ }, controllers: { type: array, items: { type: object, required: [name, pages], properties: { name: { type: string }, pages: { type: array, items: { type: object, required: [id, title], properties: { id: { type: integer }, title: { type: string } } } } } } }, children: { type: array, description: 嵌套子節(jié)點遞歸結(jié)構(gòu) } } } } } }這套協(xié)議有幾個用心之處。第一type 字段用枚舉值從源頭堵住 Agent 發(fā)明新節(jié)點類型的可能。第二所有坐標(biāo)都是相對父節(jié)點的整數(shù)不搞 float 不搞百分比讓轉(zhuǎn)換器邏輯簡單Agent 也不容易算出小數(shù)。第三resource 字段明確標(biāo)注“必須來自資源清單”這是在為后文說的資源防幻覺做準(zhǔn)備。如果你有自己的特殊組件比如進(jìn)度條、滑動條可以在枚舉里加但一定要同時告訴 Agent 這些組件需要哪些額外字段。人話就是協(xié)議越小Agent 越穩(wěn)。3.2 第二步Prompt 怎么寫才能穩(wěn)定輸出有了 SchemaPrompt 就要把 AI 往這個 Schema 里趕。我試過幾種寫法最有效的是“角色限定 輸出格式硬約束 少樣本示例”三段式你是一名資深游戲 UI 結(jié)構(gòu)工程師熟悉 FairyGUI 的組件體系和層級規(guī)則。 現(xiàn)在需要你根據(jù)用戶提供的設(shè)計稿/需求描述輸出一份 UI 結(jié)構(gòu) JSON。 硬性要求 1. 只能使用 JSON 格式輸出不要包含任何解釋性文字。 2. 必須嚴(yán)格遵循給定的 JSON Schema不得新增字段不得修改枚舉值。 3. 所有 resource 字段的值必須從下面的資源清單中選擇禁止編造資源名。 4. 坐標(biāo)系為屏幕坐標(biāo)原點在左上角x 向右為正y 向下為正。 5. 嵌套結(jié)構(gòu)要合理同一層級的節(jié)點按渲染從底到頂?shù)捻樞蚺帕小?6. 如果設(shè)計稿中存在某個圖片或文字但資源清單中沒有對應(yīng)資源用 graph 節(jié)點占位并在輸出末尾 REMARKS 字段中說明。 資源清單 bg_main, btn_start, btn_shop, icon_coin, txt_title, panel_bag, item_bg 以下是輸出的 JSON 格式示例 { name: MainPanel, width: 1280, height: 720, children: [ ... ] } 請開始輸出。這段 Prompt 里最關(guān)鍵的是第 5 條“渲染從底到頂”因為我踩過坑Agent 默認(rèn)按照“從上往下讀設(shè)計稿”的順序排列子節(jié)點導(dǎo)致最底層的背景跑到了最上層。加上這一條之后層級順序錯誤率明顯下降。另外第 6 條也重要它給了 Agent 一條合法出路——資源缺失時用 graph 占位而不是硬編一個不存在的資源名。給 Agent 留退路比反復(fù)強調(diào)“不要亂編”有效得多。還有個小經(jīng)驗如果你接的是多模態(tài)模型最好把設(shè)計稿圖片直接喂進(jìn)去讓它對著圖輸出坐標(biāo)。但注意多模態(tài)模型的文字識別有時會把設(shè)計稿里的標(biāo)注數(shù)字當(dāng)成尺寸值這點在審閱時要重點檢查。3.3 第三步JSON 到 FairyGUI XML 的映射與生成校驗通過的 JSON 進(jìn)入轉(zhuǎn)換器這一步是把“協(xié)議描述”翻譯成“編輯器語言”。核心映射關(guān)系我整理成了一張表JSON 字段FairyGUI XML 元素/屬性說明type: imageimagesrc 屬性填資源名type: texttexttext 屬性填文案fontSize 映射 font-sizetype: buttonbutton內(nèi)部往往帶一個 title 文本節(jié)點type: listlist需要配合 item 模板 URLtype: graphgraph純占位圖形不綁資源x, yxy100,20相對父節(jié)點左上角width, heightsize200,80控件原始尺寸pivotpivot0.5,0.5軸心點附加 pivotAsAnchor 可選resourcesrcui://包名/資源名需要轉(zhuǎn)換器拼上包名前綴controllerscontroller生成 controller 節(jié)點并填充 pageschildren 里的嵌套結(jié)構(gòu)displayList內(nèi)嵌套關(guān)鍵是層級順序轉(zhuǎn)換器生成的 XML 大概是這個味道拿一個簡單的“背景 標(biāo)題 開始按鈕”做示例component size1280,720 controller namestate pages0,normal,1,selected/ displayList image namebg_main srcui://Game/bg_main size1280,720 xy0,0/ text nametxt_title font-size36 text歡迎回來 color#FFFFFF xy540,100 width200 height50 aligncenter/ button namebtn_start srcui://Game/btn_start xy540,300 width200 height80 relation targetbg_main sidealign_left width100%/ /button /displayList /component這里有兩個轉(zhuǎn)換器必須處理的細(xì)節(jié)。第一個是URL 前綴FairyGUI 里所有資源引用都是ui://包名/資源名格式JSON 里只寫資源名轉(zhuǎn)換器負(fù)責(zé)拼包名。第二個是relation 關(guān)聯(lián)JSON 協(xié)議里沒有直接體現(xiàn)我的做法是在轉(zhuǎn)換器里寫規(guī)則——如果某個節(jié)點有align需求就在 JSON 里加一個擴展字段轉(zhuǎn)換器識別后生成relation。生成完 XML 后一定先去 FairyGUI 編輯器里手動打開這個組件看一眼再發(fā)布。為什么因為轉(zhuǎn)換器只能保證語法正確不能保證視覺正確。編輯器里會直接暴露層級、坐標(biāo)、透明度這些問題比你看代碼快得多。3.4 第四步命令行發(fā)布與綁定代碼生成XML 寫進(jìn)工程目錄后接著要讓它變成引擎里能用的東西。FairyGUI 編輯器提供命令行入口可以這樣走FairyGUI-Editor.exe -publish 項目.fairy -package Game -output Assets/UI/Game具體參數(shù)名不同版本可能不一樣以你裝的編輯器版本為準(zhǔn)。但思路是一致的不進(jìn)編輯器 UI直接用命令行把 XML 編譯成引擎?zhèn)瓤杉虞d的資源包。這個能力特別適合接進(jìn) Jenkins 或本地腳本讓整條 UI 生成鏈路完全無人值守。資源包發(fā)布之后FairyGUI 會為每個組件生成綁定代碼比如 Unity 下的UI_MainPanel.cs。這里又輪到 Agent 出場了——它可以把這層包裝類的生成也接管一部分。我常讓它生成這種代碼public class MainPanelView { public GComponent root { get; private set; } public GButton btnStart { get; private set; } public GTextField txtTitle { get; private set; } public MainPanelView(GComponent root) { this.root root; this.btnStart root.GetChild(btn_start).asButton; this.txtTitle root.GetChild(txt_title).asTextField; } }這類代碼極其模式化人寫純屬浪費時間Agent 生成又快又穩(wěn)。而且只要你固定了命名規(guī)范Agent 生成出來的代碼風(fēng)格也會統(tǒng)一直接省掉代碼 review 里最無聊的部分。4. 落地時我踩過的坑和排查方法理想很豐滿現(xiàn)實里全是坑。這套流程我跑了一個多月踩的坑比預(yù)想的多得多而且很多坑特別隱蔽不實際操作根本想不到。我挑幾個影響最大的展開說。4.1 坐標(biāo)錯亂pivot、錨點、關(guān)聯(lián)三件套第一次用 Agent 生成復(fù)雜組件時我打開編輯器看到的畫面是所有按鈕都往右下角偏了半個身位文字全部跑到圖片外面。排查了半天問題出在 pivot 上。FairyGUI 的坐標(biāo)系統(tǒng)是“相對父組件左上角”但如果節(jié)點設(shè)置了 pivot它的 xy 定位就變成以 pivot 點為準(zhǔn)。Agent 從設(shè)計稿里讀到的坐標(biāo)是基于左上角的它又不理解 pivot 語義于是把pivot0.5,0.5一加整個節(jié)點就偏移了。解決方法是普通靜態(tài)節(jié)點不設(shè) pivot只有需要旋轉(zhuǎn)、縮放動效的節(jié)點才設(shè)。在協(xié)議里明確“默認(rèn)無 pivot除非特別說明”并且在轉(zhuǎn)換器里加一條強制規(guī)則——如果 JSON 里沒有 pivot 字段XML 里堅決不輸出 pivot。這個坑踩一次就夠了。4.2 Agent 幻覺資源用資源清單做硬約束這是所有坑里出現(xiàn)頻率最高的。Agent 會一本正經(jīng)地引用一個根本不存在的圖片資源名比如設(shè)計稿上有個背包按鈕它直接輸出resource: icon_bag但工程里的資源實際叫bag_icon。如果你沒加保護(hù)轉(zhuǎn)換器會生成一個 XMLFairyGUI 編譯時直接報資源缺失整包發(fā)布失敗。我前面提到的“資源清單喂給 Agent”就是干這個的。但光喂還不夠轉(zhuǎn)換器一定要做二次校驗把 Agent 輸出 JSON 里的 resource 字段全部抽取出來和本地資源清單做集合比對一旦發(fā)現(xiàn)未知資源直接中止流程并把錯誤反饋給 Agent 重試。整套過程會自動跑通常一次重試就能糾正。實測下來資源幻覺率能從三成壓到 5% 以下。4.3 控制器狀態(tài)漏生成運行時 UI 點不動還有一個低頻但特別影響體驗的問題Agent 生成的組件少了控制器。比如一個按鈕需要 normal / pressed / selected 三個狀態(tài)Agent 經(jīng)常只給一個基礎(chǔ) image 節(jié)點忘了補控制器。結(jié)果運行時按鈕點擊沒有反饋UI 看起來像死了一樣。排查這種問題不能用肉眼看 XML得用腳本把所有button類型節(jié)點揪出來檢查它是否至少有一個 controller。我在轉(zhuǎn)換器校驗環(huán)節(jié)加了一條規(guī)則button 節(jié)點必須有名為 state 的控制器且 pages 數(shù)量不少于 2否則視為校驗失敗。這樣就把這個問題從“運行時才發(fā)現(xiàn)”提前到了“生成時就被攔截”。4.4 多個 Agent 并行時的沖突Git 才是隱形殺手當(dāng)我把這套流程擴大到一個四人小組使用時又遇到新問題大家各自讓 Agent 生成面板同時往同一個工程目錄里寫 XMLgit 沖突比手寫代碼還嚴(yán)重。因為 FairyGUI 工程里有個全局文件記錄了所有資源的 GUID 和組件引用關(guān)系多人同時改這個文件幾乎必然打架。我的應(yīng)對方案是每個 UI 包拆分獨立目錄每個 Agent 任務(wù)只允許寫自己負(fù)責(zé)的包合并時禁止并行寫同一包另外把 FairyGUI 的工程文件全量納入 Git 管理XML 是文本文件可以 diff、可以 review沖突至少能看見。這個教訓(xùn)是自動化生成不是免死金牌流程規(guī)范還是得人來定。4.5 常見問題速查表最后整理一張速查表遇到問題可以快速定位現(xiàn)象可能原因處理方式組件發(fā)布后資源缺失Agent 生成不存在的資源名轉(zhuǎn)換器加資源清單比對 自動重試節(jié)點整體偏移pivot 與坐標(biāo)語義沖突XML 不主動輸出 pivot按需設(shè)置按鈕點擊無反饋缺少控制器 pages校驗 button 節(jié)點的 controller 數(shù)量渲染層級不對displayList 順序顛倒Prompt 明確“底到頂”順序 人工審閱Git 沖突頻繁多人同時改同一 UI 包包級隔離禁止并行寫同一包文字內(nèi)容被 Agent 妄改需求描述不完整在協(xié)議里增加“支持原文引用”字段XML 語法正確但編輯器打不開版本不兼容或字段拼錯先打開編輯器看報錯日志再轉(zhuǎn)換器補兼容5. 給想接手這套流程的人四個實在建議前面把思路、代碼、坑都講完了最后說幾句掏心窩子的建議。如果你真想把 Agent 接進(jìn) FairyGUI 流程別急著一步到位按下面這個節(jié)奏來。5.1 從組件級接管開始別一上來就整面板我最開始想直接生成整個主界面結(jié)果被層級、控制器、關(guān)聯(lián)三座大山壓得喘不過氣。后來我退一步先讓 Agent 只生成“單組件”——比如一個按鈕、一個列表項、一個彈窗框架。這類結(jié)構(gòu)簡單字段少校驗規(guī)則也好寫。跑了幾天發(fā)現(xiàn)效率確實高再逐步擴大到完整面板。步子太大容易扯著這點在 AI 流程里也一樣適用。5.2 建一個自己的組件模板庫Agent 生成的節(jié)點結(jié)構(gòu)雖然對但風(fēng)格不一定符合你們團(tuán)隊習(xí)慣。我的做法是把團(tuán)隊里既有的優(yōu)質(zhì)組件結(jié)構(gòu)抽成模板寫進(jìn)轉(zhuǎn)換器里。比如“標(biāo)準(zhǔn)按鈕”就是“底圖 文字 state 控制器”轉(zhuǎn)換器遇到type: button時直接用模板生成而不是讓 Agent 自由發(fā)揮。模板庫越厚Agent 的自由度就應(yīng)越小整體質(zhì)量越可控。5.3 用失敗案例反向喂給 Prompt每次 Agent 生成的組件被打回我都會把錯誤原因整理成一句話加進(jìn) Prompt。比如“列表項內(nèi)部禁止嵌套滾動容器”“所有文本節(jié)點必須提供 color”。實踐兩三個星期后Agent 的生成質(zhì)量會有肉眼可見的提升。這比換更大參數(shù)的模型管用因為問題往往出在領(lǐng)域細(xì)節(jié)而不是模型智力上。5.4 留一條手工兜底的快捷通道最后提醒一句別把手工能力丟掉。我做這套流程時仍然保留了“手動微調(diào)”的工作習(xí)慣——Agent 生成的組件進(jìn)編輯器后我會快速拖一兩個節(jié)點做微調(diào)。不是因為 Agent 不好用而是因為有些細(xì)節(jié)比如像素級對齊的視覺感受機器判斷不如人眼敏感。工具的意義是讓你把時間花在真正需要判斷力的事情上而不是幫你徹底偷懶。我現(xiàn)在的工作習(xí)慣已經(jīng)完全變了早上到公司先看設(shè)計稿更新把需求丟給 Agent它生成結(jié)構(gòu)、自動校驗、發(fā)布資源我這邊做審閱和微調(diào)。原來一天手拼兩三個面板的工作量現(xiàn)在能從容地做完一整層 UI 體系。這個方向未來還有很大空間比如把動效、狀態(tài)機的生成也納入進(jìn)來但那又是另一篇文章了。