這項由香港科技大學（廣州）、香港科技大學、阿里巴巴通義實驗室、韓國電子通信研究院及螞蟻集團聯合完成的研究，以預印本形式發布於2026年4月，論文編號為arXiv:2604.20398，感興趣的讀者可通過該編號查閱完整原文。
**網站背後藏著什麼難題？**
打開一個現代網站，點擊導航欄，頁面流暢跳轉；填寫一張表單，數據實時驗證；瀏覽一個電商頁面，布局精美、層次分明。這些看似平常的體驗，背後其實是由數十個甚至數百個文件構成的複雜工程，涉及路由配置、狀態管理、組件依賴、樣式系統……任何一個環節出了差錯，整個網站就可能崩塌為一片白屏。
現在，大型語言模型（AI語言助手，簡稱LLM）已經能熟練地寫出單個函數、調試簡單腳本。但讓它獨立"交付"一個完整的多頁面網站，卻是另一回事——這就像讓一個能熟練切菜的廚師，忽然要求他獨自設計並經營一家五星級餐廳，從菜單到裝修再到服務流程全部搞定。這項研究的核心問題正是：能不能訓練一個只有70億參數的小型開源模型，讓它真正學會端到端地生成可運行、好看又好用的多頁面網站？
答案是肯定的，而且效果出人意料。研究團隊提出的方案叫做 **WebGen-R1**，它藉助強化學習（一種"讓AI在不斷試錯中學習的方法"），在只有70億參數的基礎模型上實現了突破——不僅碾壓了同等量級乃至參數量高達720億的開源大模型，甚至在某些關鍵指標上超越了擁有6710億參數的DeepSeek-R1。
---
一、從單個函數到整個網站，差距究竟有多大
要理解這項研究的價值，首先得搞清楚"寫函數"和"建網站"之間的鴻溝。
寫一個函數，就像做一道菜：給一個輸入，返回一個輸出，對不對很容易驗證——運行一下測試用例就知道了。而生成一個完整的多頁面網站，更像是從零開始建造並經營一家餐廳：廚房（後端邏輯）要和前台（界面）對齊，菜單（路由配置）要和每道菜（頁面組件）嚴格對應，裝修風格（視覺設計）要前後一致，而且顧客（用戶）來了真的要能點單、結賬、看訂單歷史。任何一個環節脫節，這家餐廳就開不起來。
過去的AI方案大致分為兩類。一類是"簡化版"——只生成單頁靜態網站，把那些複雜的動態路由、用戶認證、跨頁交互全部略去，這樣的網站在現實中幾乎沒有實用價值。另一類是"多智能體編排"——把任務拆給多個專門的AI子系統，一個負責寫界面，一個負責寫後端接口，一個負責測試，再由一個"總指揮"把各部分拼在一起。這個思路聽起來合理，但問題在於，各子系統之間的"契約"極其脆弱：一個文件名的細微出入、一個接口參數的類型不匹配，就可能讓整個工程無法編譯。更麻煩的是，這類方案通常依賴昂貴的商業大模型，每次生成要來回跑很多輪，耗費大量時間和費用。
WebGen-R1 選擇了第三條路：用強化學習訓練一個小型開源模型，讓它在一次生成中獨立完成整個網站項目，不藉助外部智能體編排，不依賴商業模型。
---
二、搭腳手架：先給AI一個"毛坯房"再讓它裝修
研究團隊面對的第一個挑戰是：網站生成的"行動空間"太大了。讓模型從一張白紙開始生成一個多頁面React項目，相當於讓它在一個無限大的草稿紙上隨意塗寫——它可能隨手發明一個不存在的構建工具，或者忘記在`package.json`里聲明某個依賴，導致整個項目根本無法安裝運行。
研究團隊的解決方案是"腳手架驅動的結構化生成"，用餐廳類比就是：不讓廚師從挖地基開始，而是給他一棟已經建好水電管道、確認消防合格的毛坯房，告訴他"你只需要負責裝修和做菜"。
具體做法是引入一個預先驗證過的React模板（基於`vite-react-typescript-starter`），這個模板固定了項目的骨架：入口文件、構建配置、路由架構、伺服器配置全都寫死，保證不會出錯。模型只需要生成"可變組件"——也就是各個頁面的內容、組件代碼、樣式文件等真正需要根據用戶需求定製的部分。生成完畢後，這些可變部分被自動"注入"到固定骨架的對應槽位，合併成一個完整的網站項目。
從數學上說，模型的生成過程被精確建模為：在給定系統提示、用戶需求說明和模板上下文的條件下，按順序生成每個可變組件的每個詞元（token）。這種約束確保了一件之前幾乎不可能保證的事：生成出來的項目，其基礎結構天然就是合法的。
---
三、分級審查：用"兩道關卡"替代昂貴的人工探索
即便有了腳手架約束，模型生成的內容仍然可能出錯——比如引用了一個沒有生成的組件文件，或者在`package.json`里填了語法錯誤的JSON。如果直接把這些內容送去做"獎勵評分"，不僅浪費算力，還會給模型提供混亂的學習信號。
研究團隊在獎勵計算之前設計了一個"分級過濾流水線"，就像餐廳出菜前的雙重檢查：先由領班檢查擺盤是否符合規範，再由試菜員確認口味是否合格，只有兩關都過了，菜才會端上桌子讓顧客評分。
第一道關卡叫"靜態合規驗證"。系統會在不運行任何代碼的情況下，檢查生成結果是否滿足四類約束：項目整體結構是否合法（文件夾層級對不對）、必要文件是否都存在（`App.tsx`、`main.tsx`等核心文件有沒有）、關鍵命令是否聲明（安裝命令和啟動命令寫了沒有）、內容層面的基本規則是否遵守（`package.json`格式是否正確、組件導出模式是否合法等）。四類約束全部以邏輯"與"的方式組合，任意一項不滿足，這次生成就直接被判定為失敗，不進入第二道關卡，立刻返回懲罰信號。
通過第一道關卡的項目會進入第二道關卡："自動化構建與渲染"。系統會依次執行四個步驟：安裝依賴（npm install）、打包構建（Vite/Webpack）、啟動本地伺服器、用無頭瀏覽器截圖並收集運行日誌和控制台錯誤。最終得到的"觀測結果"包括多個頁面的截圖、運行時日誌和瀏覽器控制台日誌，這三部分一起送往下一環節的獎勵模型。
這種"先靜態篩、再動態渲染"的流水線設計，把真正需要昂貴計算的步驟（渲染和評分）只留給那些真正有希望的候選項目，大幅提升了訓練效率。
---
四、三維獎勵：同時考量顏值、功能和思維方式
這是整個方案最有創意的部分。如何給一個生成的網站評分？
如果只看"功能對不對"，那麼一個能正常運行但界面醜陋、毫無設計感的網站會得到高分，而一個設計精美但有一兩個小按鈕失效的網站會得到低分——這顯然不符合真實世界的評價標準。但如果只用視覺評分，那麼一個外觀漂亮但實際上按鈕根本沒有綁定事件處理器的"花瓶網站"也會矇混過關。
研究團隊設計了一套"級聯多模態獎勵"，把三個維度的評價有機結合，形成一個階梯式的評分體系。
整體邏輯是這樣的：如果靜態驗證失敗，直接給0分（靜態懲罰）；如果構建失敗，也給0分（構建懲罰）；只有成功渲染的項目，才會進入三維綜合評分階段。
三維評分中，第一維是"視覺美學感知分"。系統把渲染截圖連同用戶的需求描述一起送給一個視覺語言模型（能理解圖片的AI），讓它對網站進行0到5分的評分，評價維度涵蓋布局協調性、色彩搭配、字體層級、視覺上可感知的功能完整性，以及與用戶設計意圖的風格匹配程度。這個分數是連續的，能細膩地區分"一般"與"優秀"的設計。
第二維是"功能完整性分"。系統統計運行時日誌和瀏覽器控制台日誌中的報錯數量：如果沒有任何報錯，得1分；有任何報錯，得0分。這個簡單的二值判斷確保了模型不能靠"好看但報錯"來矇混獎勵。
第三維是"推理格式分"。研究團隊希望模型在寫代碼之前先進行結構化思考——規劃目錄層級、考慮框架配置、維護跨組件的共享狀態。因此他們要求模型的輸出必須包含用`
最終的密集獎勵是三個維度的加權和：視覺分加上0.1倍的功能分加上0.1倍的格式分。功能分和格式分的權重設得較小，是因為它們是稀疏的二值信號，權重過大會干擾視覺感知分這個連續信號提供的細膩學習梯度，導致模型訓練不穩定。研究團隊通過系統的超參數搜索（在0、0.1、0.5、1.0的網格上窮舉測試）驗證了這個權重組合是最優的。
---
五、用"分組比較"代替"打獨立分"——強化學習的優化方式
有了獎勵信號，接下來就是訓練模型。研究團隊選擇了一種叫做GRPO（組相對策略優化）的強化學習算法，而沒有使用更常見的PPO算法，原因很直白：網站生成的獎勵信號極其不穩定——一個微小的語法錯誤就能讓獎勵從高分直接跌到零分，這種劇烈波動會讓PPO這類需要穩定基準線的算法很難收斂。
GRPO的核心思想可以用一個生動的比方來理解：假設你是一個培訓機構的教練，今天同時給16個學生布置了同一道題，讓他們各自獨立作答。然後你不去給每個學生打一個"絕對分數"，而是把16份答案放在一起橫向比較——做得比平均水平好的，給正向激勵；做得比平均水平差的，給負向反饋。這樣，即使整體水平參差不齊，學生也能從"我比同伴好多少/差多少"中獲得清晰的學習信號。
在實驗中，研究團隊對"每次同時生成多少個候選答案"（即分組大小G）進行了系統測試，發現G越大，效果越好——G=32時各項指標均優於G=16、G=8，這印證了"更多候選項帶來更豐富的比較資訊"的直覺。出於計算資源的平衡考慮，正式實驗選用了G=16。
此外，GRPO還引入了KL散度懲罰項，防止模型為了追求高獎勵而走向極端——就像給學生設置一條規則："你的答題風格不能偏離我們教過你的基礎太遠，不然即使答對了也要扣分"，從而保持生成代碼的語法質量和語言風格。
---
六、訓練流程的兩個階段
訓練分為兩步，就像廚師培訓先上基礎烹飪課再參加實戰競賽。
第一步是監督微調（SFT）熱身。研究團隊從訓練數據集（WebGen-Instruct，包含6667個真實網站生成任務）中按應用類型均勻採樣600個任務，用GPT-4.1生成對應的高質量參考答案，然後用這些"示範樣本"對基礎模型Qwen2.5-Coder-7B-Instruct進行微調，訓練2個輪次。這一步的目的是讓模型先建立起"網站項目長什麼樣"的基本結構感知和語義理解，相當於給廚師打好刀工基礎。
第二步是GRPO強化學習精調。在SFT模型的基礎上，繼續進行400步的強化學習優化，全局批大小256（即每步處理256個提示），分組大小G=16，KL懲罰係數0.01，學習率5×10^{-6}。提示的最大長度4096個詞元，模型輸出的最大長度8192個詞元——後者保證了在一次推理中能生成足夠完整的多頁面項目代碼。
消融實驗證明，單獨做SFT或單獨做強化學習，效果都不如兩者結合。SFT提供了結構感知的先驗，讓強化學習的探索有一個合理的起點；強化學習則在獎勵信號的引導下，把SFT無法優化的功能正確性和視覺質量推向更高層次。
---
七、實驗結果：數字背後的故事
研究團隊在兩個基準上進行了評測，並設計了四個量化指標。
第一個指標是"功能成功率"（FSR），衡量生成網站能否通過預定義的交互測試——包括按鈕點擊、表單提交、多頁面導航等。評測工具是WebVoyager，一個專為網頁環境設計的GUI智能體，它模擬真實用戶操作，記錄DOM變化和界面響應，判斷交互是否符合預期。
第二個指標是"美學對齊分"（AAS），由視覺語言模型對渲染頁面進行0到5分的評分，評價布局、色彩、字體和風格與用戶需求的匹配程度。
第三個指標是"有效渲染率"（VRR），即能夠成功渲染（不報運行時錯誤）的項目比例。
第四個指標是"代碼檢查與依賴通過率"（LDPR），即通過ESLint靜態分析並能自動解析依賴的項目比例，反映代碼質量和部署就緒程度。
在WebGen-Bench（包含101個精心策劃的網站生成任務，覆蓋從極簡作品集到複雜數據儀錶盤的13種場景）上，結果如下：基礎模型Qwen2.5-Coder-7B-Instruct的功能成功率只有1.59%，有效渲染率僅30.56%，美學分2.73。經過WebGen-R1訓練後，功能成功率躍升至29.21%（提升27.62個百分點），有效渲染率達到95.89%（提升65.33個百分點），美學分達到3.94（提升44.32%）。
橫向比較一下友商表現就更有說服力了。同為阿里巴巴出品的Qwen2.5-72B-Instruct（參數量是WebGen-R1的10倍），功能成功率只有2.54%，有效渲染率更是慘不忍睹的8.86%。Qwen3-32B稍好一些，功能成功率18.69%，但仍遜於WebGen-R1。擁有6710億參數的DeepSeek-R1功能成功率為30.25%，與WebGen-R1的29.21%接近，但其有效渲染率只有42.86%，美學分3.67，均遠低於WebGen-R1。商業模型中，Claude-3.7-Sonnet的功能成功率最高（57.72%），但美學分3.90低於WebGen-R1的3.94，有效渲染率84.00%也低於WebGen-R1的95.89%。GPT-5功能成功率46.53%，美學分3.34，有效渲染率90.43%，同樣在後兩項指標上不如WebGen-R1。
值得特別關注的是一個有趣的規律：美學分相對容易隨模型規模提升，但功能正確性的提升則難得多。例如Qwen2.5-72B的美學分3.14已經接近部分商業模型，但功能成功率僅2.54%。這說明讓AI生成"看起來好看"的界面比讓它生成"真正能用"的界面要容易很多——前者只需要掌握視覺模式，後者需要真正理解交互邏輯和事件綁定。
在13個細分場景的雷達圖中，WebGen-R1在所有場景下的美學分都優於基礎模型，並在內容呈現和設計驗證測試類別上與DeepSeek-R1和Gemini-2.5-Pro表現相當。功能成功率方面，WebGen-R1在所有指令類別和測試用例類別上都顯著超越基礎模型。
為了驗證泛化能力，研究團隊還在WebDev Arena（從10000個真實網頁開發任務中篩選出的119個高質量任務，指令風格和領域分布與訓練數據差異顯著）上進行了評測。由於WebDev Arena沒有標準化測試用例，只報告美學分。結果顯示，WebGen-R1的美學分在所有開源和商業模型中均排名最高，高於DeepSeek-R1、GPT-5、Qwen3-32B等，表明模型學到的是可遷移的架構抽象和風格理解，而非單純記憶訓練數據的特定模式。
---
八、人類評價驗證：AI打的分，人類認不認？
研究團隊擔心一個問題：獎勵模型給出的分數，真的和真實用戶的感受一致嗎？如果AI評委的偏好和人類評委的偏好不一致，那整個強化學習的方向就可能偏了。
為此，他們招募了三位有經驗的前端開發工程師，讓他們獨立對WebGen-Bench上生成的101個網站進行功能和視覺的綜合評分，然後把人工評分與獎勵模型的評分進行相關性分析。結果顯示，皮爾遜相關係數r=0.762，斯皮爾曼秩相關係數ρ=0.734，兩項統計均高度顯著（p值約為10^{-18}到10^{-20}量級）。這說明獎勵模型對網站質量的判斷與專業人類評委高度吻合，強化學習的優化方向是可信的。
---
九、回到那家餐廳：這一切意味著什麼
說到底，WebGen-R1 做的事情用餐廳類比來總結最為直觀：之前那個7B廚師，走進一家新餐廳，只能做出三成勉強能端上桌的菜（有效渲染率30.56%），其中真正讓顧客滿意的不到兩桌（功能成功率1.59%）。經過WebGen-R1的訓練，同一個廚師進步到了幾乎每次都能做出可以端上桌的菜（有效渲染率95.89%），而且有將近三成的菜能讓挑剔的顧客完全滿意（功能成功率29.21%），菜的賣相甚至超過了很多更大廚房的大廚（美學分3.94，超越GPT-5、Gemini-2.5-Pro等）。
這項研究的意義不僅在於技術指標的提升，更在於它打開了一條新路：通過強化學習，把小型開源模型從"函數級代碼生成"推向"項目級應用生成"，而且不需要依賴昂貴的商業模型或複雜的多智能體編排。這對於那些資源有限、希望在本地部署AI輔助開發工具的團隊來說，具有很現實的價值。
當然，這項研究也有清醒的局限性。在WebDev Arena這種指令極短、資訊不完整的任務上，WebGen-R1有時會因為缺乏足夠的上下文而錯過一些新的設計趨勢——研究團隊也坦承，採用更新的基礎模型有望緩解這個問題。此外，功能成功率29.21%意味著仍有七成任務沒能完全達標，距離真正的"生產級可靠性"還有相當距離。
功能成功率和美學質量之間的張力，或許是網站生成領域下一個值得深入研究的核心問題：美麗的外表和真正好用的功能，如何同時兼顧？WebGen-R1 給出了一個有說服力的起點，但這場探索才剛剛開始。有興趣深入了解技術細節的讀者，可以通過arXiv編號2604.20398查閱完整原文，研究團隊也已將代碼和數據集開放在GitHub上供研究社區使用。
---
Q&A
Q1：WebGen-R1是如何解決網站生成中"獎勵難以設計"的問題的？
A：WebGen-R1把獎勵拆成了三層：第一層用靜態規則判斷項目結構是否合法，第二層檢查構建是否成功，第三層才調用視覺語言模型進行美學評分，同時用日誌報錯數量來衡量功能完整性。這種級聯設計確保昂貴的視覺評分只用在真正值得評估的項目上，大幅提升了效率和信號質量。
Q2：WebGen-R1訓練用的基礎模型是哪個，訓練成本大概是什麼量級？
A：基礎模型是阿里巴巴的Qwen2.5-Coder-7B-Instruct，參數量70億。訓練在8張英偉達
H100 GPU（每張80GB顯存）上完成，先進行約2個訓練輪次的監督微調熱身，再進行400步的強化學習精調。整體訓練規模相對較小，屬於普通學術實驗室可以承擔的量級。
Q3：WebGen-R1生成的網站用了哪些技術棧，為什麼選這些？
A：WebGen-R1生成的網站固定基於React函數組件加TypeScript，使用Vite作為構建工具，Tailwind CSS負責樣式，Ant Design提供複雜UI組件，React Router DOM v6處理路由，需要圖表時使用Recharts。這套技術棧的選擇是為了減少渲染和交互評估中的不確定性——統一框架讓自動化測試更穩定，也讓強化學習的獎勵信號更可靠。
