三个任务,十七个检查点,九次完整运行——没有一次,模型把代码从头写到尾还留着零缺陷。这是HumanLayer上周公开的一份编程基准测试结果。
拿下第一名的Opus 5,严格通过率也只有约24%,4个检查点过关,剩下13个都留了尾巴。
发生了什么:分数第一,依然全线失守
HumanLayer用的基准叫SlopCodeBench。它不像常见测评那样一次性甩需求,而是逐检查点追加规格——每加一个新功能,都要把之前所有检查点的回归测试重新跑一遍。这更接近真实项目:需求慢慢冒出来,旧代码不会因为你写了新功能就被原谅。
这次测了三个任务:circuit_eval(易,8个检查点)、database_migration(中,5个)、dynamic_config_service_api(难,4个)。判定标准是strict pass——新功能全绿,继承下来的历史测试也要全绿,一处不达标就算这个检查点失败。
Opus 5前三个检查点全过,一度是全场唯一留下严格通过记录的模型——其兴也勃焉,其亡也忽焉,第四个检查点起,每一步都带着新缺陷,后面再没补上来。三个任务全部失败,包括标注为"易"的circuit_eval。
Opus 4.8和Sonnet 5各拿1/17,约6%。这个约24%,不能直接拿去和三月那篇原始论文里Opus 4.6的17%比——题目子集不同,不是同一场考试。三个任务九次运行的样本量也偏小,这份排名只能当方向信号,不能当稳定结论。
代码量暴涨,但别急着说"不可维护"
Opus 5为了拿这个成绩,写了约29065行代码,是另外两款模型的三倍多。生产代码量约为Opus 4.8的1.8倍,函数和可调用对象数量约为它的5倍。
三款模型的代码几乎都触发了SlopCodeBench内置的代码异味规则,具体对比如下:
| 指标 | Opus 5 | Opus 4.8 | Sonnet 5 |
|---|---|---|---|
| 严格通过检查点 | 4/17(约24%) | 1/17(约6%) | 1/17(约6%) |
| Slop规则命中率 | 93% | 98% | 89% |
| 生产代码倍数(相对Opus 4.8) | 约1.8倍 | 基准 | 与Opus 4.8相近 |
| 函数/可调用对象倍数 | 约5倍 | 基准 | 与Opus 4.8相近 |
标记为"过于冗长"的代码行占比,从检查点1的65%左右涨到检查点8的80%左右,连分数最高的Opus 5也不例外。
这不能直接读成"代码写得越多越烂"。规则本身可能偏严格,代码量、复杂度和真实可维护性之间的关系,这份报告没有验证清楚。多写测试也可能是加分项——Opus 5一半以上的新增代码是测试代码,这在真实工程里通常不算坏事。
谁该在意,接下来看什么
想让编码智能体无人值守干活的团队,这次结果是个提醒:目前没有一款模型能在没人盯着的情况下,把一个真实需求从头做到尾还不留缺陷。现阶段该做的,是保留人工review,规定每个检查点跑完都要过一遍历史回归测试,把任务边界卡在短周期、可复核的范围内,别把长期维护型任务甩给模型自治。
负责评估代码质量和维护成本的工程负责人,更该盘一遍自己团队的口径:这次代码量、函数数、slop命中率全面上涨,如果放进自己的review流程,是否真的会拖慢维护速度?比起盯着这次谁分高,更该盯SlopCodeBench后续会不会扩大样本、把逐检查点评测变成行业通用动作。
具体测试日期、模型配置、提示词和工具环境、每个检查点的失败原因、运行成本,报告都没有交代,复现难度目前还看不清。
【锐评】真正该盯的不是这次哪个模型赢,而是SlopCodeBench会不会把"逐检查点评测"钉成行业标准——钉住了,今天这份不好看的成绩单才算数。