WebCraftBench：一套给AI生成网页做系统化实测的评测基准

这两年AI生成网页的浪潮来得比想象中猛，前有对话式生成整站、后有设计稿直接转代码，看起来只要打几行字就能把落地页、后台界面、甚至完整前端项目“变”出来。但等真把AI生成的网页拿上线、接业务、跑性能的时候，实测下来的结果往往和截图差着十万八千里——有的是HTML结构稀烂、CSS类名全靠猜，有的干脆首屏三张图全裂，更别说跨端适配和可访问性了。所以我才决定搞一个WebCraftBench，目标很直接：给AI生成的网页来一场系统化的“实测大考”，把“能不能用”、“好在哪、烂在哪”、“怎么改进”从拍脑袋变成可以复现、可以量化的结论。这篇文章就把WebCraftBench从设计到落地的完整思路、踩过的坑、以及实测中发现的高频问题整理出来，给同样在折腾AI网页生成、以及想给AI前端能力“打分”的朋友一个参考。

整个项目我自己定位成一款轻量级评测基准，不追求做得多庞大，核心解决三件事：第一，用一套固定考试集去考验AI生成网页的真实水平，考试题就是一组有代表性的网页需求；第二，把评分维度统一化，视觉、代码、性能、功能、响应式、可访问性全都要管；第三，产出的结果既能横向对比不同AI工具的生成能力，也能反过来指导生成侧调优——换句话说，WebCraftBench既是“考卷”，也是“体检报告单”。

1. 为什么需要WebCraftBench：AI生成网页的“裸泳时刻”

1.1 AI生成网页的现状与真实痛点

AI生成网页这条赛道，现在主要分三波玩法。第一波是对话式生成，像各种基于大模型的前端工具，你跟它说“给我做一个带导航栏、Hero区、三个功能卡片、一个联系表单的落地页”，它会在几十秒里给你输出HTML+CSS+JS，甚至一整个React组件树。第二波是设计稿转代码，Figma插件、Sketch插件那一类，把设计师画好的图层、切图、标注转译成手写风格的前端代码。第三波是模板增强式生成，在现成模板库上做文案、配色、排版微调，算是“半智能”的改良路线。

听起来很猛对吧？但把这三波AI生成的网页拉到真实环境里跑一遍，问题就全暴露了。

我拿一个很典型的案例说。用某工具生成一个“咖啡品牌官网”的demo需求，生成出来的截图确实唬人：大图、渐变、圆角、动效该有的都有。但浏览器里一跑，先是导航栏在移动端点了没反应，因为JS只绑到了桌面断点；接着发现Hero背景图用的是Picsum这类第三方图片服务，线上偶发加载失败自然就裂了；再用Lighthouse扫一遍，CLS直接窜到0.43，原因是图片没写宽高、字体加载前后导致布局抖动。这类问题不是个例，而是目前AI生成网页的通病——视觉层做得不错，工程层和体验层一测就露馅。

说白了， AI生成网页最大的问题不是“做不到好看”，而是“好看不等于好用、可用、可维护” 。而市面上大多数评测标准，要么只评截图视觉相似度，要么只看代码能不能跑通，很少把“像一个工程人员那样去验收代码”这件事系统化。于是大家看到的现象就是：AI生成的成本越来越低、速度越来越快，但真正敢直接把生成物扔到生产环境的团队少之又少。

1.2 现有评估方式的三个明显短板

在WebCraftBench之前，我其实也试过好几类现成的评估思路，但它们都有明显短板。

第一种是人工主观评审，找几个前端工程师对着生成结果手动打分。优点是评估维度可以很灵活，缺点同样致命——主观性太强，同一份代码，一个人觉得“能看能用给80分”，另一个人觉得“这种Class命名我要全部重写、给60分”，分数拉不开有效差异。而且人力成本高，测一轮需要几小时，根本没法批量跑。

第二种是纯自动化截图对比，把AI生成的网页和设计稿或者参考站点摆在一起算像素差。这类方案能快速给出“相似度”数字，但维度太浅：只覆盖视觉层，代码质量、性能、交互可用性一概不摸。更难受的是它容易误判——一个正确的空白留白会被算成视觉偏差，一个功能完全缺失的页面反而可能因为“长得像”得到高分。

第三种是直接拿现有Web性能测试工具套上去，比如Lighthouse跑一圈。这类工具本来是用来看真实线上页面的，拿来测AI生成的临时页面，一是缺少统一的测试环境基线，二是有大量指标（比如语义化程度、可访问性细节、动态交互逻辑）根本测不出来，三是它不关心“这段代码是不是某个AI在没有真实用户交互数据的情况下凭感觉生成的”，于是评分维度完全错位。

那WebCraftBench想做的是哪种？我想得很清楚： 它要像一位既有审美、又抠工程细节、还懂线上运维的前端负责人，对AI生成的网页做一次“验收式实测” 。它既保留人工评审里那些重要的质量维度，又尽量把这些维度拆成可量化、可自动化执行的指标，再叠加上统一的测试环境，让不同AI工具的结果可以在同一把尺子下直接对比。

1.3 WebCraftBench的核心定位与解决问题

WebCraftBench的核心定位，我用一句话概括：一套面向AI生成网页的可复现评测基准与实测流水线。

它解决的是三个层面问题：

• 对使用者（比如想引入AI生成前端的团队）：提供一套统一的“验收标准”，用测试数据说话，告诉你某款AI工具到底能不能扛住某个类型的页面需求；
• 对开发者（比如做AI前端工具、想持续优化自家的生成效果）：提供可量化的反馈信号，明确把问题定位到“布局不对”、“代码混乱”、“性能拉垮”、“功能缺失”这些具体维度，而不是只给一句“效果一般”；
• 对研究者（比如研究代码生成模型的评估）：提供一个大家都用得上的测试集和评估协议，降低重复造轮子的成本。

从我自己的实践看，这三点现在都跑通了：WebCraftBench已经成为我评估不同AI网页生成方案的默认入口，凡是新产品、新版本、新prompt策略出来，先去跑一轮“大考”，用分数和问题清单说话。

2. 评测维度设计：从“看着像”到“用着稳”的六层考核

2.1 布局与视觉还原度：先看脸，但不只看脸

视觉还原度是第一个要测的维度，毕竟用户第一眼看到的就是UI。但WebCraftBench的视觉评测和“截图相似度”有一个本质区别：我不满足于“长得像”，我要的是“关键结构对”。

具体做法是这样。考试集里的每个需求都会有一个参考描述，包含了页面结构的关键要素。比如一个落地页需求会明确说清楚：“顶部有通栏导航，导航右侧有三个按钮；Hero区左侧是标题、副标题和一个CTA按钮，右侧是产品主图；下面有三个特性卡片，图片在上、标题居中、描述两行”。评测时，并不是拿AI生成图和某个标准答案做像素对比，因为这种对比在风格化页面上意义不大。我改用两个手段叠加：一是结构存在性检查，通过DOM查询和视觉检测去确认这些关键区块是否真的存在、位置顺序是否正确；二是布局比例检查，算这些区块之间的相对间距、尺寸比例是否符合设计常识，比如导航高度不能超过视口的15%、Hero区不能把CTA按钮挤到首屏之外。

说实话，仅靠视觉还原度这一项，就能筛掉一大批“看着不错但结构全乱”的AI生成结果。我实测过一个AI工具，生成出来的“电商首页”确实华丽，但把页面拉到底一看，整个版心宽度在不同区块间乱跳，导航和Banner竟然各用各的container宽度。这属于典型的“局部精致、全局失控”。视觉还原度评分里专门有一条“布局一致性”，就是抓这种问题的。

2.2 代码规范与可维护性：前端工程师的“挑刺视角”

代码质量是WebCraftBench和绝大多数只看截图的评测差异最大的一块。在我心里，一段AI生成的代码，就算效果完全还原、功能全部能跑，如果代码本身没法维护，那它也只是一个一次性demo，不能算“合格”。

代码规范的评测，我拆成了五个小维度：

• HTML语义化：页面里是不是按内容属性用了合适的标签，导航是不是用nav、正文是不是用main/article/section、按钮是不是用button而是一堆div死磕事件。这个维度很能看出AI是“模板搬运”还是“真的理解页面结构”；
• CSS组织方式：类名是否有语义、层级是否清晰、是不是一大坨内联样式或者全局暴力覆盖。AI工具特别容易输出只有三个类名却控制整站的CSS，这种代码看着短，改起来等于重写；
• JS可维护性和健壮性：事件有没有解绑，DOM查询是不是一次性查完，有没有在组件卸载里清理定时器，交互逻辑会不会因为DOM结构变化就崩掉。这些都是我可以直接给出绿/黄/红信号的质量点；
• 依赖合理性：是否为了一个简单的折叠动画引入一个100KB的动画库，是不是在2024年了还在用已废弃的方法，有没有冗余的CDN资源，这些都会影响后续负责人对项目的信任感；
• 工程化准备：代码有没有符合基础的前端工程规范——比如脚本放在合适位置、图片有合理的alt、样式有基本的设计抽象，而不是全站style布满每个元素。

实际执行中，我会用一套“静态规则+人工复核”的方式跑这部分。静态规则能刷出明显违规，人工复核负责判断“垃圾中的小确幸”——比如类名虽然长，但整体模式还算一致，这种容忍度分数就可以给高一点。这里的核心心得是： 代码规范不必追求零瑕疵，而是要判“能不能放心交付给下一个开发” 。

2.3 功能可用性与交互完整性：AI经常在这翻车

AI生成网页最爱翻车的环节之一是交互功能。这不是说AI不会写JS，而是它写出来的JS往往只考虑“主流程成功”的情况，一遇到边界情况就崩。

WebCraftBench的功能评测，会在真实浏览器里把每个可交互元素都过一遍。比如考试集里有一个“注册登录页”需求，评测人员会模拟这些动作：输入非邮箱格式的字符串，看有没有校验提示；密码框能不能切换明文显示；提交后有没有loading和成功/失败反馈；校验失败时焦点有没有跳到错误字段；重复点击提交会不会发两遍请求。再比如电商型页面，会测搜索框回车事件、筛选条件组合、空列表状态、加入购物车后的角标更新。这些在人工评审里会花掉大量时间的部分，WebCraftBench通过浏览器自动化脚本去跑，效率和一致性都高得多。

交互评测里特别值得说的一点是状态完整性。我见过太多AI生成的网页，“点击按钮变红”这种直接交互能跑，但“点击后按钮进入loading状态、然后根据结果变化”这种带中间态的逻辑基本是摆设。WebCraftBench会把“状态机是否完整”作为一个独立评分小项，一测一个准，因为我发现AI生成代码的最大问题不是不会写交互，而是不会处理“交互过程中的中间状态”。

2.4 性能与加载体验：让数字说话

性能维度是WebCraftBench所有维度里最容易量化的，但同时也是很多AI生成网页的“隐形刺客”。Lighthouse的性能分数常常被拿来说事，但实际跑过的人都清楚，性能分数受网络、硬件、页面内容类型影响很大。所以我给WebCraftBench设了一套固定的性能测试基线：统一用Chrome Headless模式、统一模拟Moto G Power的硬件规模、统一用Slow 4G网络节流，所有页面在同一个环境下跑三轮取中位数，避免单次抖动影响结论。

具体指标上，我重点盯这几个：FCP（首次内容绘制）、LCP（最大内容绘制）、CLS（累计布局偏移）、TBT（总阻塞时间）、以及页面的总资源体积和请求数。这些指标基本覆盖了“打开快不快”、“加载稳不稳”、“交互顺不顺”三个层面。

我不讳言，很多AI生成网页的性能成绩惨不忍睹。有一次测一个AI生成的“摄影作品集”页面，LCP=7.8秒，卡在了一个3.2MB的演示图片上。你说AI不知道图片要压缩吗？它不是不知道，而是在生成时贪图方便、直接用了原图链接或者高清素材库的大图，完全没有做体积优化。这也是WebCraftBench的一个核心价值—— 把“性能问题”具体到一个可修复的参数上，而不是笼统地说“你的页面很慢” 。

2.5 响应式与多端适配：跨设备的照妖镜

响应式适配几乎是AI生成网页的另一重灾区。目前的AI工具大多是在“页面宽度=1440”的假设下生成网页的，移动端适配往往是加几个媒体查询意思一下，实际效果完全没法看。

WebCraftBench的响应式评测会固定测试五个断点：375、768、1024、1440、1920，分别对应主流手机、平板、小笔记本、普通桌面、大屏显示器。每个断点下都会检查三个东西：

• 是否有横向滚动条（这几乎是移动端最高频的bug）；
• 内容是否被截断或遮挡（比如固定高度的容器在小屏下文字溢出）；
• 导航/表单等组件是否切换为适合对应屏幕宽度的形态。

这个测试乍一看不难，但自动化起来还挺费功夫。因为光“有没有横向滚动条”就要考虑body级滚动和容器级滚动两种情况，有些AI生成网页虽然body没有滚动条，但某个卡片列表的容器却滚动到屏幕外看不见的角落去了。所以我后来把响应式检测从“看body overflow”升级成“全页面元素边界检查”，遍历所有可滚动容器，确保没有任何一个子元素超出视口边界。这个细节也成了WebCraftBench最关键的技术手段之一。

2.6 可访问性与前端卫生习惯：容易被忽略的“良心分”

可访问性（a11y）在AI生成网页的评测里是冷门项，但我坚持要测，原因是： 可访问性是检验AI是否具备“真实前端责任感”的试金石 。它不要求页面多么精美，但要求按钮能被键盘登录、图片有alt文本、文本对比度不瞎眼、表单有label关联。这些内容对一个“只追求截图好看”的生成系统而言，往往是最容易被忽略的部分。

WebCraftBench在可访问性维度会自动化检查这些点：img标签的alt属性、表单控件的label绑定、页面是否有一个h1标题、按钮和链接的可聚焦性、以及文本与背景的对比度。再配合浏览器内的键盘遍历测试——Tab能不能按顺序走完所有可交互元素，焦点有没有可见的轮廓线。

我统计过前几轮测试的数据， 超过六成的AI生成网页在可访问性维度拿不到及格分 。最常见的两个问题：一是图片alt大量缺失或直接用文件名凑数；二是form表单的label标签和input之间没有建立for/id对应关系，屏幕阅读器读起来完全是一堆乱码。这可能不算影响“演示效果”的问题，但对想上生产的团队来说，它是非常关键的法律合规和用户体验风险。

3. WebCraftBench的考试集与评分体系：怎么保证考试公平

3.1 考试集设计：覆盖“真实世界的网页考卷”

说过评测维度，接下来要讲考试集——也就是让AI来做的那些“考题”。设计考试集时，我遵循一个原则：考卷上的每一道题，都必须是真实工作中会遇到的需求，而不是为了刁难AI生成的偏怪题。

目前WebCraftBench测试集包含10个基础题，按难度分成三档。第一档是“页面结构题”，包括企业官网落地页、个人作品集页面、产品功能宣传页，这类需求重在测试结构组织能力和视觉表现力。第二档是“交互逻辑题”，包括注册登录页、To-Do管理面板、后台数据看板，这类需求要求AI不仅要排版，还要写交互逻辑、状态管理、表单校验。第三档是“内容展示题”，包括博客文章页、电商商品列表页、视频课程目录页，主要考察长页面信息层级和列表/筛选场景。

每个考题都附带一个“需求描述文档”，里面写清楚页面必须包含的关键区块、必要的交互需求、以及一些硬性要求（比如“表单需要校验”、“列表需要支持筛选”）。这个考卷设计其实借鉴了软件工程里的“需求评审”思路—— 不给AI自由发挥的无限空间，而是像真正的产品经理一样，把边界划定清楚，再来看AI能不能在约束下给出好方案 。

为了让考试集更全面，下一版我还打算加入带设计稿输入的考题，考察AI的“设计稿转代码”能力，以及加入多语言页面的考题，看看AI在多语言、RTL（从右向左排版）场景下的表现。

3.2 评分模型与权重分配：维度分+总分如何折算

有了考试集和评测维度，剩下的关键问题是：这么多维度的分数，怎么汇总成一个有意义的“总成绩”？WebCraftBench的评分模型采用“维度加权+瑕疵扣分”的双层结构。

先看权重分配。六层考核里，我把权重设定为：

评测维度	权重
布局与视觉还原度	20%
代码规范与可维护性	20%
功能可用性与交互完整性	25%
性能与加载体验	15%
响应式与多端适配	15%
可访问性与前端卫生	5%

功能可用性权重最高，这是刻意为之——因为WebCraftBench评测的最终目标不是“评出好看的作品”，而是“这个页面能不能干实事”。代码规范的权重也定得很高，这是站在真实团队维护成本角度考虑的；视觉还原度虽然重要，但我有意把它压到了20%，就是为了防止“截图漂亮就能混高分”的情况。

每个维度内部再按若干检查项打分，检查项有两类。一类是硬性红线项，比如“是否存在横向滚动条”、“LCP是否超过4秒”、“是否有alt缺失”，这类只要命中就拉低该维度基础分。另一类是加分项，比如“代码里是否包含清晰的注释”、“是否主动实现了暗色模式”，这类做得好可以在维度分上做微调。所有分数的汇总逻辑，可以类比成“基础分-扣分+加分”，上限是100分，下限不做保护。实际跑下来， 目前主流AI工具在WebCraftBench上的平均分集中在62～79分之间 ，这个区间区分度很合理：能看出差距，又不会让大家连及格都拿不到。

3.3 从评分到诊断报告：分数之外更有价值的输出

单纯给出一个“AI生成的网页得了73分”没什么大用，真正有用的是这73分是怎么来的、扣在哪儿、怎么改。所以WebCraftBench最终交付的不只是分，而是一份“诊断报告”。

报告分三块。第一块是“总分与对比”，把当前页面的总成绩放到同类型考题的排行榜里，让测试者一眼知道AI工具处于什么水平。第二块是“维度雷达”，把六大维度的分数画成雷达图，直观暴露短板——有的工具是“视觉90分但功能20分”，有的则是“功能很强但视觉一层纸”。第三块是“问题清单”，把每一项原始日志里扫描到的问题折叠成一条条可读的“问题单”，每条注明严重程度、所属维度、以及建议修复方向。比如“CLS=0.43，严重；原因是轮播图未指定宽高；建议为图片容器设置固定aspect-ratio”。开发人员可以直接拿着这份清单去修，或者把清单问题反馈给生成侧去优化prompt。

我自己的使用习惯是，跑完一轮WebCraftBench、拿到报告后，把“问题清单”直接贴回AI对话里让它自己反思加修改，再做第二轮测试。往往第二轮分数能涨5～15分。这种“生成→实测→反馈→再生成”的闭环，是WebCraftBench最不经设计却最香的功能。

4. 实测流程与关键实现：从代码到报告的自动化流水线

4.1 环境搭建与浏览器自动化管线

WebCraftBench的整个实测流程，是跑在一条自动化流水线上的。先简单说一下整体架构：一个Node.js调度器负责读取考卷、启动浏览器实例、收集结果；浏览器端通过Puppeteer控制Chrome Headless执行页面加载、截图、性能采集和交互模拟；所有数据汇总到一份JSON结果文件，最后由报告生成器渲染成HTML或Markdown报告。

流水线的第一步是“准备考场”。我封装了一个独立的浏览器实例，启动时会提前注入性能监听脚本、错误捕获脚本和网络请求拦截脚本。这里有几个细节很关键。性能监听脚本不仅监听Performance API的数据，还额外挂载了MutationObserver，专门跟踪DOM新增的大尺寸图片和异步组件，因为AI生成的页面经常会在页面加载后动态插入大图或跑马灯资源，这类异步内容对LCP的影响非常大，只靠Performance API的默认上报会漏掉。错误捕获脚本则是把window.onerror和unhandledrejection全部拦截下来，记录抛出的JS异常、报错堆栈、以及出错时点击的DOM元素路径。网络请求拦截会记录所有请求的URL、资源类型、耗时和状态码，为后续诊断“第三张图为什么裂了”这类问题留下原始证据。

4.2 六大维度的自动化执行细节

六大维度在流水线里各有各的执行方法，这里挑几个核心的实现细节来说。

视觉和布局维度的自动化，依赖DOM结构性检查。我先解析HTML，建立语义树（哪些是header/nav/main/footer），再根据考试题里定义的关键区块去定位对应DOM节点。比如考卷要求“Hero区有左侧文案组和右侧图片”，那自动化就要检查是否存在包含h1的section，且这个section里有一个img或带背景图的div。定位到节点之后，再计算这些节点的几何信息——x、y、宽、高、以及和其他节点的相对关系。比如“CTA按钮不能超出首屏可视区”这个检查，就是用按钮的y坐标和window.innerHeight比较。这里的执行细节是，不能只取页面的静态定位，因为很多AI页面会做滚动动画或者视差，所以我会先做一次“所有元素滚动到视野内”的操作，再采集一次几何信息，取两轮数据的并集来判断。

功能交互维度的自动化是全流程最复杂的一块。我没有采用“录制回放”的方式（那太脆弱了，AI生成的页面ID、类名每次都不确定），而是用“行为级描述”来写测试用例。举个例子，针对搜索功能，测试脚本不是写“点击id=searchBtn”，而是写“找到页面上看起来像搜索框的input并填充关键词、触发回车，再观察页面上是否有与关键词匹配的结果出现”。“看起来像搜索框”靠什么判断呢？靠input的type属性、placeholder文本里是否包含“搜索”/“Search”关键字、以及它是否被一个form标签包裹，综合打分后再匹配。这套“语义化选择器”思路让我能稳定测试AI生成的“万变结构”，不被具体实现细节带跑。

性能维度的执行，前面已经提过，用固定的硬件模拟、固定网络节流跑三轮取中位数。不过我还要补充一个细节：不只是取Lighthouse分数，而是会同时记录Web Vitals的原始值（LCP、CLS、INP），因为这些指标才是搜索引擎和用户体验的真正衡量标准，Lighthouse分数只是包装。我遇到过几个页面，Lighthouse“Performance”分数接近90，但LCP却要4.2秒，因为分数计算里其它指标（比如资源缓存效率）被拉高了。只看分数不看原始值，依然会误导人。

响应式维度的自动化是在五个断点下执行的。每个断点都会跑一遍同样的“全部元素边界检查”和“横向滚动条检查”，再额外做一次截图存档。这套检查在375px断点上的命中率非常高，十次有八次能扫出溢出问题。可访问性维度的自动化则主要依赖两类工具：一类是浏览器自带的Accessibility Tree，我用它来检检查语义标签是否被正确暴露；另一类是自己写的小规则集，去扫图片alt、label绑定、标题层级这类基础项。

4.3 离线报告的渲染与人工复核

自动化流水线跑完后，会生成两个产物：一个是完整的数据JSON，每一条原始检查日志都在；另一个是渲染好的HTML报告。但说实话，我从不完全信任自动化报告， 每个考题在出分前一定要做一轮人工抽检 ——就像考试里光有机器阅卷还不够，得有几道主观题让老师改。

人工复核主要看三个东西。一是自动化有没有误报。比如“横向滚动条”误判，页面里可能故意设置了拖拽式的横向内容区（比如图片走马灯），那这是合理设计，不该扣分。二是看AI有没有“作弊”——比如在CSS里硬写死某个断点的样式来应付响应式测试，这种代码虽然能通过自动检查，但真实换一个设备就露馅，人工复核时要降分。三是给那些自动化测不出来的“体感项”打分，比如动画节奏是否自然、字体排版是否舒服、整体视觉层级是否清晰。这些“体感分”虽然主观，但我把它控制在总权重的5%以内，既保留人的审美判断，又不让主观性影响整体可复现性。

4.4 数据回传：让测评结果“喂”回生成环节

自动化流水线跑完拿到报告，不是终点。WebCraftBench有个设计让我觉得特别得意——它会把“问题清单”整理成一段结构化反馈文本，用户可以直接把这段文本粘贴回AI生成工具里，作为第二轮生成的优化指令。比如：“上一轮生成页面的CLS=0.42，因为轮播图未指定宽高；建议为所有图片资源设置宽高比。另外页面的移动端导航交互失效，请确保菜单按钮在小屏下可点击展开。”

实测中我发现， 这种“生成→实测→反馈→再生成”的循环，比单纯在Prompt里写更多要求有效得多 。因为Prompt里的要求是“预防性”的，AI不知道自己的上一次输出到底哪里出了问题；但反馈文本是“回溯性”的，AI能对着自己的“错题本”逐条修改。这其实已经很接近人类程序员拿到code review意见后改代码的体验了。我见过一个商用AI工具，在这样迭代三轮之后，WebCraftBench总分从64涨到了81，其中性能维度从48涨到76，效果非常明显。

5. 实测中的高频问题与调优心得：那些“考卷”暴露出的通病

5.1 AI生成网页的“典型失败模式”汇总

跑了这么多轮WebCraftBench，我总结出了几个AI生成网页的高频失败模式，也算“考卷”暴露出的行业通病，列出来给大家避坑。

第一是“图片地产商”问题。AI生成页面时，特别喜欢引用第三方图片占位服务，比如Picsum、Unsplash Source这类。好处是演示现场永远有图不会裂，坏处是这些服务的稳定性完全不可控，一旦服务挂掉或者被墙，页面就出现大片空白占位。更麻烦的是，这类服务产生的图片尺寸经常巨大，导致移动端加载缓慢。

第二是“伪响应式”。具体表现是：页面在375px宽时不会横向滚动，但导航菜单却挤压成一行图标，点击后也没有展开面板，或者弹出来的下拉菜单超出屏幕边界。这种“表面看起来没有破坏布局，但实际上交互没法用”的情况，比“明显破版”更隐蔽，也更难在自动测试里抓到。

第三是“一次性交互”。AI生成的按钮点击后能看到效果，但效果是“硬编码”的——比如点击“点赞”按钮数字变成101，但刷新页面后还原；再比如点击“添加购物车”后角标变了，但购物车页面完全没同步。这种“假装有功能”的交互，在演示demo里看起来很美，却完全没法应对真实用户。

第四是“框架幻觉”。这是做AI生成网页的人最头疼的问题。AI可能为了让代码“显得专业”，引入了它见过的框架或库名字——Bootstrap、Tailwind、React、Vue都可能出现——但引入的方式却是断章取义。比如HTML里用了 class="btn btn-primary" ，但Bootstrap的CSS根本没引进来，按钮样式完全没渲染；或者写了一堆基于 useState 的React组件，却没有配置打包，浏览器根本执行不了JSX。

5.2 我踩过的坑：自动化评测本身也有陷阱

做WebCraftBench这套评测体系的过程，本身也踩了不少坑。最有体会的是这几个。

第一个坑：太依赖Puppeteer默认的等待策略。早期我用 page.waitForTimeout(5000) 这种固定等待方式，结果有的页面5秒后动画还没加载完，有的页面2秒后就稳定了，统一等5秒既浪费又可能抓错数据。后来我改成“智能等待”策略，结合 networkidle 事件和关键DOM节点出现条件做双重判断，并且给总超时设置上限。

第二个坑：性能测试被浏览器扩展污染。有段时间性能分数忽高忽低，排查半天发现是Chrome里装了开发扩展，启动Headless时没禁用，导致HTTP缓存命中率不一样。后来我专门写了一个“纯净配置”模块：启动浏览器时禁用扩展、禁用GPU加速、禁用后台网络请求，确保每次测试环境参数完全一致。

第三个坑：代码质量评分的“静态规则”误杀率太高。刚开始我用了二三十条严苛的ESLint风格规则去扫AI生成的代码，结果误报率奇高——AI在字符串拼接、引号类型这些细节上跟我的偏好不同，但它本身不算“错误”。后来我把规则收敛到真正影响可维护性的项上，比如“是否存在全局变量污染”、“是否有未定义变量”、“是否有明显重复代码段”，而不是揪住风格不放。

5.3 提升AI生成网页得分的实操建议

在WebCraftBench的反馈闭环里跑了很多轮之后，我总结出了几个能有效提升AI生成网页得分的手段，既适用于想评估AI工具的场景，也适用于想直接产出高质量AI网页的开发者。

第一，在Prompt里“反向提出工程化要求”。不要只说“做一个网页”，而是加一句“为图片加上宽高和alt，为表单添加label和校验，为移动端提供可展开的导航菜单”。AI很擅长在这些明确指令下调整输出。

第二，要求AI“自解释”代码。在生成代码时让它给CSS类名、JS函数名加上有语义的注释，这样后续自动化评测里的代码可维护性分会明显上涨，更重要的是，代码修改时不再是一场灾难。

第三，明确指定不使用第三方图片占位服务。一条“请使用CSS渐变或SVG背景代替外部图片”就能省掉大量图片加载问题，把这个要求写进Prompt，视觉分数不一定受影响，但性能分数能显著提高。

第四，每次生成后，主动把WebCraftBench的诊断报告作为“反馈输入”丢给AI让它自己修一轮。这一点前面说过了，是我实操下来效率最高的方式，没有之一。

6. 下一步规划与个人体会

WebCraftBench到现在已经迭代了三个版本，从最初只能做视觉对比的“截图像素差”，进化成了覆盖六维度的完整评测流水线。下一步我准备做三件事。一是把测试集扩展到多语言、RTL版式、暗色模式等更细分场景，让考卷更贴近全球化产品的真实需求。二是给WebCraftBench做一套开放API，让AI工具在生成页面时能自动挂载评测钩子，生成完直接触发实测、自动拿分，省去中间传输的麻烦。三是引入统一反馈格式规范，把诊断报告的“问题清单”标准化成机器可读的JSON，这样不同AI工具能直接通过API接住这些“错题”，在生成阶段就避免同类问题。

最后分享一点我个人的体会。做WebCraftBench这段时间，我最大的感受是： AI生成网页的“生成能力”已经远超大多数人的预期，但“交付能力”还差得很远 。生成一个能看的页面只需要几十秒，但要生成一个能上线、能维护、能扛住真实用户操作的页面，还需要评测、反馈、迭代这套“慢功夫”来兜底。WebCraftBench正是我在这个方向上的一个实践——它帮我看清了AI生成网页的真实水平，也让“打分”这件事变成了一种促进AI进步的反馈力量。如果你也在做AI生成前端方向，不妨试着用这套思路先跑一个自己的“小考卷”，测一测你手里那个工具的真实成色，实测出来的数据会给你完全不一样的判断。