为什么重要
现有前端/应用类基准大多是”照着参考图或参考实现还原一个页面”：Design2Code、WebSight-Test、WebRenderBench、IWR-Bench 都是这一类，输入只有图，评测靠和金标比对。但它们回答的是一个已经被部分解决的问题——真实用户找编码 Agent 时，手里已经有一个能跑的应用，说的是”把这个按钮挪到右上角，并且像附件里这段录音那样加个渐入”。
Co-Design Bench 的立论是：从「可运行的应用」到「按要求改过的应用」这一段没有可靠评测。它的三个设计选择由此而来——真实用户请求（不是研究员编的）、多模态输入（图/音视频/文档都可以是需求的一部分）、reference-free（不给金标代码也不给目标截图，因为改法有无数种，给金标等于奖励巧合）。
构建方式
源语料是 39,325 条生产查询、26,314 个真实编码会话（其中 25,373 个是前端应用会话），去重后留下 37,463 条候选；每条候选锚定到会话里的一个编辑轮次，连同其仓库、可用历史与附件一起保留。最终入库 273 个任务，入库率约 0.7%。
两条赛道：
- ME（Multimodal Editing，100 题）：局部编辑，输入可带附件。附件分布是纯文本 20、音频 32、视频 27、文档 17、图像 4。80% 的任务带附件或截图，平均每个任务 1.35 个附件，553 条验收标准（每题均值 5.5 / 中位 6 / 最多 11）。
- RE（Repository Editing，173 题）：协同仓库级修改。96% 的任务跨多种编辑类型（结构 87%、样式 77%、交互 76%、内容 65%），58% 达到 L3–L4 交互深度，99% 的起始产物是 React 源码树。1,778 条验收标准（每题均值 10.3 / 中位 8 / 最多 46）。
三个能力维度：接地理解（92 题）、UI 变换（55 题）、功能实现（126 题）。多标签标注显示 265 个任务（97.1%）带多个能力标签、174 个（63.7%）跨不止一个高层维度——这些维度高度重叠，只能描述表现，不能当作独立能力。
评测协议：judge-then-refute
无金标评测最大的风险是”裁判说过了就算过了”。作者的做法是拆成两步加一道强制审计：
- 判（judge）：用源码 + 浏览器执行证据，逐条给隐藏标准打 Pass / Partial / Fail；Graded 口径下 Partial 记 0.5。
- 驳（refute）：另一个 LLM 验证器拿到初始判决与全部证据，专门挑战每一条 Pass 与 Partial，查桩代码、硬编码输出、不可达入口、换个输入就失败、与请求不符。这一步的目标是收回”没有证据支撑的完成度credit”，作者明确说它本身也不保证每条判决都对。
- 强制审计：视觉类断言必须有成功渲染的截图，交互类断言必须有浏览器动作日志。违反就在聚合前中止该次评测。判决、证据、反驳日志全部留存，让每个分数都能追到观测。
另有两位前端专家对 200 组「任务 × 模型」输出做了人工复核 rubric。低分案例（Graded < 0.8）会走失败归因：在隔离沙箱里做一次最小补丁探测，区分模型能力不足 / 环境阻塞 / 混合原因 / 起始产物本身有缺陷——注意归因只给辅助credit，原始分数与分母不变。
关键发现
一、标准覆盖率和完整交付率是两回事，而且差得非常远。 头名 GPT-6 Astra 在 ME 上 Strict 0.754、RE 上 0.667，但完全通过的任务只有 41.0% 和 17.9%；合并 273 题后是 0.699 对 26.4%。73.6% 的任务至少剩一条标准没被完全满足。 论文给了这个落差的公式解释：F ≤ R̄ ≤ Ḡ，差值 R̄ − F 就是”分散在很多任务上的未完成标准”。只报 R̄ 会把「做了一大半」读成「做完了」。
二、改动的”宽度”比”类型”更决定难度。 RE 上按结构/样式/交互/内容分组，各组 Strict 几乎一样（0.599–0.607）；但按编辑类型的数量分组，1–2 种是 0.654、3–4 种是 0.591，差 6.3 个百分点，且十个端点全部在更宽的那一组上更低。有意思的是全通过率几乎不变（9.1% vs 9.7%），而零通过率从 0.9% 涨到 5.8%——宽改动不是”平均分低一点”，是”整题直接崩掉的概率高了 6 倍”。
三、能力维度上，最高完成率搭配最低交付率。 功能实现是最大的一组（126 题，46.2%），Strict 最高（0.619）而 Full-Pass 最低（10.3%）；接地理解 0.604 / 20.2%，UI 变换 0.615 / 13.6%。文档类输入也是同一形状：pooled Strict 最高（0.652），全通过率却只有 18.2%，而纯文本任务是 0.637 / 37.0%。
四、多模态输入不是”更难”，而是”换了另一种难”。 pooled Strict 按模态排：文档 0.652 > 无附件 0.637 > 视频 0.625 > 图像 0.590 > 音频 0.584，极差只有 6.8 个百分点。但Partial 判决的比例差了 4 倍：图像 25.4%、音频 13.2%、视频 13.1%，而无附件只有 6.7%、文档只有 6.2%。图像任务里近八成失败是”部分满足”而不是”完全失败”——Agent 看懂了图但没改到位。分工上，Qwen3.8-27B 在纯文本上最高（0.779）、Opus 5 在图像上最高（0.891）、Astra 拿下视频/音频/文档。
五、相对排名依赖 harness，而且可以完全反转。 附录 H 用固定的两个 solver（kimi-k3 与 Qwen3.8-27B）在三个 harness（codex 0.142.0、opencode 1.18.13、qwen-code 0.21.11）上跑全部 273 题：ME 上两个 solver 的 harness 排序完全相反（Spearman ρ = −1.00），kimi-k3 在 qwen-code 下最高、opencode 下最低，Qwen3.8-27B 正好反过来；RE 上的相关性只有 +0.50。两个模型的差距在 ME 上摆动 10.0 个百分点、在 RE 上摆动 16.2 个百分点。结论很硬：从一个 solver 得到的 harness 排序不能预测另一个 solver 的。
六、Agentic 迭代不是”锦上添花”，是数量级差异。 在 150 道 WebCompass-edit 任务上的对照：single-shot 的分级完成率 73.6%、全通过 49 题（32.7%）；agentic 是 95.1%、全通过 104 题（69.3%）。
七、执行量和完成度不成正比。 ME 上 Astra 用 32 个中位轮次、1.24M token 拿到 0.754，GLM-5.2 用 69 轮、7.29M token 只有 0.572；RE 上 Qwen3.8-27B 用 57 轮、6.72M token 拿 0.645，Astra 用 48 轮、2.33M 拿 0.667。花得多不等于做得好。 轮次分布也看得出模态代价：ME 视频任务中位 44 轮，纯文本只要 27 轮；媒体交互占了最长那一档 rollout 的 82.8% 活动量。
与同类基准的差异
论文的对照表比了六个维度——真实用户会话、输入模态、无参考验收标准、Agentic 评测、对抗式验证。Design2Code / WebSight-Test / WebRenderBench / IWR-Bench / MT-Web2Code 全都只有输入模态一项；DesignBench 两项半；WebCompass（edit）三项；SWE-bench M 两项半、SWE-Lancer（IC）三项。Co-Design Bench 是唯一六项全中的。
局限
主对比把 Claude Code harness 钉死在全部端点上（容器清单、系统提示、工具接口、仓库暂存流程统一），运行上限 3 小时 / 120 轮——这是必要的，但也意味着分数是”模型 × 这个 harness”的联合产物；附录 H 已经证明换 harness 会改排序，所以跨 harness 引用本榜是不可靠的。
任务分组分析（模态、编辑类型、能力维度）是描述性的：作者明确说这些组与赛道归属强重叠，描述的是表现而非隔离出的独立能力。成本一列是按 API 计费口径（含重试与缓存）算的执行量，不是可比的货币成本。此外，整个基准只有 273 题、10 个端点、2,730 组模型-任务对；judge 模型换成别家时排序与分数分布很稳（附录 C），但”反驳”这一步本身不保证逐条判决正确。
怎么读这张卡
引用时必须带上 Strict 与 Full 两列——只报 Strict 会把 26.4% 说成 69.9%。这两列的落差（本基准是 43.5 个百分点）本身就是论文的主结论，也是它相对其他前端基准最有价值的读数。