1. 為什么生成UI會分成兩條完全不同的路子最近在很多開發(fā)團(tuán)隊里都能聽到類似的爭論AI 都能直接生成 UI 了為什么我們還要維護(hù)組件庫、搭模板、寫配置有人把 Vercel 的 v0、bolt.new 的生成界面甩到群里幾秒鐘出一個完整頁面看起來確實(shí)驚艷?？烧姘?AI 自由生成的界面放進(jìn)生產(chǎn)環(huán)境跑兩周問題就全冒出來了——樣式不統(tǒng)一、交互邏輯隨機(jī)、無障礙屬性缺失、代碼沒人敢動。另一邊那些堅持用配置模板渲染的團(tuán)隊又總被業(yè)務(wù)方抱怨做個落地頁還要排期。這兩撥人其實(shí)都沒錯只是他們在討論的根本不是同一件事。先說結(jié)論自由生成和配置模板渲染不是同一個問題的兩個解法而是兩個完全不同的問題的解法。自由生成解決的是從無到有的探索效率配置模板渲染解決的是從有到穩(wěn)的控制成本。選哪條路線取決于你的產(chǎn)品處在哪個階段、界面承擔(dān)什么角色、團(tuán)隊能接受多大的不確定性。這篇文章我想把這兩條路線的底層邏輯拆開講清楚各自適合什么場景、成本藏在哪兒、以及怎么用一套判斷框架做選型。最后會聊聊我實(shí)際踐行的混合路線因?yàn)榇蠖鄶?shù)產(chǎn)品最終都會走到先自由探索、后模板固化這條路上去。1.1 從一句話出一個頁面說起很多人對 AI 生成 UI 的第一印象來自這類動圖輸入做一個 SaaS 數(shù)據(jù)分析的 Dashboard左邊側(cè)邊欄中間圖表區(qū)深色主題幾秒鐘后一個漂亮的頁面就出來了。自由生成路線的基本流程是你把需求用自然語言描述清楚大模型理解后直接輸出前端代碼——一般是 HTML、CSS、Tailwind 或者 React 組件代碼——有些工具甚至直接給你一個可預(yù)覽的鏈接。它模仿的是設(shè)計師的工作方式給定一個抽象需求人腦快速想象出一個具體的視覺與布局方案。這套邏輯的優(yōu)勢寫在了明面上沒有邊界。沒有預(yù)設(shè)組件、沒有模板字段、沒有系統(tǒng)不支持這個布局。你想要任何形式的頁面它都能給你畫出來。再加上對話式修改——把圖表換成卡片按鈕改成圓角密度調(diào)高一點(diǎn)——整個低保真探索過程被壓縮到了分鐘級。但問題恰恰也出在沒有邊界上。你讓 AI 自由生成十個版本的頁面它給你十個不同風(fēng)格的頁面你讓 AI 修改一個按鈕顏色它可能連整體的陰影、圓角、間距一起改了。這種隨機(jī)性在探索階段是靈感在交付階段是災(zāi)難。1.2 一個容易忽略的前提UI 的生成發(fā)生在哪一層要理解兩條路線的本質(zhì)差異得先搞清楚一個問題UI 的生成發(fā)生在什么層級自由生成發(fā)生在代碼層。AI 直接生成的是瀏覽器最終運(yùn)行的那套標(biāo)記和樣式?jīng)]有中間層沒有結(jié)構(gòu)化描述。頁面長什么樣、交互怎么走全部硬編碼在生成的代碼里。你要改頁面只能改代碼或者讓 AI 重新生成一段新代碼。配置模板渲染發(fā)生在數(shù)據(jù)層。頁面長什么樣由一個 JSON 或 Schema 來描述運(yùn)行時由渲染引擎把這個配置翻譯成真實(shí)的 UI。組件是預(yù)先封裝好的交互是預(yù)先定義好的配置只負(fù)責(zé)控制顯示哪個組件、傳什么參數(shù)、按什么順序排列。這兩條路線的差異根源就在這個層的選擇上。代碼層直出效率高但不可控數(shù)據(jù)層中間多了一層犧牲一定自由度換來了規(guī)則和管理能力。這也是為什么很多人在做選型時容易混淆他們拿配置模板渲染的不夠自由去對比自由生成的生產(chǎn)效率卻忽略了自己項目的核心訴求到底是快速出活還是長期可控。搞清楚這個問題選型的方向就清楚了一大半。2. 自由生成效果上限高但自由的另一面是失控2.1 自由生成到底是怎么工作的自由生成工具的底層邏輯本質(zhì)上還是大模型生成代碼。你可能覺得這不稀奇但這里有個值得琢磨的技術(shù)細(xì)節(jié)它生成的不只是能看的頁面而是可以直接進(jìn)入工程體系的代碼資產(chǎn)。拿 v0 舉例它背后用了 React Tailwind CSS shadcn/ui 這套現(xiàn)代前端技術(shù)棧。生成出來的代碼是模塊化的、可以直接復(fù)用的組件代碼而不是一張寫死的圖片。這意味著你在探索階段產(chǎn)出的東西理論上可以直接組裝進(jìn)真實(shí)應(yīng)用。再比如 screenshot-to-code 這種工具直接把設(shè)計稿圖片變成 HTML/CSS 代碼。它的本質(zhì)同樣是代碼生成只不過輸入從自然語言變成了圖像。這里要補(bǔ)充一個重要認(rèn)知自由生成的價值不在于生成而在于快速逼近目標(biāo)。你描述需求→得到頁面→提出修改→再得到新頁面這個反饋循環(huán)的速度才是它真正的殺手锏。傳統(tǒng)方式下一個交互視覺方案從腦暴到可評審的稿子需要 1-2 天AI 自由生成把這個過程壓縮到了 10 分鐘。探索的邊際成本趨近于零你可以放心大膽地試錯。2.2 自由生成適合的現(xiàn)場高探索、低復(fù)用那自由生成適合用在什么場景我的經(jīng)驗(yàn)是高探索、低復(fù)用的場景尤其適合自由生成。舉幾個具體的例子第一個用戶落地頁、營銷活動頁、產(chǎn)品介紹頁。這類頁面追求視覺沖擊力和獨(dú)特性沒有嚴(yán)格的組件規(guī)范約束而且基本是一次性使用不需要跨頁面復(fù)用。讓 AI 從空白畫布開始自由發(fā)揮效率極高。第二個產(chǎn)品早期的概念驗(yàn)證PoC。你想驗(yàn)證這個產(chǎn)品形態(tài)有沒有人用需要先快速做一個有視覺質(zhì)感的 Demo 去跟投資人、早期用戶溝通。這時候連業(yè)務(wù)邏輯都不穩(wěn)定更別說沉淀設(shè)計系統(tǒng)。自由生成模式可以讓你在一周內(nèi)做出三個完全不同風(fēng)格的 Demo 出去測試市場反應(yīng)。第三個設(shè)計靈感探索。設(shè)計師拿草稿讓 AI 快速生成多種視覺風(fēng)格進(jìn)行對比拓寬設(shè)計思路。這種開放性生成本身就是在做探索自由生成在機(jī)制上和這個場景天然匹配。在這些場景里自由生成的隨機(jī)性反而是優(yōu)點(diǎn)。因?yàn)槟阋木褪嵌鄻踊匕l(fā)散、快速地看效果你不需要每一次生成結(jié)果都嚴(yán)格一致。2.3 繞不開的三筆賬一致性、可維護(hù)性、可測試性但自由生成的賬遲早要還。還的方式就是下面這三筆。一筆是一致性賬。AI 生成的組件是獨(dú)立的、沒有一個統(tǒng)一的視覺規(guī)范在背后約束它。同一個按鈕在 A 頁面是藍(lán)色圓角在 B 頁面可能就是深藍(lán)直角。哪怕你明確要求統(tǒng)一風(fēng)格模型也只能在一個有限的上下文窗口里保持一致。當(dāng)你的產(chǎn)品擴(kuò)展到幾十個頁面時靠自然語言約束的一致性必然會崩潰。一筆是可維護(hù)性賬。AI 生成的代碼質(zhì)量參差不齊。這次生成的組件用了 Tailwind 的 flex下次可能用了 grid這次狀態(tài)管理寫的是 useState下次可能直接甩個全局變量。當(dāng)你需要在這個代碼基礎(chǔ)上迭代時你會發(fā)現(xiàn)團(tuán)隊改 AI 生成的代碼跟改別人寫的祖?zhèn)鞔a一樣痛苦。而且更麻煩的是很多人讓 AI 生成代碼之后從不做代碼審查直接提交生產(chǎn)。還有一筆是可測試性賬。自由生成出來的 UI沒有對應(yīng)的自動化測試和可預(yù)期的渲染結(jié)果。UI 自動化測試需要有穩(wěn)定的 DOM 結(jié)構(gòu)和定位方式自由生成的代碼在多次修改后結(jié)構(gòu)可能每次都不同測試腳本的價值大打折扣。這一點(diǎn)在后面做混合路線時特別重要——你最終會需要把自由生成的可視結(jié)果收斂成一套可測試的穩(wěn)定結(jié)構(gòu)。前面提到熱搜詞里有人問前端和 UI 區(qū)別其實(shí)放在這里正好能說明問題自由生成的頁面是UI是一眼看得到的視覺層但把它變成前端變成可持續(xù)維護(hù)、可測試、可擴(kuò)展的工程資產(chǎn)中間的鴻溝需要人或者配置體系來補(bǔ)。3. 配置模板渲染把 UI 變成結(jié)構(gòu)化數(shù)據(jù)把變化收斂到配置層3.1 渲染引擎 Schema模板渲染的最小構(gòu)成配置模板渲染這條路線聽起來技術(shù)味很重其實(shí)就是日常大家熟悉的后臺界面配置化和低代碼渲染本質(zhì)都是這個思路。它的核心構(gòu)成只有兩塊**一份 Schema結(jié)構(gòu)描述用 JSON 或 YAML 描述頁面里有哪些組件、每個組件的位置、屬性、數(shù)據(jù)來源、交互行為。它是UI 的數(shù)據(jù)化表達(dá)。一個渲染引擎Runner讀這份 Schema按規(guī)則實(shí)例化真實(shí)的組件接管事件交互處理數(shù)據(jù)綁定最終把 UI翻譯到界面上。渲染引擎加上一套成熟的組件庫就是模板渲染的最小閉環(huán)?，F(xiàn)實(shí)里的實(shí)現(xiàn)很多開源的Amis百度出品JSON 配置生成后臺頁面、國外的JSON Forms專攻表單渲染、FormlyAngular 生態(tài)、還有各種基于 headless UI 庫自研的 Schema 渲染器。前端熱詞里提到的Element UI就常常作為這類渲染器背后的組件底座——配置描述這個位置放一個 el-input渲染器就去實(shí)例化一個 Element UI 的輸入框并綁上事件和數(shù)據(jù)。這套機(jī)制能把 UI 的變化全部數(shù)據(jù)化產(chǎn)品經(jīng)理改頁面不用改代碼直接改配置服務(wù)端下發(fā)一個新配置前端立刻渲染出新界面。配置即界面這就是模板渲染和自由生成在層上最本質(zhì)的分叉。3.2 一個能用起來的最小配置例子光說不練沒用我給你一個最小可運(yùn)行的配置模板渲染例子你一看就懂。假設(shè)我用 Amis 來渲染一個帶搜索框和表格的簡單頁面配置長這樣{ type: page, title: 訂單管理, body: [ { type: form, body: [ { type: input-text, name: keyword, label: 關(guān)鍵詞, placeholder: 輸入訂單號 }, { type: button, label: 搜索, actionType: reload, target: orderTable } ] }, { type: table, name: orderTable, source: { method: get, url: /api/orders?keyword${keyword} }, columns: [ { name: order_no, label: 訂單號 }, { name: amount, label: 金額 }, { name: status, label: 狀態(tài) } ] } ] }這份 JSON 描述了一個完整頁面一個輸入框、一個按鈕、一個綁定遠(yuǎn)程數(shù)據(jù)源的表格。渲染引擎拿到它就會在界面上渲染出對應(yīng)的真實(shí)組件并且自動處理搜索、刷新、數(shù)據(jù)請求這些邏輯。這就是配置模板渲染的縮影。你會發(fā)現(xiàn)頁面是什么組件堆出來的、數(shù)據(jù)從哪來、交互怎么走全部變成了可驗(yàn)證、可比對、可版本控制的配置。同一份配置放在測試環(huán)境和生產(chǎn)環(huán)境渲染出來的 UI 結(jié)構(gòu)完全一致。這給 UI 自動化測試帶來的好處是直接的——DOM 結(jié)構(gòu)穩(wěn)定測試腳本就有穩(wěn)定的錨點(diǎn)。3.3 配置模板不是做不了復(fù)雜交互而是把復(fù)雜拆成可控很多人一聽到配置模板第一反應(yīng)是那只能做做后臺管理系統(tǒng)這種規(guī)規(guī)矩矩的頁面吧。這其實(shí)是一個誤區(qū)。配置模板渲染的真正優(yōu)勢不在于只能做簡單 UI而在于它能通過分層組合把復(fù)雜交互也變成可配置的復(fù)雜。拿一個常見的自定義工作流頁面來舉例。里面有動態(tài)表單、步驟條、分支條件、懶加載區(qū)、上下文的級聯(lián)聯(lián)動——這些交互邏輯如果用傳統(tǒng)前端硬編碼改一次需求動一次代碼。但用配置模板渲染你可以做三件事把復(fù)雜組件封裝成可配置組件條件分支組件、步驟條組件、流程連接線組件這些在渲染引擎里注冊好后配置層只用寫type: flow-step加幾個屬性就能用。把頁面拆成可嵌套的子配置配置可以互相引用、嵌套一個大的復(fù)雜頁面可以拆成多個子 Schema分團(tuán)隊維護(hù)最終由一個聚合 Schema 組合渲染。把交互狀態(tài)變成可配置的數(shù)據(jù)流組件與組件之間的聯(lián)動選擇省份后動態(tài)加載城市數(shù)據(jù)在模板渲染里通常通過事件編排和數(shù)據(jù)源綁定實(shí)現(xiàn)邏輯清晰、可測試不復(fù)用全局變量和隱式依賴。所以配置模板渲染限制不了你的想象力它只是把想象的代價前置了你需要提前定義好組件邊界和交互協(xié)議之后所有的變化都只在配置數(shù)據(jù)里流動。自由生成是每次都能畫一張新畫配置模板是把筆畫和規(guī)則定義好之后每次只改寫的字。4. 我的選型判斷框架四個問題直接定方向現(xiàn)在進(jìn)入最實(shí)操的部分。落到具體項目時到底應(yīng)該怎么選我看了很多團(tuán)隊在這個問題上反復(fù)搖擺本質(zhì)原因都是憑感覺在投票。我自己總結(jié)了一套判斷框架用四個問題來定方向每個問題都指向一個不可回避的技術(shù)現(xiàn)實(shí)。4.1 這頁 UI 是給用戶看還是給流程用第一問題判斷界面的本質(zhì)屬性。如果這頁 UI 的核心價值是看——視覺沖擊力、品牌氛圍、IP 形象、情感共鳴——比如營銷落地頁、品牌官網(wǎng)、新品發(fā)布會頁面那自由生成是首選。因?yàn)樗非蟮氖遣豢蓮?fù)制的獨(dú)特性每頁都可以長得不一樣這正是自由生成的優(yōu)勢區(qū)。如果這頁 UI 的核心價值是用——完成任務(wù)、填寫信息、查看數(shù)據(jù)、審批流轉(zhuǎn)——比如后臺管理系統(tǒng)、中后臺工作臺、數(shù)據(jù)報表、配置面板那配置模板渲染就更合適。這類界面用戶要的是效率、穩(wěn)定、可預(yù)期而不是視覺新奇。用戶每天都在點(diǎn)同一個按鈕按鈕的位置至少得固定。我把這叫做展示型頁面 vs 操作型頁面的識別。很多項目糾結(jié)選型其實(shí)是一個系統(tǒng)里同時存在兩種頁面有展示型的官網(wǎng)也有操作型的后臺。不要試圖一條路線通吃分開處理是最高效的。4.2 你的界面改版頻率有多高第二個問題評估界面變化的節(jié)奏。如果這個 UI 一個月改一次版或者每次營銷活動都要全新?lián)Q皮自由生成是劃算的。因?yàn)樗〉袅司S護(hù)設(shè)計規(guī)范的成本每次都從零開始生成快且不需要考慮舊資產(chǎn)的兼容性。如果這個 UI 每周甚至每天都有微小調(diào)整——加一個字段、調(diào)一個排序、增加一種流程狀態(tài)——那配置模板渲染的價值就展現(xiàn)出來了。改配置的邊際成本遠(yuǎn)低于改代碼更低于是重新讓 AI 生成一遍代碼。改配置還天然帶審計日志——你永遠(yuǎn)知道這個字段是什么時候、被誰改過來的。這在合規(guī)嚴(yán)格的企業(yè)內(nèi)部系統(tǒng)里是硬性需求。判斷標(biāo)準(zhǔn)就一條你的 UI 是一次性的還是持續(xù)演進(jìn)的一次性的走自由生成持續(xù)演進(jìn)的走模板渲染。4.3 團(tuán)隊能不能兜住不確定性第三個問題最容易被忽視卻往往決定成敗團(tuán)隊的工程能力和風(fēng)險偏好。自由生成路線的最大隱性成本是不確定性。AI 生成的代碼你無法預(yù)測它的結(jié)構(gòu)、它的依賴、它的邊界行為。團(tuán)隊里必須有人具備能力去審查、修正、兜底——如果沒有人能真正理解 AI 生成這段代碼的含義并且能在它出錯時把它改對那么初期的效率紅利會在后期被技術(shù)債連本帶利地吞掉。相比之下配置模板渲染的不確定性很低。配置是結(jié)構(gòu)化數(shù)據(jù)有 Schema 校驗(yàn)有組件庫的能力邊界約束。組件庫本身是開發(fā)團(tuán)隊一行行寫出來的渲染行為是可預(yù)期的。哪怕出問題排查范圍也固定在配置對錯或者組件 Bug這兩個象限里不會出現(xiàn)為什么 AI 生成了一百行我看不懂的爛代碼這種災(zāi)難。所以團(tuán)隊里有沒有人能兜住 AI 生成代碼的不確定性直接決定了你有沒有資格享受自由生成的效率紅利。4.4 上游數(shù)據(jù)模型是否穩(wěn)定第四個問題看向依賴的數(shù)據(jù)層。做配置模板渲染的前置條件是你至少能大致描述出數(shù)據(jù)模型——訂單有哪些字段、用戶有哪些狀態(tài)、審批流有哪些節(jié)點(diǎn)。因?yàn)榕渲媚０謇锏拿恳粋€組件本質(zhì)上是結(jié)構(gòu)化數(shù)據(jù)在界面上的投影它的字段、類型、關(guān)聯(lián)關(guān)系要基本穩(wěn)定渲染層才能建立起穩(wěn)定的映射。如果數(shù)據(jù)模型還在劇烈變動期——今天有價格字段明天改成原價/折扣價兩段式后天冒出個會員專屬價——那自由生成反而更合適。直接用 AI 在界面上鋪陳一個模糊但好看的結(jié)構(gòu)跟著數(shù)據(jù)模型的搖擺快速迭代。等數(shù)據(jù)模型穩(wěn)定了再把界面固化到模板渲染路線上。你可以用需求爛熟度來輔助判斷需求反復(fù)橫跳、講不清楚的場景自由生成需求已經(jīng)形成清晰的字段和流程定義配置模板。四個問題做完了最后再疊加一個決策矩陣你可以直接對號入座判斷維度偏向自由生成偏向配置模板渲染頁面屬性給用戶看展示/營銷給流程用操作/管理變更頻率一次性/低復(fù)用持續(xù)演進(jìn)/高頻微調(diào)團(tuán)隊不確定性兜底有資深前端審查兜底組件與配置邊界清晰數(shù)據(jù)模型成熟度需求未定型、字段快速變化字段/流程基本穩(wěn)定典型場景官網(wǎng)、活動頁、MVP Demo后臺、工作臺、審批流5. 混合路線真正能落地的做法是先自由后收斂5.1 探索-固化-渲染的三階段流程大多數(shù)真實(shí)產(chǎn)品走到最后都既不是純自由生成也不是純配置模板而是混合路線。我自己的項目就是典型例子產(chǎn)品是后臺管理系統(tǒng)核心頁面走配置模板渲染但每當(dāng)我們設(shè)計一個新模塊也是用自由的 AI 生成工具先跑出幾個不同風(fēng)格的初稿。探索、評審、確定方向之后才把確定下來的視覺和結(jié)構(gòu)固化到模板組件里然后拿到渲染引擎上去多場景復(fù)用。我把這個流程叫探索—固化—渲染三階段探索階段用自由生成工具讓 AI 快速產(chǎn)出多個布局和視覺方向供產(chǎn)品、設(shè)計、開發(fā)一起評審。這時候追求的是快和多一定要打開腦洞讓 AI 自由發(fā)揮。固化階段評審選定方向后設(shè)計師/前端把這套定調(diào)的視覺語言拆解成可復(fù)用的組件和樣式規(guī)范在組件庫里注冊成新的可配置組件。這一步是把一次性的靈感轉(zhuǎn)成標(biāo)準(zhǔn)化的資產(chǎn)。渲染階段新組件正式進(jìn)入模板配置庫后續(xù)所有新頁面復(fù)用不再需要 AI 生成一次代碼。頁面之間的排列組合變成了修改配置數(shù)據(jù)。這個模式的好處是什么它把自由生成放在它該在的位置——靈感探索把配置模板渲染放在它擅長的地方——工程交付。兩者各司其職不打架。5.2 混合落地時三個最容易踩的坑混合路線聽起來美好實(shí)際操作里坑非常多。我把我踩過的或者見證別人踩過的三個先列出來你再走會順很多。第一個坑探索階段過度信任 AI 生成的設(shè)計。AI 生成的 UI 視覺效果往往很好但很少考慮無障礙對比度、移動端適配、不同字體渲染下的留白塌陷、以及 loading/error/empty 這些邊界狀態(tài)。你把一個只有理想態(tài)的頁面當(dāng)成最終方案去固化等于把隱患一起固化進(jìn)了組件庫。正確的做法是AI 生成結(jié)果只當(dāng)作視覺方向固化成組件前必須窮舉空態(tài)、加載態(tài)、錯誤態(tài)。第二個坑固化階段的成本被嚴(yán)重低估。把 AI 生成的一次性頁面固化成標(biāo)準(zhǔn)化、可配置的模板組件不是簡單地把代碼復(fù)制進(jìn)組件庫里就行。你要做 state 設(shè)計、props 規(guī)范、Schema 定義、事件協(xié)議、單元測試、文檔。這些工作量加起來常常比直接從頭手寫一個組件還大導(dǎo)致團(tuán)隊在這個環(huán)節(jié)很容易滑坡。我實(shí)際嘗試下來的建議是固化的節(jié)奏要克制優(yōu)先固化復(fù)用頻率最高、復(fù)雜度中等偏上的組件——不是所有頁面都值得固化。第三個坑Schema 設(shè)計過度/不足。配置模板渲染里Schema 的設(shè)計直接決定靈活性。過度設(shè)計配置寫起來比寫代碼還麻煩每個字段都一堆可選項設(shè)計不足頁面一復(fù)雜就需要在配置里寫大量custom組件退化成換皮硬編碼。Schema 設(shè)計的核心原則是只暴露業(yè)務(wù)變化的維度把實(shí)現(xiàn)細(xì)節(jié)全部封裝在組件內(nèi)部。訓(xùn)練有素的配置開發(fā)團(tuán)隊看一眼配置就能知道這一頁的結(jié)構(gòu)是清晰還是失控。配置也是代碼也要有 code review。它只是把 UI 的代碼換成了數(shù)據(jù)。提示接上前面提到的 UI 自動化話題混合路線在測試上的最佳實(shí)踐是——在固化階段給組件接上穩(wěn)定的>