一句话定义：SlopCodeBench 是一类衡量 AI 生成代码“泔水度”的评测基准（benchmark）。它不只问这段代码能不能跑通，还算一算：为了跑通，它往仓库里加了多少本来不必加的东西。
先解释“slop”。这个词原来指 AI 批量生成的大量看似完整、实则无用的内容，中文常译成“泔水”或“注水”。放到代码里，slop 就是那种能编译、能过测试，但没人愿意接手维护的产物：为一个函数引入三个依赖，为改一行逻辑重写整个文件，调用一个根本不存在的 API 却写得像真的。
它怎么打分。传统基准（比如 HumanEval、SWE-bench 这一类）像体检只看“能不能站起来”，核心指标是“解没解决”。Slop 类基准更像验收装修：不仅看水电通不通，还算你多砸了几面墙、多买了多少用不上的材料。
| 维度 | 看什么 | 生活化说法 |
|---|---|---|
| 正确性 | 隐藏用例是否通过 | 灯亮不亮 |
| 冗余度 | 相对“最小修复”多写了多少行、多少重复实现 | 换个灯泡拆了整面墙 |
| 依赖膨胀 | 是否为一件事引入整套新库 | 为拧一颗螺丝买一工具房 |
| 幻觉接口 | 调用了不存在的函数、参数、配置项 | 报了个不存在的门牌号 |
| 测试质量 | 测试能不能真抓到 bug（常用变异测试检验） | 锁装了，但什么钥匙都能开 |
| 可维护性 | 命名、结构、注释、安全气味 | 走线像一盘意面 |
通常做法是自动指标打底（diff 体积、圈复杂度、死代码、lint 与类型错误、测试变异存活率），再加人工评分表（rubric）问一句最关键的：这份 diff，你愿不愿意接手？ 有些设计还会专门计算“过度修改率”：题目只要改三行，模型交了三百行。
和相邻概念的区别：SWE-bench 衡量“能不能解决”，SlopCodeBench 衡量“解决同一个问题要付出多少代价”。前者是能力上限，后者是交付成本。
关于排名与档位争议。围绕某些旗舰模型（以及它们的高推理档位）的名次讨论，争议一般来自三处：一是推理强度调高往往同时提升正确率、又诱发过度设计——想得越久，越容易把一个小需求做成一个项目；二是权重一变名次就换，冗余度算重一点，“话少”的模型立刻上浮；三是输出风格的偏置，长篇大论的模型在“通过率”上占便宜，在“泔水度”上吃亏。所以看到“谁第几、某档位公不公平”的说法，先看榜单公开的题源、权重与评审方式。具体模型版本、档位命名和分数，以官方页面为准。
实际意义：对团队，slop 是一种可以量化的交付成本，值得自建小评测，把“我的仓库能不能接受这种风格”变成一条可回归的指标；对普通人，判断 AI 给的代码有个土办法——先问一句“删掉一半还能不能跑”。能跑，那多半就是泔水。