🤖 AI

HTMLCure: Turning Browser Experience into State Guided Repair for Interactive HTML

HTMLCure 引入了一种状态引导的浏览器体验框架，该框架通过确定性交互轨迹评估并修复交互式 HTML，从而将种子语料库显著扩展为高质量数据集，使 27B 模型在交互式网络基准测试中取得与 Kimi-K2.6 和 GPT-5.4 等领先系统相当的性能。

原作者： Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

发布于 2026-05-27

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

以下是 HTMLCURE 论文的解析，将其拆解为简单概念并辅以日常类比。

核心难题：“看着不错，实则已坏”

想象你请一位极具天赋的艺术家（人工智能）制作一辆玩具车。艺术家递给你一个精美的模型。它在照片中看起来完美无缺。但当你试图推动它时，轮子却掉了；当你试图转动方向盘时，方向盘却空转无用。

这就是当前 AI 生成网页（HTML）面临的问题。它们往往在单张快照（截图）中看起来很棒，但当真人尝试点击按钮、向下滚动、调整窗口大小或玩游戏时，页面就会崩溃。

旧方法： 研究人员过去只是拍摄页面的照片，检查它是否美观，以此判断它是否“好”。这种方法忽略了所有像“掉落的轮子”那样的问题。
结果： 他们丢弃了成千上万本可修复的页面，或者保留了一些看起来不错但无法运行的页面。

解决方案：HTMLCURE（“试驾”技师）

作者构建了一个名为 HTMLCURE 的系统。它不再仅仅查看照片，而是像一位技师那样，将汽车进行试驾。

以下是其工作原理，分步说明：

1. 试驾（浏览器体验）

HTMLCURE 不只是拍张照片，而是将网页加载到真实的浏览器中。它不会只是静止不动，而是主动与之交互：

它上下滚动。
它调整窗口大小（就像检查汽车是否能停进小车库）。
它点击按钮、悬停在链接上，并尝试玩游戏。
它精确记录发生的情况：“按钮没反应”、“游戏卡死”或“移动端布局崩坏”。

类比： 这就像给汽车进行 驾驶测试。你不仅仅看车漆，还要开起来看看引擎能否启动、刹车是否有效、变速箱换挡是否顺畅。

2. 诊断（状态信号）

试驾结束后，系统会给页面一个“健康评分”和诊断结果。它将页面分为三类，就像医生对病人进行分诊：

低分（报废车）： 页面一团糟。缺失了大块的结构性内容。
- 修复方案： 彻底重写。 不要试图修补它；从零开始建造一辆新车。
中等分数（旧破车）： 页面大部分能运行，但有特定的损坏部分（例如收音机不工作，或门把手卡住）。
- 修复方案： 针对性修复。 诊断出具体损坏的部分，仅修复该部分。
高分（跑车）： 页面已经非常出色。
- 修复方案： 仅做抛光。 不要触碰引擎；也许只需打蜡。如果你试图“修复”那些并未损坏的东西，反而可能会弄坏它。

关键洞察： 论文指出，对所有页面使用相同的修复方法是一个错误。你需要根据页面实际损坏的程度采取不同的策略。

3. 修复循环（反馈周期）

一旦系统确定了策略（重写、修补或抛光），它就会要求 AI 修复页面。

关键步骤： 系统不会仅仅相信 AI 的话。它会获取页面的 新版本 并再次运行试驾。
守门人： 如果新版本更好，就保留它；如果新版本更差（即“回归”），则将其丢弃并重试。
目标： 持续进行此过程，直到页面通过高质量标准（达到 97/100 的分数）。

类比： 想象一位厨师在品尝汤。如果太咸，他们就加水。然后他们再次品尝。他们不会假设加水就解决了问题，而是进行验证。如果他们加了太多水导致汤现在太淡，他们就停下来尝试不同的食谱。

成果：构建更优质的库

作者将这套系统应用于一个包含 97,000 个 AI 生成页面的庞大集合。

他们从一个小的“完美”页面堆开始。
他们使用 HTMLCURE 修复了那些“损坏”的页面。
最终，他们获得了 63,000 个经过验证的高质量页面（相比最初的小集合有了显著增长）。

随后，他们利用这个新的、经过清理的库来训练一个新的 AI 模型（称为 HTMLCure-27B）。

结果：

新模型在制作可运行网页方面显著更出色。
在名为 HTMLBENCH 的严格测试中，它得分 50.6，与顶级商业模型（如 Kimi-K2.6 和 GPT-5.4）相当。
在另一项测试（MiniAppBench）中，与未训练版本相比，其得分提高了 15 分。

一句话总结

HTMLCURE 是一个系统，它阻止 AI 仅仅“猜测”网页是否可用；相反，它强制 AI 试驾每一个页面，诊断确切的问题所在，利用正确的策略修复它，并 重新测试 以确保修复确实有效，从而构建出一个包含大量高质量、可运行代码的庞大库。

技术摘要：HTMLCure

问题陈述

大型语言模型（LLM）已展现出生成完整 HTML 页面的能力，但这些输出往往存在“表面正确性”问题。虽然生成的页面在单一静态截图中可能渲染正确，但在滚动、悬停、点击、调整大小或游戏交互等动态条件下却经常失效。依赖静态截图或稀疏视觉轨迹的传统评估方法忽略了这些特定于交互的故障。此外，标准的数据过滤方法将许多此类页面视为不可用而丢弃，未能认识到它们通常是可修复的。核心挑战在于，交互式 HTML 的数据构建是一个状态估计问题，而不仅仅是评分问题；静态观察无法揭示仅在特定用户交互后才显现的故障。

方法论

本文介绍了HTMLCURE，这是一个浏览器体验框架，旨在通过由浏览器执行轨迹驱动的闭环过程，对交互式 HTML 进行评估、诊断和修复。

1. 多维体验评估流水线

HTMLCURE 不依赖静态截图，而是通过执行一系列查看和交互动作（ $\pi$ ）来评估 HTML 工件（ $h$ ）。

四层体验协议：
- L1（视觉观察）： 检查加载行为和初始渲染。
- L2（主动交互）： 测试控件、悬停状态、键盘绑定和滚动行为。
- L3（深度游戏）： 针对游戏或复杂 UI 运行任务驱动的 rollout，以验证状态转换、计数器和画布变化。
- L4（响应式）： 从执行轨迹中选取带有事件上下文的关键帧。
结构化证据： 评估器生成有序轨迹 $E(h, \pi)$ ，包含视觉证据（ $v_t$ ，例如渲染帧）和行为证据（ $b_t$ ，例如 DOM 状态、控制台错误、探针结果）。
五维评分： 分数 $S(h)$ 源自五个维度：渲染、视觉设计、功能、交互性和代码质量。关键在于，视觉设计是唯一由视觉语言模型（VLM）基于精选关键帧进行判断的组件；所有其他维度均依赖确定性的浏览器执行和静态分析。

2. 状态感知交互式修复引擎

修复过程并非通用的重新生成，而是基于页面当前状态的受控干预。

状态路由： 系统根据分数 $s$ $s$ 将页面分类为三种状态：
- 低（< 40）： 无稳定局部目标的页面。策略：整体重写。
- 中（40–79）： 结构可用但行为受损的页面。策略：诊断引导的局部修复（例如修复特定的交互错误）。
- 高（≥ 80）： 优质页面。策略：保留或针对性优化以避免回归。
闭环执行： 控制器选择一个修复族，提示 LLM 生成候选项，并在浏览器中重新执行每个候选项。
回归感知接受： 候选项使用复合分数 $S_{comp}$ 进行选择，该分数会对功能和交互性的回归进行惩罚，确保视觉设计的改进不会以逻辑损坏为代价。
终止： 当页面达到高目标分数（≥ 97）、收益 plateau 或轮次预算耗尽时，循环停止。

3. 数据构建

HTMLCURE 将修复视为一种数据构建机制。来自初始 97K 提示语料库的已接受修复被导出到精炼的监督微调（SFT）池中。此过程将可用数据集从一小部分“高”页面扩展到包含 63,703 个经过质量清理页面的更大池，并从中构建了最终的 40K 训练集。

主要贡献

浏览器体验作为修复状态信号： 本文证明，将浏览器执行轨迹转换为结构化页面状态，可以精确界定 VLM 的视觉判断范围，并驱动具体的修复决策。
状态感知交互式修复： 该框架引入了一种策略，即根据观察到的页面状态动态选择修复策略（重写 vs. 诊断 vs. 保留）。这防止了高质量页面中可用组件的破坏，并确保了对低质量页面的结构重建。
修复即数据构建： 通过重新执行来验证修复，系统创建了一个高质量、已验证的 SFT 语料库。这种方法将“过滤”范式（丢弃坏页面）转变为“恢复”范式（修复并验证页面）。

结果

作者使用HTMLBENCH-400（一个确定性浏览器可执行基准）和MiniAppBench验证分割评估了该方法。

性能： 在相同的骨干网络（Qwen3.5）和训练配方下，HTMLCure-27B-Refined 模型实现了：
- HTMLBENCH-400 总分：50.6。
- 确定性测试用例通过率：45.2%。
- MiniAppBench 验证分割平均分：81.2。
对比： 这些结果使该模型与 Kimi-K2.6 和 GPT-5.4 等强参考系统处于相同的性能区间。
消融实验： 在数据量相等（12,392 个示例）的控制实验中证实，“精炼”路线（使用经过修复和验证的数据）优于“原始”路线（原始生成）和“过滤”路线（仅原始高质量页面），证明源自浏览器体验的监督质量是改进的主要驱动力，而不仅仅是数据量。

意义与主张

本文主张 HTMLCURE 将交互式 HTML 生成的范式从“生成并过滤”转变为“体验、修复并验证”。

执行即控制： 核心主张是，浏览器执行不应仅用作最终的通过/失败判断，而应作为连续的控制信号，区分缺失的结构与损坏的交互。
数据质量： 该工作证明，在特定状态控制下修复弱页面和部分页面，比单纯选择预先存在的高质量页面能为 SFT 提供更强的监督。
可复现性： 作者提供了一个带有确定性测试用例的冻结基准（HTMLBENCH）以及用于可复现比较的完整流水线，超越了缺乏标准化故障记录的基于智能体的评估。

本文对其局限性保持谦逊，承认 VLM 仍用于限定范围的视觉设计评分，浏览器探针无法覆盖所有可能的交互，且复杂游戏可能会暴露耦合的时序故障。它建议未来的工作可以直接从修复轨迹中学习路由和停止策略。