WebCompass:面向代码语言模型的多模态Web编程评测基准 WebCompass: Towards Multimodal Web Coding Evaluation for Code Language Models
首个覆盖生成/编辑/修复全生命周期并支持文/图/视频三模态的Web编程评测基准,提出Agent-as-a-Judge新范式。
前置知识
大语言模型与代码智能体
基于Transformer的大规模预训练语言模型已从被动补全工具演化为可端到端完成软件工程的智能体,具备工具调用、代码执行、多轮交互能力。本文评测的就是这类模型在前端开发中的表现。
理解评测对象的能力边界是阅读本文的前提——基准的目的就是衡量代码LLM在真实工程场景中能做什么、不能做什么,从而反推动智能体技术发展。
Web前端技术栈(HTML/CSS/JavaScript与React/Vue框架)
现代Web前端由HTML定义结构、CSS控制样式、JavaScript实现交互逻辑;React用JSX将渲染融入JS,Vue用单文件组件(SFC)将模板、脚本、作用域CSS混合在一个文件里。这些技术差异会显著影响模型代码质量。
WebCompass的子集评测显示React/Vanilla/Vue三个框架下模型表现差异巨大(Vue最差)。读者需要知道这些框架的语法特点才能理解实验结论。
Model Context Protocol (MCP) 与智能体工具调用
MCP是一种让LLM智能体控制浏览器、文件系统等外部工具的协议,智能体可以发送点击、滚动等指令并接收DOM快照、控制台日志作为证据,实现与真实运行环境的双向通信。
Agent-as-a-Judge是本文最大的方法创新,完全建立在MCP之上。读者必须理解MCP如何桥接LLM与浏览器才能看懂评测为什么能做到真实交互验证。
LLM-as-a-Judge 与 checklist 引导评分
用大语言模型作为裁判,通过预先设计好的细粒度评估清单(checklist)逐项打分,通过格式化输出与证据引用控制偏见。Harmonic mean汇总避免被单项零分拖累整体。
这是本文编辑与修复任务的核心评测范式,理解它才能理解为何评测分数兼具可解释性与接近人类标注的一致性(Pearson r达0.93-0.96)。
前端缺陷类型学(visual/semantic/interactive三维度)
Web前端错误可分为视觉层(遮挡/拥挤/溢出/对齐)、语义层(标签错误/嵌套错误)、交互层(失活/属性缺失)三大类。WebCompass从中归纳出11种代表性缺陷,基于V0社区200+真实GitHub Issue的统计分布设计。
本文的修复任务(Repair)基于这11类缺陷构造,数据来源于真实的开发者反馈而非人工设想,使评测具有生态有效性(ecological validity)。
研究动机
现有Web编程评测基准如Interaction2Code、WebGen-Bench、SWE-bench Multimodal等普遍存在三个缺陷:一是任务类型单一,几乎只覆盖从文本生成网页这一场景,真正工程师日常的大量工作(基于已有代码库的编辑、修复)被忽略;二是输入模态有限,通常只看文本或静态截图,而真实开发中设计师会发参考图、产品经理会发操作视频;三是评测方式扁平,要么用DOM断言/单元测试验证功能但测不出美感,要么用截图相似度评分但验证不了动态交互。具体来说,如FronTalk 1000条、Web-Bench 1000条、WebApp1K 1000条都只标有✓ Generation一项,Edit和Rep两栏全是✗;且HumanEval的pass@k、SWE-Bench的单元测试通过率这类代码中心化指标无法反映前端开发的视觉保真度、交互质量、响应性、可访问性和整体用户体验。
本文的目标是本文旨在构建一个覆盖Web开发完整生命周期、跨三种输入模态、采用任务感知评测的多模态基准WebCompass,具体目标包括:(1)把生成、编辑、修复三类任务和文本、图像、视频三种模态正交组合得到7个互补的任务类别(共1526条数据),真实映射专业开发工作流;(2)为每类任务设计专属的可执行评分方式——编辑/修复用checklist引导的LLM-as-a-Judge,生成用基于MCP+真实浏览器交互的Agent-as-a-Judge;(3)在10个代表性LLM(闭源+开源)上系统揭示各模型在不同任务、不同模态、不同难度、不同前端框架下的强弱异同,推动前端代码智能体发展。
与已有工作不同的是，论文的独特切入角度是用'评测范式要与任务本质对齐'作为核心方法论。传统评测把所有任务当成可静态打分的对象,本文则论证生成任务输出空间是开放、长视野、依赖多步运行时行为的,必须由能在真实浏览器里点击、滚动、查询DOM的智能体动态合成测试用例并迭代验证;而编辑/修复输出空间受限(局部patch),用checklist+静态diff就能高效打分。这种'任务感知评测'思路加上精心设计的数据来源(查询池来自WebGen-Bench/ArtifactsBench/BigCode Arena/V0真实用户请求,缺陷类型来自V0社区200+ GitHub Issue统计分布)使基准兼具现实代表性、生态有效性和可重复性。
核心方法
WebCompass的方法体系由两部分组成:数据集构建流水线(2.2节)和评测流水线(第3节)。直觉上,作者把Web开发解构成'生成新网站→修改已有网站→修复已有缺陷'三阶段循环,对应文本/图像/视频三种输入,从而形成7类任务;数据来源不再是凭空创造的toy例子,而是从WebRenderBench测试集中筛选(长度32k-64k字符、GPT-4o打分≥9、人工遴选)出50个高质量原型,再扩展为单页/多页变体作为编辑与修复任务的共同底座。评测侧的核心思想是'静态可用列表 + 动态智能体'的混合:对开放长视野的生成任务,让Claude Code通过Model Context Protocol实际操控Chromium浏览器,边执行用户动作(click/type/scroll)边合成JavaScript测试用例迭代验证;对解空间受限的编辑/修复patch,直接让Claude-Opus-4.5按checklist逐项打分并引用证据。两者均通过harmonic mean归一化、用三层失败兜底(完全构建失败/部分渲染/运行时崩溃)保证评分稳定可解释。
本文的核心创新是与已有'统一评测'基准的本质区别在于任务感知的双重范式(dual paradigm)。传统基准要么纯依赖pass@k或DOM相似度等粗粒度指标,要么单一地用LLM-as-a-Judge照单全评。WebCompass提出的Agent-as-a-Judge区别于普通LLM-judge之处,在于把评审员从'对着截图打分'升级为'能够执行点击、合成断言、读DOM、读控制台、迭代debug后再打分'的智能体;它通过MCP把LLM的双重身份(代码生成器 + 浏览器操作员)结合,在四阶段流水线(checklist生成→浏览器交互→自适应代码验证→证据落地打分)中由三道防线(checklist不可变、只调整selector保持行为断言、必须有可审计证据)防止评分漂移。这套机制首次把人类QA工程师'视觉判断 + ad-hoc脚本'的工作方式在自动化框架中近似实现。
方法步骤详情
数据集构建具体步骤:Step1. 在WebGen-Bench、ArtifactsBench、BigCode Arena、V0 showcase收集原始查询,用BGE-M3嵌入+k-means聚类去重得到候选集;Step2. 每条查询由LLM做5次独立难易度标注取多数投票,再按类别和难度分层采样得到123条Text-Guided Generation查询;Step3. 每条原始查询由LLM扮演产品经理扩充为结构化Web设计文档(页面内容/交互行为/视觉外观三方面);Step4. Vision-Guided Generation取WebRenderBench主页,通过DOM解析定位子页URL,用Playwright自动截图并叠加JS高亮子页位置,另一部分从V0/Figma人工抓取动态交互关键帧;Step5. Video-Guided Generation由标注员先规划浏览路径再录屏;Step6. 编辑任务以高质量Web原型为基础,引入16类操作(数据表、富文本编辑器、拖放接口、滚动视差、粒子特效等)的需求,但刻意隐藏具体实现细节;Step7. 修复任务反向构造——以干净原型为目标,由LLM在11类缺陷(遮挡、拥挤、文本重叠、对齐、对比度、溢出、比例失调、交互失活、语义错误、嵌套错误、属性缺失)中各注入一类,生成自然语言提示(留有暗示但不泄露细节),并保存精确search/replace逆向标注保证唯一解。评测运行时,编辑/修复走LLM-as-a-Judge:对原始源码施加predicted patch,丢弃施加失败的块,在headless Chromium里启动拿before/after截图+日志,送入Claude-Opus-4.5按三维度0-10打分;生成走Agent-as-a-Judge:Claude Code通过chrome-devtools MCP生成checklist→launch项目→执行交互→合成JS测试(只调整selector保持行为断言不变)→失败则读实际代码迭代debug→以可审计证据(screenshot/log/test result)为基础产出三维分(RUN/SPI/DSQ),最后由各item分取harmonic mean作为任务分。
技术新颖性
技术新颖性体现在三个层面。第一,任务生命周期全覆盖:目前已知基准均只覆盖任务三阶段(Gen/Edit/Repair)中的一项或两项,而WebCompass是首个支持全部三项并都跨三种模态的统一基准(1526 tasks、表1');第二,缺陷数据的生态有效性:11种缺陷类别不是凭空设计,而是从V0社区200+真实GitHub Issue中按频率统计抽取,使修复任务直接对应开发者最常遇到的前端反模式;第三,评测范式本身的可信度:Claude-Opus-4.5作为裁判与人类标注一致性达到Pearson r 0.93-0.96(表4),且Agent-as-a-Judge的完整模型排名与人类排名的差异在绝大多数情况下为0或±1(图7),这是现有web评测中第一个公开如此严格的人机一致性验证的工作。
实验结果
整体排名表现(Table 3):Claude-Opus-4.5以Overall 67.40微弱领先Gemini-3-Pro-Preview的66.68,Gemini-3-Flash-Preview 65.42,GPT-5.2 61.90,Claude-Sonnet-4.5 57.12;开源侧Qwen3-VL-235B-A22B-Instruct仅41.14,与最佳闭源差距超过26分,30B级模型更跌至28.08。生成维度Claude 77.18(GEM-RUN)> GPT 75.38> Gemini-Pro 74.05,功能维度SPI Claude 68.95最强,视觉维度DSQ最高仅64.07(Gemini-Pro),视觉是普遍瓶颈。编辑维度ITG Claude 71.86最强,FTI Gemini-Pro 65.14,STC Gemini-Pro 58.16;修复维度呈现独特规律Interaction Integrity(ITI)≫ Reference Fidelity(RFF)> Root-Cause Targeting(RCT),例如Gemini-Pro的87.30 > 72.00 > 54.16,说明交互保持因9/11缺陷在视觉或语义层而自动达到高分,但定位根本原因仍最难。框架子集(图8)显示Vanilla无框架代码在生成/编辑上一致占优(Vue最弱,因SFC要在HTML-like模板/JS/Scoped CSS三种异构语法间协同),但修复上GPT-5.2改用React表现更好。难度分析(图12)显示Gemini-Pro Generation的SPI从Easy 89.83掉到Hard 37.64,断崖式下降说明复杂spec实现仍是开放难题。Worst-of-N稳定性(图16)显示Gemini-Pro保留~80%的Pass@1分数(66.96→53.56,W@4),Qwen3-VL-235B只保留~69.5%(39.95→27.78),Edit维度ITG更跌至16%以下,揭示一致性是真问题。Thinking模式对比显示Qwen3-VL-235B-A22B-Thinking反而因长思维链挤压上下文导致Spec Implementation从42.14掉到35.02(详见Table 3)。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Overall (跨三类任务九维度的算术平均) | Overall Score (0-100) | 67.40 (Claude-Opus-4.5) | 61.90 (GPT-5.2) / 41.14 (最佳开源Qwen3-VL-235B-A22B-Instruct) | 闭源 vs 开源约 26 分绝对差距;Claude-Opus-4.5 比 GPT-5.2 高约 5.5 分 |
| Generation - Runnability (项目能否成功构建启动) | RUN (0-100) | 77.18 (Claude-Opus-4.5) | 74.05 (Gemini-3-Pro-Preview) / 75.38 (GPT-5.2) | Claude相对Gemini提升3.13分,基本三强并跑 |
| Generation - Spec Implementation (设计规范实现度) | SPI (0-100) | 68.95 (Claude-Opus-4.5) | 60.22 (GPT-5.2) / 55.76 (Gemini-3-Pro-Preview) | Claude比GPT-5.2高约8.7分,功能实现仍是头号关键能力 |
| Generation - Design Quality (视觉设计美感) | DSQ (0-100) | 64.07 (Gemini-3-Pro-Preview) | 62.26 (Claude-Opus-4.5) / 55.92 (GPT-5.2) | 整体最高仅64分,且Gemini比GPT-5.2高8分,视觉质量独立于可执行性,不与功能同步提升 |
| Editing - Instruction Targeting (patch是否对准指令目标) | ITG (0-100) | 71.86 (Claude-Opus-4.5) | 69.52 (Gemini-3-Pro-Preview) / 66.97 (GPT-5.2) | Claude领先Gemini约2.3分,领先开源Qwen3-VL-235B(27.74)约44分 |
| Repair - Interaction Integrity (修复后原始交互保留度) | ITI (0-100) | 87.30 (Gemini-3-Pro-Preview) | 85.54 (Claude-Opus-4.5) / 79.33 (GPT-5.2) | 9/11缺陷为视觉/语义层,交互保持近乎自动,此项整体偏高(>79) |
| Repair - Root-Cause Targeting (能否定位根本原因) | RCT (0-100) | 54.16 (Gemini-3-Pro-Preview) | 48.45 (Claude-Opus-4.5) / 41.24 (GPT-5.2) | 全任务最难的子项,即便最佳也只54分,与编辑ITG差距近18分 |
| Judge模型与人类标注一致性 (评测可信度) | Pearson r | 0.93/0.94/0.96 (Opus-4.5在Gen/Edit/Repair上) | 0.88/0.90/0.89 (Sonnet-4.5) / 0.76/0.79/0.81 (Haiku-4.5) | Opus-4.5在修复任务达r=0.96最强,在生成任务仍保持0.93,验证benchmark judge可信 |
| Worst-of-4稳定性 (输出一致性最差下界) | Overall Score 衰减率 (%) | 20.0% (Gemini-3-Pro-Preview,从66.96到53.56) | 30.5% (Qwen3-VL-235B,从39.95到27.78) | Gemini稳定性领先约10.5个百分点,开源在Edit类ITG上W@4降至<16%几近崩盘 |
局限与改进
作者公开承认的局限性包括:(1)仅覆盖前端,未涉及后端数据库/Server/API/DevOps;(2)生成任务的查询是经结构化扩展后的设计文档,而非真实用户的模糊创意需求,主要测的是instruction-following而非创意理解,模糊创意的场景需要WebDev Arena等人评榜互补;(3)对高动态页面(实时游戏/快速状态切换)的浏览器实时交互评估仍有困难;(4)静态基准的数据污染风险,随时间可能需要动态生成;(5)Agent-as-a-Judge成本高,Gen评估每条任务要跑真实浏览器+多轮LLM调用。读者还可以观察到:(a)11类修复缺陷虽是社区高频,但仍是合成而非真实生产事故,且各类型分布未在论文中显式披露权重;(b)Vue评测样本仅60条,跨框架子集容差有限;(c)Eval judge全部用Claude-Opus-4.5,可能对Claude自家生成物有隐性偏好(虽然r很高,但rank差仍可能有偏好方向);(d)Worst-of-n只报告两个模型,不全面;(e)开源模型版本未与最新更新同步,235B Thinking变体反而比Instruct在SPI上有损失,可能是在测量一种训练中尚未稳定的特性。
独立分析的弱点
独立分析下WebCompass可以改进的方向:(1)Judge单一化风险——当Claude-Opus-4.5既做生成参考又当裁判,且编辑/修复judge也用同款时,会产生评分系统同源偏差,建议引入GPT-5.2或独立代理模型作为cross-judge做bland-altman分析验证;(2)Hard难度的Generation SPI断崖掉到37.64,这暗示Spec Implementation的checklist可能过于苛刻或测试用例过度依赖具体selector,未来可放宽selector匹配并采用更柔性的完成度评估;(3)生成评估Agent-as-a-Judge单次运行成本高,缺乏并行化与结果可缓存设计,对于学术复现门槛过高;(4)框架子集仅180任务,不足以得出Vue系统性弱的统计显著结论,应扩大到每框架每任务≥150条并配t检验;(5)Thinking模式在235B模型上因长思维链稀释特征(spec被推到很远)而SPI下降,提示prompt设计可加入'需求复述后再生成代码'的中间步骤强制锚定;(6)Repair的E5.1占主导(45-75%)说明模型只会patch不会诊断,可考虑将诊断任务独立出来作为'理解'类的评测单元。
未来方向
作者提出的+基于结果可延伸的方向:(a)把benchmark扩展到全栈,纳入Node/Python后端、API契约、数据库schema、容器化部署,形成完整的Web Engineering Spectrum;(b)增加多轮交互式任务,模拟真实'产品经理反馈→修改→再次验收'的迭代loop,衡量智能体收敛能力;(c)引入creative divergence维度,用人类偏好排序(类似WebDev Arena)与自动评分互补,衡量模型在模糊需求下的创意解空间;(d)构造动态生成流水线,使用LLM持续合成新query和新缺陷,搭配周期性数据污染检测(如训练数据水印)保持基准长期有效性;(e)基于Repair误差分布(45-75%缺陷未处理)开发专门的diagnosis-first智能体训练数据,先用模型解释bug再修;(f)把Agent-as-a-Judge的代码执行与浏览器交互解耦到可插拔架构,允许第三方研究者接入自己的工具组合,推动评测民主化;(g)将web评测范式迁移到移动端/桌面端UI开发(RN/Electron),验证方法的可推广性。
复现评估
复现评估较为友好:全部数据(1526条任务+checklist+标注)与评测代码已开源在 https://huggingface.co/datasets/NJU-LINK/WebCompass 与 https://github.com/NJU-LINK/WebCompass (主页 https://nju-link.github.io/WebCompass/),论文附录A.6公开了生成、编辑、修复以及checklist生成、错误分析、LLM-judge、Agent-judge的完整prompt模板,可以做到prompt级复现。所需算力因评测范式分两档:LLM-as-a-Judge只需一台Linux机器跑headless Chromium,每条成本$4.66(Opus-4.5 judge,每条4.66美元)或$2.34(Sonnet)/$1.02(Haiku);Agent-as-a-Judge需要能跑Claude Code(v2.0.67)+ Chrome DevTools MCP Server(v0.19.0)的Linux环境,时间显著长于静态评分,且评估脚本是确定性的(可重复)。但完整跑全套10个模型×7个任务=70个cell评估,即便用Haiku也接近数千美元,且Agent-as-a-Judge部分LLM-dependent行为存在非确定性问题,需多次重复取平均才能与论文结论对齐,门槛较高;此外闭源模型API需自费,开源模型(Qwen3-VL系列)可本地推理但235B-A22B需多卡H100/H200集群。整体可复现性评级:数据/代码/prompt ★★★★★,全表分数精准复现 ★★★。
论文图表
雷达图横轴列出七类任务(Text/Vision/Video-Guided Generation, Text/Vision-Guided Editing, Diagnostic/Visual-Diagnostic Repair),展示5个代表性模型(GPT-5.2、Claude-4.5-Opus、Gemini-3-Pro-Preview、Qwen3-VL-235B-A22B-Instruct、Qwen3-VL-32B-Instruct)在各任务上的Overall分数。
读者能一眼看出哪些模型在哪些维度上呈均衡的图形、哪些偏向单点,直观理解闭源三强 vs 开源之间的整体形态差距。
堆叠柱状图显示七类任务中Easy/Medium/Hard的样本数分布,例如Text-Guided Generation有68+114+123里按Easy 50 / Mid 40 / Hard 33的分布;Vision/Video-Gen等也各有标定。
让读者快速判断每个子任务的难度构成,判断评测对小模型是否过难或对大模型是否过易,以及本文后续Hard难度断崖分析的数据根基。
概览示意图,把Text/Image/Video三种input与Generation/Editing/Repair三种task正交组合成7个互补的任务类别,展示Web开发全生命周期视角。
本文最重要的一张概念图,是一切后续实验设计与对比的baseline chart,必须第一时间在motivation部分消化,理解为何需要7个而不是1个任务。
Repair的RCT/ITI/RFF在Hard/Mid/Easy下的模型对比;RCT在Hard上下降尤其显(开源模型在Hard上接近不可用)。
说明Repair即便是闭源在Hard RCT上也很吃力,与作者'最难的是定位根因'的解读一致。