**前端工程師的工作流**是一個復雜而精細的過程，它從抽象的設計概念開始，經過精確的視覺感知理解，最終轉化為功能完備的交互式代碼。隨著技術的發(fā)展，多模態(tài)大語言模型（MLLMs）展現(xiàn)出了在處理視覺信息和生成代碼方面的巨大潛力，有望徹底改變前端開發(fā)領域。但是，我們是否真的了解這些模型在整個前端開發(fā)流程中的表現(xiàn)如何呢？

這項由同濟大學的孫浩宇、華盛頓大學的王惠辰、中山大學的顧嘉偉、微軟的李林杰以及香港中文大學的成宇領導的研究發(fā)表于2025年5月的arXiv預印本（arXiv:2505.17399v1），為我們提供了一個全面的答案。研究團隊創(chuàng)建了名為"FullFront"的基準測試，系統(tǒng)性地評估了多模態(tài)大語言模型在完整前端開發(fā)流程中的能力。有興趣深入了解的讀者可以通過https://github.com/Mikivishy/FullFront訪問完整論文和代碼。

一、為什么我們需要全面的前端工程評測基準？

想象一下烹飪一道復雜的菜肴：你需要先構思菜單（概念化），然后理解每種食材的特性和搭配（感知理解），最后按照特定步驟烹飪出成品（實現(xiàn)）。前端工程也是如此，包含三個關鍵階段：設計概念化、視覺理解和代碼實現(xiàn)。

目前的問題在于，現(xiàn)有的評測基準就像是只測試廚師切菜或調味的能力，而非評估整道菜肴的制作過程。例如，IW-Bench和WebCode2M專注于評估從視覺輸入生成代碼的能力，但忽略了交互功能的實現(xiàn)或現(xiàn)有代碼庫的優(yōu)化。另一方面，WebQuest和Webqa則專注于網頁的視覺理解，但往往只關注內容層面的推理，而忽視了精細的感知能力，比如元素大小、位置和布局等，這些對于準確的前端實現(xiàn)至關重要。

更重要的是，這些分散的評測方法通常完全忽略了開發(fā)過程中的初始"設計"階段，因此無法全面評估MLLM在端到端前端工程中的能力。就像評價一個廚師，我們不僅要看他能否按照菜譜烹飪，還要看他能否根據(jù)食材創(chuàng)造菜單，以及是否能準確辨別食材的品質。

FullFront基準測試恰好填補了這一空白，它不是簡單地測試模型的單一能力，而是模擬了真實世界中前端工程師的完整工作流程，從設計概念的生成，到網頁元素的視覺理解，再到功能代碼的實現(xiàn)。

二、FullFront：一個全面的前端工程評測基準

FullFront基準測試被精心設計為涵蓋三個核心任務，每個任務對應前端開發(fā)流程中的一個關鍵階段：

**網頁設計（Webpage Design）**：這好比是廚師根據(jù)食材清單構思一道菜肴。模型需要根據(jù)文本描述生成網頁設計圖像，測試其將抽象需求轉化為具體視覺布局的能力。FullFront包含50個網頁設計問題，讓模型展示它們的創(chuàng)意構思能力。

**網頁感知問答（Webpage Perception QA）**：這類似于廚師識別各種食材的特性和質量。這部分評估模型對網頁元素的位置、樣式、空間關系和整體布局的感知能力，通過三個子任務實現(xiàn)：真實世界QA（1250個問答對）、合成QA（400個問答對）和多窗口QA（150個問答對）。這些問題都是關于"這個按鈕比那個按鈕大嗎？"或"這個導航菜單的文字樣式如何？"等細節(jié)的多選題。

**網頁代碼生成（Webpage Code Generation）**：這就像廚師按照特定步驟將原料轉化為美味佳肴。這部分專注于將視覺設計準確轉化為功能性代碼，包括四個子任務：圖像到代碼（200個樣本）、文本到代碼（50個樣本）、交互實現(xiàn)（100個樣本）和代碼優(yōu)化（50個樣本）。這些任務測試模型不僅能夠生成靜態(tài)網頁，還能實現(xiàn)交互功能并優(yōu)化現(xiàn)有代碼。

與其他基準測試相比，F(xiàn)ullFront的一個重要創(chuàng)新是其數(shù)據(jù)構建方法。傳統(tǒng)方法要么使用從Common Crawl等來源簡化的HTML（通常冗長且混亂），要么使用LLM從頭生成的HTML（往往過于簡化）。而FullFront采用了一種新穎的兩階段處理方法：

首先，從真實世界網頁截圖開始，使用OmniParser提取元素信息。 然后，GPT-4o生成初始HTML-v1，之后Claude 3.7 Sonnet進一步優(yōu)化樣式、位置、對齊和布局，生成更高質量、更復雜的HTML-v2。

這種方法的巧妙之處在于，它既保留了真實網頁的視覺多樣性，又避免了版權問題，同時生成了干凈、標準化的HTML代碼。這就像是保留了各種菜肴的獨特風味，但用標準化的食譜記錄下來，便于不同廚師之間的比較。

在圖像處理方面，F(xiàn)ullFront不像其他基準測試那樣使用單一占位圖或隨機圖像，而是采用了基于類別的圖像表示策略。研究團隊將常見的圖像內容分為15個預定義類別（如人物、動物、食物等），每個類別鏈接到一個固定的非版權圖像URL。這確保了視覺一致性，同時也測試了模型對圖像內容的感知、分類和樣式設置能力。

三、評測方法：如何衡量前端工程能力？

要全面評估模型在前端工程中的表現(xiàn)，研究團隊設計了多層次的評估框架，就像評價一道菜肴需要考慮其外觀、口感、香氣和創(chuàng)意等多個維度一樣。

**視覺層面評估**：研究團隊使用兩種方法評估生成內容的視覺相似度：

1. CLIP得分：這就像快速判斷兩道菜肴的整體相似度。它通過嵌入空間相似性衡量生成內容與目標圖像之間的高級概念一致性。

2. Gemini視覺評分：這更像是專業(yè)廚師的細致評價。使用Gemini 2.5 Flash模型，從十個維度（如元素復現(xiàn)、比例和大小一致性、布局和排版保真度等）對生成的網頁進行評分，每個維度0-10分，分數(shù)越高表示與原始設計越相似。

**代碼層面評估**：研究團隊提出了"代碼評分"（Code Score）來評估生成的HTML與參考HTML的相似度：

1. 首先，將HTML解析為DOM樹并提取關聯(lián)的CSS。 2. 然后，評估結構相似性，通過DOM標簽序列的最長公共子序列（LCS）比率來量化。 3. 同時，評估文本、圖像和表單的內容類型相似性，識別對應元素并根據(jù)內容（如文本通過SequenceMatcher）、關鍵樣式屬性（如顏色、字體大小、圖像尺寸）和關鍵屬性（如圖像src、表單元素類型）進行比較。 4. 針對每種內容類型，計算實現(xiàn)率（反映參考元素在生成代碼中的覆蓋比例），用于調整相似度分數(shù)，以捕捉質量和完整性。 5. 最終的代碼評分通過預定義權重組合結構和調整后的內容類型相似性。

這種多維度評估方法確保了評測結果的全面性和準確性，就像評價一位廚師不僅要看最終的菜肴，還要考察其烹飪技巧、食材選擇和創(chuàng)新能力。

四、實驗設置：模型陣容與測試環(huán)境

為了全面評估當前最先進的MLLMs在前端工程領域的能力，研究團隊選擇了十個代表性模型進行測試：

**開源模型**：包括Qwen2.5-VL-72B-Instruct、InternVL2.5-78B、InternVL3-78B和LLaVA-Onevision-72B。這些模型代表了開源社區(qū)的最新進展。

**專有模型**：包括Claude 3.7 Sonnet、Gemini 2.5 Flash、GPT-4o、o4-mini、GPT-4.1以及o1和Gemini 2.5 Pro（僅在FullFront-mini上測試）。這些是當前業(yè)界領先的商業(yè)模型。

對于專門針對圖像生成的網頁設計任務，研究團隊測試了GPT-4o和gemini-2.0-flash-exp-image-generation兩個模型的能力。

為了便于研究者進行快速迭代評估和初步探索，研究團隊還構建了FullFront-mini數(shù)據(jù)集，這是完整FullFront數(shù)據(jù)集的精簡版本，包含200個真實世界QA、100個合成QA、50個多窗口QA、20個圖像到代碼、10個文本到代碼、20個交互創(chuàng)作和10個代碼優(yōu)化樣本。

五、實驗結果：模型在前端工程中的表現(xiàn)如何？

就像不同廚師在烹飪比賽中展現(xiàn)各自的強項和弱點一樣，不同的MLLMs在FullFront的三個主要任務上表現(xiàn)各異。

**網頁設計任務**：在這項任務中，當前的文本到圖像生成MLLMs展現(xiàn)出了生成網頁布局概念的基礎能力，但在生成高保真度的設計方面仍面臨困難。GPT-4o在Gemini評分（5.47）和人類評分（6.96）上都優(yōu)于gemini-2.0-flash-exp-image-generation。質性分析顯示，GPT-4o在渲染整體頁面結構、排版和元素實現(xiàn)保真度方面表現(xiàn)更好。不過，即使是表現(xiàn)最好的模型，在精確細節(jié)（如頁腳部分的背景顏色）方面仍有不足。

**網頁感知問答**：這個任務的結果令人意外。即使是表現(xiàn)最好的模型，如Claude 3.7 Sonnet和Gemini 2.5 Pro，在三個子任務上的平均準確率也僅略高于50%。相比之下，LLaVA-OneVision-72B的準確率在所有QA子任務上都低于35%。更令人擔憂的是，所有模型的表現(xiàn)都遠遠落后于人類專家，后者在三個子任務上的準確率分別為97%、96%和94%。這表明當前的MLLMs在精細化網頁元素感知方面存在嚴重不足。

進一步分析顯示，MLLMs在準確理解元素對齊（21.5%）、大?。?9.5%）、間距（15.5%）和精確定位（18.5%）方面面臨著特別的困難。這些因素構成了感知失敗的核心原因。例如，所有模型都無法正確識別標簽"Human Rights Advocates"相對于主標題和副標題的位置，或者無法正確比較兩個"LEARN MORE"按鈕的大小。

有趣的是，研究發(fā)現(xiàn)模型在單頁真實世界QA和合成QA上的表現(xiàn)幾乎相同，但在更復雜的多窗口QA上表現(xiàn)顯著下降。這表明隨著任務復雜性的增加，模型的感知能力面臨更大挑戰(zhàn)。

**網頁代碼生成**：在這個任務中，閉源模型顯著優(yōu)于開源模型，在所有子任務和指標上都領先。Claude 3.7 Sonnet始終表現(xiàn)最佳，緊隨其后的是其他專有模型如Gemini 2.5 Pro、Gemini 2.5 Flash和GPT-4.1。例如，在FullFront-mini的代碼優(yōu)化任務中，Gemini 2.5 Pro獲得了9.17的Gemini視覺評分，表明在大多數(shù)情況下幾乎完美的視覺復制，而表現(xiàn)最好的開源模型InternVL3-78B在相同設置下僅得到6.25分。

子任務分析顯示了明顯的模式：提供部分HTML（代碼優(yōu)化任務）比僅提供圖像輸入（圖像到代碼任務）能獲得更好的性能。然而，生成功能性交互代碼（交互實現(xiàn)任務）更具挑戰(zhàn)性，盡管目標HTML-v1更簡單，但得分更低。這一困難在交互實現(xiàn)率（表5）中得到了進一步證實，閉源模型的成功率超過65%，遠高于開源模型如LLaVA-Onevision-72B（僅16%）。文本到代碼任務，需要根據(jù)文本描述自主設計，證明是最困難的，導致整體模型性能最低。

人類評估（表4）進一步證實，閉源模型如Claude 3.7 Sonnet和Gemini 2.5 Pro被認為更準確，在復制質量方面經常得分超過8/10。雖然這些模型實現(xiàn)了高整體保真度，但詳細示例顯示，即使頂級表現(xiàn)者也可能在精細細節(jié)方面表現(xiàn)出輕微缺陷。

六、深入分析：MLLMs在前端工程中的挑戰(zhàn)與局限

通過分析200個所有MLLMs（除o1和Gemini 2.5 Pro外）都無法正確回答的問題，研究團隊發(fā)現(xiàn)了當前MLLMs在網頁感知方面面臨的主要困難。如前所述，MLLMs在準確理解元素對齊（21.5%）、大?。?9.5%）、間距（15.5%）和精確定位（18.5%）方面存在特別的難題。

**感知能力與代碼表現(xiàn)之間的關系**：一個反直覺的發(fā)現(xiàn)是，在感知任務中表現(xiàn)出色的模型并不一定在代碼生成中表現(xiàn)同樣出色，盡管它們能夠更詳細地理解頁面。誠然，一些模型如Claude 3.7 Sonnet和Gemini 2.5 Pro在兩類任務中都表現(xiàn)強勁。然而，InternVL3-78B雖然在感知QA中超過了Gemini 2.5 Flash，但在代碼生成能力上卻存在明顯差距。InternVL2.5-78B和GPT-4o之間也觀察到了類似的模式。

研究團隊試圖分析這一現(xiàn)象的潛在原因。如圖4(b)所示，在感知QA階段，所有測試的模型都錯誤地識別了"Human Rights Advocate"標簽相對于標題的位置。然而，在分析它們生成的頁面時，所有模型都正確地將標簽直接放在標題上方。這一觀察表明，即使模型在精細感知上存在錯誤，它們仍然可以生成視覺協(xié)調和結構合理的網頁。這表明用于QA中的視覺感知和將視覺概念轉換為代碼的過程可能在MLLMs內部以不同的敏感度運作，或依賴于不同的內部表示和生成策略。

**MLLMs能否成為出色的前端工程師？**：為了確定MLLM生成的網頁是否優(yōu)于真實世界版本，三名人類專家對各種MLLMs（除o1和Gemini 2.5 Pro外）生成的100個網頁與其真實世界對應物進行了盲評。結果顯示，領先模型（如o4-mini、Gemini 2.5 Flash）在絕大多數(shù)情況下優(yōu)于真實世界對應物。

然而，對生成網頁的進一步分析揭示了MLLMs可能出現(xiàn)的三種常見錯誤類型：異常圖像大?。ㄆ茐牟季滞暾缘漠惓４髨D像）、空白圖像（盡管代碼非空但完全空白的截圖）和隔離錯誤（僅包含隔離交互元素的輸出）。每種錯誤類型都會顯著降低生成網頁的有效性。表6顯示，開源模型比閉源模型更頻繁地表現(xiàn)出這些錯誤，這大大降低了它們的可靠性和穩(wěn)定性。

此外，對代碼級性能的詳細檢查（表7）表明，當前MLLMs在文本和表單實現(xiàn)方面仍有很大的改進空間，這些組件的相似度分數(shù)不超過0.6。

總體而言，盡管在精細細節(jié)方面存在某些缺陷，MLLMs確實展示了從文本描述設計一般連貫的網頁界面的能力，并能從網頁截圖生成相應的代碼。然而，它們在感知能力上的總體不足，加上代碼生成過程中潛在的關鍵錯誤，使得它們當前的可靠性和穩(wěn)定性不確定。研究團隊認為，一個有前途的未來方向是將MLLMs與專門工具集成，以彌補它們的感知限制，并提供機制來識別和糾正生成異常，從而幫助MLLMs發(fā)展成為優(yōu)秀的前端工程師。

七、總結與展望：前端工程的智能化未來

FullFront作為一個開創(chuàng)性且全面的多模態(tài)前端基準測試，為系統(tǒng)評估MLLMs在完整前端開發(fā)流程中的能力鋪平了道路。通過構建高質量、多樣化的合成數(shù)據(jù)和設計多層次評估系統(tǒng)，F(xiàn)ullFront成為分析當前MLLMs優(yōu)勢和局限性的強大工具，特別是揭示了MLLMs在處理復雜前端細節(jié)（如圖像大小和交互實現(xiàn)）以及準確感知網頁元素方面面臨的挑戰(zhàn)。

雖然FullFront像任何基準測試一樣存在一定局限性，但它為評估MLLMs在前端工程領域的能力設定了新標準，為下一代智能網頁開發(fā)工具的發(fā)展奠定了基礎。未來的工作可以通過引入更先進的評估指標、擴大數(shù)據(jù)集規(guī)模或探索新的任務類型來改進FullFront。

總的來說，這項研究表明，雖然當前的MLLMs在前端開發(fā)的某些方面表現(xiàn)出色，但要成為真正的"前端工程師"還有很長的路要走。它們在精細感知、復雜布局處理和交互實現(xiàn)方面的局限性表明，人類專業(yè)知識在可預見的未來仍將不可或缺。然而，隨著技術的不斷進步，我們可以期待MLLMs在前端開發(fā)中扮演越來越重要的角色，最終可能作為人類開發(fā)者的強大助手或協(xié)作伙伴，而不是完全替代者。

對于普通用戶和開發(fā)者來說，這項研究的意義在于：它不僅展示了AI在前端開發(fā)中的潛力，也明確了當前技術的局限性。這有助于我們對AI輔助開發(fā)工具形成更現(xiàn)實的期望，并指導未來工具的開發(fā)方向，使其更好地滿足實際需求。隨著這些技術的成熟，我們可以期待更智能、更高效的前端開發(fā)體驗，但同時也應認識到人類創(chuàng)造力和專業(yè)知識在設計和實現(xiàn)高質量用戶界面方面的持續(xù)價值。