文章介绍了SlopCodeBench这一新型编程基准测试，它通过多阶段需求演化评估模型维护代码库的能力。测试显示，Opus 5在该基准子集上获得24%的严格通过率，仅略高于Opus 4.6的17%，表明当前顶尖模型表现仍不理想。

SlopCodeBench 基准测试：评估 Opus 5 的代码维护能力

核心发现

上周五，我在 SlopCodeBench（威斯康星大学麦迪逊分校 @GOrlanski 实验室于 2026 年 3 月发布的新基准测试）上对三个 Claude 模型（Opus 4.8、Sonnet 5 和 Opus 5）进行了测试。该基准测试的独特之处在于：每个挑战包含多个"检查点"，模型无法预先获知完整问题，必须随着新需求的逐步披露来演化代码库。

关键结果： - Opus 5 在测试子集上获得 24% 的严格通过率（4/17 个检查点），仅略高于原始论文中 Opus 4.6 的 17% - Opus 4.8 和 Sonnet 5 均仅获得 6% 的通过率（各 1/17 个检查点） - 所有模型均未能在任何挑战中完成全部检查点且无缺陷，即使是标记为"简单"的问题

测试方法

我让 Claude 从基准库中选取了 3 个问题，共 17 个检查点： 1. circuiteval（简单，8 个检查点）— 电路仿真 CLI 2. databasemigration（中等，5 个检查点）— 数据库迁移工具 3. dynamicconfigservice_api（困难，4 个检查点）— 动态配置服务 API

所有模型使用相同的提示词，在 Claude Code 框架中并行运行，每个检查点使用全新的上下文窗口。严格通过标准要求：所有新增代码必须通过测试，且所有从之前检查点继承的回归测试也必须保持绿色。

代码质量退化趋势

复杂度持续增长： 没有一个模型能在不增加复杂度的情况下完成所有挑战。Opus 4.8 最为极端，在 8 个检查点中复杂度上升了 70%，其最差函数的圈复杂度达到 93。

代码膨胀严重： Opus 5 编写的函数数量是 Opus 4.8 的 5 倍。虽然部分增长来自测试代码，但生产代码量仍增加了约 1.8 倍。

重复代码问题： Opus 4.8 的代码重复率从 4.6% 飙升至 16.8%，而 Opus 5 基本持平（2.41% 到 2.64%）。

"垃圾代码"检测： 绝大多数代码行触发了至少一条基准测试的"垃圾代码"规则：Opus 4.8 为 98%，Opus 5 为 93%，Sonnet 5 为 89%。被标记为"过于冗长"的代码行从检查点 1 的约 65% 增长到检查点 8 的约 80%。

成本效益分析

有趣的是，Sonnet 在第一个检查点成本最高，但到问题结束时反而成为最便宜的模型——一旦基础架构建立，工作转为维护模式，成本优势开始显现。

个人解读

我认为 SlopCodeBench 终于为一些我此前只能凭经验论证的观点提供了数据支撑：对于真正的软件工程工作，逐问题构建时，当前模型无法在无人监督的情况下可靠运行。

一个更有前景的评估思路是：让前沿模型（如 Opus 5、Fable 5）编写前 N 个检查点，然后测试较简单的模型（如 Sonnet 5）能否实现第 N+1 个检查点。这能放大信号，检验智能模型是否真正维护了易于变更的高质量代码。

当模型能在类似 SlopCodeBench 的迭代式基准测试中获得 80% 以上的通过率时，我才会对让它们"无人值守"地运行感到更有信心。

根据评论内容，总结主要观点如下：

1. 对Opus 5模型的评价存在分歧 - 正面观点：部分用户认为Opus 5是“不错的改进”（nice improvement），尤其在效率方面（“用更少token，更快”），并称“这是Opus 5的闪光点”（This is where Opus 5 shines）。 - 负面观点：有用户批评其“过度自信且愚蠢”（overconfident stupid model）、“生成太多垃圾内容”（generate too much slop），并已回退使用旧版本（“reversed back to fable and codex sol”）。

2. 基准测试本身的价值与问题 - 正面：有用户认为该基准测试“首次瞄准了非功能性和长期需求”（first I've found that start to aim at some of the non-functional and longitudinal requirements），并赞赏“确定性评分很好”（deterministic scores are so nice）。 - 负面：有用户批评“基准测试太多，模型本身反而被忽视”（So many benchmarks more the models themselves），建议“统一标准”（make one unified standard to benchmark all），否则“基准测试这个词已失去意义”（this word lost its meaning）。

3. 对代码质量长期退化的关注 - 有用户希望“你带来的对代码库长期劣化的关注能反馈给实验室”（all of the attention you're bringing to the longitudinal sloppification of codebases makes it back to the labs），但担忧“他们可能优先改进花哨的一次性演示而非这个”（hard for them to prioritize this over improving flashy one-shots）。

4. 其他技术讨论 - 有用户质疑“这是否是系统提示词问题”（To what degree is this a harness/system prompt problem），建议模型“默认以最小影响实现新功能”（implement new stuff with as little impact on the existing stuff as possible）。 - 有用户提出“可维护性可能是由这些信号描述的高维空间”（what 'maintainable' is is probably some high dimensional space described by these signals），并提到“形式化方法最近频繁出现”（formal methods pop up a lot recently）。