两条曲线，差的是最后几条要求
arXiv 2610.35138 提交的 Co-Design Bench，做的是一件看起来不大、读起来有点扎手的事：把编码智能体「满足要求的比例」和「把整件事做完的比例」分开量。
在共用同一套智能体 harness 的条件下，表现最好的那个模型端点，逐条要求平均通过 69.9%，但完整满足全部要求的任务只占 26.4%。十六位作者给出的判断很直白：约四分之三的任务至少留了一项没做到。
这两个数字之间的落差，才是这篇论文真正想摆出来的东西。行业里习惯的口径是前者——改对了多少、通过了几条标准；而用户拿到手要的是后者——这个应用现在能不能用。中间那一段，就是开发团队日常抱怨「它做得挺快，我收尾收得更累」的那一格。
题目来自真实会话，不是实验室的表述
任务的来源值得单独说。273 道题是从 26314 个真实用户编码会话里的 37463 条去重请求中筛出来的，每道题配一个规范化后的请求和一个可运行的改动前应用，另附 2331 条由专家撰写、对智能体隐藏的验收标准。
没有参考解，也没有目标截图。这个设计带着明确主张：要测的是真实用户怎么提要求，而不是实验室希望他们怎么提要求。单纯这一条，就把很多熟悉的表述优惠拿掉了——真实请求往往含糊、带截图、省略前提。
两条赛道分别叫多模态编辑与仓库编辑，输入可以是图像、音频、视频或文档；能力维度分接地理解、界面改造与功能实现三块。判定流程叫「先判后驳」：先用源码与浏览器证据给每条标准打分，再另派一个模型复核所有肯定结论，视觉与交互类的主张单独审计。
最像日常开发的那一类，分数最低
另有一个结果比 26.4% 更值得留意。十个模型端点在仓库编辑上呈现同一个方向：横跨三类或四类改动的任务，逐条要求通过率一律低于只涉及一两类改动的任务。
这与基准设计的意图是重合的。真实工作里一句「把这个页面改一下」，往往同时牵动界面、逻辑与配置；而基准里最容易拿分的，恰恰是被切得干净的单点改动。也就是说，当基准开始贴近现实，分数就往下掉——这本身就是一个结论。
冷水：能读出方向，读不出座次
限制要说清楚。摘要层面没有点名那十个端点分别是谁，因此这篇论文不该被用来给厂商排序；69.9% 与 26.4% 描述的是这套任务与这套判定方法下的表现，迁移到别的基准或某个具体产品上未必成立。
判定本身也有成本。它依赖浏览器证据与模型裁判，而裁判的误差没有被单独量化；「完整满足」的门槛是所有标准同时成立，这个定义比日常语境里的「能用」严，也比「改了不少地方」宽，读数字时得记住口径。273 道题的规模在同类工作里不算小，但来源平台的会话结构是否会带来选择偏差，论文没有给出量化说明。这部分目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
对团队的含义：分开量，按复杂度分级
本站此前记录过几件相邻的事：网页环境的自动复刻让 Web 智能体有地方练，运行时评测让已部署的智能体实例可以被打分，基准失明的三条缝隙指出规约与神谕之间的落差。Co-Design Bench 补的是另一格——它不测环境也不测运行时，测的是「交付物本身达标没有」。
落到实操，三件事可以直接做。其一，把逐条通过率和整单完成率当成两条曲线分别记录，只量前者会系统性地高估收益。其二，验收标准在任务开始之前写好，智能体结束后按标准过一遍——这正是这套基准的判定结构，团队可以照抄。其三，按改动类型数给任务分级：横跨三类以上的请求，人工介入的密度要明显高于单点改动，因为论文在这个方向上的证据是十个端点一致的。