WebGen-R1：用强化学习激励大语言模型生成兼具功能性与美观性的网站 WebGen-R1: Incentivizing Large Language Models to Generate Functional and Aesthetic Websites with Reinforcement Learning
用强化学习让 7B 小模型端到端生成可部署的多页网站，匹敌 671B 模型。
前置知识
强化学习与 GRPO
GRPO 是无需 critic 的策略梯度方法。它对同一 prompt 采样 $G$ 个输出，用组内奖励的均值与标准差归一化得到相对优势 $\hat{A}=\frac{R-\text{mean}}{\text{std}}$，再以 PPO 风格 clip 目标优化策略。
WebGen-R1 核心训练算法就是 GRPO。网站生成奖励稀疏、方差极大，PPO 的 critic 难以稳定学习，必须靠组内相对比较给出可用学习信号。
级联多模态奖励 (Cascaded Multimodal Reward)
分层奖励设计：先对结构/构建失败给硬约束（失败置 0），通过后才算稠密奖励 $R_{\text{dense}} = s_{\text{vis}} + \gamma s_{\text{func}} + \lambda s_{\text{cot}}$。
把主观审美与客观功能合并到同一目标，让昂贵视觉评估只用在能渲染的样本上，避免算力浪费。
脚手架驱动结构化生成 (Scaffold-driven Structured Generation)
不从头生成项目，而是先固定预验证的 React 模板骨架，让 LLM 只在插槽中填入可变组件 $\Delta = W \setminus T$。形式化 $W_{\text{gen}} = T \oplus \pi_\theta(\Delta \mid S, x, T)$。
让 7B 模型也能写可构建项目的关键工程思路。直接生成完整仓库易在 import、依赖、构建脚本上出错，骨架保证「至少能跑起来」的下限。
Vision-Language Model 作为人类偏好代理 (VLM-as-Judge)
用 VLM（如 GPT-4o）对渲染截图按 0-5 分打分，评估布局、配色、字体层级、可观察的交互元素。论文验证其与 3 位工程师人类评分 Pearson $r=0.762$、Spearman $\rho=0.734$。
没有 VLM 评分就没法把「美观」这种主观目标变成可优化标量；人评成本太高，VLM 是 RL 奖励的「廉价近似人评」路径。
研究动机
现有 LLM 网站生成方法存在两类典型缺陷。第一类只生成单页静态网站，抽象掉了现代 Web 应用的动态路由、状态管理、鉴权和跨页导航等真实复杂度。第二类采用多智能体编排框架（让不同子代理负责 UI、后端、测试再集成），依赖多轮执行和专有模型，虽然能完成复杂任务，但 token 成本高、延迟大，且智能体间契约、文件名、接口定义的微小不一致会级联成不可构建的产物。更关键的是，这两类方法都没能同时优化功能性与美观性——要么只能跑但视觉割裂，要么好看但交互失效。以 Qwen2.5-Coder-7B-Instruct 为基线，在 WebGen-Bench 上功能成功率（FSR）仅 1.59%、有效渲染比（VRR）仅 30.56%，就是一个很直接的证据。
本文的目标是论文的具体目标是训练一个 7B 级别的开源小模型，使其在端到端一次性生成多页 React 网站时，同时满足三项硬指标：(1) 功能成功率（FSR）大幅提升并能比肩 671B 的 DeepSeek-R1；(2) 审美对齐分（AAS）超越或匹敌所有闭源大模型；(3) 有效渲染比（VRR）接近 100%，使生成的网站真正可部署。作者不要求多智能体协作，不依赖多轮 GUI 探索，只用一次前向生成 + 自动构建/渲染 + 分层奖励的方式，把端到端项目级代码生成做出来。
与已有工作不同的是，论文的独特切入角度是「把奖励设计成级联式的」：先用脚手架 + 静态校验保证结构，再用确定性构建管道（安装→打包→启动→截图）拿到运行时证据，最后才用 VLM 打审美分。这与现有方法有三点本质区别——(a) 与单页静态生成相比，它坚持多页动态项目；(b) 与多智能体框架相比，它坚持端到端单模型一次出稿；(c) 与已有的 RL 代码工作（DeepSeek-R1 等主要优化单元测试通过率）相比，它把「看得见的美观」和「控制台无错」作为同等重要的一阶目标，并创新性地把这两类异质信号放在同一个级联公式里优化。
核心方法
WebGen-R1 的整体思路可以概括为「约束动作空间 + 级联过滤 + 三模态奖励 + GRPO 优化」。直觉上，模型不需要从零搭建一个 React 项目，而只需要在一个固定好的「项目模板」中填充「可变组件」（页面、命令、样式等），这就把一个原本极其脆弱的开放式生成问题转成相对稳定的「填空题」。然后用一个两阶段的过滤管道把关：先做静态合规校验（文件结构、package.json 字段、组件导出模式），再走真实的安装-打包-启动-截图流程，对能渲染的样本才动用昂贵的 VLM 审美评估。最后把审美分、功能完整性分、CoT 格式分加权和作为稠密奖励，配合 GRPO 的组内相对优势稳定地训练小模型。技术上，这是一个把「模板约束的概率生成」「确定性执行环境」和「视觉语言模型」三者拼成一条 RL 流水线的工程方案。
核心创新点是把「奖励稀疏且异质」的问题拆成「硬过滤 + 稠密加权」。已有 RL 代码工作要么只奖励「单元测试是否通过」，要么只奖励「人评投票」，前者忽略视觉、后者没有可执行反馈。WebGen-R1 把生成过程建模为 $W_{\text{gen}} = T \oplus \pi_\theta(\Delta \mid S, x, T)$，把执行环境 $E_{\text{env}} = R_{\text{render}} \circ L_{\text{serve}} \circ B_{\text{bundler}} \circ I_{\text{install}}$ 当作 reward oracle，让 $\pi_\theta$ 在 GRPO 下用 $R = s_{\text{vis}} + \gamma s_{\text{func}} + \lambda s_{\text{cot}}$ 学习。脚手架把 VRR 从 30.56% 抬到 95.89%，级联结构让 VLM 不被浪费。
方法步骤详情
方法分四步。第一步 SFT 热启动：从 WebGen-Instruct 抽 600 任务，用 GPT-4.1 蒸馏 silver 响应，微调 Qwen2.5-Coder-7B-Instruct 2 epoch（学习率 $10^{-5}$、batch 32）。第二步 RL：GRPO 做 400 步，$G=16$、batch 256、$\epsilon=0.2$、$\beta=0.01$、学习率 $5\times 10^{-6}$、温度 0.7。第三步对每个采样跑级联评估：先判静态合规（不通过给 $\psi_{\text{static}}=0$），通过则走 install→bundle→serve→render 拿截图与日志，构建失败给 $\psi_{\text{build}}=0$，成功才算 $R_{\text{dense}}=s_{\text{vis}}+\gamma s_{\text{func}}+\lambda s_{\text{cot}}$（$\gamma=\lambda=0.1$）。第四步用 GRPO 目标 $J(\theta)$ 更新策略。
技术新颖性
技术新颖性体现在四个层面。模板层面，把生成空间 $\Delta = W \setminus T$ 的设计明确形式化，比「全项目自由生成」显著降低了对小模型的负担。验证层面，提出「静态合规 + 自动构建渲染」两阶段管道，把低层错误在视觉评估前就剔除，避免把算力浪费在空 HTML 上。奖励层面，级联公式 $R_{\text{dense}} = s_{\text{vis}} + \gamma s_{\text{func}} + \lambda s_{\text{cot}}$ 是第一个把「截图审美、控制台无错、CoT 格式」三类异质信号放在同一目标里的设计，并通过人类评分验证了与人类偏好的高相关（$r=0.762$）。训练层面，是首个把 GRPO 应用到端到端多页 Web 项目生成的工程实现，并通过消融证明 SFT+RL 组合比单用 SFT 或单用 RL 都强得多（AAS 分别高 21.60% 和 28.76%）。整体上，这是一个「约束 + 过滤 + 多模态奖励」三件套，与已有 RL 代码工作形成清晰区隔。
实验结果
表 1 的 WebGen-Bench：WebGen-R1-7B 取得 FSR 29.21%（基线 1.59%，+27.62 pp）、AAS 3.94（+44.32%）、VRR 95.89%（+65.33 pp），AAS 与 VRR 居 15 个基线之首，FSR 仅低于 671B 的 DeepSeek-R1（30.25%）和 7 个更大模型。表 2 在 Content Presentation（35.29%）、Design Validation Testing（54.92%）等子任务上与 DeepSeek-R1、Gemini-2.5-Pro 相当。图 4/表 3 消融表明 SFT+RL 强于纯 SFT/RL。图 5/表 4 显示 GRPO 组大小从 2 增到 32 时 FSR 从 22.39% 涨到 34.79%。图 6 在 WebDev Arena OOD 评测上仍以 AAS 击败 Qwen3-32B、DeepSeek-R1、GPT-5 等。图 7 表明奖励与人类评分强相关（Pearson 0.762）。图 8 网格搜索表明 $\gamma=\lambda=0.1$ 是帕累托最优。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| WebGen-Bench 综合（101 任务） | FSR (%) | 29.21 | Qwen2.5-Coder-7B-Instruct 1.59 / DeepSeek-R1 30.25 | 相对基线 +27.62 个百分点；与 671B 的 DeepSeek-R1 仅差 1.04 |
| WebGen-Bench 综合 | AAS (0-5) | 3.94 | Qwen2.5-Coder-7B-Instruct 2.73 / Claude-3.7-Sonnet 3.90 | 相对基线 +44.32%；在 15 个模型中最高 |
| WebGen-Bench 综合 | VRR (%) | 95.89 | Qwen2.5-Coder-7B-Instruct 30.56 / DeepSeek-R1 42.86 | 相对基线 +65.33 个百分点；在 15 个模型中最高 |
| WebGen-Bench：Content Presentation 类别 | FSR (%) | 35.29 | Qwen2.5-Coder-7B-Instruct 0.00 / DeepSeek-R1 31.11 | 相对基线 +35.29 个百分点，超过 DeepSeek-R1 与 Gemini-2.5-Pro |
| WebGen-Bench：Design Validation Testing 类别 | FSR (%) | 54.92 | Qwen2.5-Coder-7B-Instruct 0.00 / DeepSeek-R1 33.33 | 相对基线 +54.92 个百分点；逼近 Claude-3.7-Sonnet 的 62.86 |
| WebDev Arena OOD（119 任务） | AAS | 约 3.4（图 6 最高点） | Qwen3-32B / Qwen2.5-72B / DeepSeek-R1 / GPT-5 / Claude-Sonnet-4 | 在更弱指令细节的分布外场景仍保持 AAS 优势 |
| GRPO 组大小消融（G=2 → 32） | FSR (%) | 22.39 → 34.79 | G=2 (22.39) | +12.40 个百分点，验证组内多样性收益 |
| 奖励 vs 人类评分（101 网站） | Pearson / Spearman | r=0.762, ρ=0.734 | 随机评估基线 | p<2.4e-18，奖励与人类偏好强相关 |
局限与改进
作者在文中承认了两点局限。一是 WebDev-Arena 任务描述比 WebGen-Bench 短得多，WebGen-R1 偶尔跟不上更新的设计潮流，作者表示将通过换用更新的基座模型来缓解。二是奖励函数是「控制台 0 错」这种粗粒度的功能代理，可能漏掉更细粒度的 UX 问题（如按钮位置、响应式布局细节）。我自己观察的额外限制有：(1) 评测管线强依赖 GPT-4o 作为 VLM 和 GUI 代理，引入闭源模型依赖并产生不可忽略的 API 成本；(2) 脚手架目前只覆盖 React + Vite + Tailwind 栈，对 Vue/Svelte/纯后端等服务端渲染或非 React 生态未验证；(3) SFT 阶段只用 600 个 GPT-4.1 蒸馏样本，覆盖面有限，可能有 SFT 阶段就锁定的某种风格偏差；(4) AAS 评分与人类评分的 Pearson 0.762 虽强但仍有 24% 解释方差未被捕获，说明审美评估在配色、留白、动效等更细的视觉维度上仍有提升空间。
独立分析的弱点
独立分析有四个值得改进的弱点。第一，奖励信号对 $s_{\text{vis}}$ 的依赖过高，而 VLM 评估存在位置/顺序偏差、倾向于「看起来完整」的页面而忽略真实交互链路；可考虑引入「截图-代码双向一致性」对比模块，让代码与视觉相互验证。第二，SFT 热启动的 600 样本从 GPT-4.1 蒸馏而来，相当于把 GPT-4.1 的项目结构偏好「蒸馏」进了 7B 模型，可能限制了对新设计风格的探索；可改为用更大规模、更多源的 silver 响应或自举式 self-play 数据。第三，级联管道对单一执行环境（npm + Vite）依赖强，对 monorepo、SSR、TypeScript 严格模式等场景没有覆盖；可参数化执行环境并支持多模板切换。第四，论文的 FSR 通过 WebVoyager 代理交互式验证，代理本身的可靠性构成「奖励噪声」上界，可考虑用多代理投票或基于 DOM diff 的确定性检查替换 GPT-4o 驱动的 GUI 代理。
未来方向
作者已明确提出两个方向：换用更新的基座模型以跟上 WebDev-Arena 的设计潮流、把 RL 拓展到全栈应用开发（不只前端）。基于论文成果还可在三条线上延伸：一是把「模板-填充」范式推广到移动端（React Native、Flutter）、游戏（Unity + Lua）、数据管线（Airflow）等更多项目级代码生成场景，验证脚手架思路的普适性；二是把 $s_{\text{func}}$ 从「控制台无错」升级为「测试用例通过率 + 用户行为模型模拟」，让功能评估更细粒度；三是把级联奖励与过程奖励模型（PRM）结合，在组件级别给中间步骤打分，应对超长项目生成中 credit assignment 困难的问题。
复现评估
复现性整体良好但有门槛。代码与数据仓库已公开（https://github.com/juyongjiang/WebGen-R1），超参数、奖励权重 $\gamma=\lambda=0.1$、GRPO 组大小 $G=16$、批大小 256、$\epsilon=0.2$、$\beta=0.01$、学习率 $5\times 10^{-6}$、推理温度 0.7 等都写得很清楚。算力门槛是 8 张 H100 80GB（全篇实验的硬件配置），SFT 2 epoch + RL 400 步是中等规模训练量，个人研究者用更少卡也能跑但需要降 batch 和组大小。主要的不确定因素在于：VLM 和 GUI 代理均标准化为 GPT-4o，会产生显著 API 费用；WebGen-Instruct 训练集（6667 任务）和 WebVoyager 都是公开的，但每次 RL rollout 都要跑完整 install→bundle→serve→render 流程，单步延迟较高。整体上，工程实现是透明的，但完整复现需要接近论文级别的算力和 API 预算。
论文图表
柱状图比较 Base（Qwen2.5-Coder-7B-Instruct）、SFT、RL only（即 R1-Zero）、SFT+RL 四种训练策略下的 AAS 分数。SFT 把 AAS 从基线提升约 18.68%，RL only 提升约 12.09%，SFT+RL 取得最高 AAS（3.94），分别比 SFT、RL only 高 21.60% 和 28.76%。
这是消融实验的核心证据，回应了「SFT 和 RL 是不是替代关系」这一关键疑问，结论是两者互补。
散点图，横轴是奖励模型分数（1-5），纵轴是 3 位前端工程师对 101 个网站的人类评分。Pearson $r=0.762, p=2.3\times 10^{-20}$，Spearman $\rho=0.734, p=2.4\times 10^{-18}$，并附人类评分 1-4 的密度曲线。
它为整个级联奖励的可信度背书——如果奖励与人评弱相关，RL 就会跑偏。强相关是论文最关键的「软」证据之一。
4 行 × 3 列的消融表：Base（FSR 1.59 / VRR 30.56）、SFT（20.08 / 30.69）、RL only（18.23 / 26.82）、SFT+RL（29.21 / 95.89）。RL only 的 VRR 反而比 Base 还低，提示纯 RL 在没有 SFT 初始化时容易跑出不可构建的项目；SFT+RL 才是真正的赢家。
FSR/VRR 视角下的消融，与图 4 的 AAS 视角一起构成完整的训练策略分析。