FullFront：探索跨越前端工程全流程的多模态大语言模型基准测试

**前端工程师的工作流**是一个复杂而精细的过程，它从抽象的设计概念开始，经过精确的视觉感知理解，最终转化为功能完备的交互式代码。随着技术的发展，多模态大语言模型（MLLMs）展现出了在处理视觉信息和生成代码方面的巨大潜力，有望彻底改变前端开发领域。但是，我们是否真的了解这些模型在整个前端开发流程中的表现如何呢？

这项由同济大学的孙浩宇、华盛顿大学的王惠辰、中山大学的顾嘉伟、微软的李林杰以及香港中文大学的成宇领导的研究发表于2025年5月的arXiv预印本（arXiv:2505.17399v1），为我们提供了一个全面的答案。研究团队创建了名为"FullFront"的基准测试，系统性地评估了多模态大语言模型在完整前端开发流程中的能力。有兴趣深入了解的读者可以通过https://github.com/Mikivishy/FullFront访问完整论文和代码。

一、为什么我们需要全面的前端工程评测基准？

想象一下烹饪一道复杂的菜肴：你需要先构思菜单（概念化），然后理解每种食材的特性和搭配（感知理解），最后按照特定步骤烹饪出成品（实现）。前端工程也是如此，包含三个关键阶段：设计概念化、视觉理解和代码实现。

目前的问题在于，现有的评测基准就像是只测试厨师切菜或调味的能力，而非评估整道菜肴的制作过程。例如，IW-Bench和WebCode2M专注于评估从视觉输入生成代码的能力，但忽略了交互功能的实现或现有代码库的优化。另一方面，WebQuest和Webqa则专注于网页的视觉理解，但往往只关注内容层面的推理，而忽视了精细的感知能力，比如元素大小、位置和布局等，这些对于准确的前端实现至关重要。

更重要的是，这些分散的评测方法通常完全忽略了开发过程中的初始"设计"阶段，因此无法全面评估MLLM在端到端前端工程中的能力。就像评价一个厨师，我们不仅要看他能否按照菜谱烹饪，还要看他能否根据食材创造菜单，以及是否能准确辨别食材的品质。

FullFront基准测试恰好填补了这一空白，它不是简单地测试模型的单一能力，而是模拟了真实世界中前端工程师的完整工作流程，从设计概念的生成，到网页元素的视觉理解，再到功能代码的实现。

二、FullFront：一个全面的前端工程评测基准

FullFront基准测试被精心设计为涵盖三个核心任务，每个任务对应前端开发流程中的一个关键阶段：

**网页设计（Webpage Design）**：这好比是厨师根据食材清单构思一道菜肴。模型需要根据文本描述生成网页设计图像，测试其将抽象需求转化为具体视觉布局的能力。FullFront包含50个网页设计问题，让模型展示它们的创意构思能力。

**网页感知问答（Webpage Perception QA）**：这类似于厨师识别各种食材的特性和质量。这部分评估模型对网页元素的位置、样式、空间关系和整体布局的感知能力，通过三个子任务实现：真实世界QA（1250个问答对）、合成QA（400个问答对）和多窗口QA（150个问答对）。这些问题都是关于"这个按钮比那个按钮大吗？"或"这个导航菜单的文字样式如何？"等细节的多选题。

**网页代码生成（Webpage Code Generation）**：这就像厨师按照特定步骤将原料转化为美味佳肴。这部分专注于将视觉设计准确转化为功能性代码，包括四个子任务：图像到代码（200个样本）、文本到代码（50个样本）、交互实现（100个样本）和代码优化（50个样本）。这些任务测试模型不仅能够生成静态网页，还能实现交互功能并优化现有代码。

与其他基准测试相比，FullFront的一个重要创新是其数据构建方法。传统方法要么使用从Common Crawl等来源简化的HTML（通常冗长且混乱），要么使用LLM从头生成的HTML（往往过于简化）。而FullFront采用了一种新颖的两阶段处理方法：

首先，从真实世界网页截图开始，使用OmniParser提取元素信息。 然后，GPT-4o生成初始HTML-v1，之后Claude 3.7 Sonnet进一步优化样式、位置、对齐和布局，生成更高质量、更复杂的HTML-v2。

这种方法的巧妙之处在于，它既保留了真实网页的视觉多样性，又避免了版权问题，同时生成了干净、标准化的HTML代码。这就像是保留了各种菜肴的独特风味，但用标准化的食谱记录下来，便于不同厨师之间的比较。

在图像处理方面，FullFront不像其他基准测试那样使用单一占位图或随机图像，而是采用了基于类别的图像表示策略。研究团队将常见的图像内容分为15个预定义类别（如人物、动物、食物等），每个类别链接到一个固定的非版权图像URL。这确保了视觉一致性，同时也测试了模型对图像内容的感知、分类和样式设置能力。

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

要全面评估模型在前端工程中的表现，研究团队设计了多层次的评估框架，就像评价一道菜肴需要考虑其外观、口感、香气和创意等多个维度一样。

**视觉层面评估**：研究团队使用两种方法评估生成内容的视觉相似度：

1. CLIP得分：这就像快速判断两道菜肴的整体相似度。它通过嵌入空间相似性衡量生成内容与目标图像之间的高级概念一致性。

2. Gemini视觉评分：这更像是专业厨师的细致评价。使用Gemini 2.5 Flash模型，从十个维度（如元素复现、比例和大小一致性、布局和排版保真度等）对生成的网页进行评分，每个维度0-10分，分数越高表示与原始设计越相似。

**代码层面评估**：研究团队提出了"代码评分"（Code Score）来评估生成的HTML与参考HTML的相似度：

1. 首先，将HTML解析为DOM树并提取关联的CSS。 2. 然后，评估结构相似性，通过DOM标签序列的最长公共子序列（LCS）比率来量化。 3. 同时，评估文本、图像和表单的内容类型相似性，识别对应元素并根据内容（如文本通过SequenceMatcher）、关键样式属性（如颜色、字体大小、图像尺寸）和关键属性（如图像src、表单元素类型）进行比较。 4. 针对每种内容类型，计算实现率（反映参考元素在生成代码中的覆盖比例），用于调整相似度分数，以捕捉质量和完整性。 5. 最终的代码评分通过预定义权重组合结构和调整后的内容类型相似性。

这种多维度评估方法确保了评测结果的全面性和准确性，就像评价一位厨师不仅要看最终的菜肴，还要考察其烹饪技巧、食材选择和创新能力。

四、实验设置：模型阵容与测试环境

为了全面评估当前最先进的MLLMs在前端工程领域的能力，研究团队选择了十个代表性模型进行测试：

**开源模型**：包括Qwen2.5-VL-72B-Instruct、InternVL2.5-78B、InternVL3-78B和LLaVA-Onevision-72B。这些模型代表了开源社区的最新进展。

**专有模型**：包括Claude 3.7 Sonnet、Gemini 2.5 Flash、GPT-4o、o4-mini、GPT-4.1以及o1和Gemini 2.5 Pro（仅在FullFront-mini上测试）。这些是当前业界领先的商业模型。

对于专门针对图像生成的网页设计任务，研究团队测试了GPT-4o和gemini-2.0-flash-exp-image-generation两个模型的能力。

为了便于研究者进行快速迭代评估和初步探索，研究团队还构建了FullFront-mini数据集，这是完整FullFront数据集的精简版本，包含200个真实世界QA、100个合成QA、50个多窗口QA、20个图像到代码、10个文本到代码、20个交互创作和10个代码优化样本。

五、实验结果：模型在前端工程中的表现如何？

就像不同厨师在烹饪比赛中展现各自的强项和弱点一样，不同的MLLMs在FullFront的三个主要任务上表现各异。

**网页设计任务**：在这项任务中，当前的文本到图像生成MLLMs展现出了生成网页布局概念的基础能力，但在生成高保真度的设计方面仍面临困难。GPT-4o在Gemini评分（5.47）和人类评分（6.96）上都优于gemini-2.0-flash-exp-image-generation。质性分析显示，GPT-4o在渲染整体页面结构、排版和元素实现保真度方面表现更好。不过，即使是表现最好的模型，在精确细节（如页脚部分的背景颜色）方面仍有不足。

**网页感知问答**：这个任务的结果令人意外。即使是表现最好的模型，如Claude 3.7 Sonnet和Gemini 2.5 Pro，在三个子任务上的平均准确率也仅略高于50%。相比之下，LLaVA-OneVision-72B的准确率在所有QA子任务上都低于35%。更令人担忧的是，所有模型的表现都远远落后于人类专家，后者在三个子任务上的准确率分别为97%、96%和94%。这表明当前的MLLMs在精细化网页元素感知方面存在严重不足。

进一步分析显示，MLLMs在准确理解元素对齐（21.5%）、大小（19.5%）、间距（15.5%）和精确定位（18.5%）方面面临着特别的困难。这些因素构成了感知失败的核心原因。例如，所有模型都无法正确识别标签"Human Rights Advocates"相对于主标题和副标题的位置，或者无法正确比较两个"LEARN MORE"按钮的大小。

有趣的是，研究发现模型在单页真实世界QA和合成QA上的表现几乎相同，但在更复杂的多窗口QA上表现显著下降。这表明随着任务复杂性的增加，模型的感知能力面临更大挑战。

**网页代码生成**：在这个任务中，闭源模型显著优于开源模型，在所有子任务和指标上都领先。Claude 3.7 Sonnet始终表现最佳，紧随其后的是其他专有模型如Gemini 2.5 Pro、Gemini 2.5 Flash和GPT-4.1。例如，在FullFront-mini的代码优化任务中，Gemini 2.5 Pro获得了9.17的Gemini视觉评分，表明在大多数情况下几乎完美的视觉复制，而表现最好的开源模型InternVL3-78B在相同设置下仅得到6.25分。

子任务分析显示了明显的模式：提供部分HTML（代码优化任务）比仅提供图像输入（图像到代码任务）能获得更好的性能。然而，生成功能性交互代码（交互实现任务）更具挑战性，尽管目标HTML-v1更简单，但得分更低。这一困难在交互实现率（表5）中得到了进一步证实，闭源模型的成功率超过65%，远高于开源模型如LLaVA-Onevision-72B（仅16%）。文本到代码任务，需要根据文本描述自主设计，证明是最困难的，导致整体模型性能最低。

人类评估（表4）进一步证实，闭源模型如Claude 3.7 Sonnet和Gemini 2.5 Pro被认为更准确，在复制质量方面经常得分超过8/10。虽然这些模型实现了高整体保真度，但详细示例显示，即使顶级表现者也可能在精细细节方面表现出轻微缺陷。

六、深入分析：MLLMs在前端工程中的挑战与局限

通过分析200个所有MLLMs（除o1和Gemini 2.5 Pro外）都无法正确回答的问题，研究团队发现了当前MLLMs在网页感知方面面临的主要困难。如前所述，MLLMs在准确理解元素对齐（21.5%）、大小（19.5%）、间距（15.5%）和精确定位（18.5%）方面存在特别的难题。

**感知能力与代码表现之间的关系**：一个反直觉的发现是，在感知任务中表现出色的模型并不一定在代码生成中表现同样出色，尽管它们能够更详细地理解页面。诚然，一些模型如Claude 3.7 Sonnet和Gemini 2.5 Pro在两类任务中都表现强劲。然而，InternVL3-78B虽然在感知QA中超过了Gemini 2.5 Flash，但在代码生成能力上却存在明显差距。InternVL2.5-78B和GPT-4o之间也观察到了类似的模式。

研究团队试图分析这一现象的潜在原因。如图4(b)所示，在感知QA阶段，所有测试的模型都错误地识别了"Human Rights Advocate"标签相对于标题的位置。然而，在分析它们生成的页面时，所有模型都正确地将标签直接放在标题上方。这一观察表明，即使模型在精细感知上存在错误，它们仍然可以生成视觉协调和结构合理的网页。这表明用于QA中的视觉感知和将视觉概念转换为代码的过程可能在MLLMs内部以不同的敏感度运作，或依赖于不同的内部表示和生成策略。

**MLLMs能否成为出色的前端工程师？**：为了确定MLLM生成的网页是否优于真实世界版本，三名人类专家对各种MLLMs（除o1和Gemini 2.5 Pro外）生成的100个网页与其真实世界对应物进行了盲评。结果显示，领先模型（如o4-mini、Gemini 2.5 Flash）在绝大多数情况下优于真实世界对应物。

然而，对生成网页的进一步分析揭示了MLLMs可能出现的三种常见错误类型：异常图像大小（破坏布局完整性的异常大图像）、空白图像（尽管代码非空但完全空白的截图）和隔离错误（仅包含隔离交互元素的输出）。每种错误类型都会显著降低生成网页的有效性。表6显示，开源模型比闭源模型更频繁地表现出这些错误，这大大降低了它们的可靠性和稳定性。

此外，对代码级性能的详细检查（表7）表明，当前MLLMs在文本和表单实现方面仍有很大的改进空间，这些组件的相似度分数不超过0.6。

总体而言，尽管在精细细节方面存在某些缺陷，MLLMs确实展示了从文本描述设计一般连贯的网页界面的能力，并能从网页截图生成相应的代码。然而，它们在感知能力上的总体不足，加上代码生成过程中潜在的关键错误，使得它们当前的可靠性和稳定性不确定。研究团队认为，一个有前途的未来方向是将MLLMs与专门工具集成，以弥补它们的感知限制，并提供机制来识别和纠正生成异常，从而帮助MLLMs发展成为优秀的前端工程师。

七、总结与展望：前端工程的智能化未来

FullFront作为一个开创性且全面的多模态前端基准测试，为系统评估MLLMs在完整前端开发流程中的能力铺平了道路。通过构建高质量、多样化的合成数据和设计多层次评估系统，FullFront成为分析当前MLLMs优势和局限性的强大工具，特别是揭示了MLLMs在处理复杂前端细节（如图像大小和交互实现）以及准确感知网页元素方面面临的挑战。

虽然FullFront像任何基准测试一样存在一定局限性，但它为评估MLLMs在前端工程领域的能力设定了新标准，为下一代智能网页开发工具的发展奠定了基础。未来的工作可以通过引入更先进的评估指标、扩大数据集规模或探索新的任务类型来改进FullFront。

总的来说，这项研究表明，虽然当前的MLLMs在前端开发的某些方面表现出色，但要成为真正的"前端工程师"还有很长的路要走。它们在精细感知、复杂布局处理和交互实现方面的局限性表明，人类专业知识在可预见的未来仍将不可或缺。然而，随着技术的不断进步，我们可以期待MLLMs在前端开发中扮演越来越重要的角色，最终可能作为人类开发者的强大助手或协作伙伴，而不是完全替代者。

对于普通用户和开发者来说，这项研究的意义在于：它不仅展示了AI在前端开发中的潜力，也明确了当前技术的局限性。这有助于我们对AI辅助开发工具形成更现实的期望，并指导未来工具的开发方向，使其更好地满足实际需求。随着这些技术的成熟，我们可以期待更智能、更高效的前端开发体验，但同时也应认识到人类创造力和专业知识在设计和实现高质量用户界面方面的持续价值。