BaseThesis Labs与QwikBuild联合揭开"氛围编程"平台的真实底细

这项由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平台进行全方位考察。

第一个维度是"交互模式"。研究区分了两种截然不同的任务类型：一种是"从零建应用"（ACR，App Creation Request），即让AI从一段自然语言描述出发，完整构建一个新应用；另一种是"修改已有应用"（AMR，App 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个问题；Emergent（E1-OPUS）采用代理式架构配合配置问答，平均提5个问题；Lovable（Plan Mode）先生成计划再构建，平均4个问题；QwikBuild采用多智能体架构并配备专属产品经理代理，平均提15个问题；Replit（Agent3）完全自主运行，平均只提0.3个问题；v0-Max（Vercel）单次生成，平均1.3个问题。

测试用了三个业务场景作为"靶标"，每个场景都刻意设计成能暴露不同类型弱点的"诊断探针"。

第一个场景是"ExamEdge Academy"（教育科技领域），提示词写成一个深夜创业者发WhatsApp消息的语气，充满口语化和情绪化表达，完全没有出现"CMS""RBAC""SaaS"这类专业词汇，而是用"一切都靠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查阅完整论文，研究团队也已开放了全部提示词、评分标准和代码，供任何人独立复现和验证。

Q&A

Q1：SWE-WebDev Bench是什么，和SWE-bench有什么区别？

A：SWE-WebDev Bench是专门用来评测AI建站平台（也就是"氛围编程"平台）的评测框架，共有68个指标，覆盖需求理解、代码质量、安全性、修改稳定性等维度。传统的SWE-bench只测试AI能不能修复已有代码中的Bug，而SWE-WebDev Bench测的是AI能不能从一段自然语言描述出发，完整构建一个可用的商业应用，同时还评测修改已有应用的能力，是完全不同的评测场景。

Q2：AI建站平台生成的应用安全吗，可以直接上线用吗？

A：根据这项研究的测试结果，目前不安全，不建议不经审查直接上线。六个被测平台的安全评分最高只有64%，目标是90%。常见问题包括API密钥硬编码在前端、没有限流机制、缺少跨站攻击防护等。此外，所有平台的并发处理能力也严重不足，在多用户同时访问时容易出问题。建议找懂代码的人做安全审查后再上线。

Q3："金丝雀需求保留率"这个指标是什么意思，为什么重要？

A：金丝雀需求保留率（CRR）衡量的是AI平台有多少细节需求被正确实现了。研究团队在提示词里埋入了80条具体细节需求（比如特定日期格式、特定货币单位），然后检查生成的应用里这些细节有多少真正被做进去了。这个指标之所以重要，是因为普通用户看不懂代码，无法自己检查细节是否被正确实现，如果AI悄悄忽略了关键业务细节，用户可能到了正式使用时才发现问题。