EvoGenUI-Bench：评估大语言模型作为多轮生成式UI助手 EvoGenUI-Bench: Evaluating LLMs as Multi-Turn Generative UI Assistants
首个评估LLM多轮维护可执行界面的基准：单轮通过率严重高估五轮全流程可靠性
前置知识
生成式 UI (Generative UI)
让大语言模型直接生成可运行的交互式网页界面（仪表盘、表单、迷你应用）作为对用户的回复模态，而不再只输出文字。模型每轮返回完整的 React 源码，浏览器渲染后用户可直接操作，界面本身就是回答。
本文评估的对象正是这种『界面即回复』的范式，理解它才能明白为什么评估必须在浏览器里执行而不是看代码或截图打分。
LLM-as-a-Judge
用一个模型按预定义评分规则（rubric）对另一个模型的开放输出打分或判定的方法，可扩展地替代人工标注，但需要严格控制评估器可见的证据范围与偏差。
本基准的 Presentation、Execution、Alignment 三个维度都由 MiMo-V2.5 评估器按 1-5 分制裁决，三项均 ≥4 分该轮才算通过，人工盲评验证其准确率 86.7%、Cohen's κ=0.73。
多轮累积修订 (Cumulative Revision)
评估单元不是孤立页面，而是同一个工件在五轮内被连续修改的会话轨迹：每轮必须实现新请求，同时保留所有仍然有效的旧需求，最终形成一个不断演化的可执行应用。
这是本文任务形式化的核心，TP@5、CPT、APR 等全部指标都建立在这个五轮累积结构之上，区别于一次性的前端生成评测。
执行式评估与浏览器自动化
在沙箱中构建并运行生成的界面（Chromium/Playwright），由自动 actor 操作页面，采集截图、DOM、交互轨迹、工具日志与运行时快照作为评分证据，而非依赖静态代码分析或参考渲染。
论文的证据消融显示去掉 actor 交互轨迹后评估精度从 87.5% 跌至 55.0%，行为证据是判定成败的关键，这是理解其评估协议的基础。
工具调用与外部状态接地
模型通过 callTool/readResource 等声明式接口读写后端状态；工具接地场景要求界面显示、局部 UI 状态与权威外部状态三方一致，且只信权威工具，忽略缓存快照、乐观状态等诱饵。
工具接地套件是最难的部分（聚合 APR 仅 52.4%），其独有失败机理『外部状态接地』是本文诊断分类法的重要组成。
派生状态 (Derived State)
UI 中由局部状态推导出的联动视图，例如修改 PID 增益参数 $K_p$ 后，依赖它的超调量、调节时间等仿真指标和汇总卡片应当同步更新；若改了输入而派生视图仍是旧值，即派生状态传播失败。
派生状态传播是交互套件的第一大失败机理（31.8%），也是本文论证『必须执行才能发现故障』的标志性现象。
研究动机
现有评估体系把『构建界面』与『执行任务』割裂开来。前端生成基准（Design2Code、WebGen-Bench、MiniAppBench、Interaction2Code）主要评估视觉保真度或一次性的自包含生成片段，模型要么独立生成页面、要么在预定义环境中操作；而 WebArena、OSWorld、τ-bench、ToolSandbox、AppWorld 等 agent 基准中，界面由环境预先提供，模型只负责选择工具、修改状态。生成式 UI 恰好跨越这条界线：模型要在多轮对话中持续修订同一个可执行界面，每轮新请求要实现、仍然有效的旧需求要保留，界面行为、可见状态与助手回复还要彼此一致。FronTalk 虽触及多轮前端开发并指出遗忘或覆盖旧特性是核心挑战，SlopCodeBench 显示迭代扩展会累积结构性退化，但都不把界面当作持久的交互层系统评估。单轮评估因此掩盖了回归、状态过时、跨轮不一致等只在演化过程中才暴露的故障。
本文的目标是本文要回答的问题是：当用户需求在多轮对话中不断演化时，大语言模型能否可靠地维护一个可执行的界面？为此作者构建了 EvoGenUI-BENCH：150 个人工编写的五轮任务、共 750 个请求轮，均匀分为三个场景套件——信息呈现（解释与决策支持工件）、可交互（有状态迷你应用与推理工作台）、工具接地（读/写/对账/刷新外部状态的界面），每套件 50 任务、150 个互不重复的领域标签。评估上，每个生成的工件都要在固定浏览器环境中构建并执行，用截图、DOM、交互轨迹、源码、运行时日志等多面证据打分；指标上覆盖四个层次：单轮 Turn Pass、整集 TP@5、连续通过轮数 CPT 和相邻轮留存率 APR。作者还给出经人工校验的六类失败机理分类法，系统评估 GPT-5.5、Claude-Opus-4.7 等八个模型，把生成式 UI 评估从『判断孤立输出』推进到『检验行为、派生状态、外部状态与助手声明是否随演化保持同步』。
与已有工作不同的是，本文的独特切入有三点。第一，把生成的界面同时当作助手输出与任务执行的交互层：评估单元是持续演化的可执行工件而非孤立页面，这既不同于评估单次生成的 GenUI 基准，也不同于环境提供界面的 agent 基准。第二，验证的是请求语义而非参考实现：每个轮次绑定一份对生成器隐藏的私有验证契约，每条要求必须锚定到至少一个可观测证据面（渲染 UI、DOM、交互轨迹、源码、助手回复、工具日志或运行时状态），功能等价的实现都能通过，从而既防评估泄漏，又能拒绝静态空壳与无凭据的『已完成』声明。第三，提出 APR 这个转移级留存指标，度量『上一轮通过的前提下本轮仍通过』的条件概率，把可靠性从孤立结果推进到相邻修订之间的保持性；同时用 requested-slot 记账法把构建失败、无效输出也计为失败，下游轮被阻塞而非静默重启，避免遗漏失败。
核心方法
直觉上，可靠的生成式 UI 助手应该像维护一个活的应用：每次改动既要落实新需求，又不能弄坏还在生效的旧功能。技术路线上，每个任务是五轮 episode：第 $t$ 轮模型收到当前用户请求、公共任务上下文、公共工具契约、此前轮次的紧凑上下文（用户请求、助手回复、最终界面文本）以及上一轮生成的完整源码，必须同时返回用户可见回复与更新后的完整 React 源文件。评测框架随后在固定 React/Vite 脚手架中构建源码，用 Chromium/Playwright 渲染，MiMo-V2.5 扮演的自动 actor 操作界面收集行为轨迹；工具接地任务还会恢复确定性 mock 运行时状态。评估器基于最终 DOM 与截图、actor 观察、工具与资源日志、运行时快照、源码摘要等证据，对 Presentation、Execution、Alignment 三个维度按 1-5 分打分，三者均 ≥4 才算该轮通过（$p_{T,t}=1$）。最后在轮级之上计算 TP、TP@5、CPT 与 APR 四级可靠性指标。
核心创新是把生成式 UI 评估形式化为『多轮工件维护』。与 FronTalk 等多轮前端工作相比，本文的界面不只是开发对象，而是任务赖以完成的交互层，评估因此必须同时覆盖新需求的实现、旧需求的保留、界面行为与助手声明的一致性；工具接地套件更进一步，要求可见控件、浏览器交互、局部 UI 状态与权威外部状态四方同步，这是现有任何基准都没有的组合。与 SWE-bench 式执行评估相比，本文验证的是语义而非参考实现：私有验证契约锚定证据面，允许功能等价解，拒绝不能构建、不能执行或证据不足的工件。APR 则是概念上的关键一步：它以条件概率 $\Pr(\text{本轮通过} \mid \text{上轮通过})$ 的形式度量留存，让『回归』第一次成为可量化的失败维度；事后审计进一步把失败转移拆分为『含旧需求回归』与『仅新需求失败』两类，为后续归因铺路。
方法步骤详情
流程分六步。第一步任务构造：作者撰写五轮累积轨迹，为每轮指定私有验证要求并绑定证据面，再由另一名审核者检查歧义、泄漏、跨轮修订压力与需求可观测性；工具接地任务每任务含 6-22 个工具，权威读写工具之外还布置诱饵与非权威助手。第二步生成：8 个模型温度 0、输出上限 32,768 token，统一输出 assistant_text 加完整源文件，无效格式或构建失败均计为该轮失败。第三步执行与证据收集：harness 在固定 React/Vite 环境构建源码，Chromium/Playwright 渲染，MiMo-V2.5 actor 沿主路径操作并记录交互状态；执行是顺序的，后续轮复用先前源码与快照，必需工件缺失时下游轮被阻塞而非重开——6,000 个请求槽位中实际执行 5,310 个（88.5%），443 个因先前构建失败、247 个因无效输出被阻塞，均按失败计。第四步评分：MiMo-V2.5 评估器输出含 score、summary、failure_types 的 JSON，明确『源码不是运行时证明』。第五步指标：$\mathrm{TP@5}(T)=\prod_{t=1}^{N} p_{T,t}$，CPT 为初始连续通过段长度，$$\mathrm{APR}(S)=\frac{\sum_{T\in S}\sum_{t=2}^{N} e_{T,t}\, p_{T,t-1}\, p_{T,t}}{\sum_{T\in S}\sum_{t=2}^{N} e_{T,t}\, p_{T,t-1}}$$ 其中 $e_{T,t}$ 指示第 $t$ 轮生成调用是否返回响应。第六步诊断：冻结六类机理代码本后，对全部 2,750 个非通过调用标注主失败机理。
技术新颖性
技术新颖性体现在四点。其一，APR 是新的转移级指标：与宏观平均的 TP/TP@5 不同，它汇集全部合格相邻转移，度量通过状态的保持概率，并配以独立性基线 $\widehat{\mathrm{TP@5}}=\prod_{t=1}^{5} \hat{p}_t$ 对照——八个模型的实测 TP@5 全部显著超过该基线（如 Claude-Opus-4.7 37.3% 对 23.4%），为『任务难度异质、通过轮聚集』提供了统计证据。其二，多面证据束设计：消融显示去掉 actor 交互轨迹评估精度从 87.5% 跌到 55.0%，去掉私有参考掉到 63.8%、去掉源码 67.5%、去掉截图 78.3%，证明单一视角不足以判定执行式工件。其三，requested-slot 记账与『阻塞而非重启』的顺序执行语义，忠实模拟真实会话中前一步坏了后面无法继续的情形。其四，经人工校验的诊断分类法：诊断判官与三名盲评标注者的精确一致率 90.3%、多类 Cohen's κ=0.89，人类间 Fleiss' κ=0.91，使机理级结论可信。
实验结果
四大发现。发现一：单轮成功严重高估整集可靠性——最强的 Claude-Opus-4.7 总体 TP 74.9%、APR 83.6%，但五轮全对的 TP@5 仅 37.3%、CPT 2.81；八模型聚合 TP 42.7% 而 TP@5 仅 11.8%。发现二：工具接地任务在条件化于上一轮通过后依然最难——TP 从呈现 55.5%、交互 47.6% 跌到 25.0%，TP@5 仅 5.0%，APR 52.4%（呈现 71.1%、交互 68.7%），与其最密的验证契约（每轮 11.9 条，对比 3.0 与 5.9）一致。发现三：第二轮之后可靠性骤降——聚合通过率在第 3、4 轮降至 39.4% 与 35.1%，工具接地更从第 2 轮 39.5% 跌到第 3 轮 18.5%、第 4 轮 14.0%。发现四：失败机理随场景系统变化——呈现失败 84.5% 集中在信息架构；交互失败以派生状态传播（31.8%）与可供性绑定（19.9%）为主；工具接地叠加外部状态接地（23.2%）与需求分解（18.5%）；110 个可归因的失败 APR 转移中 52.7% 含旧需求回归、47.3% 仅新需求失败。模型画像迥异：GPT-5.5 交互 TP 77.6% 但呈现仅 44.8%；Gemini-3.1-Pro 总体 TP 仅 23.6% 但通过后 APR 高达 70.3%-79.6%。三个案例（SVG 图表合并 x 轴标签、改 $K_p$ 后指标冻结在 100.0% 超调与 10.00 s 调节时间、后端 token 失配致 hold_slot 全部失败）说明不同失败需不同证据面才能暴露。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 总体五轮全流程完成 (Overall) | TP@5 (%) | Claude-Opus-4.7: 37.3 | 八模型聚合: 11.8 | +25.5 个百分点 |
| 总体单轮通过率 (Overall) | TP (%) | Claude-Opus-4.7: 74.9 | 八模型聚合: 42.7 | +32.2 个百分点 |
| 信息呈现套件单轮通过 | TP (%) | Claude-Opus-4.7: 82.4 | 聚合 55.5；次优 Claude-4.5-Haiku 76.0 | 较次优 +6.4 pp，较聚合 +26.9 pp |
| 交互套件五轮全对 | TP@5 (%) | Claude-Opus-4.7 与 GPT-5.5 均为 40.0 | 八模型聚合: 14.8 | +25.2 个百分点 |
| 工具接地套件五轮全对 | TP@5 (%) | GPT-5.5 与 Claude-Opus-4.7 均为 20.0 | 八模型聚合: 5.0 | +15.0 个百分点 |
| 工具接地跨轮留存 | APR (%) | Claude-Opus-4.7: 68.6 | 八模型聚合: 52.4 | +16.2 个百分点 |
| TP@5 实测 vs 独立性基线（通过轮聚集效应） | TP@5 (%) | Claude-Opus-4.7: 37.3 vs 基线 23.4；GPT-5.5: 21.3 vs 8.7 | 独立性基线 $\prod_{t=1}^{5} \hat{p}_t$（各轮独立假设） | 全部 8 个模型实测显著高于独立性基线 |
局限与改进
作者承认的局限：任务为人工编写的固定五轮 episode，跑在固定的 React/Vite 环境，未覆盖自然产生的交互日志、其他 UI 框架、无障碍要求与设备条件；APR 是结果级留存而非因果归因——一次失败转移可能源于旧需求回归、新需求失败或两者，事后审计只在 110 个转移的样本上区分，完整归因需要对每个后续工件重放所有先前轮的验证契约；工具接地套件用确定性 mock 运行时保证可复现，因此不覆盖真实服务的延迟、认证、限流、宕机与 API 变更等运维挑战；整体是受控诊断基准，不能证明部署安全。我自己的观察：主结果每个槽位只生成一次，而再生实验显示 Qwen3.6-Plus 的 TP 波动在 39.7%-46.4%（±3.4 个百分点），单次运行的模型排名可能有噪声；评估器与 actor 都是 LLM，虽经 86.1%-91.4% 人工一致性校验，仍可能对某些失败模式系统性盲视；150 个任务下置信区间较宽（如 Claude-Opus-4.7 TP@5 的 95% CI 为 [30.0%, 45.3%]），细分到模型×套件层面的结论应谨慎解读。
独立分析的弱点
独立分析的弱点与改进方向：(1) 规模与统计功效——150 任务在模型×套件的细粒度对比上置信区间偏宽，可扩充到 500+ 任务并采用分层抽样或配对检验设计；(2) 单次生成方差——±3.4 个百分点的再生波动意味着应至少跑 3 次取聚合，基准可提供官方多次运行协议与方差报告规范；(3) APR 归因粗粒度——52.7%/47.3% 的二分法来自 110 个转移的小样本审计，可内置『逐契约重放』机制，对每个失败转移自动定位被破坏的具体需求条目，把 APR 升级为可归因指标；(4) mock 环境确定性——诱饵工具与固定初始状态使模型可能学到模式化应对，可引入随机化 fixture 与受控噪声提高外推效度；(5) LLM judge 的成本与偏差——证据消融只测试了一种评估器，可公开多评估器集成评分与人工校准的持续回归测试，降低对单一模型的依赖；(6) 五轮上限——真实需求演化常超过二十轮，结构性退化可能在更深处才显现，应增加长 episode 分层并追踪退化曲线。
未来方向
作者指出的方向：完整归因需要把所有先前轮验证契约对每个后续工件重放，把 APR 从结果级指标升级为因果级指标；工具接地套件可扩展到真实服务的运维挑战（延迟、认证与权限失败、限流、API 变更）。基于本文成果可自然延伸的方向：把 APR 与六类失败机理用作奖励或过程信号训练界面维护策略，例如对『旧需求回归』施加显式惩罚的强化学习；研究架构层面的界面-状态同步机制，如让派生视图从单一状态源自动推导、工具写入后强制回读校验；将 episode 长度、框架多样性（Vue/Svelte）、无障碍要求纳入下一版基准；把浏览器 actor 轨迹与运行时日志作为多模态反馈融入生成循环（与 FronTalk 的视觉反馈互补）；以及利用通过轮聚集现象做难度自适应的任务采样与更高效的模型比较。
复现评估
复现条件相当好。代码、任务数据、mock fixtures 与完整流水线以 MIT 许可发布在 GitHub（MAPS-research/EvoGenUI-Bench，v1.0），并严格区分 generator-visible 与 evaluator-only 材料供审计；附带本地 Web 可视化界面。无训练成本，算力需求主要是 API 调用：每个模型跑满 150 任务×5 轮共 6,000 个请求槽位，生成温度 0、输出上限 32,768 token，actor/评估器用 MiMo-V2.5（上限 4,096/8,192 token）；浏览器执行用本地 Chromium/Playwright。论文提供了完整的推理配置表、任务级 bootstrap 95% 置信区间、7 种 actor-evaluator 配置的敏感性分析（人工一致率 86.1%-91.4%）、证据消融与三次再生稳定性实验，并要求注明基准版本、代码 commit、任务清单与 prompt 版本。难度评级中低：工程上需搭好浏览器沙箱并正确实现顺序执行与状态恢复语义，学术上无训练门槛，主要成本是八家商业模型的 API 费用。
论文图表
以周末行程规划为例展示五轮对话：第 1 轮生成按天分组的行程卡片视图，第 2 轮追加预算与天气区块，后续轮在保留行程与地图的前提下简化布局、增加暗色模式等，每轮更新都不得破坏先前功能。
一图定义了全文的任务范式——界面是持续演化的单一可执行工件而非独立页面，是理解 EvoGENUI 设定的入口。