最强 AI 编程模型做真实需求，能拿到近 70 分，但真正能直接交差的只有四分之一。2026 年 10 月 26 日，阿里巴巴联合多所亚洲高校提交了新基准测试 Co-Design Bench 的论文（arXiv:2610.35138）。在参测的 10 个模型里，排名第一的 GPT-6 Astra 平均满足了单任务约 70% 的子需求，但完全通过率只有 26.4%。近四分之三的任务，最后还得人类程序员上手收拾残局。
旧编程测试集已经被刷爆了。一旦允许智能体自己运行、检查和修复代码，模型在老题库上的得分动辄超过 99%。就拿 WebCompass-edit 的 150 个固定任务来说，评分标准和裁判完全不变，仅仅把执行模式改成智能体迭代，qwen3.7-plus 的分级完成率就能从 73.6% 直接跳到 95.1%。为了挤掉这层水分，研究团队从 26,314 个真实用户编程会话、37,463 条去重请求里，筛出了 273 个评估任务和 2,331 项隐藏验收标准，统一放在共享的 Claude Code 框架下跑，每次运行给足 3 小时和 120 轮交互上限。
- 考题拆解.包含 100 个多模态编辑任务（ME，含 553 项标准，另设 96 题的 ME-96 子集含 521 项标准），要求从收据、表格、音视频或文档里提取信息并改代码；以及 173 个代码库编辑任务（RE，含 1,778 项标准），专考跨组件、路由、状态和数据流的协同修改。
- 双裁判审讯.采用无参考标准的先评判后反驳（judge-then-refute）协议。先渲染出真实网页应用，收集源码 diff、截图和浏览器轨迹，由第一个 AI 裁判按 PASS、PARTIAL、FAIL 打分；紧接着第二个独立大模型验证器进场，专门挑刺桩代码（stubs）、硬编码、不可达功能和需求错位。
- 核心战报.GPT-6 Astra 领跑但偏科严重，多模态赛道完全解决率 41%，代码库赛道还不到 18%；Claude Opus 5 和 Qwen3.8-Max-0902 紧随其后，Grok 4.6 垫底；而在大型重构任务里，体量小得多的 Qwen3.8-27B 反而冲到了第二名。
| 模型名称 | 严格完成率（子需求均分） | 完全通过率（零瑕疵交卷） |
|---|---|---|
| GPT-6 Astra | 69.9% | 26.4% |
| Claude Opus 5 | 66.1% | 18.3% |
| Qwen3.8-Max-0902 | 65.3% | 16.5% |
| Qwen3.8-27B | 64.4% | 15.0% |
| Grok 4.6（第 10 名） | 51.1% | 6.6% |
70% 与 26.4% 的剪刀差：死在跨组件联动
69.9% 和 26.4% 这两个数字放在一起，最能看清今天 AI 写代码的真实水位。69.9% 是严格完成率，代表模型平均能把一个任务里近七成的验收点做对（如果把 PARTIAL 算半分，GPT-6 Astra 的分级完成率甚至有 75.3%）；但 26.4% 是完全通过率，要求一个任务底下所有细分标准全部拿到 PASS。
《战国策》里讲，行百里者半九十。软件工程里最折磨人的从来不是搭起前 70% 的架子，而是把剩下 30% 的边界条件和状态同步严丝合缝地对齐。
一旦一个需求同时叠加了布局、设计、交互和内容等三四种变更，10 个参测模型的得分全部跳水。比如让 AI 从一张收据图片里提取金额，再去更新网页应用里所有关联的汇总视图。模型往往能把收据读出来、把当前页面的数字改对，却忘了同步另一个路由下的结算组件，或者干脆在界面上写死一个假数字糊弄过去。这种九成完工、一处漏风的代码交给程序员，排查暗坑的精力未必比自己重写省多少。
更扎心的是，面对这种多线并发的工程复杂度，大力出奇迹失灵了。在小型修改任务上，GLM-5.2 烧掉了将近 GPT-6 Astra 6 倍的 Token，得分反而明显更低。论文披露的 Token 消耗数据包含了重试与缓存流量：GPT-6 Astra 在多模态编辑和代码库编辑中分别平均消耗 1.24M 和 2.33M tokens，而 Qwen3.8-27B 在代码库编辑中平均吞掉了 6.72M tokens。当模型底层缺乏全局状态追踪能力时，给它再多的轮次去重试，也只是在死胡同里空转烧钱。
换套脚手架差出 19 分：我们在测模型还是测工具？
这份报告里最值得技术团队警醒的变量，其实不在模型榜单上，而在执行框架（Harness）里。
所谓 Harness，就是智能体用来读文件、写代码、跑测试、看报错的那套外部工具链。研究团队把同一个 Qwen3.8-27B 放进不同的执行框架里跑大型重构任务，它的得分居然在 56% 到 75% 之间剧烈摆动，足足差出 19 个百分点。甚至两个模型谁排前面，换一套环境就能直接反转。
单看基座模型的裸分选工具，就像只看发动机参数去买整车。
这直接戳破了当前大模型跑分榜的一个盲区。各大厂商发模型时都爱晒自己在 SWE-bench 或某某榜单上又涨了几个点，但开发者买到手的是包含提示词工程、上下文裁剪、编译器反馈回路在内的整套工具。之前另一项针对编程智能体的研究也发现，有些花哨的框架消耗了高达 3 倍的 Token，却几乎没带来任何可测量的性能提升。好鞍能救次马，烂鞍也能毁掉千里马。
- 建议.企业技术团队在采购或自研 AI 编程工具时，必须把基座模型与执行框架绑定成一对组合来压测；同时盯紧小模型在复杂任务下的重试流量，单价便宜的模型一旦在代码库里跑出 672 万 Token 的吞吐，实际账单和时间损耗可能比顶配大模型更贵。
别被 26.4% 吓退：这本就是一份错题集
那是不是说明 AI 写代码根本没法用，四分之三的时候都在帮倒忙？我不太买账这种悲观外推。
如果去翻论文的附录 I，就会发现这 273 道题根本不是日常编程需求的随机抽样。研究团队在从 2.6 万多个真实会话里挑题时，专门优先筛选了那些结构高度复杂、而且带有明显历史失败信号的任务——也就是人类用户在真实使用中不得不反复重述需求、甚至被迫回滚代码的骨头题。拿一份专门收集历史疑难杂症的错题集去考 AI，考出 26.4% 的满分率，其实恰恰说明最强的模型已经能独立啃下四分之一的硬骨头了。把它直接等同于日常写个接口、改个按钮也只有两成把握，属于典型的幸存者偏差。
这套测试方法本身也有没闭环的地方。首先，测试每次只给一条固定指令，不允许人类在半路追问或纠偏，而真实开发本来就是人与 Agent 多轮对话的过程。更关键的是裁判问题：虽然双大模型先评判后反驳的设计很严厉，但反驳器在抓硬编码时，完全可能把原本合规的另类实现误杀掉（即假阴性）。论文附录 J 虽然提到请了两名人类前端专家抽检了 200 个任务-模型输出，却没有公布精确一致率、Kappa 系数或混淆矩阵等定量数据。既然此前 METR 的研究已经证明，通过 SWE-bench Verified 测试的 AI 代码放到真实项目负责人手里，实际接受率会比跑分低大约 24 个百分点，那么完全靠 AI 裁判互相监督得出的分数，离真实工业界的可用性到底隔着多远，目前还得打个问号。
- 风险.盲目迷信 99% 的旧跑分去搞全自动无人工厂会撞得头破血流，但看到 26.4% 就彻底拒绝 AI 编程工具同样会错失红利；真正的工程落点，是让 AI 去干那 70% 枯燥的局部代码生成，把人类的精力省下来，专门盯死跨组件状态同步与最后那三成的验收底线。