南京大学与快手联合打造"网页编程考试场"：当AI遇上全套前端工程挑战

这项由南京大学与快手技术联合开展的研究，于2026年4月以预印本形式发布在arXiv平台，编号为arXiv:2604.18224。这是一项关于如何更科学地评价人工智能写网页代码能力的基础性研究，感兴趣的读者可通过该编号查询完整论文。

网页，是我们每天打开浏览器后看到的一切。从购物车到登录框，从动态图表到炫酷动画，这些视觉上生动、功能上复杂的数字界面，背后都是由成千上万行代码支撑的。近年来，各种人工智能大模型逐渐宣称自己能"写代码"，而且写得越来越好。然而，一个隐秘的问题悄然浮现：我们真的知道它们"写得好不好"吗？

回到最朴素的常识层面。当你雇一位装修工人，你不会只看他能不能把墙涂上颜色，你更在意墙面是否平整、门窗是否开合顺畅、灯光是否美观协调。网页开发也是如此——一个合格的网页不只要能"跑起来"，还得好看、能点击、能交互、能适配不同设备。可现有的AI评测体系，大多只盯着"代码能不能运行"这一件事，完全忽略了网页作为视觉和交互产品的其他维度。南京大学与快手的研究团队注意到了这个盲区，并着手建造一套更完整的"考场"——他们称之为WebCompass。

一、考场为何需要重建？现有评测的三大死角

要理解WebCompass的价值，得先明白现有评测体系存在什么问题。

以往那些被广泛使用的代码评测基准，比如HumanEval和SWE-Bench，本质上是在考算法题和修复代码bug，就像只用数学题来衡量一个建筑师的能力，完全看不出他能不能设计出美观实用的房子。即便是专门针对网页的评测，也大多只给模型一段文字描述，让它生成一个静态页面，然后截个图对比一下——既不测试页面里的按钮能不能点，也不测试动画是否流畅，更不测试当原有代码需要修改时模型能不能改得又准又美。

这带来了三个明显的死角。第一，评测任务太单一，只考"从零生成"，完全不考"修改已有代码"和"修复代码中的缺陷"这两种在真实工作中同样常见的场景。第二，输入形式太窄，几乎只接受文字描述，忽视了开发者在实际工作中经常要对着参考截图甚至演示视频来写代码的情况。第三，评判标准太粗糙，不管页面好不好看、交互是否顺畅，只要代码不报错就算过关。

WebCompass的出现，正是为了填补这三个死角。

二、七张考卷，三种题型，覆盖网页开发全生命周期

研究团队把真实的网页开发工作拆解成三个核心环节：生成（从无到有写出网页）、编辑（在已有代码上按要求修改）、修复（找到代码中的毛病并打补丁）。这三个环节，就像厨师的三项基本功——从食材到成品的烹饪、对菜品进行改良调味、以及修正出锅前发现的问题。

在这三个环节之上，研究团队又叠加了三种输入方式：纯文字描述、参考截图、以及演示交互过程的视频。两两组合之后，生成了七类任务。文字引导的生成任务，相当于给厨师一份菜谱让他做菜。图片引导的生成任务，是把一道菜的成品照片摆在厨师面前，让他复刻出来。视频引导的生成任务，则是让厨师看一段别人做菜的录像，再自己动手做出同款。文字引导的编辑任务，是告诉厨师"这道菜太咸了，少放点盐，再加点香菜"。图片引导的编辑任务，是给厨师看一道改良后应该是什么样子的图，让他自己判断需要做哪些调整。文字引导的修复任务，是告诉厨师"这道菜出了点问题，好像火候过了"，让他自己找到问题所在并修正。图片引导的修复任务，则是同时给厨师看现在这道菜的照片和理想状态的照片，让他找出差距并动手修复。

整个数据集共包含1526道题目：文字引导生成123题，图片引导生成109题，视频引导生成94题，文字引导编辑300题，图片引导编辑300题，文字引导修复300题，图片引导修复300题。每道题都被标注了简单、中等、困难三个难度等级，难度的划分依据是功能复杂程度、交互组件数量和视觉设计精细程度。

三、考题从哪里来？一套严格的"出卷流程"

一套好的考试，题目质量至关重要。WebCompass采用了多阶段、人工介入的流水线来保证数据质量，这个流程本身就相当值得深入了解。

生成类题目的原始素材，来自四个渠道的汇聚：一个专门收集多样网页需求的公开数据集WebGen-Bench、另一个经过严格筛选的多类别数据集ArtifactsBench、来自真实用户的BigCode Arena需求记录，以及一个专为AI网页设计打造的平台V0上的高质量展示案例。研究团队用一种文本嵌入技术对这些素材去重，再用大语言模型按类别和难度打标签，最后按比例抽样，得到123道文字生成题。

然而，原始用户需求往往太模糊。比如"给我做一个购物网站"，这种描述太开放，不同模型可能做出天差地别的页面，根本无从比较好坏。研究团队的解决方案是：让一个大语言模型扮演"产品经理"，把每一个模糊的需求扩充成一份结构化的网页设计文档，明确写清楚页面内容、交互行为和视觉风格三个方面。这样一来，评测标准有了，比较就有了依据。

图片引导生成的数据，来源于一个包含大量视觉复杂网页的公开数据库WebRenderBench。研究团队用Playwright自动化工具截取了首页和两个子页面的截图，并在截图上用彩色框标注出页面中的跳转链接位置，以此测试模型能否理解多页面网站的整体结构。对于动态交互内容，研究团队手工从V0和Figma平台挑选了有丰富动效的网页，提取关键帧来构建数据集。视频引导生成的数据，则完全由人工录制：标注员先探索每个网页，规划好完整的操作路径，再录制一遍确保覆盖所有交互功能。

编辑和修复类题目，共用一批被称为"原型"的高质量代码库。这批原型经历了三道筛选：先过滤代码量太少或太多的（控制在3.2万到6.4万字符之间），再用GPT-4o打代码质量分，只保留9分及以上的，最后由人工逐一审核，选出50个最优质的。每个原型还被扩展成单页版和多页版两种形式。

编辑题的设计思路，是在这些原型的基础上，加入16种预定义的高难度前端功能需求。这16种需求涵盖了复杂组件（如可拖拽界面、树状结构展示）、前后端交互（如实时数据仪表盘、异步表单验证）、高级动效（如视差滚动、粒子特效）和完整业务流程（如购物车、多步骤向导）。需求描述会告诉模型"要做什么"，但绝不透露"怎么做"，不提供任何CSS类名或选择器，以保证评测的公平性。

修复题的设计则更有意思，采用了一种"逆向工程"思路。研究团队先保留一个干净无缺陷的原型作为"答案"，再用大语言模型向其中注入经过设计的缺陷，制造出有问题的"题目代码"。注入的缺陷分三类：视觉布局类（元素遮挡、文字溢出、对齐偏差、颜色对比不足等七种）、语义结构类（语义标签用错、HTML嵌套不合规范）、交互可用性类（点击事件被禁用、关键属性缺失）。为了保证评测的确定性，每道修复题都附带一个精确的"搜索替换"注释，记录了注入缺陷时修改了哪些代码，确保修复后的代码能被精准核验。

值得一提的是，这11种缺陷类型并非凭空捏造，而是基于对V0平台上超过200个真实用户项目和对应GitHub Issues的系统分析，从中提炼出最常见的前端反模式。这让整个数据集具有很强的现实代表性——测的是模型在真实工作场景中最可能遇到的那类问题。

四、怎么打分？两套评判机制各司其职

出了好题还不够，还要有公平科学的判卷方式。WebCompass针对不同任务设计了两套截然不同的评判机制。

对于编辑和修复任务，研究团队使用了"LLM-as-a-Judge"（大语言模型担任评委）的方案。具体流程是：把模型生成的代码补丁应用到原始代码库，在无头Chromium浏览器中运行，截取修改前后的页面截图，然后把这些证据全部提交给担任评委的Claude模型，让它沿着三个维度逐项打分。编辑任务的三个维度分别是：补丁是否打到了正确位置、原有功能是否保留且新功能是否正常、视觉风格是否符合要求。修复任务的三个维度则是：是否找准了缺陷根源、交互功能是否完好、修复后的视觉效果是否接近标准答案。每个维度0到10分，最终分数取三维度的调和平均值。之所以用调和平均而非算术平均，是因为调和平均对短板更敏感——一个在某个维度表现极差的模型，不应该靠其他维度的高分来拉平。

对于生成任务，则引入了一套全新的"Agent-as-a-Judge"（智能体担任评委）方案。这套方案的背景是：现有的静态截图比较抓不住动态交互，而纯代码测试又看不出视觉质量，二者都有明显局限。这套新方案让一个AI智能体（具体使用的是Claude Code）通过MCP协议控制真实的Chrome浏览器，像一个真实用户那样打开页面、点击按钮、滚动页面、填写表单，同时录屏截图，并动态编写JavaScript测试脚本来核验具体的DOM状态和CSS属性。

这个过程分四步完成。首先，一个大语言模型根据任务需求生成一份结构化的评测清单，每条清单项都包含任务名称、操作步骤、预期结果和分值，这份清单在整个评测过程中保持不变，不允许修改。然后，智能体按清单一条条操作页面，收集截图、控制台日志和DOM快照作为证据。接着，智能体针对每条清单项自动编写JavaScript测试代码，如果执行失败，还会回头看实际代码，调整DOM选择器后重试——但关键在于，调整的只是"怎么找到这个元素"，判断标准本身绝不改动，防止智能体为了让测试通过而降低要求。最后，只有能提供截图、测试结果或控制台日志等具体证据的评分才会被计入，没有证据支撑的打分直接作废。

为了验证这两套方案的可靠性，研究团队在200个样本子集上与人类标注进行了对比。结果显示，使用Claude Opus 4.5作为评委时，与人类判断的皮尔逊相关系数在生成、编辑、修复三类任务上分别达到0.93、0.94和0.96，非常接近人类水平。在模型排名的对比上，自动评估与人工评估的排名差异几乎都在0到1名之间，说明这套自动化评测体系是可信的。

五、谁考了多少分？闭源模型大幅领先，视觉始终是软肋

研究团队在WebCompass上测试了来自闭源和开源两大阵营的十款模型，结果揭示了几个清晰的规律。

闭源模型整体领先，且优势相当悬殊。在综合总分上，Claude Opus 4.5以67.40分排名第一，Gemini 3 Pro Preview以66.68分紧随其后，GPT-5.2以61.90分位居第三。而表现最好的开源模型Qwen3-VL-235B-A22B-Instruct，综合得分只有41.14，与第一名相差超过26分。更小的30B开源模型，分数更只有28分左右，尚不及顶级闭源模型的一半。这道鸿沟反映出当前开源与闭源模型在代码生成能力，尤其是复杂前端代码生成能力上的真实差距。

三类任务呈现出截然不同的得分模式。对于生成和编辑任务，闭源模型的得分始终遵循"可运行性 > 功能实现 > 视觉质量"的顺序，以Claude Opus 4.5的生成任务为例，三项得分分别是77.18、68.95、62.26，逐级递降。这说明AI写出能跑的代码并不难，但要写出既能跑又功能完整、还视觉精美的代码，难度依次增加。修复任务则呈现出完全不同的模式：交互完整性得分远高于参考还原度，参考还原度又高于根因定位。这背后有个逻辑：修复题的11种缺陷中，有9种是视觉或语义问题，并不涉及交互逻辑，所以即便不修任何东西，交互部分也很可能安然无恙，导致交互完整性得分虚高。真正体现修复能力的根因定位，恰恰是所有模型得分最低的那项。

视觉质量是所有模型的持久短板。在生成任务的设计质量和编辑任务的样式合规性两个维度上，所有十款模型都拿到了最低分。即便是在视觉维度表现最好的Gemini 3 Pro Preview，生成任务的设计质量也只有64.07分，远低于它的功能得分。更耐人寻味的是，Gemini的视觉得分在多项指标上超过了GPT-5.2，尽管两者的可运行性得分相近，说明视觉理解和代码执行能力是两条相对独立的发展轨道，并不会同步提升。

六、框架选择有多重要？Vue让所有模型都头疼

为了探究前端框架的选择如何影响模型表现，研究团队抽取了180道题，分别用React、Vue和原生HTML/CSS/JS（Vanilla）三种框架来完成，测试了四款代表性模型。

结果出乎很多人意料，但仔细想想又在情理之中。在生成和编辑任务上，四款模型使用Vanilla框架时得分均最高，使用Vue时得分几乎无一例外是最低的。原因可以这样理解：Vanilla就像用最基础的食材手工烹饪，没有复杂的厨具，出错概率低；而Vue就像使用了一套功能繁多但规则也繁多的全自动料理机，稍有不慎就会出错。Vue的单文件组件格式把HTML模板、JavaScript逻辑和CSS样式全塞在一个文件里，三种语法并存，任何一块写错都可能引发跨模块的连锁错误。React用的是JSX语法，虽然也有一定特殊性，但本质上还是标准JavaScript，相对更容易处理。

修复任务的情况有些不同。GPT-5.2在React框架下取得了最好的修复得分，而不是Vanilla。研究团队的解释是：修复任务的核心是精准定位并修改缺陷，React的组件化架构为代码划定了清晰的边界，让模型更容易找到问题所在，而Vanilla代码往往更加"散漫"，缺少结构性的参照点。

无论模型强弱，这种"Vue最难、Vanilla在生成编辑中最容易"的规律都保持稳定，说明这是框架本身特性与任务类型之间的固有张力，而非某款模型的特殊弱点。

七、难度越高，崩溃越明显——尤其是功能实现这一关

简单、中等、困难三档难度题的得分对比，揭示了模型能力的天花板在哪里。

整体而言，所有模型的得分都随难度提升而下滑，且排名基本保持稳定——强的还是强，弱的还是弱，困难题只是把所有人都往下拉，而不是制造剧烈的排名洗牌。

最显著的崩溃发生在生成任务的功能实现维度上。以Gemini 3 Pro Preview为例，它在简单生成题上的功能实现得分是89.83，但到了困难题，这个数字直接跌至37.64，缩水了一半还多。困难的生成题通常要求模型实现复杂的多步骤用户流程、动态状态切换和丰富的交互行为，这对模型理解复杂规格并逐一落实的能力提出了极高要求，而这恰恰是目前所有模型的共同弱点。

与此形成对比的是，可运行性这一维度受难度影响相对较小。换句话说，模型在困难题上"跑起来没什么报错"这件事做得还行，但"跑起来之后是否实现了题目要求的全部功能"，往往一塌糊涂。

八、修补越多，副作用越大——过度编辑的陷阱

研究团队还专门分析了模型生成的代码补丁的结构特征，得出了一个颇具实践意义的发现。

编辑任务的补丁普遍比修复任务大得多。编辑补丁的中位变更行数在646到1976行之间，而修复补丁的中位变更行数只有16到19行，与人类专家写的标准答案非常接近。然而，修复补丁虽然整体接近人类水平，但分布的"尾巴"很长——有相当一部分修复补丁远超应有的体量。

这种"过度编辑"会带来明显的副作用：在修复原有缺陷的同时，引入了新的问题。从错误类型统计来看，"新引入缺陷"在闭源模型的修复错误中占到8%到12%，而Claude和GPT-5.2这两款生成最大补丁的模型，恰恰是引入新缺陷最多的模型。这与厨师改善一道菜时手太重、结果把原来好的地方也弄坏的情形如出一辙。

更有说服力的一条规律是：更强的模型并不简单等于生成更大的补丁。Claude Opus生成的编辑补丁，大约是Gemini系列的三倍，但两者在质量评分上的差距并不成比例。成功的网页代码修改，依赖的不是改动量的大小，而是能否精准找到需要改的地方并做出连贯、有针对性的修改。

九、思维链有没有用？在某些场景下反而帮倒忙

近年来，让大语言模型"先想再说"的思维链技术受到广泛关注。研究团队专门比较了Qwen3-VL系列模型的"Instruct版"（直接给答案）和"Thinking版"（先展开推理链再给答案）在WebCompass上的表现差异。

结论是：影响有限，且存在明显的反向效应。

在生成任务的可运行性维度上，两个规模的Thinking版模型得分都略高于Instruct版，说明推理链对代码结构的完整性有一定帮助。但235B规模的Thinking版在功能实现维度上，得分从42.14显著下滑到35.02，这是一个不小的退步。

研究团队的解释颇有洞察力：网页开发的提示词通常同时包含多项要求——布局、样式、交互行为、响应式设计……当模型展开很长的思维链时，原始需求被推离了上下文的核心位置，到真正生成代码的时候，一些需求已经"忘了"。较小的30B模型因为思维链本身不那么冗长，这个问题反而不那么明显。在编辑和修复任务上，Thinking版与Instruct版几乎没有差别，而这两类任务本来就是所有Qwen模型的重大弱点所在——这说明当任务本身已经超出模型能力边界时，思维链也无力回天，因为没有足够的基础知识可供推理链调用。

十、错误图鉴：AI写网页时最常犯的毛病

为了从另一个角度理解模型的失败模式，研究团队对所有评测中的扣分项目进行了系统分类，建立了一套两级错误分类体系，涵盖代码执行、功能实现、视觉样式和非功能性四个大类，共15种细分错误类型。

在生成任务上，"功能缺失"是出现频率最高的错误，尤其是在同时要求布局、交互和样式的困难题中。"资源加载失败"排在第二位，通常表现为图片、字体或外部依赖找不到。这两类错误合计占大多数模型总错误数的40%到55%。强模型减少了这些基础性失败，但因此暴露出更多细粒度的布局和样式问题；弱模型则在连基础功能都跑不顺的泥潭里打滚。

从输入模态看，文字引导生成的错误以功能缺失为主，说明模型在把文字需求转化为可运行代码时仍有明显障碍。图片引导生成的错误则向视觉还原偏差集中，说明AI对像素级外观的理解和还原还有很大提升空间。视频引导生成的错误最为均衡，功能和视觉问题都有，因为视频同时考验了模型理解时序交互和还原视觉外观两件事。

编辑任务的错误几乎被两类主导：功能缺失和功能不完整。开源模型中，功能缺失一项就能占到所有错误的76%，即便是顶级闭源模型，功能缺失和功能不完整合计也高达70%。这说明模型在处理复杂多步骤编辑指令时，很容易"部分完成"，丢掉一些要求。

修复任务的错误分布则完全是另一番景象，最主导的错误类型是专门为修复任务设计的"缺陷未被处理"。弱模型中，高达74%的错误就是因为生成的补丁根本没有修到出问题的地方。即便是综合修复表现最好的Gemini 3 Pro Preview，也有49%的错误属于这一类型。换句话说，修复任务最大的挑战不是"怎么改"，而是"改哪里"——精准的缺陷定位，依然是当前所有模型的软肋。

说到底，WebCompass这套评测体系告诉我们的核心信息是：AI写网页代码的能力，远比"能不能生成一段能跑的代码"复杂得多。一个真正可用的网页，需要同时在可运行性、功能完整性和视觉质量三条赛道上达标，而目前即便是最强的闭源模型，视觉这条赛道依然是最薄弱的环节。开源模型与闭源模型之间的差距超过26个百分点，说明这个领域的技术进步远未结束。生成、编辑、修复三类任务考验的是截然不同的能力，没有任何一款模型能在三类任务上同时独占鳌头。框架选择不是小事，Vue的"全合一"设计让几乎所有模型都举步维艰。而"思维链"这种被寄予厚望的推理增强技术，在超长需求描述面前反而可能引发注意力稀释，让功能实现得分下滑。

这项研究的另一层意义在于：它本身就是一个方法论上的示范，向整个AI评测社区证明，面对网页这类视觉与功能并重的数字产品，评测工具也需要像真实的QA工程师一样，既能点按钮、跑测试，又能审美地看待页面设计。未来的研究有三个明显的延伸方向值得期待：将评测范围从前端扩展到后端和全栈、引入真实用户偏好打分作为补充维度、以及随着模型持续更新不断刷新基准版本。有兴趣深入探究这套方法的读者，可通过arXiv编号2604.18224查阅完整论文，数据集和评测代码均已在HuggingFace和GitHub上公开。

Q&A

Q1：WebCompass评测体系和传统代码评测基准有什么本质区别？

A：传统代码评测基准如HumanEval主要考算法题，只要代码能运行、输出正确结果就算通过，完全不考察页面是否好看、按钮能不能点、动画是否流畅。WebCompass则把网页开发拆解为生成、编辑、修复三类任务，覆盖文字、图片、视频三种输入形式，并从可运行性、功能完整性、视觉质量三个维度同时打分，更接近真实开发场景中对一个网页的综合评判标准。

Q2：Agent-as-a-Judge是什么，为什么要用它来评测生成的网页？

A：Agent-as-a-Judge是WebCompass提出的一套新评测方案，让一个AI智能体（使用Claude Code）通过MCP协议控制真实Chrome浏览器，像真实用户一样打开页面、点击按钮、填写表单，同时截图并动态编写JavaScript脚本来核验具体功能。之所以需要这套方案，是因为静态截图对比看不出交互是否正常，纯代码测试又看不出视觉质量，而这套方案能同时覆盖两个维度，更接近人工验收测试的水平。

Q3：开源大模型在WebCompass上表现差在哪里？

A：最直接的差距体现在综合得分上，最好的开源模型Qwen3-VL-235B综合得分仅41分，而顶级闭源模型超过67分，差距超过26个百分点。具体来看，开源模型在编辑任务上的表现尤其糟糕，多个维度得分跌到18到28分，说明它们在理解已有代码结构、精准定位修改位置、生成符合上下文的补丁这套流程上存在根本性短板，而不仅仅是视觉质量差的问题。