清华智谱发布全栈Web开发基准：顶级AI模型集体翻车

AI写网页很强，但搭全站呢？

让AI帮你写一个静态网页，它可能分分钟就能交差。但如果让它从零开始搭建一个完整的全栈网站——包含需求文档、原型图、数据库设计、状态管理——结果会怎样？

全栈Web开发是指同时涵盖前端（用户界面）、后端（服务器逻辑）、数据库（数据存储与查询）以及它们之间通信协议的完整软件开发过程。与单纯的静态页面生成不同，全栈开发需要开发者理解HTTP请求生命周期、RESTful API设计、ORM映射、会话管理、身份认证（如OAuth、JWT）等多层技术栈的协同工作。一个典型的全栈项目可能使用React或Vue作为前端框架，Node.js或Python作为后端运行时，PostgreSQL或MongoDB作为数据库，再加上Redis缓存、消息队列等中间件。这些组件之间的耦合关系和数据流转逻辑，构成了远超单文件代码生成的工程复杂度。

清华大学和智谱AI联合发布的最新基准测试给出了令人大跌眼镜的答案：即便是当前最强的大语言模型，在全栈Web开发任务上也会集体"翻车"。Gemini 2.5 Pro在静态网页上能拿63分，但到了全站任务，视觉得分直接暴跌至11.7，功能分也仅有22.6。

三级难度递进：从静态页面到全栈系统

这项基准测试最大的创新在于其层层递进的难度设计，不再像以往只测试静态页面或零散的代码片段，而是设计了三个逐步升级的关卡：

第一关：响应式静态网页

这是最基础的任务，要求AI生成能够适配不同屏幕尺寸的静态页面。响应式设计（Responsive Design）的核心技术包括CSS媒体查询（Media Queries）、弹性盒布局（Flexbox）、CSS Grid、相对单位（rem、vw、vh）以及断点（Breakpoints）设计。看似简单的适配背后，涉及到图片的自适应裁剪、导航栏在移动端的折叠逻辑、触摸事件与鼠标事件的差异处理、以及不同浏览器渲染引擎的兼容性问题。AI模型在处理这类任务时，往往能生成桌面端的合理布局，但在处理断点切换时的元素重排、隐藏逻辑和交互模式变化时容易出错。在这一关，顶级模型的表现尚可，Gemini 2.5 Pro能拿到约63分的成绩。

第二关：交互式前端应用

难度升级到带有页面跳转、用户交互逻辑的前端应用。模型需要处理路由、事件绑定、组件通信等前端工程问题。现代前端框架中的路由系统（如React Router、Vue Router）需要处理嵌套路由、动态参数、路由守卫、懒加载等复杂场景，而组件通信则涉及props传递、事件总线、Context/Provide-Inject、以及状态提升等多种模式的合理选择。

第三关：全栈系统开发

这是真正的"地狱模式"——需求文档、原型图、数据库设计、状态管理、前后端联调，一个都不能少。这一关直接暴露了当前AI模型在复杂工程任务上的短板。

测试结果：SOTA模型集体露怯

测试覆盖了当前主流的顶级模型，包括Claude、GPT系列和Gemini，结果揭示了几个关键发现：

全栈任务得分断崖式下跌

Gemini 2.5 Pro从静态网页的63分，到全站任务视觉得分仅11.7、功能分22.6，降幅超过60%。这说明当前模型在处理长流程、多模块协同的复杂工程任务时，能力严重不足。

移动端适配普遍拉胯

所有模型在平板和手机端的适配表现，普遍比桌面端低10%到20%。响应式设计看似是前端基本功，但AI在处理多端适配的细节时仍然力不从心。移动端的挑战不仅在于布局调整，还包括触摸手势识别、虚拟键盘弹出时的视口变化、iOS和Android浏览器的渲染差异、以及移动网络环境下的性能优化等一系列平台特定问题。

复杂业务场景更是重灾区

在交易类和SaaS类这种业务逻辑复杂的网站上，AI的表现更加糟糕。SaaS（Software as a Service）类应用通常需要实现多租户架构（不同客户数据隔离）、细粒度的角色权限控制（RBAC）、订阅计费与支付集成、数据导入导出、审计日志、Webhook回调等企业级功能。此外还需要考虑高并发下的性能优化、数据安全合规（如GDPR）、以及复杂的业务工作流引擎。这些需求交织在一起，形成了极其复杂的系统依赖图谱，对AI模型的全局规划能力提出了严峻挑战，远超当前模型的"舒适区"。

评估方式的创新：全自动化打分

这项基准测试的另一大亮点是其评估方式的创新。传统的代码评估要么依赖人工审查，要么只能做简单的单元测试，而这套系统采用了完全自动化的双维度评估：

功能测试维度： 让AI Agent自主执行预设的功能测试用例，验证页面跳转、表单提交、数据持久化等功能是否正常工作。这里的AI Agent通常基于浏览器自动化框架（如Playwright或Puppeteer），能够模拟真实用户的点击、输入、滚动等操作，并验证DOM状态变化、网络请求响应和本地存储数据是否符合预期。

视觉还原维度： 利用视觉语言模型（VLM）将生成的页面截图与原型设计图进行对比，评估视觉还原度。VLM是一类能够同时理解图像和文本的多模态AI模型，系统会对生成的网页进行多分辨率截图，然后将截图与原始设计稿一起输入VLM，由模型从布局结构、色彩搭配、字体排版、间距比例、组件对齐等多个维度进行打分。这种方法相比传统的像素级对比（如SSIM结构相似性指数）更接近人类的视觉感知，能够容忍合理的实现差异同时捕捉明显的设计偏离。

这种方式不仅公平可复现，还能大规模自动化运行，为后续的模型迭代提供了可靠的评估基础。

深层启示：AI开发能力的真实边界在哪里

这项研究的核心价值在于撕开了AI开发能力的"滤镜"。我们日常看到的AI编程演示，大多是精心挑选的简单场景——写一个组件、修一个Bug、生成一段函数。但真实的软件工程远不止于此。

一个完整的Web应用开发涉及：

• 架构设计：技术选型、模块划分、接口设计。这要求开发者在项目初期就对系统的可扩展性、可维护性和性能瓶颈做出前瞻性判断，例如选择微服务还是单体架构、采用事件驱动还是请求-响应模式、如何设计API版本策略等。
• 状态管理：跨页面数据同步、缓存策略。在复杂的单页应用中，应用状态包括用户登录信息、购物车数据、表单输入、API响应缓存、UI交互状态等多种类型。真正的难点在于如何在多个组件间保持数据一致性、如何处理异步操作带来的竞态条件、如何设计合理的状态粒度避免不必要的重渲染、以及如何在页面刷新或路由切换时正确恢复状态。
• 异常处理：边界情况、错误恢复、降级方案。生产环境中的异常处理远比try-catch复杂，需要考虑网络超时重试策略、分布式事务的最终一致性、服务熔断与降级、以及用户友好的错误提示与恢复引导。
• 工程规范：代码组织、可维护性、性能优化。包括合理的目录结构、代码分割与懒加载、Tree Shaking、CDN部署策略、以及CI/CD流水线的配置等。

当前模型在单点任务上表现亮眼，但在需要全局规划、长程依赖管理的复杂工程任务上，仍然存在明显的能力断层。这也为AI辅助开发工具的未来发展指明了方向——不是简单地生成更多代码，而是需要具备真正的工程思维和系统设计能力。

总结

清华和智谱的这项工作为AI代码生成领域提供了一个更贴近真实场景的评估标准。它提醒我们：在为AI的编程能力欢呼时，也要清醒地认识到，从"能写代码"到"能做工程"之间，还有很长的路要走。对于开发者而言，AI目前更适合作为提效工具而非替代方案，尤其是在复杂的全栈项目中。未来的突破方向可能在于：让AI模型具备更强的长上下文推理能力、多步骤规划能力、以及对软件工程最佳实践的深度内化，而非仅仅追求单次代码生成的正确率。