这项由BaseThesis Labs与QwikBuild联合开展的研究发表于2026年5月以arXiv预印本形式公开编号arXiv:2605.04637v1研究方向为多智能体系统评测。有兴趣深入了解的读者可通过该编号查询完整论文。近年来一种叫做氛围编程vibe coding的新方式正在悄悄改变软件开发的版图。你不需要会写代码只需要用中文或英文描述你想要什么样的应用程序AI平台就会自动帮你生成一整套可运行的软件系统。Lovable、Replit Agent、Vercel v0这些平台纷纷宣称原本需要一个团队花几个月才能完成的工作现在几分钟就能搞定。听起来像魔法对吗然而这些平台生成的软件真的靠谱吗能不能直接用于正式商业环境这正是这项研究要回答的核心问题。研究团队构建了一套名为SWE-WebDev Bench的评测框架用68个维度的指标对六大主流AI建站平台进行了全面体检结果揭示出四个令人警觉的共同问题。值得注意的是研究团队中有两位作者供职于被评测的平台之一QwikBuild他们在论文中坦诚地披露了这一潜在利益冲突并采取了一系列措施加以规避。一、为什么我们需要一套全新的评测标准在这套框架出现之前评判AI写代码能力的主流方式大致分为三种路子。第一种是函数级测试比如业界知名的HumanEval它给AI出一道道算法题看AI能不能写出正确的函数——但这种测试需要提供非常详细的技术规格说明与用自然语言描述需求的氛围编程完全不是一回事。第二种是补丁测试代表是SWE-bench它让AI去修复真实的GitHub代码问题测的是AI的代码修复能力而不是从零开始造应用的能力。第三种是新兴的应用级测试包括Vibe Code Bench、WebCoderBench等它们开始评测整个应用程序的生成质量但普遍缺少对产品经理行为也就是AI理解业务需求的能力的评估也不测试对已有应用进行修改的能力。SWE-WebDev Bench的设计初衷正是要填补这些空白。研究团队把整个评测框架比作审查一家虚拟软件公司一个真正的软件公司需要有产品经理来理解客户需求有工程师来写出高质量的代码还有运维团队来确保系统稳定运行。以往的测试只盯着工程师这一个环节而新框架把三个环节都纳入了考察范围。二、这套评测框架是如何设计的研究团队构建了一个评测魔方从三个互相独立的维度切入对AI平台进行全方位考察。第一个维度是交互模式。研究区分了两种截然不同的任务类型一种是从零建应用ACRApp Creation Request即让AI从一段自然语言描述出发完整构建一个新应用另一种是修改已有应用AMRApp Modification Request即让AI在已经生成的应用基础上进行迭代更改。这个区分非常关键因为现实中用户几乎不会只用一次AI——他们会不断提出修改意见而修改本身的难度远高于从零创建。此前没有任何平台基准测试区分过这两种模式。第二个维度是角色视角。评测从三个角色的视角分别考察平台表现产品经理视角关注AI是否真正理解了业务意图、是否发现了需求中的矛盾工程师视角关注代码质量、安全性、架构设计运维视角关注部署稳定性、性能和监控。第三个维度是复杂度层级。评测划分了两个档位T4代表具有多角色权限管理、定时任务、多系统集成的典型商业SaaS应用T5代表包含AI流水线、信任安全约束和多供应商切换的AI原生应用。在这三个维度之外整个框架还包含25个主要指标和43个诊断指标合计68个维度。主要指标衡量结果如何诊断指标则追问为什么会这样。四个层级的评判方式从全自动化测试比如用Lighthouse扫描网页性能、用k6做压力测试到专家小组主观评分按照适用场景分层使用。三、金丝雀需求一把测出AI真实理解力的特殊量尺研究团队在设计评测提示词时埋入了一种特别的测试机关——金丝雀需求Canary Requirements。这80条需求专门设计成具有文化特异性和领域专属性的细节要求比如日期格式必须用DD/MM/YYYY而不是MM/DD/YYYY、金额单位用印度卢比、符合JEE/NEET考试的评分惯例等。为什么要这样设计因为一个只会套模板的AI平台很容易生成一个看起来像样的通用SaaS应用但遇到这些具体的文化细节时它往往会悄悄忽略掉用默认的西方惯例代替。用户如果不懂代码根本不会发现这些静默违规。金丝雀需求就像矿井里的金丝雀一旦它死了即需求没有被正确实现就说明AI并没有真正理解用户的意图只是在走形式。这80条需求被分为四种类型。原始型21条是明确说明的约束条件新增型37条是在修改阶段新引入的需求存活型18条是在从零建应用阶段就存在、理论上应该在后续修改中被完整保留的需求矛盾型4条则是故意设置的互相冲突的需求用来测试AI是否能识别并主动向用户提示冲突。四、参与测试的六个平台和三个业务场景研究团队选取了六个代表不同技术路线的主流平台参与测试Base44采用低代码生成方式平均只向用户提出1个问题EmergentE1-OPUS采用代理式架构配合配置问答平均提5个问题LovablePlan Mode先生成计划再构建平均4个问题QwikBuild采用多智能体架构并配备专属产品经理代理平均提15个问题ReplitAgent3完全自主运行平均只提0.3个问题v0-MaxVercel单次生成平均1.3个问题。测试用了三个业务场景作为靶标每个场景都刻意设计成能暴露不同类型弱点的诊断探针。第一个场景是ExamEdge Academy教育科技领域提示词写成一个深夜创业者发WhatsApp消息的语气充满口语化和情绪化表达完全没有出现CMSRBACSaaS这类专业词汇而是用一切都靠WhatsApp群和Google表格我快崩溃了来描述痛点。这个场景专门测试AI能否从模糊的痛点描述中推断出产品结构同时还埋入了一个矛盾老师不应该看到其他分校的数据但同时又要有一个显示所有分校前10名学生的跨校排行榜。一个合格的产品经理代理应该发现并主动询问如何解决这个矛盾。第二个场景是FieldOps Pro现场服务管理领域提示词是一份极度详尽的企业需求说明书包含10种工单状态的切换逻辑、SLA服务等级协议的暂停与恢复机制、配件库存的自动补货触发器还有一个明确标注了这是矛盾的测试项先说评分不应该对技术人员可见又说我希望技术人员能看到评分以便学习并且明确要求系统应该标出这个矛盾并询问我要哪种行为。第三个场景是VettAI金融科技AI领域难度最高测试AI能否生成一个安全可审计、对不确定性诚实的AI分析应用。这个场景包含多阶段AI分析流水线、蒙特卡洛风险模拟、AI视觉识别扫描文件以及严格的信任安全要求——不能捏造数据、必须显示置信度评分、风险评分超过8分时必须强制弹出红色警告横幅等。五、测试结果一所有平台都在需求理解这一关卡壳了测试结果揭示的第一个、也是最普遍的问题研究团队称之为规格说明瓶颈。大多数平台在接收到用户描述后会把丰富的业务需求压缩成一个过于简化的技术计划大量业务细节在这个过程中悄悄蒸发掉。金丝雀需求保留率CRR这个指标最能说明问题。六个平台的这一数值从17.7%到97.7%不等差距高达5.5倍。也就是说在最糟糕的情况下AI平台把100条具体的业务细节需求塞进去出来的时候只有不到18条被正确实现了其他的全部悄悄消失而用户完全不知道。关于这个维度最能说明问题的是各平台面对同一个ExamEdge提示词时的截然不同反应。某平台的产品经理代理进行了6轮对话、提出15个具体业务问题比如一个班级的学生同时有物理、化学、数学三个老师师生关系应该怎么建立以及如果老师忘记当天签到后面还能补录吗。它最终生成了一份12个章节的产品需求文档包含产品概述、版本范围、角色定义、数据模型、后台任务、验收标准等内容。而另一个平台提了4个问题全部是技术配置问题比如用Twilio还是Mock做短信、用JWT还是谷歌登录做认证——没有一个问题涉及业务流程直接开始构建而且完全没有发现提示词中的矛盾。还有平台连一个问题都没问立刻输出一个17项功能列表直接开始干活同样没有发现任何矛盾。那个明确标注了这是矛盾的P2场景六个平台都检测到了这个矛盾但后续处理方式差异显著。有的平台检测到矛盾后还是把应用里一半的核心功能SLA引擎、审计追踪、发票系统、工时记录、客户签名推迟到未来版本生成了一个严重残缺的现场服务应用有的平台标出矛盾后给出了三个解决方案让用户选择并把用户的选择整合进产品文档再开始构建有的平台检测并提供了结构化选项然后就开始拼命赶进度在10分37秒时超时用户反馈我花了很多人工努力才让它完成。P1场景中那个没有明确标注的矛盾老师不能看到其他分校数据但又要有跨分校排行榜更能说明真实情况只有一个平台通过深入追问权限规则主动发现了这个矛盾其余五个平台全部把这个矛盾静默地嵌入代码生成了有隐藏逻辑冲突的应用用户在实际使用前不会察觉。研究团队还做了一个有趣的观察即使是提问数量为零、完全不进行业务沟通的平台其计划文档的结构有时也显得颇为完整。某平台在没有任何用户互动的情况下自动生成了含有意图与目标、受众与角色、核心流程和不做什么章节的计划文档——结构看起来很正规但所有假设都未经验证。这导致该平台的声称构建与实际构建之间存在35%的差距也就是说它在仪表盘上声称已经完成的功能有35%实际上并不正常工作。这对于看不懂代码的普通用户来说是个隐患你以为应用已经完工了实际上坑还没踩完。六、测试结果二界面好看不代表后端能用第二个发现研究团队称之为前后端解耦问题简单说就是AI平台特别擅长做漂亮的界面但后端基础设施往往严重缺失。在前端工程评分这个维度上四个平台的得分相差不超过6个百分点61%到74%之间说明UI生成已经是一个相当成熟的能力。但在定时任务与后台作业评分CBS这个维度上平台之间的差距高达49个百分点——最好的是49%最差的是0%。一个后台作业评分为0%的平台意味着它根本就没有实现任何能够自动运行的后台任务那些需要定期执行的业务逻辑比如每天生成报表、到期提醒、自动同步数据全部缺失。研究根据各平台的技术策略归纳出三种截然不同的建站风格。第一种是基础设施集成型平台本身提供了数据库、任务调度器、存储空间等预构建模块AI生成的代码不需要自己实现基础设施调用现成模块就行。这种策略在前端和后端上都保持了相对均衡的表现CBS达到49%是六个平台中最高的——但离90%的目标仍然差得远。第二种是生态系统借力型平台借助npm生态中丰富的开源库比如passport做认证、prisma做数据库、node-cron做定时任务来搭建后端基础设施。这种策略有时能达到不错的效果但稳定性欠佳在复杂场景下后台任务的可靠性会明显下降。第三种是前端优先型平台生成的应用视觉呈现非常精美但后端基本是空架子。某个平台在最复杂的金融科技场景下数据库结构得分为0也就是说根本就没有设计数据库后台作业得分也是0但界面的前端工程得分却有72%。Emergent平台的案例是个典型的华而不实范例。它为VettAI场景生成了一个有动态过渡效果的精美入职流程连暂无案例点击导入客户文件开始使用这样的友好空状态提示都做到了还有符合印度SEBI格式的注册信息校验前端工程评分68%。然而因为平台存在一个共性的组件缺陷组件崩溃核心的案例管理功能完全无法使用。打开前30秒你会以为这是一个精致的产品真正使用的前3分钟你就会发现它是坏的。这个案例生动说明了一个普通用户极难自行发现的风险视觉上的精良造成了虚假的产品就绪假象。七、测试结果三每个平台都需要大量人工修补才能真正上线第三个发现研究团队称之为生产就绪悬崖——没有任何一个平台的工程评分超过60%而且每个平台都需要大量的人工修补才能让AI生成的应用真正可用于正式环境。以最简单的EdTech场景为例各平台从生成完成到应用可以正式上线需要的额外工作量差距高达5倍最少的平台只需要12个开发工时0次重新提示0次手动代码修改最多的平台需要60个开发工时8次重新提示还需要5小时的人工代码编写。即使是表现最好的平台仍然在绝大多数指标上未能达到目标值。功能缺口指标FGD用开发工时来衡量需要手动补充实现的缺失功能同样差距悬殊最好的平台只有5小时的功能缺口最差的有41.7小时。而声称漂移指数CDI衡量平台自我报告的完成度与实际工作功能之间的差距百分比同样引人注目最低的平台只有4%的声称漂移最高的有35%。也就是说某些平台的仪表盘显示应用已完成但实际上三分之一以上的功能是假的。对于完全依赖平台报告来判断应用状态的非技术用户而言这是个严重的信任问题。研究还发现了一个有意义的规律减少声称漂移对平台整体价值的提升可能不亚于提升代码质量本身。声称漂移低的平台用户能够准确知道哪里是坏的调试和修复都更高效声称漂移高的平台用户首先需要花大量时间自己摸索哪里其实没做好这个额外的发现开销会叠加在本就不小的修复工作量之上。八、测试结果四安全漏洞是全行业的通病第四个发现也是研究团队认为最令人担忧的一个在安全性方面没有任何一个平台通过了测试全部远低于90%的安全评分目标最高的只有64%最低的只有34%。常见的安全问题包括API密钥被硬编码进前端代码任何人都可以直接在浏览器开发者工具里看到、缺少CSRF跨站请求伪造保护、没有限流机制意味着任何人都可以用脚本无限次调用接口、存在可被枚举的公开接口比如可以通过ID遍历猜出所有用户、JWT令牌的过期策略不一致。并发处理能力同样是全行业的短板并发负载评分CLS从6%到42%不等而目标是70%。一个并发处理评分只有6%的应用意味着当稍多一点的用户同时访问时应用就会出现严重问题甚至崩溃——这在正式的商业环境中是不可接受的。研究还发现了一个有些反直觉的现象SEO和网页标准评分SWS与整体工程质量呈负相关。工程质量最低的前端优先型平台SEO评分反而最高40%因为它们专注于生成结构良好的HTML自然带上了正确的meta标签。而工程质量最高的基础设施集成型平台SEO评分却是全场最低9%因为其架构重心完全在后端基础设施完全忽视了网页标准合规。这提醒用户看单一维度的得分可能产生误导一个SEO友好的页面背后可能完全没有数据库。九、修改应用比从零创建更难——单平台初步验证除了从零创建应用的测试研究团队还对修改已有应用这种更贴近现实的使用场景进行了评测。需要特别说明的是这部分评测目前只完成了一个平台QwikBuild且评分由与该平台有关联的作者执行因此这部分数据只能作为方法论验证和模式观察不能据此做跨平台排名判断未来需要更多独立研究者在多个平台上重复验证。初步观察揭示修改评分普遍比创建评分低1到14个百分点确认了修改比创建难的预期。降幅最大的两个指标是后台作业评分下降24.3个百分点和金丝雀需求保留率下降14个百分点。前者是因为修改任务引入了更复杂的定时调度需求后者的降幅则主要集中在存活型金丝雀——那些本应从第一阶段贯穿保留到修改阶段的需求细节。在10条存活型金丝雀需求中有3条出现了部分降级而14条新增型金丝雀中只有1条出现问题也就是说存活型金丝雀的部分丢失率是新增型的3倍。这意味着在AI对应用进行结构性修改时原有的细节约束比新引入的需求更容易被遗忘迭代开发会逐渐放大需求规格漂移。另一个有趣的观察是两个指标在修改后反而有所提升外部服务可靠性评分提升了5.4个百分点因为某次修改引入了供应商抽象层Lead与增长评分也有所提升因为修改引入了加盟模式、AI调度和PDF导出等功能。这表明有针对性的迭代修改有时能补上创建阶段的短板。在金丝雀需求的逐阶段追踪中所有需求在计划阶段和PRD阶段都100%存活——说明计划模块对需求的捕获是完整的。但进入代码阶段和部署阶段后出现了明显的损耗说明从计划到实现之间存在落差部署流程也会引入额外的不一致性。十、横向对比没有任何一个平台是全能冠军把所有测试数据放在一起看一个清晰的图景浮现出来每个平台都有自己独特的擅长区和盲区没有任何一个平台在所有维度上都表现出色。某平台在核心集成70%和外部服务可靠性35%全场最高方面领先但完全不问业务问题经常构建出功能完整但方向不对的应用。另一个平台生成最精美的视觉效果却有一个影响所有生成应用的共性组件崩溃问题。表现最均衡的平台SEO评分却是全场最低9%代码卫生度52.8%也是头部平台中最低的外部服务可靠性28.3%同样低于平均水平。某个平台不问任何业务问题却能在两个域场景中表现高于平均但在专业技术场景中不稳定跨域方差最大单域内就有13个百分点的起伏。最后一个前端优先型平台虽然整体工程评分垫底SEO得分却最高说明它在前端规范方面确实有独特优势。这种每个平台各有所长的格局对用户有实际的选择参考意义如果你需要的是一个快速可用的展示原型前端优先型平台可能满足需求如果你需要一个真正运行中的后台任务密集型业务系统则需要选择基础设施集成型平台如果你的业务需求比较复杂、模糊需要AI认真理解业务逻辑而不只是生成代码则产品经理代理的充分程度可能是关键决策因素。说到底这项研究做了一件很有意义的事它把AI建站平台从炫酷的科技展示拉回到了实际能用吗这个朴素的问题面前。答案是还不能直接用于正式生产至少不能不加人工干预地直接用。在安全性、后端可靠性、修改稳定性这些关键维度上整个行业都还有相当长的路要走。对于普通用户来说这意味着用AI平台来做原型演示、快速验证想法是完全合适的但如果你打算直接把AI生成的应用开放给真实用户使用建议找懂代码的人先审查一遍尤其要关注安全漏洞和核心业务逻辑的正确性。对于开发者和AI平台建设者来说这套68维度的评测框架本身就是一份改进路线图告诉你哪些方向是全行业的短板投入哪些改进可能带来最大回报。如果对原始研究感兴趣可以通过编号arXiv:2605.04637v1查阅完整论文研究团队也已开放了全部提示词、评分标准和代码供任何人独立复现和验证。QAQ1SWE-WebDev Bench是什么和SWE-bench有什么区别ASWE-WebDev Bench是专门用来评测AI建站平台也就是氛围编程平台的评测框架共有68个指标覆盖需求理解、代码质量、安全性、修改稳定性等维度。传统的SWE-bench只测试AI能不能修复已有代码中的Bug而SWE-WebDev Bench测的是AI能不能从一段自然语言描述出发完整构建一个可用的商业应用同时还评测修改已有应用的能力是完全不同的评测场景。Q2AI建站平台生成的应用安全吗可以直接上线用吗A根据这项研究的测试结果目前不安全不建议不经审查直接上线。六个被测平台的安全评分最高只有64%目标是90%。常见问题包括API密钥硬编码在前端、没有限流机制、缺少跨站攻击防护等。此外所有平台的并发处理能力也严重不足在多用户同时访问时容易出问题。建议找懂代码的人做安全审查后再上线。Q3金丝雀需求保留率这个指标是什么意思为什么重要A金丝雀需求保留率CRR衡量的是AI平台有多少细节需求被正确实现了。研究团队在提示词里埋入了80条具体细节需求比如特定日期格式、特定货币单位然后检查生成的应用里这些细节有多少真正被做进去了。这个指标之所以重要是因为普通用户看不懂代码无法自己检查细节是否被正确实现如果AI悄悄忽略了关键业务细节用户可能到了正式使用时才发现问题。