SWE-WebDevBench：把 AI 应用生成平台当作虚拟软件公司来评估 SWE-WebDevBench: Evaluating Coding Agent Application Platforms as Virtual Software Agencies
提出 68 指标框架，揭示六大 vibe coding 平台在规范理解、后端基础设施、生产可用性和安全上的系统性短板。
前置知识
Vibe coding
Andrej Karpathy 提出的概念，指用户用自然语言描述需求，由 AI 智能体自主完成全栈软件的设计、编码和部署。它把软件开发的入口从代码移到了语言描述，目标用户是非技术人群。
本文评测的就是这类平台（Replit、Lovable、v0-Max 等），如果读者没听过 vibe coding，就无法理解为什么 SWE-bench 那类代码级 benchmark 不够用。
LLM-as-Judge（用大模型当裁判）
用一个强 LLM（如 Claude）按结构化 rubric 给被评估对象的输出打分的做法。优点是可扩展，缺点是存在位置偏置、长度偏置、自家偏置等系统性问题。本文用 Tier 分层来缓解这些偏置。
SWE-WebDevBench 的 Tier 1/2 指标都依赖 LLM judge，理解其偏置来源才能看懂为什么作者把高风险主观指标（BIF/ETF/FGD）划到 Tier 3 专家小组。
KPI 多维评测立方体（Evaluation Cube）
用正交的多维度把评测空间切成互不重叠的格子，让每个评测单元只承担一种变量的影响。本文用「交互模式 × 代理角色 × 复杂度档」三轴切出 18 个评测单元（2×3×3 的子集）。
这是 SWE-WebDevBench 区别于 SWE-bench 的方法论核心，不理解多维结构就读不懂为什么 ACR/AMR 要分开打分。
Canary Requirement（金丝雀需求）
嵌入在主需求里的细微、文化特定、易被模板匹配系统忽略的测试要求，例如「日期用 DD/MM/YYYY、金额按 INR lakhs 写」。它用来分辨平台是真正理解需求还是只套模板。
Canary Retention Rate（CRR）是本文最尖锐的指标之一，揭示出 v0-Max 之类平台在 80% 的细节上会悄悄丢失用户要求，这是现有 benchmark 看不出来的。
研究动机
现有的 AI 编程评测框架（HumanEval、SWE-bench、FeatBench、Vibe Code Bench、WebGen-Bench 等）只能覆盖软件开发全过程的某个切片：HumanEval/SWE-bench 要的是函数签名或代码补丁输入，FeatBench 测的是「修 issue」能力，Vibe Code Bench 测的是 100 条 web 规格下的端到端工作流。这些 benchmark 至少存在三个共性短板：（1）输入端假定「规格已给好」，无法评测 vibe coding 中「由自然语言推断需求」的关键环节；（2）只看代码补丁或单页应用，不评估完整多角色 SaaS 的生产可用性（部署、安全、并发、本地化、商业就绪）；（3）完全不区分首次创建（ACR）和后续修改（AMR）这两种根本不同的工作模式，而 FeatBench 已经发现 73.6% 的修改任务会破坏既有功能。结果是：vibe coding 用户（非技术人）信任平台声明的「应用已就绪」，但没人能告诉他们生成的软件到底能不能上线。
本文的目标是本文要回答一个更完整的问题：vibe coding 平台能否像一个完整的「虚拟软件公司」一样工作——理解商业意图、澄清歧义、做出合理架构决策、写出可上线代码、承受迭代修改？为此，作者构建 SWE-WebDevBench，一个 68 指标评测框架（25 主指标 + 43 诊断指标，跨 7 个指标组），并按 3 个正交维度组织评测：交互模式（ACR vs AMR）、代理角色（PM × 工程 × 运维）、复杂度档（T4 多角色 SaaS / T5 AI 原生应用），最终用 6 个标准化 prompt × 3 个业务领域 × 6 个平台 = 18 个评测单元来暴露行业共性短板。
与已有工作不同的是，SWE-WebDevBench 的独特切入角度是「平台即软件公司」这一隐喻：之前的 benchmark 把 AI 当成「写代码的工具」，本文把平台当成「承担 PM+工程师+SRE 全套职责的乙方」。由此衍生三个方法论创新：（1）首次明确区分 ACR（App Creation Request）和 AMR（App Modification Request），用 24 条 canary 需求（含「存活型」和「矛盾型」）跟踪需求在迭代过程中是否被保留或正确演化；（2）四层裁判体系（Tier 0 全自动 → Tier 3 三人专家组），把 LLM judge 的偏置控制在低风险任务，把高风险主观判断留给专家；（3）把诊断指标（43 条 process-level 指标）和主指标配对，使得低分可以被归因到「PM 没问清」「工程没写对」「部署没上线」的具体环节，benchmark 因此具备了可操作性而不只是排名表。
核心方法
SWE-WebDevBench 的整体思路是：先按三个正交维度（交互模式 / 代理角色 / 复杂度档）切出评测空间，再为每个评测单元装上 68 个可观测的指标，最后用一个 7 阶段、共 14 天的协议来跑完所有指标。它的核心方法论创新是「诊断而非仅打分」：每条主指标（测交付了什么）都配诊断指标（追踪为什么成功或失败），并且引入 canary 需求来分辨「真理解」与「模板匹配」。直觉上，它像一次对 AI 平台的「端到端软件交付审计」：先把 prompt 喂给平台（构建阶段），再对生成的代码做静态/动态/安全审计（质量阶段），再用 k6 跑并发、用 Lighthouse 跑 SEO、用 npm audit 跑漏洞（基础设施阶段），再对修改请求做回归测试（变更阶段），最后由专家小组评 PM 表现、改造成本和声明可信度（商业就绪阶段）。
和已有 benchmark 的本质区别在于「评测对象的提升」。SWE-bench 评测的是「单 issue 修复」，FeatBench 评测的是「单特性添加」，Vibe Code Bench 评测的是「单页 web 应用功能是否跑通」。SWE-WebDevBench 评测的是「平台是否具备完整软件公司能力」——它同时考察：PM 是否问对了问题（Inference Quality Score 20–70 跨平台差 3.5 倍）、工程代码是否安全可扩展（SS ≤ 65%，CLS 6%–42%）、生成的应用在迭代中是否退化（ACR→AMR 系统性下降 1–14pp）、平台对自身的声明有多可信（CDI 4%–35.7%）。因此它的「创新」不是单点技术，而是把 vibe coding 这个新兴产品形态拆成可观测、可归因、可改进的诊断工具。
方法步骤详情
7 阶段协议对每平台×prompt 跑约 14 天：(1) Build Execution 提交 prompt 并记录构建轨迹与部署状态；(2) Code Quality Audit 用 Claude 3.5 Sonnet 按 Schema/Backend/Frontend/Hygiene/Architecture 五维打分；(3) Integration & Security Testing 跑集成、后台、k6 负载与 npm audit；(4) Feature & Canary Testing 人工核验功能完整度与 80 条 canary 保留率；(5) AMR Change Injection 把修改 prompt 喂给已部署应用，按变更影响、回归、改造成本打分；(6) Human Panel 三名专家按 rubric 评 PM 行为、改造成本与声明漂移；(7) Diagnostic Scoring 从对话日志提取 43 条诊断指标。工程分取 G2–G6 适用指标加权均值。指标按 4 档分裁判：Tier 0 全自动→Tier 3 三人专家组，平台身份对 LLM judge 隐藏。
技术新颖性
本文四个新颖性。第一，用 canary 需求和 PM 指标（IQS 20–70）把「AI 是否真懂需求」量化；PM 投入只解释 10–15% 质量差距，更大差距来自构建期反馈环。第二，把架构策略分为 Infra-Integrated、Ecosystem-Leveraged、Frontend-Prioritized 三档聚类与指标谱系对应。第三，ACR/AMR 分离 + Surviving Canary：18 条 surviving canary 跟踪需求在修改中是演化还是丢失，surviving 类型 partial-loss 率是 new 的 3 倍。AMR 的 Adaptive Coherence Score 为 $\text{ACS} = 0.5 \times \text{Existing}_{ok} + 0.5 \times \text{Change}_{correct}$，把既有功能与新需求合起来测。第四，43 条 process-level 诊断指标与主指标配对让低分可归因到具体环节，v0-Max P3 上 SDS=0% 配 FES=72% 极化归因到「前端优先」策略。
实验结果
对 18 评测单元（6 平台 × 3 域）的实测给出 4 大共性短板。发现 1 规范瓶颈：CRR 17.7%–97.7% 跨 5.5×，IQS 20–70 跨 3.5×，PM 提问 0–15 轮；6 平台都检测到 P2 明示矛盾但仅 3 家会问用户。发现 2 前端-后端解耦：4 平台 FES 紧（68–74%），CBS 跨 50pp（0%–49%），v0-Max P3 SDS=0% 配 FES=72% 是最尖锐样本。发现 3 生产就绪悬崖：无人工程分超 60%，ETF 跨 5×（14.7–65.7h），QwikBuild 12h+0 re-prompt vs Base44 60h+8 re-prompts+5h 修改。发现 4 安全失败：SS 最高 64%（目标 90%），CLS 最低 6%；常见漏洞有硬编码 API key、缺 CSRF、缺限流、JWT 过期不一致。AMR 预实验（仅 QwikBuild）显示 16/19 指标从 ACR 退化到 AMR，CBS −24.3pp、CRR −14pp 最严重，但 P6 Provider Swap 实现首次 AIA PASS。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| P1 ExamEdge 教学辅导 SaaS（T4 多角色） | Engineering Score (%) | QwikBuild 57.5% / Emergent 39.9% / Replit 41.5% | Lovable 39.1% / Base44 30.2% / v0-Max 22.8% | 第一名比最后一名高 34.7pp（57.5% vs 22.8%），全部未达 60% 目标 |
| P2 FieldOps 现场服务系统（T4，含 10 态工单/GST 发票/SLA） | Engineering Score (%) | QwikBuild 55.6% / Emergent 53.8% / Lovable 49.3% | Replit 47.4% / Base44 33.5% / v0-Max 26.2% | 第一比最后高 29.4pp，6 平台都在 P2 上比 P1 表现更好（说明详细 RFP 比含糊需求更容易做对） |
| P3 VettAI 金融 AI 审核（T5 AI 原生） | Engineering Score (%) | Replit 54.5% / QwikBuild 50.3% / Emergent 47.1% | Lovable 39.0% / Base44 28.0% / v0-Max 26.4% | Replit 在 P3 上比 P1 高 13pp，呈现显著领域倾向；v0-Max SDS=0%（P3 极化案例） |
| 规范保真度（跨平台 ACR 平均） | Canary Retention Rate (%) | QwikBuild 97.7% / Emergent 57.0% / Replit 54.0% | Base44 24.3% / Lovable 21.7% / v0-Max 17.7% | 第一是最后 5.5 倍；目标 80%，仅 1 平台达标 |
| 后台任务（跨平台 ACR 平均） | Cron & Background Jobs Score (%) | QwikBuild 49.3% / Replit 29.7% / Emergent 20.3% | Base44 15.0% / Lovable 2.0% / v0-Max 0.0% | 50pp 极差；目标 90%，0 平台达标 |
| 生产就绪（跨平台 ACR 平均） | Security Score (%) | QwikBuild 63.7% / Lovable 51.7% / Emergent 50.7% | Replit 40.0% / v0-Max 34.3% / Base44 31.3% | 目标 90%，最高仅 63.7%，缺 26.3pp；CLS 更糟，最低 6%（v0-Max） |
局限与改进
作者明确承认 6 项局限：（1）作者关联性——2 位作者隶属被评 QwikBuild，benchmark 对 PM 行为维度的强调可能偏向有专门 PM Agent 的平台；AMR 仅完整测 QwikBuild 一家。（2）单评估者偏置——G1 用三人专家组，但多数代码质量指标仍依赖 LLM judge+人工验证。（3）小样本——18 评测单元无统计显著性检验，作者多次强调 descriptive of our sample；估计需 15–20 prompts × 5–7 域才能在 d≥0.5 下达到 power 0.8。（4）平台版本敏感——2026 年 2–3 月快照结果未必能复现。（5）AMR 跨平台数据有限。（6）非盲评估——评估者知道哪个平台生成哪个输出，约 60% 的 Engineering Score 来自 Tier 1–3 主观判断。我的额外观察：QwikBuild 在 G1 三指标上几乎全胜但同时 SWS 全场最差（9.3%）、CLS 42%、CHS 52.8%，「赢在 spec、输在基础」极化提示 PM 投入与工程质量的解耦，关联作者评估的结果可信度需谨慎。
独立分析的弱点
独立分析 4 个最值得关注弱点。弱点 A：canary 需求设计可被反向工程——80 条 canary 集中在印度场景（INR、JEE/NEET、DD/MM/YYYY、GST），平台供应商硬编码这些字符串就能拉高 CRR 而不真正理解需求；改进方向是动态生成 canary（每次评测随机换文化背景）。弱点 B：6 prompts 对「修改」诊断粒度不够——AMR 只有 3 条（复杂/中等 × 详细/含糊），无法覆盖「删除功能」「重命名接口」「修改既有 UI」等常见修改；改进方向是引入回归型 AMR prompt 并对全部 6 平台都跑 AMR。弱点 C：SS ≤ 65% 结论可能低估真实风险——评分用 LLM judge + 抽样工具，平台可专门训练通过这种 judge；改进方向是引入红队测试和动态漏洞注入。弱点 D：CDI 4%–35.7% 的声明漂移意味着平台自我报告的完成度与实际差距巨大，而 vibe coding 用户正是不读代码的人，改进方向是要求平台输出结构化 acceptance test 自检。
未来方向
作者明确呼吁的未来工作有 4 条：（1）社区独立复制——任何研究者用公开的 prompt/rubric/打分协议即可对其他平台打分，结果经核验后入公开 leaderboard；（2）扩 prompt 套件——到 15–20 prompts × 5–7 域以达到统计稳健性；（3）季度再评——跟踪主流平台随版本演进的改进轨迹；（4）AMR 跨平台评测——把 AMR 协议在所有 6 平台上跑通。基于结果我看到 3 个可延伸方向：（a）T1–T3 简单应用评测——目前 T4/T5 可能偏向复杂平台，T1–T3（如单页落地页）能揭示 v0-Max 类前端优先平台的优势；（b）多模态 prompt——加语音/截图 prompt，测真实非技术用户的输入分布；（c）经济性纵深——TCC 现在只算货币成本，可以扩展到「总拥有成本（TCO）」含运维、故障恢复、扩展性，把 benchmark 变成 CTO 选型工具。
复现评估
可复现性评估整体良好但有关联性风险。开源情况：完整代码与 prompt 在 GitHub（snowmountainAi/webdevbench）和 webdevbench.com 公开，含 6 prompts、80 canary 规格、9 个 LLM judge prompt 模板、原始打分 CSV、评估 rubric 和去标识脚本。数据：3 业务域 × 1–2 prompt/域 = 6 条；80 canary 跨 4 类（Original 21 / New 37 / Surviving 18 / Contradiction 4）。算力：未明确披露总成本，18 单元 × 7 阶段 × 4 档裁判可粗估数万次 Claude 3.5 Sonnet 调用 + k6 + Lighthouse + npm audit，单评估者约 8 个月单人月。难度：技术上中等。最关键风险是 AMR 部分仅在 QwikBuild 测过且由关联作者评分；6 prompts × 3 域小样本使得换 prompt 风格可能改变排名。
论文图表
4 个平台在 P1 上的真实对话片段：QwikBuild 3 轮 15 问（含教师-学生关系、出勤编辑窗口、leaderboard 算分），Emergent 2 轮 5 问全是基础设施配置（SMS/Email/Auth），Replit 0 问直接构建，v0-Max 2 轮 4 问 plan mode。
把 PM 行为差异从数字变成可读对话，揭示「问什么」比「答什么」更决定产品质量。