一个代码模型通过了功能测试，下一步应该测什么？9 月 11 日提交的 CQBench 给出的答案不是再加一批普通编程题，而是从近 79 万个真实函数任务中挑出 27346 个“易错题”：旧模型能写出不太空洞的实现，却常在同一题上触发多条静态缺陷或安全规则。新模型要在这些已知薄弱点上少留问题，才算过关。
这让代码评测从“能不能生成答案”推进到“答案会留下什么质量债”。代价也写在筛选方法里：CQBench 主动放大了失败，衡量的是模型面对已知易错任务时的鲁棒性，不是 AI 代码在真实项目中的总体缺陷率，更不能证明程序语义正确。
27346 题不是随机样本，而是三道门筛出的压力赛道
论文先建立了 787562 个函数级任务。Python 和 Java 来自 CodeSearchNet 衍生的 HMCorp，C 来自 TheVault；每个任务保留自然语言说明、函数签名与人类实现，再让 OpenAI、DeepSeek-Coder 和 Qwen2.5-Coder 生成对应实现。这里的“OpenAI”也不是同一个模型：Python、Java 使用 HMCorp 中的 gpt-3.5-turbo，C 使用 gpt-oss-20B，因此跨语言绝对数不能被当成单一模型的横向成绩。
在测量完整的 255879 个 Python、193837 个 Java 和 177611 个 C 任务上，作者依次设置三道门。
第一道门先排除近乎空实现：模型输出的平均有效代码行数或 Halstead Volume 至少达到人类参考的 10%。这个门槛只证明代码没有短到明显退化，不证明它完成了需求。
第二道门要求至少两个通过复杂度门的旧模型，各自触发不少于三条纳入统计的发现。第三道门再要求这些模型共享至少一个缺陷类别：要么是 ODC（正交缺陷分类）类型，要么是归一化后的 CWE 弱点类别。人类参考实现还必须能解析、包含目标函数，并且不是桩代码或常量式空操作。
最终留下 10354 个 Python、10103 个 Java 和 6889 个 C 任务。其中 13693 题由共同的 ODC 缺陷类型入选，3176 题由共同 CWE 入选，10477 题同时满足两类条件。仓库没有再截取一个预设的 Top-N，而是保留全部满足固定规则的任务。
这套构造最重要的信息不是“27346”有多大，而是分母发生了变化：它从普通任务集合变成了旧模型已经暴露过问题的集合。若模型在这里频繁失败，可以说它没有绕开已知故障模式；若它成绩很好，也只能说明对这批压力题更稳健，不能直接换算成生产代码事故率。
四类分析合在一起，仍没有跨过“程序是否正确”这条线
CQBench 用 Pylint、PMD 和 Clang-Tidy 分别检查 Python、Java 与 C，再把不同工具的规则映射到 ODC；安全问题由 Semgrep 扫描，并沿用规则自带的 CWE 与严重度。ODC 原本就是把具体缺陷归入可比较的类型，用缺陷分布反推开发过程，而不是判定某段代码是否满足业务需求。
对新模型，仓库的主指标 clean_strict_at_1 要求一次生成同时满足：可解析、目标函数存在且参数数量匹配、不是桩或常量空操作、结构不退化，并且没有被纳入的静态缺陷与安全发现。任务、参考实现、四组基线结果、冻结的 Semgrep 规则、ODC 映射、完整性哈希、原生与 Docker 执行路径都已公开。对 9 月 11 日前固定提交的工件核对显示，任务文件恰好包含 27346 个不重复主键，语言分布与论文一致；人类基线也能按同一批主键完整对齐。
但“严格干净”仍只是对这套分析器和规则干净。CQBench 不编译或运行提交，不提供覆盖每题行为的测试预言，也不判断两段实现是否语义等价。Semgrep 命中意味着代码形态符合某条弱点规则，不等于攻击者已经能够利用；没有命中也不等于没有漏洞。OWASP 对静态分析的定位同样是帮助审计者缩小检查范围，并明确提醒这类工具同时存在假阳性与假阴性。
人类参考代码在 CQBench 上也不天然是“无缺陷金标准”。论文用 Claude Opus 4.8 演示时，从三个入选分层按比例抽取每种语言 200 题。人类参考在 Python、Java、C 子集中分别有 62.0%、57.5% 和 72.0% 至少触发一项缺陷；Claude 则为 63.0%、64.5% 和 68.5%。这不是“Claude 与人类质量相当”的普遍结论，而是在故障富集的 600 题子集里，两者都频繁触发分析器规则。
更有用的结果是故障类型是否延续：Claude 在 62.8% 的样本上再次触发该题入选时的共同 ODC 或 CWE 类别。它说明 CQBench 捕捉到了一部分能跨模型延续的薄弱结构，也说明测试目标是复现已知故障类别，而不是寻找所有未知错误。
代码 Agent 需要两条证据链，而不是一个总分
CQBench 补的是“功能通过以后怎么办”，却不能独自回答“功能是否通过”。更稳妥的评测应把两条证据链分开：第一条用编译、单元测试、属性测试或可执行预言验证行为；第二条再用静态分析、依赖与配置检查、动态安全测试和人工审计寻找质量与安全债。两条都过，才接近可交付代码。
CWEval 提供了一个互补参照。它为 119 个安全敏感任务同时准备功能与安全测试预言，目标就是避免“功能测试通过”或“静态扫描没有报警”被单独当成安全结论。CQBench 的规模和故障富集适合做回归压力测试，CWEval 这类可执行安全任务则更接近验证结果；真实仓库还需要构建系统、调用上下文、依赖版本和运行配置。
因此，CQBench 最适合进入代码 Agent 的发布门禁，而不是宣传榜单：模型升级后，先看它是否仍在相同易错题上复发，再追到具体 ODC/CWE 类别；随后用可执行测试确认行为，用安全验证确认影响。真正值得跟踪的不是某个总分是否上升，而是模型能否在功能不退步的前提下，把反复出现的检查遗漏、接口错误、硬编码凭据、命令注入和内存安全问题逐类消掉。
