为什么重要
代码基准正面临严重饱和问题——HumanEval (99.4%)、MBPP (94.2%)、EvalPlus (89.0%) 已接近或超过天花板。Web-Bench 填补了一个关键空白：真实 Web 开发中的项目级编程评测。SOTA 仅 25.1%，远低于 SWE-bench Verified (65.4%)，说明 LLM 在结构化 Web 项目开发上仍有巨大提升空间。
更重要的是，Web-Bench 是首个系统性覆盖 Web 标准（DOM、BOM、CSS、SVG、Canvas、ECMAScript、TypeScript）和 Web 框架（React、Vue、Redux、Tailwind、Next.js、Prisma）的评测基准，填补了现有代码基准偏重算法/后端而忽视前端开发的缺陷。
构建方式
- 项目设计：由 5-10 年经验的前端工程师人工设计 50 个独立 Web 项目，覆盖 8 类业务场景（购物、博客、表格、画板、小游戏等）
- 任务分解：每个项目分解为 20 个具有顺序依赖性的任务，模拟真实开发工作流——前一个任务的输出是后一个任务的输入
- 标准覆盖：系统覆盖 Web Standards 和 Web Frameworks 两大维度
- 难度校准：工程师定性为中低难度，但 LLM 表现远低于预期，说明当前模型在项目级任务上能力不足
- 评估流程：Docker 容器化环境 → 代码生成 → 环境初始化 → 构建检查 → Playwright 端到端测试
关键发现
- SOTA 仅 25.1%：Claude 3.7 Sonnet (thinking) 在 Web-Bench 上的 Pass@1 仅为 25.1%，远低于其在 SWE-bench Verified 上的 65.4%，说明 Web 开发对 LLM 而言是更难的挑战
- 闭源模型仍占优：闭源模型平均 Pass@1 为 15.08%，开源模型为 10.73%，差距约 4.4 个百分点
- 思考模式有效：启用 thinking 后模型表现普遍提升，Claude 3.7 Sonnet thinking vs non-thinking 差距显著
- Scaling Law 成立：同一系列中，参数更大的模型通常表现更好
- 顺序依赖是难点：任务之间的依赖关系导致错误累积，一个早期任务的失败会影响后续所有任务
- Web 标准 > 框架难度：纯 Web 标准任务（CSS、DOM）比框架任务更难，说明 LLM 对底层 Web 技术理解不足
评测指标
- Pass@1：首次尝试通过的任务比例（主要指标）
- Pass@2：允许一次重试后的通过率（重试时可获知上次错误）
- pass_tasks@1：首个失败任务之前的连续成功任务数
- pass_tasks@2：所有任务的重试通过总数
局限性
- 当前仅支持 JavaScript/TypeScript 项目
- Web-Agent 作为标准评测代理，不同 Agent 架构可能产生不同结果
- 50 个项目虽覆盖面广，但某些细分领域（如 WebGL、WebRTC）未涉及
- 随 LLM 能力提升，基准可能需要升级任务难度
关联基准
- SWE-bench Verified：Python 仓库级代码修复
- HumanEval：单函数代码生成（已饱和）
- BigCodeBench：多语言代码生成
- WebGen-Bench：网站生成评测（从零创建网站）
编者评
Web-Bench 的价值不仅在于它填补了前端代码基准的空白，更在于它揭示了 LLM 编程能力的真实瓶颈。25.1% 的 SOTA 告诉我们：在真实项目级开发中，LLM 的表现远不如算法竞赛或单函数生成中的成绩那么亮眼。顺序依赖的任务设计尤其精妙——它模拟了真实开发中”一步错步步错”的困境，这是 HumanEval 等基准完全无法测量的维度。字节跳动前端团队基于工程实践构建基准的思路，值得其他基准开发者借鉴。