80 个 canary 测试 6 个 vibe coding 平台 UI 都漂亮 后端能跑的没一个

最近 arxiv 上有篇挺扎心的论文叫 SWE-WebDev Bench，把市面上 6 个主流 vibe coding 平台拉出来正面 PK：Lovable、Replit Agent3、Vercel v0-Max、Base44、Emergent E1-OPUS、QwikBuild。一句话结论：所有平台 Engineering 综合分都没超过 60%，前端 UI 大家都做得漂亮，但后端、安全、生产就绪度集体翻车，没有一个能直接交付能跑的系统。下面把它怎么测的、测出了什么、为什么得看怎么用拆给你。先说一个利益冲突要点：论文 2 个作者来自 QwikBuild，AMR 修改场景的测试也只跑了 QwikBuild 一家，这个事论文自己披露了，下面会专门讲。

评测怎么做：3 维度 × 68 指标 × 6 平台

直接拿 LeetCode 那种小函数题考 vibe coding 平台没意义，因为这些平台标榜的是「一句话变上线产品」。SWE-WebDev Bench 的设计思路是把这些平台当成完整的「虚拟软件工作室」来评。

3 个维度切出整套评测。Mode 维度分 ACR（创建新应用）和 AMR（修改已有应用），AMR 是这篇论文新引入的。Angle 维度分 PM、Engineering、Ops 三个角色，分别看需求理解、代码质量、部署运维。Tier 维度分 T4 传统 SaaS 和 T5 AI 原生应用。

业务场景挑了 3 个真实领域：教育（ExamEdge 类考试系统）、现场服务（FieldOps 类巡检系统）、金融科技 + AI（VettAI 类风险评估系统）。68 个指标分 7 大组（G1 规格保真到 G7 生产就绪），25 个主指标加 43 个诊断指标。判分是 4 层金字塔，Tier 0 全自动（Lighthouse、k6、npm audit）占 40%，Tier 1 LLM 评分占 35%，Tier 2 LLM + 人工占 15%，Tier 3 专家组占 10%。

整套设计核心是看「平台能不能把模糊需求变成能上线的系统」，而不是看「能不能写出对的函数」。

4 个共性短板：所有平台都没逃掉

测完 6 家发现所有平台都掉同一批坑。

第一坑是规格压缩。同一个 prompt 给不同平台，PM 角色能问的澄清问题数从 0 到 15 不等，规格推断质量分 3.5 倍极差。最差的平台直接默默压缩需求开始写代码，用户根本不知道哪些细节被砍了。

第二坑是前后端脱钩。前端工程分大家都能做到 68-74%，UI 看起来都挺像那么回事。但后台跑批和定时任务（CBS）的得分从 0 到 49.3%，50 个百分点的极差。意思是几个平台的 UI 完全是「一张漂亮的壳」，按钮点下去后面没有任何真实工作流在跑。

第三坑是生产就绪悬崖。论文用 ETF（人工修复工时）和 CDI（声称功能 vs 真实功能差距）量化，ETF 从 12 工时到 60 工时，5 倍极差。CDI 高的平台会让你以为系统跑起来了，结果用户先于你发现 bug。

第四坑是安全全员翻车。Security Score 全员 38-65%，目标线是 90%。常见问题包括硬编码 API key、缺 CSRF 保护、没限流。并发负载分（CLS）只有 6-42%，目标线 70%。

所有 6 家在某个维度都有明显短板，但短板分布不一样。

Canary 设计：80 条文化特定需求看真懂还是拼凑

这篇论文最巧的设计是 canary requirements 这套方法。

Canary 就是埋在 prompt 里的特定要求，比如「日期格式必须是 DD/MM/YYYY」「金额要带泰铢符号 ฿」「必须支持泰文输入」。这种文化特定的、域内嵌入的细节，模型如果是真懂业务就会保留，如果只是拿训练数据里的模板拼，就会默默丢掉。

80 条 canary 分 4 种。Original 21 条是初始 prompt 里明确写的。New 37 条是 AMR 修改阶段新加的。Surviving 18 条是修改之后必须保留的。Contradiction 4 条是逻辑互相冲突的，看模型敢不敢质疑用户而不是闷头实现。

CRR（Canary 留存率）的 5.5 倍极差是这套方法测出来的最有信息量的指标。最高的平台留住 97.7%，最低的只留 17.7%，意味着用户花一小时写的需求描述，最差情况下有 80% 被默默删掉了。

6 平台 3 路线：架构选择决定短板长在哪

虽然所有平台都翻车，但翻车的姿势不一样。论文把 6 家归成 3 条架构路线。

路线一是基建一体化，代表是 QwikBuild。前端工程分 68%，后台跑批 49.3%，强项是真有完整后端基建在跑。短板还是规格理解不够细。

路线二是生态借力，代表是 Replit Agent3。前端 74.3%、后台 29.7%。靠 Replit 自己的开发环境生态，能拉外部服务，但跨域稳定性有限。Replit 在不同业务域上的得分极差 13 个百分点，说明对特定领域的泛化能力还不够。

路线三是前端优先，代表是 Vercel v0-Max 和 Lovable。前端工程也能做到 68%，但后台跑批 0-2%。这俩平台最大的问题是「漂亮 UI 给你信心，让你以为系统跑了」，等你拿到生产环境才发现按钮点下去后面什么都没有。

Base44 和 Emergent E1-OPUS 也参评，得分介于上述三档之间。论文里完整的指标对照表值得对照自己用过的平台看一遍。

利益冲突必须先看

这篇论文最关键的事是利益冲突。

论文 3 个作者里有 2 个来自 QwikBuild，QwikBuild 又是 6 个被评测平台之一。AMR（修改场景）的跨平台测试还没做完，目前只在 QwikBuild 一家上跑过完整的 AMR 评估，CAR 100%、回归率 0% 这些好看的数字都是单平台数据。

论文自己披露了这个 COI，做了 G1 指标的盲评（评分人不知道是哪个平台的代码），也专门列出了 QwikBuild 的失败点。但完全的双盲没做到。第三作者 Saxena 独立设计了 prompt 和 canary，这是降低 COI 影响的另一个机制。

读这篇怎么用：80 个 canary 的方法论、3 维度的评测框架、4 个共性短板的发现可以放心抄。具体平台排名建议自己复现一次再下结论。论文承诺会做成 living benchmark，每季度重测，未来版本要换独立评测员。

一句话抓重点

vibe coding 这一波平台目前都还在「Demo 阶段」，UI 能给老板演示，但拿到生产环境都需要 12-60 小时的人工修复。SWE-WebDev Bench 提供的不是「该买哪家」的答案，是「评估任何 vibe coding 平台时该看哪些指标」的脚手架。

适合谁看：在选 vibe coding 平台的产品经理、CTO、独立开发者；想做 AI 编程产品的创业者，看完知道哪些短板可以做差异化；做 LLM 评测的研究者，可以参考 canary 方法论。

不适合谁：纯爱好者随便玩 demo 的话不用看这么细，看完反而焦虑。

完整论文：arxiv.org/abs/2605.04637 仓库 github.com/snowmountainAi/webdevbench。

论文叫 Evaluating Coding Agent Application Platforms as Virtual Software Agencies，作者 3 人，2 人来自 QwikBuild 团队，第三作者 Saxena 负责 prompt 和 canary 设计。