阿里巴巴和多所亚洲高校的研究人员发布了 Co‑Design Bench。该测试要求编程智能体根据真实用户的修改请求，改动正在运行的网页应用。测试包含图片、音频片段、视频和文档等多模态输入，力求还原开发者的实际工作方式。研究人员评估了 10 个模型，从类似 OpenAI 的 GPT‑6 Astra，到 Claude Opus 5 和 Qwen 3.8‑Max。
GPT‑6 Astra 表现最佳，平均能满足每项任务约 70% 的要求。即便如此，它只有在 26.4% 的案例中生成了完全正确的应用。多数任务中，AI 虽然完成了大部分工作，却至少遗漏一处细节；这意味着发布前仍需由人工检查并修正代码。
在 WebCompass‑edit 等较早的基准测试中，同一批模型的得分接近满分，但 Co‑Design Bench 显示，两者相差超过 35 个百分点。研究人员表示，较早的测试如今已变得太容易，因为智能体可以在封闭循环中运行、检查并修复自己的代码，导致得分虚高。
当一项任务同时包含三四种不同的修改类型——布局、设计、交互和内容——模型的表现便大幅下滑。包括较小的 Qwen 3.8‑27B 在内，所有模型在这种情况下都难以应对。即使增加算力，帮助也不大：GLM‑5.2 在简单修改任务上使用的 token 数是 GPT‑6 Astra 的 6 倍，得分却仍然更低。
测试揭示了什么
这项研究指出，编程智能体的配套运行框架——负责向其提供代码并运行输出结果的程序——对测试结果的影响可能不亚于模型本身。同一个模型在处理较大规模改造时，在一种环境中的得分为 75%，在另一种环境中则为 56%。作者建议企业在采用工具前，同时评估模型和运行框架。
研究人员也指出了测试的局限：每项任务只有一个固定请求，因此不会测试后续追问；为应用打分的 AI 评审也可能出错。METR 此前的研究发现，AI 生成代码在现实中的接受率，比 SWE‑bench Verified 等热门基准测试的得分低约 24%。
为什么重要
对于考虑采用 AI 编程助手的开发者而言，这些发现意味着，软件发布前，他们仍需检查并修正大多数改动。企业应同时测试 AI 模型及其集成环境，而不能只依赖可能高估实际表现的基准测试分数。
