中科大与阿里揭秘:AI编程助手真的能从零搭建企业级软件系统吗？

中国科学技术大学与高德地图联合做了一项很有意思的研究，成果于2026年5月以预印本形式发布。他们围绕一个在AI编程圈子里越来越热门、却始终没有明确答案的问题，展开了一场大规模测试：当前最强的AI编程助手，到底能不能像一位真正的软件工程师那样，从零开始，把一套完整的企业级云服务软件系统（也就是常说的SaaS系统）搭建出来？

这个问题之所以值得认真对待，是因为近年来AI编程工具的进化速度确实惊人。从最初只能补全几行代码，到如今能独立修改文件、运行命令、调试错误，甚至自主规划整个项目的开发流程——Claude Code、OpenHands这类工具已经开始真正融入专业开发者的日常工作。与此同时，“Vibe Coding”这个词也流行起来，描述的是一种全新的开发方式：用自然语言告诉AI你想要什么，剩下的事情全部交给它来搞定。

不过，现有的评测基准普遍存在一个共同的短板：它们测试的要么是AI能不能解一道算法题、补全一个函数，要么是能否修复某个开源项目里的小bug，更高级一点的，也无非是生成一个结构相对简单的单语言小项目。换句话说，这些测试就好比只考查一个厨师能不能煎好一个荷包蛋，却从未验证过他是否真能在一家餐厅正式开业前，独立完成从菜单设计、食材采购、后厨搭建到前厅布置的全套工作。

真实的企业级SaaS软件恰恰更接近后者。一套完整的CRM客户管理系统、一个在线项目协作平台、或者一套电商交易系统，背后涉及的是前端界面、后端服务、数据库设计、权限管理、部署配置等多个相互依赖的复杂环节，而且往往同时横跨多种编程语言、框架和数据库技术。要评价AI在这种真实场景下的表现，就需要一套全新的测试工具。

SaaSBench正是为此而生。作为目前第一个专门针对企业级SaaS开发场景设计的AI编程基准测试平台，它不仅规模庞大——涵盖30个复杂任务、超过5370个验证节点，而且完全扎根于真实的软件开发市场，每一个任务都对应着现实世界中真实存在、有用户在用的商业SaaS产品类别。这无疑是向前迈出的重要一步。

一、为什么现有的测试方法不够用

要理解SaaSBench的价值，首先得弄清楚现有AI编程测试的局限在哪里。

当前最知名的AI编程测试，比如HumanEval和MBPP，本质上都是一道道算法题，考查的是AI能否根据一段函数说明写出正确的代码实现。这就好比考察一个厨师的刀工——刀功固然重要，但光凭这个可评不了一家米其林餐厅的水准。而且这类测试几乎清一色只涉及Python这一种语言，完全不需要考虑系统部署、数据库连接或用户权限这些真实工程中必须面对的问题。

稍微进阶一点的测试，比如SWE-Bench，会给AI一个真实的开源代码仓库，然后让它修复一个已知的bug。这已经比做算法题更贴近真实工作了，但性质上仍然是“修改已有代码”，而非“从零创建新系统”。就像让一个厨师去修复某道菜里某个步骤的失误，而不是从头设计并烹饪一整桌宴席。

近年来出现了一些要求AI“从零构建项目”的测试，比如NL2Repo-Bench要求AI根据规格说明书生成完整的Python项目，PRDBench则使用类似产品需求文档的输入形式。这些测试走出了重要的一步，但仍然普遍局限于单一编程语言、简单系统架构，缺少真实企业软件中必不可少的多组件联动、数据库迁移、权限体系和生产级部署等关键环节。

研究团队通过系统梳理发现，现有基准测试在三个核心维度上都存在明显缺口。第一，任务缺乏真实市场基础——它们往往是人为构造的，并不对应真实的商业产品类别，因此很难判断AI究竟有没有能力构建出真正能上线运营的商业软件。第二，系统复杂度不足——单一语言、弱耦合架构的项目与真实SaaS系统之间存在巨大鸿沟，后者往往需要同时打通前端、后端、数据库、认证和部署多个层次。第三，评估机制不够精细——“跑通了多少单元测试”这类评估方式，遇到复杂的多组件系统时会产生严重的噪音：一个基础功能的失败，会在评分上被反复惩罚几十次，完全无法准确反映AI真实的能力边界。

二、SaaSBench是如何从真实市场出发设计的

SaaSBench的构建逻辑是自上而下的：先明确市场上真实存在的SaaS产品类别，再为每个类别找到对应的高质量开源实现，最后把这些真实系统的需求转化为AI需要完成的任务。

研究团队参考了Gartner、Forrester等业界权威分析机构的产品图谱，以及G2等评测平台的分类框架，最终确定了6个一级领域和30个细分类别。这6个领域沿着企业价值链和服务对象两个维度分布：面向外部客户的“客户增长”领域（CG），包含邮件营销、CRM客户关系管理、帮助台工单、表单构建、社区论坛、即时通讯和视频会议7类产品；面向内部协作的“生产力与协同”领域（PC），涵盖项目管理、知识库、时间追踪、游戏化生产力工具、日程预约和学习管理系统6类；“商业与金融”领域（CF）包含电商平台、订阅计费、会计开票和库存管理4类；“数据与内容基础设施”领域（DCI）包含无头CMS、商业智能、数据目录、功能开关和分析5类；“安全与身份基础设施”领域（SI）包含监控运维、身份访问管理、密码管理和文件存储4类；“行业与工作流”领域（DW）包含电子签名、低代码平台、电子健康记录和工作流自动化4类。

为确保这30个类别之间足够独立、不存在大量重叠，研究团队对所有435对类别组合进行了四维正交性检验，从核心业务对象、核心用户角色、主要数据读写模式和核心架构挑战四个维度逐一比对。结果显示，421对完全正交，仅14对存在某一维度的有限重叠，且重叠主要集中在表面语义而非工程本质上。

每个类别对应一个种子代码仓库，候选仓库必须满足三个条件：有持续维护的活跃信号、能提供完整的SaaS系统形态、具备清晰的主要业务边界。最终入选的30个种子仓库包括Discourse（社区论坛）、n8n（工作流自动化）、Grafana（监控运维）、Keycloak（身份管理）、Nextcloud（文件存储）等业界知名的开源项目，每一个都是对应领域真实在用、经过生产验证的系统。

三、AI收到的“作业题”是什么样的

SaaSBench为每个任务准备了四份材料：一份长篇产品需求文档（PRD）、一份歧义消解知识库（KB）、一套标准化运行环境，以及一套基于依赖关系图的测试套件。

产品需求文档平均长达4363行，内容包括技术选型要求、完整的数据模型定义、核心业务流程描述、API接口约定、权限策略规则、边界条件说明和部署步骤说明。这份文档的厚度相当于一本中篇小说，其详尽程度远超大多数现有测试中的任务描述，更接近真实企业开发项目中甲方交给开发团队的正式技术规格说明书。

知识库则扮演着“客户补充说明”的角色。现实中，任何一份需求文档都不可能把所有细节说清楚——客户的分页默认值是多少？删除一个客户时关联的项目数据该怎么处理？这些需要在开发过程中通过沟通确认的细节，在SaaSBench中被整理成了结构化的问答形式，供AI按需查阅。每条记录包含问题、答案、来源引用和置信度标注，让AI能够在遇到需求歧义时主动查找答案，而不是随意猜测。

运行环境方面，每个任务都配有一套预先构建好的Docker容器环境，其中已预装对应任务所需的系统依赖、数据库服务、端口映射和环境变量。AI在这个沙盒里拥有完整的自主权：可以自由创建文件、安装依赖、执行命令、运行数据库迁移，直到把系统完整地部署起来并跑通为止。

整个任务横跨8种编程语言（Python、TypeScript、Go、Ja va、Ruby、PHP、Rust、Elixir），6种数据库类型（PostgreSQL、MySQL/MariaDB、MongoDB、SQLite、ClickHouse），13种前后端开发框架（Rails、Django、NestJS、Next.js、Spring等）。这种技术栈的多样性，真实反映了企业软件世界的异质化现实。

四、评分系统是怎么设计的

SaaSBench最具创新性的部分之一，是它的评分机制。

传统的测试评分就像是考试卷的批改方式——跑了多少个测试，通过几个算几分。但这种方式放在复杂系统的评估上会产生一个严重问题：如果AI在最基础的数据库连接环节就失败了，那么后续所有依赖这个数据库的接口测试、业务逻辑测试全都会跟着失败。这一个根本原因导致的失败，会在评分上被计算几十甚至上百次，完全淹没了真正的能力信号。

SaaSBench的解决方案是构建一个有向无环图（DAG）——可以把它理解成一张工序依赖地图。地图上的每一个节点代表一个独立的验证检查项，节点与节点之间的箭头代表前置依赖关系。当一个节点的前置依赖没有满足时，这个节点会被标记为“因依赖跳过”而不是直接计零分——它的分值分母仍然保留，但不会触发重复执行，也不会因同一个根本原因在评分上被反复惩罚。这就像工厂里的流水线：前道工序没完成，后道工序自动暂停等待，但暂停不等于失败——失败只记录在真正出问题的那一道工序上。

每个验证节点内部由一条原子操作链组成，链上的操作包括发送HTTP请求、执行SQL查询、验证返回的JSON数据结构、检查数据库表的字段类型和约束条件，以及调用浏览器渲染页面等28种不同类型的基础检验动作。节点的评分方式分为三种：对于必须完全正确的场景（比如权限拦截是否到位），采用“全对才得分”的二值评分；对于允许部分完成的场景（比如多步骤的增删改查流程），采用按完成比例给分的加权评分；对于无法用确定性规则描述的场景（比如页面布局是否合理、代码组织是否整洁），则引入基于Claude Sonnet 4.5的LLM评判，提供一个基于详细评分标准的主观评分。

这5370个验证节点被组织进6个工程能力维度：部署可达性（Deploy）、数据建模（Data）、API合约一致性（API）、业务逻辑正确性（Logic）、访问控制（AuthZ）和工程质量（Quality）。这六个维度就像一栋楼的六层：最底层是部署，楼盖起来才能住人；往上依次是数据、接口、逻辑和权限，最顶层的质量维度则对应着精装修水平。

为确保测试套件本身的准确性，研究团队在每个任务完成构建后，都会把该任务对应的种子代码仓库的原始代码部署到同款标准环境里，要求其通过全套测试。只有通过这项“参考实现验证”的任务才能正式纳入基准，未通过的任务必须修订直到达标。这相当于用考试题的“标准答案”来反向验证题目本身是否出对了。

五、最强AI助手的真实表现如何

研究团队在SaaSBench上测试了两个代表性的AI编程框架——开源的OpenHands和商业化的Claude Code，并分别搭配了8个当前最强的大语言模型：GPT-5.4、Gemini 3.1 Pro、Claude Opus 4.7、Kimi K2.6、Qwen 3.6 Plus、DeepSeek V4 Pro、GLM 5.1和MiniMax M2.7。

结果并不乐观。综合来看，成绩最好的组合是Claude Code框架搭配Claude Opus 4.7，Pass@1得分为20.68分（满分100分）。OpenHands框架搭配Claude Opus 4.7的得分是18.12分。其余组合的得分普遍在4到14分之间，Claude Code框架的平均得分为11.64分，OpenHands框架的平均得分为9.26分。换句话说，即便是当前最强的AI编程组合，在30道题里平均只有约五分之一的分数能拿到。从零完成一套完整企业级SaaS系统的能力，显然还不在线。

从6个SaaS领域的分项表现来看，各模型在安全与身份基础设施（SI）和数据与内容基础设施（DCI）领域得分相对较高，而在商业与金融（CF）和生产力与协同（PC）领域得分普遍偏低。这种差异背后有其内在逻辑：SI和DCI类的任务往往有清晰的接口规范和相对固定的架构模式，AI在这类“有迹可循”的任务上表现更好；而CF类任务涉及复杂的业务状态机（比如订单流转、账务一致性），PC类任务需要管理多用户之间复杂的协同状态（比如日历冲突检测、共享内容版本），这两类场景对跨组件一致性的要求更高，当前AI明显力不从心。

从六个工程能力维度的表现分布来看，部署（Deploy）维度得分最高，说明AI对于基础服务启动和运行环境配置已经具备一定能力；数据（Data）维度居中；API、逻辑和权限控制三个维度得分偏低，反映了AI在接口合约一致性、持久状态建模和基于角色的访问控制上仍面临明显挑战；而质量（Quality）维度的得分在所有维度中垫底，说明即便能生成可运行的服务并实现部分功能，AI在代码组织规范性、前端渲染质量、边界情况处理和整体工程健壮性上，与生产级标准仍有相当大的差距。

六、失败究竟发生在哪里

除了整体分数，研究团队对480个能力单元进行了更细致的失败模式分析，定义了5种执行轨迹类型，用以追踪AI在开发过程中究竟在哪个阶段掉链子。

最理想的轨迹（T1）是AI按照部署、数据建模、认证、业务逻辑、权限策略、质量检查的顺序有条不紊地推进，每一层都验证完毕再继续下一层。遗憾的是，在所有480个样本中，没有一个能力单元达到这个水准。

第二种轨迹（T2）是系统整体可运行，只在某一个具体的能力维度上存在局部失败——比如忘记实现某个安全要求，或者漏掉了某个质量约束。这种“差一口气”的情况只占0.6%，可见整体可运行的系统本身就已经非常罕见。

第三种轨迹（T3）是基础设施和主要流程都能跑通，但业务语义实现不完整——简单的功能路径能走通，但边界情况、配额限制、信任等级规则等细节没有到位。这类情况占3.8%，也就是说，大约每25个任务里有不到一个能到达“业务逻辑实现不完整”这个层次。

第四种轨迹（T4）是系统表面上可以访问（HTTP端口有响应），但底层基础不稳固——数据库迁移没跑完、认证流程有漏洞、会话处理存在问题，后续的接口测试和业务逻辑测试跟着失败是因为地基没打好。这类占32.1%。

最后，也是最主要的一种失败轨迹（T5）是系统从头到尾都没能稳定地跑起来。依赖冲突、Docker配置错误、端口占用、数据库连接失败、目录路径写错、健康检查缺失，或者AI明明系统还没跑起来就已经宣告完成任务——这类“根基未稳”的情况占据了63.5%的绝大多数。

这个数字意义重大：超过95%的任务失败（T4和T5合计）都发生在AI还没来得及真正实现业务逻辑之前。问题的根源不是AI不懂某个特定的算法或接口规范，而是在完成一套多组件系统的配置、集成和部署这个更基础的工程工作上力不能及。

七、同一个AI大脑，不同的编程框架，差别有多大

研究团队专门针对框架影响做了比较测试，对GPT-5.4、DeepSeek V4 Pro和Claude Opus 4.7三个模型，分别在OpenHands、Claude Code和Codex CLI三个框架下进行了评测。

结论是，同样的大语言模型底座，配上不同的编程框架，表现差异相当显著。以Claude Opus 4.7为例，在Claude Code框架下得到20.68分，在OpenHands框架下得到18.12分，在Codex CLI框架下得到18.81分，三者之间存在可见差距。这说明SaaSBench测试的并不只是孤立的语言模型能力，而是“模型+工具接口+执行循环+环境反馈机制+记忆管理+错误恢复策略”这整套系统的综合能力。

商业IDE导向的框架（如Claude Code）普遍优于开源框架的原因，在于它们与文件编辑、终端执行、诊断信息和中间项目状态的集成更为紧密，降低了模型追踪工作区变化和从失败命令中恢复的认知负担。在长周期的SaaS任务中，这种差异会不断积累，最终在部署稳定性、依赖修复、schema一致性和错误恢复等方面体现出明显的分差。

从交互行为的角度来看，“步骤多”并不等于“做得好”。MiniMax M2.7在OpenHands框架下平均执行了279步，却只拿到了6.78分，而Claude Opus 4.7只执行了102步，得分却达到18.12分。相比之下，GPT-5.4只执行了区区36步就拿到了7.44分，这说明它在单步生成质量上具备优势，但受限于交互轮次不足，在系统验证和调试方面明显受限。长周期SaaS开发更依赖的是高质量的“推理-行动-观察”循环，而不是更多的交互预算。

八、这项研究说明了什么，对未来意味着什么

说到底，SaaSBench揭示的是一个关于当前AI编程助手能力边界的清醒判断：在“能写出正确的函数”和“能从零交付一套完整的企业软件系统”之间，存在一道巨大的鸿沟。而这道鸿沟的核心障碍，不是业务知识或算法能力，而是在系统配置、多组件集成、依赖管理和部署稳定性这些工程基本功上的可靠性不足。

研究团队对现有AI编程工具表现出的两种典型失败模式做了生动的命名。第一种叫“过度自信的提前收手”：AI在系统其实还没正常跑起来的时候就宣告任务完成，就像一个工人把地基刚打了一半就开始贴墙纸，并且报告说工程已经竣工。第二种叫“无效的长期调试循环”：AI在同一个问题上反复尝试局部修补，却始终找不到根本原因，就像试图用橡皮膏一层一层地贴，来修复一根漏水的主管道——越贴越乱。

对于研究社区而言，SaaSBench提供了一个迄今最接近真实工程场景的评测平台，能够精准定位当前AI编程助手的能力边界，并为未来的改进方向提供具体指引。未来版本的SaaSBench还计划向两个方向扩展：一是增加任务数量、拓展SaaS品类，覆盖更宽泛的技术栈；二是引入更动态的开发场景，比如迭代式需求更新、系统维护任务和多阶段产品演进，让测试更贴近真实开发工作的全生命周期。

归根结底，AI编程助手距离真正意义上的“从需求到上线”全自动开发，还有相当长的路要走。但SaaSBench的出现至少让我们能更清楚地看到这条路还剩多远、难点在哪里——这或许是推动这个领域继续向前的最重要的第一步。

Q&A

Q1：SaaSBench测试的是哪方面的AI能力，和普通的编程测试有什么区别？

A：SaaSBench测试的是AI从零开始完整构建企业级SaaS软件系统的能力，包括前端界面、后端服务、数据库设计、权限管理和系统部署等全部环节。普通编程测试通常只考查AI能否写出正确的函数或修复已有代码中的小bug，就像只考厨师的刀工，而SaaSBench更像是要求厨师独立完成一整桌宴席的筹备和烹饪。

Q2：SaaSBench评分系统中的依赖关系图（DAG）是怎么工作的？

A：依赖关系图像工厂流水线一样，把所有验证检查项按前置依赖关系串联起来。如果某个基础环节失败，依赖它的后续检查会被标记为“因依赖跳过”而不是直接计零分，这样同一个根本原因造成的失败就不会在评分上被反复惩罚几十次，能更准确地定位AI真正的能力瓶颈所在。

Q3：当前最强AI编程助手在SaaSBench上的得分为什么这么低？

A：得分低的核心原因不是AI不懂某个特定技术，而是在多组件系统的配置、集成和部署这些工程基本功上可靠性不足。分析发现，超过95%的任务失败都发生在AI还没来得及实现业务逻辑之前——63.5%的情况下，系统从头到尾都没能稳定跑起来，典型失败包括依赖冲突、Docker配置错误、数据库连接失败，以及AI在系统未就绪时就过早宣告任务完成等问题。