这项由香港科技大学（广州）、香港科技大学、阿里巴巴通义实验室、韩国电子通信研究院及蚂蚁集团联合完成的研究，以预印本形式发布于2026年4月，论文编号为arXiv:2604.20398，感兴趣的读者可通过该编号查阅完整原文。
**网站背后藏着什么难题？**
打开一个现代网站，点击导航栏，页面流畅跳转；填写一张表单，数据实时验证；浏览一个电商页面，布局精美、层次分明。这些看似平常的体验，背后其实是由数十个甚至数百个文件构成的复杂工程，涉及路由配置、状态管理、组件依赖、样式系统……任何一个环节出了差错，整个网站就可能崩塌为一片白屏。
现在，大型语言模型（AI语言助手，简称LLM）已经能熟练地写出单个函数、调试简单脚本。但让它独立"交付"一个完整的多页面网站，却是另一回事——这就像让一个能熟练切菜的厨师，忽然要求他独自设计并经营一家五星级餐厅，从菜单到装修再到服务流程全部搞定。这项研究的核心问题正是：能不能训练一个只有70亿参数的小型开源模型，让它真正学会端到端地生成可运行、好看又好用的多页面网站？
答案是肯定的，而且效果出人意料。研究团队提出的方案叫做 **WebGen-R1**，它借助强化学习（一种"让AI在不断试错中学习的方法"），在只有70亿参数的基础模型上实现了突破——不仅碾压了同等量级乃至参数量高达720亿的开源大模型，甚至在某些关键指标上超越了拥有6710亿参数的DeepSeek-R1。
---
一、从单个函数到整个网站，差距究竟有多大
要理解这项研究的价值，首先得搞清楚"写函数"和"建网站"之间的鸿沟。
写一个函数，就像做一道菜：给一个输入，返回一个输出，对不对很容易验证——运行一下测试用例就知道了。而生成一个完整的多页面网站，更像是从零开始建造并经营一家餐厅：厨房（后端逻辑）要和前台（界面）对齐，菜单（路由配置）要和每道菜（页面组件）严格对应，装修风格（视觉设计）要前后一致，而且顾客（用户）来了真的要能点单、结账、看订单历史。任何一个环节脱节，这家餐厅就开不起来。
过去的AI方案大致分为两类。一类是"简化版"——只生成单页静态网站，把那些复杂的动态路由、用户认证、跨页交互全部略去，这样的网站在现实中几乎没有实用价值。另一类是"多智能体编排"——把任务拆给多个专门的AI子系统，一个负责写界面，一个负责写后端接口，一个负责测试，再由一个"总指挥"把各部分拼在一起。这个思路听起来合理，但问题在于，各子系统之间的"契约"极其脆弱：一个文件名的细微出入、一个接口参数的类型不匹配，就可能让整个工程无法编译。更麻烦的是，这类方案通常依赖昂贵的商业大模型，每次生成要来回跑很多轮，耗费大量时间和费用。
WebGen-R1 选择了第三条路：用强化学习训练一个小型开源模型，让它在一次生成中独立完成整个网站项目，不借助外部智能体编排，不依赖商业模型。
---
二、搭脚手架：先给AI一个"毛坯房"再让它装修
研究团队面对的第一个挑战是：网站生成的"行动空间"太大了。让模型从一张白纸开始生成一个多页面React项目，相当于让它在一个无限大的草稿纸上随意涂写——它可能随手发明一个不存在的构建工具，或者忘记在`package.json`里声明某个依赖，导致整个项目根本无法安装运行。
研究团队的解决方案是"脚手架驱动的结构化生成"，用餐厅类比就是：不让厨师从挖地基开始，而是给他一栋已经建好水电管道、确认消防合格的毛坯房，告诉他"你只需要负责装修和做菜"。
具体做法是引入一个预先验证过的React模板（基于`vite-react-typescript-starter`），这个模板固定了项目的骨架：入口文件、构建配置、路由架构、服务器配置全都写死，保证不会出错。模型只需要生成"可变组件"——也就是各个页面的内容、组件代码、样式文件等真正需要根据用户需求定制的部分。生成完毕后，这些可变部分被自动"注入"到固定骨架的对应槽位，合并成一个完整的网站项目。
从数学上说，模型的生成过程被精确建模为：在给定系统提示、用户需求说明和模板上下文的条件下，按顺序生成每个可变组件的每个词元（token）。这种约束确保了一件之前几乎不可能保证的事：生成出来的项目，其基础结构天然就是合法的。
---
三、分级审查：用"两道关卡"替代昂贵的人工探索
即便有了脚手架约束，模型生成的内容仍然可能出错——比如引用了一个没有生成的组件文件，或者在`package.json`里填了语法错误的JSON。如果直接把这些内容送去做"奖励打分"，不仅浪费算力，还会给模型提供混乱的学习信号。
研究团队在奖励计算之前设计了一个"分级过滤流水线"，就像餐厅出菜前的双重检查：先由领班检查摆盘是否符合规范，再由试菜员确认口味是否合格，只有两关都过了，菜才会端上桌子让顾客评分。
第一道关卡叫"静态合规验证"。系统会在不运行任何代码的情况下，检查生成结果是否满足四类约束：项目整体结构是否合法（文件夹层级对不对）、必要文件是否都存在（`App.tsx`、`main.tsx`等核心文件有没有）、关键命令是否声明（安装命令和启动命令写了没有）、内容层面的基本规则是否遵守（`package.json`格式是否正确、组件导出模式是否合法等）。四类约束全部以逻辑"与"的方式组合，任意一项不满足，这次生成就直接被判定为失败，不进入第二道关卡，立刻返回惩罚信号。
通过第一道关卡的项目会进入第二道关卡："自动化构建与渲染"。系统会依次执行四个步骤：安装依赖（npm install）、打包构建（Vite/Webpack）、启动本地服务器、用无头浏览器截图并收集运行日志和控制台错误。最终得到的"观测结果"包括多个页面的截图、运行时日志和浏览器控制台日志，这三部分一起送往下一环节的奖励模型。
这种"先静态筛、再动态渲染"的流水线设计，把真正需要昂贵计算的步骤（渲染和打分）只留给那些真正有希望的候选项目，大幅提升了训练效率。
---
四、三维奖励：同时考量颜值、功能和思维方式
这是整个方案最有创意的部分。如何给一个生成的网站打分？
如果只看"功能对不对"，那么一个能正常运行但界面丑陋、毫无设计感的网站会得到高分，而一个设计精美但有一两个小按钮失效的网站会得到低分——这显然不符合真实世界的评价标准。但如果只用视觉评分，那么一个外观漂亮但实际上按钮根本没有绑定事件处理器的"花瓶网站"也会蒙混过关。
研究团队设计了一套"级联多模态奖励"，把三个维度的评价有机结合，形成一个阶梯式的打分体系。
整体逻辑是这样的：如果静态验证失败，直接给0分（静态惩罚）；如果构建失败，也给0分（构建惩罚）；只有成功渲染的项目，才会进入三维综合打分阶段。
三维打分中，第一维是"视觉美学感知分"。系统把渲染截图连同用户的需求描述一起送给一个视觉语言模型（能理解图片的AI），让它对网站进行0到5分的评分，评价维度涵盖布局协调性、色彩搭配、字体层级、视觉上可感知的功能完整性，以及与用户设计意图的风格匹配程度。这个分数是连续的，能细腻地区分"一般"与"优秀"的设计。
第二维是"功能完整性分"。系统统计运行时日志和浏览器控制台日志中的报错数量：如果没有任何报错，得1分；有任何报错，得0分。这个简单的二值判断确保了模型不能靠"好看但报错"来蒙混奖励。
第三维是"推理格式分"。研究团队希望模型在写代码之前先进行结构化思考——规划目录层级、考虑框架配置、维护跨组件的共享状态。因此他们要求模型的输出必须包含用`<think>`标签包裹的链式推理（一种让AI先"想清楚再动手"的技巧）。如果模型确实输出了这种格式，得1分，否则得0分。
最终的密集奖励是三个维度的加权和：视觉分加上0.1倍的功能分加上0.1倍的格式分。功能分和格式分的权重设得较小，是因为它们是稀疏的二值信号，权重过大会干扰视觉感知分这个连续信号提供的细腻学习梯度，导致模型训练不稳定。研究团队通过系统的超参数搜索（在0、0.1、0.5、1.0的网格上穷举测试）验证了这个权重组合是最优的。
---
五、用"分组比较"代替"打独立分"——强化学习的优化方式
有了奖励信号，接下来就是训练模型。研究团队选择了一种叫做GRPO（组相对策略优化）的强化学习算法，而没有使用更常见的PPO算法，原因很直白：网站生成的奖励信号极其不稳定——一个微小的语法错误就能让奖励从高分直接跌到零分，这种剧烈波动会让PPO这类需要稳定基准线的算法很难收敛。
GRPO的核心思想可以用一个生动的比方来理解：假设你是一个培训机构的教练，今天同时给16个学生布置了同一道题，让他们各自独立作答。然后你不去给每个学生打一个"绝对分数"，而是把16份答案放在一起横向比较——做得比平均水平好的，给正向激励；做得比平均水平差的，给负向反馈。这样，即使整体水平参差不齐，学生也能从"我比同伴好多少/差多少"中获得清晰的学习信号。
在实验中，研究团队对"每次同时生成多少个候选答案"（即分组大小G）进行了系统测试，发现G越大，效果越好——G=32时各项指标均优于G=16、G=8，这印证了"更多候选项带来更丰富的比较信息"的直觉。出于计算资源的平衡考虑，正式实验选用了G=16。
此外，GRPO还引入了KL散度惩罚项，防止模型为了追求高奖励而走向极端——就像给学生设置一条规则："你的答题风格不能偏离我们教过你的基础太远，不然即使答对了也要扣分"，从而保持生成代码的语法质量和语言风格。
---
六、训练流程的两个阶段
训练分为两步，就像厨师培训先上基础烹饪课再参加实战竞赛。
第一步是监督微调（SFT）热身。研究团队从训练数据集（WebGen-Instruct，包含6667个真实网站生成任务）中按应用类型均匀采样600个任务，用GPT-4.1生成对应的高质量参考答案，然后用这些"示范样本"对基础模型Qwen2.5-Coder-7B-Instruct进行微调，训练2个轮次。这一步的目的是让模型先建立起"网站项目长什么样"的基本结构感知和语义理解，相当于给厨师打好刀工基础。
第二步是GRPO强化学习精调。在SFT模型的基础上，继续进行400步的强化学习优化，全局批大小256（即每步处理256个提示），分组大小G=16，KL惩罚系数0.01，学习率5×10^{-6}。提示的最大长度4096个词元，模型输出的最大长度8192个词元——后者保证了在一次推理中能生成足够完整的多页面项目代码。
消融实验证明，单独做SFT或单独做强化学习，效果都不如两者结合。SFT提供了结构感知的先验，让强化学习的探索有一个合理的起点；强化学习则在奖励信号的引导下，把SFT无法优化的功能正确性和视觉质量推向更高层次。
---
七、实验结果：数字背后的故事
研究团队在两个基准上进行了评测，并设计了四个量化指标。
第一个指标是"功能成功率"（FSR），衡量生成网站能否通过预定义的交互测试——包括按钮点击、表单提交、多页面导航等。评测工具是WebVoyager，一个专为网页环境设计的GUI智能体，它模拟真实用户操作，记录DOM变化和界面响应，判断交互是否符合预期。
第二个指标是"美学对齐分"（AAS），由视觉语言模型对渲染页面进行0到5分的打分，评价布局、色彩、字体和风格与用户需求的匹配程度。
第三个指标是"有效渲染率"（VRR），即能够成功渲染（不报运行时错误）的项目比例。
第四个指标是"代码检查与依赖通过率"（LDPR），即通过ESLint静态分析并能自动解析依赖的项目比例，反映代码质量和部署就绪程度。
在WebGen-Bench（包含101个精心策划的网站生成任务，覆盖从极简作品集到复杂数据仪表盘的13种场景）上，结果如下：基础模型Qwen2.5-Coder-7B-Instruct的功能成功率只有1.59%，有效渲染率仅30.56%，美学分2.73。经过WebGen-R1训练后，功能成功率跃升至29.21%（提升27.62个百分点），有效渲染率达到95.89%（提升65.33个百分点），美学分达到3.94（提升44.32%）。
横向比较一下友商表现就更有说服力了。同为阿里巴巴出品的Qwen2.5-72B-Instruct（参数量是WebGen-R1的10倍），功能成功率只有2.54%，有效渲染率更是惨不忍睹的8.86%。Qwen3-32B稍好一些，功能成功率18.69%，但仍逊于WebGen-R1。拥有6710亿参数的DeepSeek-R1功能成功率为30.25%，与WebGen-R1的29.21%接近，但其有效渲染率只有42.86%，美学分3.67，均远低于WebGen-R1。商业模型中，Claude-3.7-Sonnet的功能成功率最高（57.72%），但美学分3.90低于WebGen-R1的3.94，有效渲染率84.00%也低于WebGen-R1的95.89%。GPT-5功能成功率46.53%，美学分3.34，有效渲染率90.43%，同样在后两项指标上不如WebGen-R1。
值得特别关注的是一个有趣的规律：美学分相对容易随模型规模提升，但功能正确性的提升则难得多。例如Qwen2.5-72B的美学分3.14已经接近部分商业模型，但功能成功率仅2.54%。这说明让AI生成"看起来好看"的界面比让它生成"真正能用"的界面要容易很多——前者只需要掌握视觉模式，后者需要真正理解交互逻辑和事件绑定。
在13个细分场景的雷达图中，WebGen-R1在所有场景下的美学分都优于基础模型，并在内容呈现和设计验证测试类别上与DeepSeek-R1和Gemini-2.5-Pro表现相当。功能成功率方面，WebGen-R1在所有指令类别和测试用例类别上都显著超越基础模型。
为了验证泛化能力，研究团队还在WebDev Arena（从10000个真实网页开发任务中筛选出的119个高质量任务，指令风格和领域分布与训练数据差异显著）上进行了评测。由于WebDev Arena没有标准化测试用例，只报告美学分。结果显示，WebGen-R1的美学分在所有开源和商业模型中均排名最高，高于DeepSeek-R1、GPT-5、Qwen3-32B等，表明模型学到的是可迁移的架构抽象和风格理解，而非单纯记忆训练数据的特定模式。
---
八、人类评价验证：AI打的分，人类认不认？
研究团队担心一个问题：奖励模型给出的分数，真的和真实用户的感受一致吗？如果AI评委的偏好和人类评委的偏好不一致，那整个强化学习的方向就可能偏了。
为此，他们招募了三位有经验的前端开发工程师，让他们独立对WebGen-Bench上生成的101个网站进行功能和视觉的综合评分，然后把人工评分与奖励模型的打分进行相关性分析。结果显示，皮尔逊相关系数r=0.762，斯皮尔曼秩相关系数ρ=0.734，两项统计均高度显著（p值约为10^{-18}到10^{-20}量级）。这说明奖励模型对网站质量的判断与专业人类评委高度吻合，强化学习的优化方向是可信的。
---
九、回到那家餐厅：这一切意味着什么
说到底，WebGen-R1 做的事情用餐厅类比来总结最为直观：之前那个7B厨师，走进一家新餐厅，只能做出三成勉强能端上桌的菜（有效渲染率30.56%），其中真正让顾客满意的不到两桌（功能成功率1.59%）。经过WebGen-R1的训练，同一个厨师进步到了几乎每次都能做出可以端上桌的菜（有效渲染率95.89%），而且有将近三成的菜能让挑剔的顾客完全满意（功能成功率29.21%），菜的卖相甚至超过了很多更大厨房的大厨（美学分3.94，超越GPT-5、Gemini-2.5-Pro等）。
这项研究的意义不仅在于技术指标的提升，更在于它打开了一条新路：通过强化学习，把小型开源模型从"函数级代码生成"推向"项目级应用生成"，而且不需要依赖昂贵的商业模型或复杂的多智能体编排。这对于那些资源有限、希望在本地部署AI辅助开发工具的团队来说，具有很现实的价值。
当然，这项研究也有清醒的局限性。在WebDev Arena这种指令极短、信息不完整的任务上，WebGen-R1有时会因为缺乏足够的上下文而错过一些新的设计趋势——研究团队也坦承，采用更新的基础模型有望缓解这个问题。此外，功能成功率29.21%意味着仍有七成任务没能完全达标，距离真正的"生产级可靠性"还有相当距离。
功能成功率和美学质量之间的张力，或许是网站生成领域下一个值得深入研究的核心问题：美丽的外表和真正好用的功能，如何同时兼顾？WebGen-R1 给出了一个有说服力的起点，但这场探索才刚刚开始。有兴趣深入了解技术细节的读者，可以通过arXiv编号2604.20398查阅完整原文，研究团队也已将代码和数据集开放在GitHub上供研究社区使用。
---
Q&A
Q1：WebGen-R1是如何解决网站生成中"奖励难以设计"的问题的？
A：WebGen-R1把奖励拆成了三层：第一层用静态规则判断项目结构是否合法，第二层检查构建是否成功，第三层才调用视觉语言模型进行美学打分，同时用日志报错数量来衡量功能完整性。这种级联设计确保昂贵的视觉打分只用在真正值得评估的项目上，大幅提升了效率和信号质量。
Q2：WebGen-R1训练用的基础模型是哪个，训练成本大概是什么量级？
A：基础模型是阿里巴巴的Qwen2.5-Coder-7B-Instruct，参数量70亿。训练在8张英伟达H100 GPU（每张80GB显存）上完成，先进行约2个训练轮次的监督微调热身，再进行400步的强化学习精调。整体训练规模相对较小，属于普通学术实验室可以承担的量级。
Q3：WebGen-R1生成的网站用了哪些技术栈，为什么选这些？
A：WebGen-R1生成的网站固定基于React函数组件加TypeScript，使用Vite作为构建工具，Tailwind CSS负责样式，Ant Design提供复杂UI组件，React Router DOM v6处理路由，需要图表时使用Recharts。这套技术栈的选择是为了减少渲染和交互评估中的不确定性——统一框架让自动化测试更稳定，也让强化学习的奖励信号更可靠。