协作编程评测：部分满足为何不等于完整交付

1. 一句话结论

Co-Design Bench 把真实用户会话中的多模态改码请求做成无参考评测：它要回答的不是“模型能不能写代码”，而是“智能体能不能把用户的多模态要求改成一个真正可运行、且完整满足隐藏验收标准的应用修订”。论文给出的核心信号很直接：最强端点平均能过 69.9% 的验收标准，却只完整满足 26.4% 的任务。

2. 方法要点

核心思路是“真实请求 + 可运行改前应用 + 隐藏验收标准 + 先判后驳”。作者从 37,463 条去重查询、26,314 次真实用户编码会话中整理出 273 个任务。任务分为多模态编辑（ME）与仓库编辑（RE）：前者是带可选图像、音频、视频、文档输入的局部修改，后者是跨仓库的协同修改。每个任务都配一个规范化请求和一个可运行的改前应用，另有 2,331 条隐藏的专家验收标准。

评分不做“有标准答案代码”的对比，而是先判后驳：先用源码与浏览器证据判定每条验收标准是否通过；对判为通过的标准，再让一个独立的大语言模型验证器提出反驳；视觉与交互类断言也在没有标准答案代码、没有目标截图的情况下审计。换句话说，它把“看起来改对了”拆成可核查的证据链，降低单次模型判分直接放行的风险。

伪代码按论文协议抽象如下：

def judge_then_refute(task, patch, criteria):
    evidence = collect(task.app, patch)  # 源码与浏览器证据
    results = []
    for c in criteria:
        verdict = judge(task.request, patch, c, evidence)
        if verdict.passed:
            verdict = refute(task.request, patch, c, evidence, llm_verifier)
        results.append(verdict)
    return {
        "criteria_pass_rate": mean(v.passed for v in results),
        "task_success": all(v.passed for v in results),
    }

关键设计不在“多写几条测试”，而在判断与反驳分离：先判断单条标准，再专门挑战正判。这样能暴露“部分要求满足、整体任务没完成”的情况，也更贴近真实协作改码。

3. 关键数字

这张表最值得看的是结果行：69.9% 与 26.4% 不是同一层面的分数。前者按验收标准平均，后者按任务完全满足计。开发者如果只看“标准通过率”，容易把“改对大半”误当成“交付完成”。原文没有给出相对基线的提升幅度，因此这里不补造数字。

4. 局限与前提

适用场景很明确：局部多模态编辑与仓库级协同修改，评测对象是能执行改动、可被浏览器与源码证据检查的编码智能体。前提是任务有可运行的改前应用，评判侧能采集证据，并愿意承担独立大语言模型验证器的调用成本。

边界也要看清。

• 基准是无参考设计，不依赖标准答案代码或目标截图，这减少了参考泄漏，但也把压力转移到证据采集与验证器判断上。
• 验收标准是隐藏的，适合做榜单或盲测；如果团队想本地调试，缺少标准明细就只能做近似自测。
• 论文摘要没有列出具体失败案例、跨运行稳定性与人工复核一致性，这些不能靠摘要补写。
• 结果只说明“十个端点中最强端点”的表现，不能直接外推到所有模型或所有真实项目。

5. 能不能用

论文注释给出了项目页，但摘要没有明确代码与权重是否开放、以什么许可开放；要用先看项目页与正文的发布物，不要假定可直接下载复现。本地复现的最低条件是：准备可运行的改前应用，能采集源码与浏览器证据，接入同一套先判后驳评判协议，并准备一个独立的大语言模型验证器。若隐藏验收标准不公开，本地只能做流程复现和近似评分，不能声称复现官方分数。

对开发者的实用结论：把它当作“协作改码的完整交付检查表”比当作单一跑分榜更有价值。自测时至少同时记录标准通过率与任务完全满足率，否则很容易高估智能体的交付能力。

参考来源

• Co-Design Bench 论文摘要（arXiv）
• Co-Design Bench 全文 HTML（ar5iv）