一个网站看起来完整，不代表按钮真的能点、表单真的会提交。8月10日进入arXiv最新批次的WebGrader研究，把网站生成模型的训练重点从“像不像成品”移到“交互是否真实发生”：它先把需求拆成浏览器可执行流程，再依据页面状态变化发放强化学习奖励。由此训练的8B模型在WebGen-Bench取得52.01%的功能成功率，比同配置脚本奖励方案高7.88个百分点。

先让网站跑起来，再决定模型该不该得分

网站生成的难点在于，正确性通常藏在交互之后。旅游预订页可能外观精致，却在选择日期、搜索航班或刷新页面后失去状态。手写Playwright脚本能够验证功能，但开放式需求变化太多，维护成本高；用视觉模型或GUI智能体评分更容易扩展，却可能在关键状态出现前就给出结论。

北京理工大学、北京交通大学和中国人民大学团队因此提出“可执行奖励构造”。WebGrader先从需求中推导必须发生的交互流程，再结合生成项目的源码和实时DOM定位控件，执行浏览器操作，并沿同一轨迹记录页面画面、DOM、响应、存储与刷新后的状态。缺少控件、无法触发动作或违反后置条件都会直接判为失败；基础设施异常和证据不足则单列为不确定，而不是硬算成功。

评分器也会复盘错误，但训练前必须冻结

这套方法的第二层设计是让评分器先自我改进。研究者构建WebGen-Verifier-100，用100个公开网站需求配对已验证的React/Vite应用，再注入缺控件、错误动作落点、状态未保存等故障，共得到100个干净应用和778个有效故障变体。数据按页面划分为训练、验证、测试集，避免同一页面的变体跨集合泄漏。

评分器连续三轮收集误判轨迹，把重复问题整理为可复用技能，例如补齐执行前置条件、按实时DOM定位目标、把观察证据绑定到正确步骤。新技能只有在独立验证页上提高故障召回、干净页特异性，并且不引入回归时才会进入SkillGraph。之后整个评分图冻结，再用于GRPO训练，避免奖励规则在策略学习过程中同步漂移。

最终结构在验证测试中达到0.9248的F1、0.92的召回率和0.92的特异性，不确定结果降至4%。正式训练阶段共形成12124个流程判定，仍有3.09%因评分端证据不足被标记为不确定。这些数字说明自动评分并非完全可靠，但它至少把“看起来合理”推进到“执行轨迹可复查”。

52.01%来自什么对照，边界又在哪里

WebGen-Bench公开测试集包含101个网站需求和647个手工整理的功能案例。以同一Qwen3-8B初始模型、数据与训练预算比较，基础模型功能成功率为14.92%，监督微调后为33.62%，GUI奖励训练为41.96%，视觉加基础脚本奖励为44.13%，WebGrader-RL提升到52.01%。与此同时，外观分数只从3.46微升到3.48，表明主要收益确实来自功能，而不是页面变得更漂亮。

横向比较中，WebGrader训练的8B模型超过o4-mini的40.65%和DeepSeek-v4-flash的47.91%，接近GPT-5.4-mini的52.32%，但仍低于Qwen3-Coder-480B的53.25%和Claude Opus 4.8的68.20%。在另一套WG-core-250任务上，它以44.953的综合分超过Qwen3-Coder-480B的42.504。论文把不同协议分开报告，没有把单一榜单扩大成普遍胜负。

真正值得关注的是奖励工程，而不是又一次小模型逆袭

局限同样清楚：论文目前是预印本，训练集中于React/Vite与HTMLBench类任务，测试网站不等于复杂生产系统；流程规划和语义判断仍依赖模型，长轨迹、数据绑定与跨页面依赖仍是主要失败点。研究也只验证了一个8B策略，尚不能证明方法会对更大模型、移动端应用或企业遗留系统保持相同增益。

ATYUN认为，WebGrader最有价值的变化不是“8B击败某个闭源模型”，而是把网站生成的奖励从静态截图转向可重放的行为证据。对AI编程工具而言，下一轮竞争可能不只在模型会写多少代码，还在训练系统能否自动构造可信测试、隔离评分漂移，并把失败变成可复用的验证能力。只有当页面真的完成用户要求的状态转移，“能生成网站”才开始接近“能交付软件”。