SlopCodeBench：AI代码基准测试为何正在失效

当代码基准测试遇上"Slop"

近日，一个名为"SlopCodeBench"的项目在 Hacker News 上引发讨论，标题《Benchmarking Opus 5 on SlopCodeBench》获得了 42 个点赞与 10 条评论。虽然热度不算爆炸级别，但它触及了当下 AI 编程领域一个愈发敏感的话题——我们究竟该如何评测大模型生成代码的真实质量？

"Slop"一词近年在英文技术社区中被广泛用于形容 AI 生成的低质量、冗余或看似合理实则经不起推敲的内容。这个词原意为泔水、残羹剩饭，2023年起被技术社区借用后迅速流行。与"hallucination"（幻觉）侧重事实错误不同，slop更强调内容的冗余性和表面合理性——它看起来像是正确的回答，结构完整、语法流畅，但缺乏真正的深度思考和精确性。在代码领域，slop表现为：函数签名合理但内部逻辑冗余、变量命名规范但算法选择不当、注释详尽但掩盖了根本性的设计缺陷。将"Slop"与"CodeBench"（代码基准测试）组合，本身就带有一层自嘲与批判色彩：这不仅是一次对所谓"Opus 5"模型的基准测试，更像是对整个 AI 编程评测体系的一次反讽式审视。这个词的流行也反映了社区对AI输出质量从最初的惊叹转向更审慎的批判性审视。

为什么现有的代码基准正在失效

从 HumanEval 到 SWE-bench 的演进

过去几年，业界评测 AI 编程能力主要依赖 HumanEval、MBPP 等函数级别的基准，随后演进到 SWE-bench 这类基于真实 GitHub Issue 的端到端任务集。

具体来说，HumanEval 由 OpenAI 于2021年发布，包含164个手工编写的 Python 编程问题，每个问题附带函数签名、文档字符串和单元测试，用 pass@k 指标衡量模型在 k 次生成中至少一次通过所有测试的概率。MBPP（Mostly Basic Python Problems）由 Google 发布，包含约1000个入门级 Python 任务。这两个基准的共同特点是聚焦于单函数级别的代码生成，任务边界清晰、输入输出明确。然而，真实软件工程中的编程任务很少如此干净——开发者面对的是模糊的需求文档、复杂的代码库上下文、多模块间的依赖关系以及需要在性能、可读性和安全性之间权衡的设计决策。

SWE-bench 的出现标志着评测范式的重要升级。它由普林斯顿大学团队于2023年提出，从 Django、scikit-learn、sympy 等12个知名 Python 开源项目中抽取了2294个真实的 GitHub Issue 及其对应的 pull request。模型需要理解 issue 描述、定位相关代码文件、生成补丁并通过项目的测试套件。这种设计大幅提升了评测的真实性，但也带来新问题：由于这些 issue 和修复方案都是公开的 GitHub 历史记录，大模型在预训练阶段极有可能已经"见过"这些数据。SWE-bench Verified 等后续变体试图通过人工验证和筛选来缓解这一问题，但基准污染的根本矛盾——公开的测试集终将被训练数据覆盖——始终难以彻底解决。

这些基准确实推动了模型能力的提升，但也带来了一个不用多说的问题——基准污染（benchmark contamination）。

基准污染指训练数据与测试数据之间存在重叠，导致模型性能被高估。在大语言模型时代，这一问题尤为严峻，原因有三：第一，现代 LLM 的训练语料规模达数万亿 token，覆盖了互联网上绝大多数公开文本，包括几乎所有公开基准的题目和答案；第二，精确去重极其困难，即使进行了 n-gram 去重，经过改写或变体形式的测试数据仍可能残留；第三，即便不是完全记忆，模型也可能通过训练中见过的类似问题模式获得不公平优势。近年来出现的"数据飞轮"效应使问题更加复杂——模型的输出被用于生成合成训练数据，这些数据中可能隐含对已有基准答案的"蒸馏"。

当训练数据中已经包含了测试集的答案，任何漂亮的通过率都值得怀疑。SlopCodeBench 这类项目的出现，某种程度上正是对"刷分文化"的一种回应：如果模型只是记住了答案，那么它在面对真正新颖、混乱、缺乏标准解的现实任务时，产出的往往就是"slop"。

通过率不等于代码质量

更深层的问题在于，绝大多数基准只关注"测试是否通过"，却忽视了代码本身的可维护性、可读性、安全性与工程合理性。一段能跑通单元测试的代码，可能充斥着冗余逻辑、错误的边界处理或潜在的安全漏洞。

从软件工程的视角来看，代码质量的度量维度远不止"能否运行"。业界已有成熟的量化指标体系，包括圈复杂度（Cyclomatic Complexity，衡量代码路径复杂性）、认知复杂度（Cognitive Complexity，衡量代码理解难度）、代码重复率、依赖耦合度等。常见的静态分析工具如 Python 的 Pylint 和 Bandit（安全扫描）、JavaScript 的 ESLint，以及跨语言的 SonarQube 和 Semgrep，都能在不执行代码的情况下，通过分析源代码的结构、数据流和控制流来发现潜在缺陷。比如一段通过所有测试但圈复杂度高达50的函数，在实际工程中几乎不可能被维护——然而在当前的基准体系中，它会被记为"满分通过"。

这正是"Opus 5 在 SlopCodeBench 上的表现"这一命题的价值所在——它试图衡量的或许不是模型能否解题，而是模型有多容易产出看似正确的垃圾代码。

"Opus 5"命名背后的深意

说个细节，截至目前 Anthropic 公开的 Claude 系列最高版本为 Opus 4 系列，"Opus 5"更像是一个前瞻性或戏谑性的假设标的。

Anthopic 是由前 OpenAI 研究副总裁 Dario Amodei 和 Daniela Amodei 于2021年创立的 AI 安全公司，其 Claude 系列模型采用 RLHF（基于人类反馈的强化学习）和 Constitutional AI（宪法AI）技术进行对齐训练。Claude 的模型层级分为 Haiku（轻量快速）、Sonnet（平衡型）和 Opus（旗舰型）。截至2025年中，Claude 4 Opus 是公开发布的最高级别版本，以其在复杂推理、长文本处理和代码生成方面的能力著称。Claude 系列的版本迭代遵循能力逐步提升的路线，但每一代的实际进步幅度往往需要在多个独立基准上交叉验证才能确认。

这种命名方式恰恰强化了项目的批判基调：无论模型迭代到第几代，只要评测方法论本身存在缺陷，我们对"进步"的度量就始终建立在不牢靠的地基之上。

这也提醒从业者，在阅读任何"新模型刷新 SOTA"的宣传时，都需要追问三个关键问题：

• 测试集是否可能已被训练数据覆盖？
• 评测指标是否只看通过率而忽略工程质量？
• 任务是否足够贴近真实开发场景中的混乱与不确定性？

对 AI 编程实践的启示

评测应回归工程本质

SlopCodeBench 的核心洞见在于，代码的价值不在于"能否运行"，而在于"能否长期维护、被人理解并安全部署"。未来更有意义的代码基准，或许应当引入代码审查视角、静态分析指标、安全扫描结果，甚至引入资深工程师的主观评分作为交叉验证。

具体而言，将 SonarQube 的代码质量门禁、Bandit 的安全漏洞检测、以及基于认知复杂度的可维护性评分整合进评测流水线，可以构建一个多维度的代码质量雷达图。这种评测方式能够揭示模型在不同质量维度上的真实表现——一个模型可能在功能正确性上得分90%，但在安全性上仅有60%，在可维护性上更低至40%。这种细粒度的画像远比一个笼统的"通过率"数字更有决策参考价值。

开发者需要建立自己的"内部基准"

对于实际使用 AI 编程助手的团队而言，与其盲信公开榜单，不如建立贴合自身业务场景的私有评测集。

构建私有评测集需要系统性方法：首先，从历史工单系统（如 Jira、Linear）中筛选具有代表性的 bug 修复和功能开发任务，确保覆盖团队日常面对的典型挑战；其次，为每个任务构建包含完整代码库上下文的测试环境，包括相关文件、依赖关系和编码规范文档；再次，设计多维度的评分标准，不仅包括功能正确性，还应涵盖是否遵循团队的架构规范、命名约定和错误处理模式。关键在于，私有评测集应定期更新以防止模型通过微调或缓存"记住"答案，同时保持足够的任务多样性，避免评测结果偏向特定类型的编程任务。像 Anthropic 的 METR 和 Google 的内部代码评测实践都采用了类似的滚动更新策略。

用真实的历史工单、真实的代码库上下文去测试模型，才能得到有参考价值的结论。这也是应对基准污染最务实的手段。

结语：警惕对"分数"的迷信

SlopCodeBench 或许只是一个带着调侃意味的小项目，但它抛出的问题却极具现实意义。在 AI 编程能力突飞猛进的今天，我们比任何时候都更需要一套诚实、抗污染、关注工程质量的评测体系。

真正衡量一个编程模型的，不该是它在精心设计的题库上刷出的漂亮数字，而是它在混乱、真实、无标准答案的工程现场中，能否持续产出值得信赖的代码——而不是更多的 slop。