返回评测
代码生成 代码-工程交付 未饱和 模态 · 代码 任务 · 执行验证

SWE-WebDevBench

将 AI 编码平台作为虚拟软件机构评估，68 指标覆盖产品/工程/运维三维度

BaseThesis Labs & QwikBuild ·

考察能力

全栈开发 业务需求理解 架构决策 安全评估 运维就绪度 迭代修改

构建信息

数据规模
68 项指标 (25 核心指标 + 43 诊断指标)，6 个平台，3 个领域，18 个评估单元
构建方式
三维度组织：交互模式(ACR/AMR) × 代理视角(PM/工程/运维) × 复杂度层级(T4/T5)
评测方式
Canary Requirements 方法论，80 个文化特定领域嵌入式测试需求
核心指标
Engineering Score (%) / Security Score (%)

资源链接

论文: arXiv:2605.04637 代码: github.com/snowmountainAi/webdevbench 官网

模型效果排行

🥇 Lovable
工程<60% / 安全<65% 2026-05
🥈 Replit Agent
工程<60% / 安全<65% 2026-05
🥉 Vercel v0
工程<60% / 安全<65% 2026-05
4. Bolt.new
工程<60% / 安全<65% 2026-05
5. QwikBuild
工程<60% / 安全<65% 2026-05
6. LlamaCoder
工程<60% / 安全<65% 2026-05

为什么重要

SWE-WebDevBench 是首个将 AI 编码平台作为虚拟软件机构进行评估的基准。当 SWE-bench 等基准只测”AI 能不能修 bug”时，SWE-WebDevBench 问的是更根本的问题：AI 能不能像一个真正的软件公司一样运作？——理解业务需求、做架构决策、写出生产级代码、处理迭代修改、保证安全与运维就绪。这对”vibe coding”时代的平台选型具有直接指导意义。

构建方式

  1. 68 项评估指标：25 项核心指标 + 43 项诊断指标，覆盖 7 个维度
  2. 三维度组织：
    • 交互模式：应用创建请求 (ACR) vs 应用修改请求 (AMR)
    • 代理视角：产品经理 (PM) / 工程 / 运维
    • 复杂度层级：T4（多角色 SaaS 应用）/ T5（AI 原生应用）
  3. Canary Requirements：80 个文化特定、领域嵌入式的测试需求，区分真正理解还是模板响应
  4. 四级判定分类：从”完全满足”到”完全未满足”的细粒度评分
  5. 6 个平台 3 个领域 18 个评估单元的完整交叉评测

关键发现

  • 四大共性缺陷：
    1. 需求规约瓶颈：平台将丰富的业务需求压缩为过度简化的技术方案
    2. 前后端普遍脱节：视觉精美的 UI 背后是缺失或故障的后端基础设施（BackgroundJob 得分 0%-49%）
    3. 生产就绪度断崖：所有平台工程质量得分均低于 60%，不同平台所需人工后期投入差异显著
    4. 安全与基础设施普遍失效：安全得分最高仅 65%（目标 90%），并发处理能力低至 6%
  • 前端光鲜≠后端可用：所有平台都能生成”看起来不错”的 UI，但后端能力普遍不足
  • ACR vs AMR 差异大：创建新应用的表现普遍优于修改已有应用
  • T5 (AI 原生) 比 T4 (SaaS) 更难：AI 原生应用的复杂度对各平台挑战更大

最新进展

  • 2026-05：arXiv 预印本发布 (arXiv:2605.04637)，首次系统揭示 vibe coding 平台的真实能力边界
  • 2026-05：开源评测框架及基准资源 (GitHub + webdevbench.com)
  • 关键趋势：vibe coding 平台更适合快速 UI 原型而非生产级应用，人类工程师仍是不可或缺的

关联基准

不足与展望

  • 当前仅覆盖 6 个平台，需更大规模验证以确立普适性
  • 评估平台而非模型，评测维度与传统模型基准不同
  • 两位作者供职于被评测平台之一 (QwikBuild)，虽已披露但仍存潜在利益冲突
  • 平台持续更新，评测结果时效性有限，需定期重评
  • 未覆盖非英文市场和中国本土 vibe coding 平台
全栈开发 vibe coding 平台评估 安全 生产就绪度