- 论文 IWC-Bench 的 arXiv 编号为 2609.15387,v1 提交于 2026 年 9 月 14 日,v2 更新于 9 月 17 日;作者来自腾讯混元团队,其中几位作者的署名单位包含清华大学与北京大学。
- 数据集含 369 条真实用户需求,配 5,088 条验收标准:2,706 条功能、1,447 条内容、935 条视觉,平均每个任务 13.8 条。
- 评测流程分四个阶段:自动插桩、覆盖率引导探索、状态抽象、三维评分;验收标准的出现时点限于评分阶段,探索阶段看不到。
- 17 个前沿模型在 369 条需求上生成 6,273 个应用,综合分第一为 Claude-Opus-5(+1.326);没有模型包揽三个维度的第一。
- 197 组人工偏好对比中一致率为 85.3%,分差不小于 0.75 的 50 组里有 49 组一致;换成 Gemini-3.7-Flash 当裁判后排名相关系数为 0.980,数据集与源码不公开。
为什么静态打分不够:功能写在源码里,用户却点不到
让模型交付一个网页应用,验收的难点出现在看不见的地方。论文把两类失效分开写:静态基准会给源码里存在、运行时却不可达的功能记分;交互式基准会操作应用,但探索不完整时,已实现的功能会被漏掉,这层探索带来的另一个问题是应用缺陷与智能体操作失败容易混在一起。
落到具体页面上,失效有三种形态。入口按钮坏掉,用户走不进主流程。表单提交失败,代码里的处理函数停留在未执行状态。需求被自作主张地扩大,用户想要一个免登录的待办清单,交付物里多了账号体系与管理后台。
代码里有某个功能,不等于用户能到达并使用它。这句话是论文的立论起点,并解释了三个评测维度的由来:页面看起来怎么样,操作起来顺不顺,用户交代的事情有没有做到。三项需要分开检查,因为它们的证据来源不同,一个靠截图,一个靠交互轨迹,一个靠需求清单。
顺着这条线往下走,会撞上一个硬问题。测试智能体本身会遗漏功能,当它判定某项检查不通过时,区分这两者的难度不小:原因可能在于网页没有做好,或者它没找到入口。预先写好的验收清单存在边界:围绕清单逐项检查,清单之外的交互容易被忽略。于是论文的解法多了一层,评测需要知道哪些实现进入了被测范围。
四个阶段:从插桩到三维评分
第一阶段是自动插桩。工具基于 JavaScript 测试工具 Istanbul 构建,覆盖静态 HTML、Vite、Next、Create React App 与 Astro 等框架。应用启动后,每次交互带回代码覆盖率及其增量,系统由此知道探索触达了多少实现。主实验的 6,273 个应用里,插桩失败 7 个,成功率 99.89%;失败原因有三类:4 个应用使用 Istanbul 不支持的 JSX 输入表单,2 个使用 npm-workspaces 单仓库导致工具定位不到 Vite 工程根目录,1 个超出沙箱部署体积上限。这 7 个应用继续接受探索与评分,代价是失去覆盖率反馈。
第二阶段是覆盖率引导探索。探索智能体基于 AWorld 框架,用 Playwright MCP 操作页面;每一步读取简化后的页面结构,步骤之间读取的内容限于结构差异,以节省上下文。它被提示为一名软件测试人员,任务是发现可用功能并测试边界情况,它看不到源代码、验收标准与参考答案。当连续三次交互没有带来覆盖率增量时,系统判定探索进入平台期,提取未执行的代码,交给另一个模型产出自然语言建议,随后把这些建议注入探索智能体的上下文。探索在智能体宣布完成或耗尽 100 步预算时结束,收尾的一步要求它汇总功能、交互与观察到的故障。
第三阶段是状态抽象。页面被点来点去之后会留下大量近似记录,直接交给评分模型会挤占上下文,重要故障反而被淹没。系统对页面结构做规范化处理,移除脚本、样式与易变属性,把时间戳替换成固定占位符;规范化表示相同的页面合并为同一个状态,点击、输入、拖动这类操作连接状态,一段冗长的操作序列由此变成状态转移图。评分模型先看这张图定位路径,随后查阅对应的运行记录。
第四阶段是三维评分,三个维度的证据与流程各不相同。美观度从探索截图里筛选代表画面,数量上限为五张,先用前景与边缘密度过滤空白帧与未加载完的帧,接着用最远点采样挑出视觉差异大的画面,评委检查布局、信息组织、字体、图形质量与完成度。易用性依据完整交互轨迹与状态转移图,检查核心操作能否完成、反馈是否及时、导航是否清楚、状态能否恢复、出错时有无合理处理。这两项走三轮评议:支持者找优点,批评者找缺陷,裁判对照证据复核后打分;裁判在 0 到 5 的基础上做七项维度调整并截断到该区间,随后独立运行五次且前两次评估固定,去掉最高分与最低分,剩下的三次取平均后按 20 倍映射到 0 到 100。
需求符合度按清单逐条判定,判定结果限于满足与不满足两种,没有部分得分;实现存在于源码而未被执行的,不算证据;功能、内容、视觉三个子项各自按满足比例计分。汇总阶段先做标准化,美观度与易用性各占三分之一,需求符合度占三分之一并在三个子项间等权。论文给这张榜单的定位值得记住:分数是相对这批参评模型的标准化结果,含义不是成功率或百分制得分。
成绩单:6,273 个应用里没有全能选手
每个模型对每条需求生成一个应用,17 个模型乘 369 条需求得到 6,273 个应用,评分按维度统计。综合分前五名是 Claude-Opus-5(+1.326)、GPT-5.6-Sol(+1.077)、Qwen3.8-Max(+0.970)、Kimi-K3(+0.967)、HY4-Preview(+0.911),第六到第八是 Claude-Opus-4.8(+0.755)、Grok-4.5(+0.750)、GPT-5.5(+0.468)。论文在表格里标注了每个模型的运行框架与推理强度,Claude 系列走 Claude Code,GPT 系列走 Codex,推理强度从 high 到 xhigh 不等。 拆开维度看,优势分布互补。GPT-5.6-Sol 的美观度得分 +2.239 排在第一,需求符合度落在 +0.137,易用性掉到第六。Claude-Opus-5 的三项是美观度 +1.428、易用性 +1.757、需求符合度 +0.794。没有模型包揽三个维度的第一,把能力压成一个总名次会掩盖这类差异。
论文把 17 个共有模型的排名与 Code Arena 做了对照,Spearman 排名相关系数为 0.890,Code Arena 榜单的时点为 2026 年 9 月 10 日。两套评测在能力层级上一致,排名 1 至 5、6 至 10、11 至 14、15 至 17 四个区间保持分层。需要注意的是,两边的量纲不同,部分模型的运行框架与推理强度存在差异,论文用这张图说明的是趋势一致,而不是分数可比。
85.3% 的人类一致率,与分差的关系
验证样本来自内部平台的 200 个会话,其中 197 个保留了有效的应用对比,与前面的 369 条基准需求相互独立,人工投票经过额外标注人员复核。在这 197 组里,IWC-Bench 的判断与人类偏好一致的有 168 组,一致率 85.3%。
分差拉大之后,一致率随之上升。综合标准化分差不小于 0.25 的 132 组里,一致组数为 120,一致率 90.9%;分差不小于 0.75 的 50 组里,49 组一致,一致率 98.0%。29 组分歧集中在分差小的区间,17 组落在分差不小于 0 且小于 0.25 的区间,7 组落在 0.25 到 0.5 之间,4 组落在 0.5 到 0.75 之间,1 组落在 1.0 到 1.5 之间。
分差不小于 0.75 的 50 组样本里,分歧数量为一组,是论文专门放进附录的数独案例。人工评分者偏好界面精致、视觉一致的版本,运行测试发现它进入主要游戏路径后崩溃;另一个版本界面朴素,核心数独交互可用,评测在易用性与需求符合度上的优势超过了对手的视觉优势,于是选了后者。论文对这个案例的说明留有余地:投票本身无法还原评分者在美观与功能可靠性之间的权重。
读数时要注意样本口径。85.3% 是这 197 组经复核样本上的成对偏好一致率,接近的分数需要谨慎解读,这一点与论文自己的表述一致。
换一个裁判,排名会变吗
稳健性检查保留了任务、生成应用、探索轨迹、评分流程与提示词,把主裁判从 Claude-Opus-4.8 换成 Gemini-3.7-Flash。两套结果的整体分数 Pearson 相关为 0.983,Spearman 排名相关为 0.980;136 对模型里有 130 对保持原有先后顺序,一致率 95.6%,前四名以及第 8、9、12 名没有变化,所有模型的位次移动不超过两名。
顺序变化限于 6 对比较,其中 3 对在主裁判下分差低于 0.04。另外 3 对里,一对发生在 HY4-Preview 与 Grok-4.5 之间,两对涉及 MiniMax-M3,它在 Gemini-3.7-Flash 下从第 17 升到第 15。 绝对分数与分布的变化不容忽略。模型池的平均易用性从 60.1 升到 75.7,模型级美观度分数的极差从 26.8 扩大到 44.2 分。论文因此强调,排序稳定与绝对评分一致是两件事,标准化应当在各自裁判的模型池内进行。
覆盖率引导有用吗:360 个应用的对照
这段对照由 Claude-Opus-5 生成的 360 个可部署应用组成,369 条需求里有 9 个因缺文件、部署错误或端口声明错误未能部署,对比有覆盖率反馈与没有反馈两种探索方式,衡量指标是函数覆盖率。有引导时中位数从 91.9% 升到 94.3%;低于 90% 的任务从 139 个降到 99 个,占比从 39% 降到 28%,相对降幅 29%;达到 100% 覆盖率的任务从 38 个增加到 52 个。
改善集中在中等与较高覆盖区间,覆盖率为 70% 到 90% 的区间少了 38 个任务,90% 及以上的任务增加 40 个,从 221 个升到 261 个;低于 70% 的低覆盖尾部从 17 个变成 15 个,变化有限。人工检查给出的解释是,这些应用包含阻断探索的故障,例如入口页直接报错、事件处理函数抛出异常、关键路径损坏导致下游功能不可达。
这段结果给出另一条诊断提示:低覆盖率本身携带信息,它可能来自用户会撞上的产品故障。不过覆盖率上升并不等于功能正确率上升,两者的证据需要分开判断。
意义与局限:不公开数据,任务限单轮纯前端
对做前端交付验收的团队,这套流程里可以搬走的是三件事:用代码覆盖率给探索查漏、把交互轨迹压成状态转移图、把验收标准与探索阶段隔离。三者的使用不依赖论文的具体榜单,对模型批次没有要求。三项参数同样可搬运:探索预算为 100 步,连续三次交互无覆盖率增量即触发建议注入,裁判重复五次并去掉最高与最低;其中评分轮次的影响由论文附录 D 的对照实验单独交代,探索预算与平台期阈值以论文给定值为准。
论文自己列出的局限有四项。评测依赖 LLM 裁判,裁判偏好会影响结果,论文用人类偏好对比与换裁判实验检查其稳定性,检查的是稳定性而非正确性。标准化后的分数依赖同一批参评模型,不适合跨模型池直接比较,论文建议未来使用固定的参考均值与标准差,并配合原始分阅读。任务范围限于单轮、纯文本、纯前端、来自单一平台的请求,不包含迭代修复、多模态输入与后端集成。数据集与源码不公开,论文给出的理由是防止数据泄漏并遵守业务保密政策。
落到实际选型,这份榜单的可用之处在于区分三类能力:视觉表现、交互稳定、需求完成度。它的不可用之处一样清楚,即分数无法脱离参评模型池解读,无法替代自家需求的验收标准。
作者、代码与资源
论文作者共 12 位,来自腾讯混元团队,其中 Peizhong Gao 与 Zhexin Zhang 的署名单位包含清华大学,Jiawen Tao 的署名单位包含北京大学,通讯作者为 Chenxu Liu。论文提交于 2026 年 9 月 14 日,9 月 17 日更新到 v2,分类为软件工程,交叉方向为人工智能。
资源方面,arXiv 提供摘要页、PDF 与 HTML 全文。本次检索的范围里没有找到官方代码仓库或数据集发布页,这与论文的说明一致。
引用时有处命名需要注意:部分中文资料把这套基准写作 WebCraftBench,arXiv 上 v1 与 v2 的标题为 IWC-Bench。检索论文时用 IWC-Bench 或编号 2609.15387,避免按另一个名字搜不到原文。