在SlopCodeBench上对Opus 5进行基准测试

长周期编码基准揭示模型退化

**当前的前沿LLM，包括Opus 5，目前尚不能被依赖用于“lights-off”软件工程，因为它们在需求演变过程中难以保持代码库质量。**虽然Opus 5相较于其前身仅有微小改进，但它仍然无法在不引入缺陷或增加技术债务的情况下完成复杂的多阶段编码挑战。

大多数传统编码基准会一次性提供完整的问题陈述，这奖励了能够解决即时问题的模型。相比之下，SlopCodeBench（由威斯康星大学麦迪逊分校的研究者在2026年3月提出）通过多个“检查点”测试模型演进代码库的能力。模型会逐步接收需求，迫使它调整现有代码以适应新规格——这一过程与真实世界的软件工程相呼应。

Opus 5在SlopCodeBench上的表现

**Opus 5在SlopCodeBench的一个子集上达到了24%的严格通过率，相比原论文中报道的Opus 4.6的17%略有提升。**然而，“严格通过”指标——要求所有新测试通过且所有继承的回归测试保持绿色——揭示了显著的局限性。

在跨越17个检查点（涵盖简单、中等和困难问题）的测试运行中，结果如下：

• Opus 5: 4/17 严格通过 (24%)
• Opus 4.8: 1/17 严格通过 (6%)
• Sonnet 5: 1/17 严格通过 (6%)

尽管通过率更高，Opus 5表现出对“昂贵冗余”的倾向。它编写的函数数量是Opus 4.8的五倍，并且产生的总代码行数显著更多（大约29,000行，而其他模型仅为9,000行）。尽管这部分体积主要用于测试，但生产代码量的增加并未带来正确性的相应提升。

Measuring "Slop": 代码质量和复杂性

**SlopCodeBench使用41个确定性指标来跟踪代码库退化，表明所有测试模型的复杂度随时间增长。**这些指标被分类为大小、复杂度（例如，环路复杂度）、重复、分解和规则违规。

代码质量的主要发现：

• Complexity Growth: 没有模型在不增加跨检查点复杂度的情况下完成挑战。Opus 4.8表现出最极端的退化，其最差函数的环路复杂度达到93。
• Code Duplication: Opus 4.8的重复率从4.6%上升到16.8%，因为新需求与初始设计冲突。Opus 5保持相对平坦（2.41%到2.64%），表明它在处理结构变化方面略有改进。
• Slop Density: 大量代码行触发了“slop规则”（衡量冗余和不良模式的指标）。在三个问题中，Opus 5的93%代码行被标记。与人工审查的AI生成TypeScript单仓库相比，Opus 5生成的“lights-off”代码每千行代码的slop触发次数超过11倍。

通往可维护AI代码之路

**SlopCodeBench上的高失败率表明，维护代码库的能力是解决单个编码任务能力的独立技能。**为了提高软件质量的信号，作者提出了一种“交接”评估：让前沿模型（如Opus 5或Fable）编写前N个检查点，然后测试较小的、“笨拙”的模型（如Sonnet 5）是否能够成功实现检查点N+1。

如果较小的模型无法在较大模型的工作基础上进行构建，这强烈表明较大的模型未能维持一个干净、可维护的架构。

社区视角与反驳

从业者的讨论表明，结果可能受到代理 harness 和系统提示的影响，而不仅仅是模型的原始能力。

"当代理可以触及任何东西时，Slop会积累，因此将其限制在一个接缝并让它旁添加而非就地编辑，比模型选择更重要。"

其他用户指出，虽然Opus 5在速度和令牌效率方面相比4.8有所改进，但它可能不是之前版本或其他专门模型（如Fable）所展示的“革命性”飞跃。

基准挑战摘要

挑战	难度	重点
circuit_eval	简单	CLI, 布尔逻辑, 向量信号, 三值逻辑, 优化
database_migration	中等	SQLite 迁移, 数据转换, 外键, 回滚
dynamic_config_service_api	困难	REST API, 版本控制, 模式注册, 变更管理工作流