腾讯联合清华北大实测AI网页生成：多维度评分一致率85.3%

你是否有过这样的经历：让AI生成一个网页应用，以为交代完需求就能坐等验收，结果打开后却发现：页面内容挤在一起，按钮和输入框重叠错位；熬了很久生成的应用，首页打开就报错，根本没法用；明明只想要一个简单的待办清单，AI却强行加上了账号体系和复杂的后台管理，完全偏离了最初的需求。

这些问题分别对应网页评测的三个核心维度：页面美观度、操作易用性和需求符合度，也就是要分别检查页面看起来怎么样、操作起来顺不顺、有没有准确满足用户的初始需求。针对AI网页生成的评测痛点，相关团队推出了WebCraftBench，将软件测试方法引入网页生成评测流程。

该评测体系让智能体实际操作生成的网页，通过代码覆盖率帮助查漏，再从上述三个维度进行评分。在197组经过复核的应用对比中，该系统与人类偏好的判断一致率达到85.3%。

• 相关论文标题：WebCraftBench: Evaluating Web Application Generation from a Software Testing Perspective
• 相关论文可在学术平台查阅

为什么AI网页生成评测需要真实交互测试？

评价一张图片只需要看最终呈现效果，但网页应用的评测需要关注交互后的表现：点击按钮、输入内容、切换页面后，功能能否正常运行。如果只看源代码，可能会发现代码中实现了排行榜功能，但无法得知入口按钮是否失效，普通用户根本无法访问；如果只看首页截图，也无法判断表单能否提交、游戏能否正常运行、出错后能否恢复。

代码中存在某个功能，不等于用户能够实际到达并使用它。让智能体实际操作网页，可以补上这些静态评测无法覆盖的证据，但同时也会带来新的问题：如果智能体判定某项检查未通过，到底是网页本身存在缺陷，还是测试智能体没有找到正确入口、操作出现偏差？另外，预先编写的验收清单也存在边界限制，智能体围绕清单逐项检查时，可能会忽略清单之外的交互逻辑；如果探索不够充分，还可能将未被发现的功能当成没有实现。

基于这些问题，WebCraftBench进一步优化了评测逻辑：不仅要记录“测出了什么”，还要明确“实现中的哪些部分已经被测到”，让评测结果更全面准确。

WebCraftBench的实测流程拆解

从真实用户需求出发构建评测集

WebCraftBench的需求来自内部平台的实际使用流量，该平台参照同类网页评测平台搭建。研究者先对流量数据进行匿名化处理，再由人工筛选，移除无法理解、依赖缺失素材或超出网页应用范围的请求，并进行文本和语义去重，最终保留369条纯文本需求。

这些需求非常贴近用户日常表达：60.2%使用口语化表达，63.4%的需求并未完整说明全部要求。需求长度从7个字符到37903个字符不等，覆盖娱乐应用、科学演示、在线办公、数据可视化等多种场景。每条需求还配有一份验收清单，由三个模型独立生成后合并，再由人工专家核验。清单仅描述用户应该能看到和用到的属性，不限制唯一的代码实现，也不会额外添加原需求没有提出的要求。

全数据集共有2706条功能标准、1447条内容标准和935条视觉标准，平均每个任务约13.8条验收标准。该评测体系的关键设计是：验收标准仅在评分阶段使用，探索阶段不会向智能体展示这份清单，系统先收集运行证据，再依据初始需求检查交付结果。

为代码添加运行计数器实现自动插桩

“插桩”听起来技术化，但作用很直观：在程序中加入计数器，记录哪些语句在运行时被执行过。WebCraftBench基于JavaScript测试工具Istanbul实现自动插桩工具，支持静态HTML、Vite、Next、Create React App和Astro等主流框架。应用启动后，每一次交互都可以返回覆盖率及其增量，帮助系统了解探索过程触达了多少代码实现。

在主实验的6273个应用中，该插桩工具的成功率达到99.89%。仅有的7个失败应用仍继续参与交互探索与评分，只是不再获得覆盖率反馈。

让智能体像专业测试人员一样操作网页

探索智能体按照软件测试中GUI测试的流程，通过Playwright MCP操作网页，读取简化后的页面结构，发现功能、尝试交互，并测试边界情况。该智能体无法直接查看源代码，也看不到验收标准或参考答案。

探索过程中，系统会持续监测覆盖率；如果连续三次交互都没有带来新增覆盖，就会请另一个模型分析尚未执行的代码，将分析结果转化为自然语言建议，交给探索智能体继续尝试。可以将这种分工理解为：前台测试人员负责实际操作，后台分析员查看哪些代码还没有被触达，再提示下一步值得检查的方向。

探索过程最多进行100步，也可以由智能体提前宣布完成。最后，系统会保留交互轨迹、页面结构、截图，以及对已发现功能和故障的总结。需要注意的是，覆盖率只是查漏的线索，某段代码被执行过，仍然需要结合实际运行结果判断功能是否正确。

将冗长的操作记录整理为状态转移图

网页经过多次交互后，会产生大量近似的截图和页面记录，如果直接全部交给评分模型，重复信息会挤占上下文空间，真正重要的故障反而会被淹没。WebCraftBench会对页面结构进行状态抽象和规范化处理，例如移除脚本、样式和易变属性，将时间戳替换为固定占位符。

经过规范化处理后，相同的页面会被合并为同一个状态，点击、输入、拖动等操作则作为连接不同状态的节点。这样，一段冗长的操作序列就会被转化为清晰的状态转移图，评分模型可以先查看这张图，再查阅对应的运行记录，大幅提升评测效率。

从三个维度进行多维度评分

WebCraftBench从三个核心维度对生成的网页进行评分：

• 美观度：从探索截图中筛选最多五张有代表性的画面，检查页面布局、信息层次、字体、图形质量和整体完成度。
• 易用性：根据交互轨迹和状态转移图，检查核心操作能否完成、反馈是否及时、导航是否清晰、能否恢复状态，以及出错时是否有合理的处理机制。
• 需求符合度：逐条查验用户的初始需求，评分智能体可以检索交互记录、阅读页面结构和查看截图，但每条判断都必须引用运行证据。单条标准只有“满足”或“不满足”两种结果，功能、内容、视觉三个子项分别按照满足比例计分。

其中美观度和易用性采用三轮评议流程：先由一个角色找出优点，再由另一个角色指出缺陷，最后由裁判核对证据并给出分数。最终评分会独立进行五次，去掉最高分和最低分后取平均值，以减少采样波动带来的误差。

三个大维度的原始分数均在0到100的范围内。汇总生成榜单时，研究者会先对各项分数进行标准化处理，再按照美观度、易用性、需求符合度各占三分之一的比例合成总分；需求符合度内部的三个子项采用等权计分。需要注意的是，榜单中的相对分数是相对于本次参评模型池的综合表现，并非百分制得分。

前沿模型测评结果与关键发现

各维度第一各有不同，总排名会隐藏差异

在本次论文的配置下，Claude-Opus-5综合排名第一，GPT-5.6-Sol第二，Qwen3.8-Max第三，Kimi-K3第四，Hy4 preview第五。但没有任何一个模型能够同时包揽三个维度的第一名：例如GPT-5.6-Sol的美观度排名第一，但易用性排名仅为第六。如果仅将所有能力压缩为一个总名次，会掩盖这类优势差异。

网页颜值无法替代交互可靠性

从模型的平均表现来看，美观度与易用性的相关系数为0.85；但具体到单个生成的应用，这个相关系数仅为0.36。这意味着，即便某个模型整体上更擅长生成优质作品，也不能仅凭某次生成结果的截图，就判断该网页一定操作顺手、运行稳定。

研究论文附录中给出了一个具体案例：在两款数独应用中，人工投票更偏好界面更精致的一款，但运行测试发现，该应用进入主要游戏路径后会崩溃；另一款界面更简单的应用，核心数独交互却能正常工作，WebCraftBench最终选择了后者。这一案例提示我们，美观与功能可靠性的权衡会影响对产品的最终判断，单次投票本身不足以解释用户做出选择的完整原因。

与人类偏好一致率达85.3%，分差越大一致率越高

研究者另外抽取了200个内部平台会话，其中197个保留了有效应用对。这批样本独立于前面的369条基准需求，原始人工投票经过额外标注人员复核后，用于验证自动评测的准确性。

在197组对比中，WebCraftBench有168组与经复核的人类偏好一致，一致率为85.3%。如果仅看两份应用的综合标准化分差至少为0.25的132组样本，一致率为90.9%；在分差至少为0.75的50组样本中，有49组判断一致，一致率达到98.0%。相反，在全部29组出现分歧的对比中，有24组的分差小于0.5，分数接近的作品更容易出现不同的判断结果。

这些结果支持自动评分可用于辅助区分应用质量，但同时也提醒我们：分数接近的作品需要谨慎解读，85.3%的一致率仅代表该批经复核样本上的成对偏好一致率。

更换评分裁判，整体排名依然稳定

研究者保留生成应用、探索轨迹、评分流程和提示词，将评分裁判替换为Gemini-3.7-Flash，对比两套评分结果的差异。最终两套结果的Spearman排名相关系数达到0.980。在17个模型的两两比较中，共有136对对比，其中130对保持了原有的先后顺序，占比95.6%，前四名的顺序也没有发生变化。

不过，更换评分裁判后，原始分数的高低和分布确实发生了明显变化。例如，模型池的平均易用性分数从60.1上升到75.7。这说明，“排序比较稳定”与“绝对评分完全一致”是两件不同的事情。本次实验保留了原有探索轨迹，验证的仅为评分裁判更换后的排名稳定性。

覆盖率反馈确实能帮助智能体提升测试覆盖范围

为了验证覆盖率引导的作用，研究者生成360个可部署应用，对比了有、无覆盖率反馈的两种探索方式。结果显示：

• 函数覆盖率中位数从91.9%提升至94.3%，增加了2.4个百分点；
• 覆盖率低于90%的任务从139个减少到99个，数量相对减少约29%；
• 达到100%函数覆盖率的任务，从38个增加到52个。

覆盖率的提升主要集中在中高覆盖区间，低覆盖区间的改善相对有限。人工检查发现，一些应用在首页就出现报错，或者关键事件处理函数抛出异常，导致下游功能无法被触达。此时，低覆盖本身也能提供有价值的诊断线索：探索受阻可能来自用户同样会遇到的产品故障。但需要注意的是，覆盖率升高并不直接等于功能正确率提高，两者仍需结合运行证据分别判断。

核心总结

• 网页生成评测需要沿着用户的实际操作路径展开。从入口按钮，到页面切换，再到输入与反馈，整条使用路径都可能改变用户体验。静态呈现之外，运行证据能告诉我们功能是否真正可达、可用。
• “有没有测到”应该成为评测方法的一部分。测试智能体也会遗漏功能。覆盖率让这种探索不足变得更可观察，还能为下一步操作提供线索，帮助减少把探索失败与应用缺陷混在一起的情况。
• 把探索与评分分开，有助于扩大观察范围。先让智能体发现应用的实际行为，再围绕验收标准检索证据，既保留需求约束，也给清单之外的交互留出被观察的机会。
• 解读榜单时要同时看维度、分差和配置。视觉表现突出、交互稳定、需求完成度高，分别对应不同优势。标准化综合分依赖参评模型池，跨榜单不能直接对比；很小的名次差异，也不宜被放大成明确的能力鸿沟。