上次说“没有靠谱的尺子”，这次 Dex Horthy 找到了一把——Opus 5 实测通过率只有 24%
内容提要
Dex Horthy在第三篇文章中承认此前“无好基准”的判断有误，介绍新基准SlopCodeBench（SCB），通过检查点模拟需求逐步演进。他实测Opus 5、Sonnet 5、Opus 4.8，最强Opus 5严格通过率仅24%，其余仅6%。代码质量指标显示劣化严重，结论是当前模型仍无法无人值守运行，但SCB提供了可追踪的衡量工具。
延伸解读
基准设计：从一次性解题到渐进式维护
SCB 的核心创新在于用检查点模拟需求逐步演进，而非一次性给出完整问题。这种设计更贴近真实开发中需求不断变化、代码持续迭代的场景。论文发布时，最强模型 GPT-5.4 和 Opus 4.6 的严格通过率仅 11% 和 17%，说明该基准尚未被刷穿，能有效区分模型在长期维护任务上的能力。
实测结果：通过率低但信号明确
Dex 的六小时实测中，Opus 5 严格通过率 24%，Sonnet 5 和 Opus 4.8 仅 6%，且无一模型能完整通过任何一道题。这印证了当前模型在无人值守的长期维护任务上仍不可靠。但 SCB 提供了可量化的追踪工具，未来若模型在类似基准上达到 80% 以上，或可成为“放心关灯”的参考信号。
代码质量指标：劣化趋势明显
SCB 的 41 项质量指标显示，模型生成的代码中超过 89% 的行触发劣化规则，且“啰嗦”代码占比随检查点推进持续上升。Opus 5 通过拆分小函数降低复杂度，但函数数量是 Opus 4.8 的 5 倍；Opus 4.8 复杂度上涨 70%，重复率从 4.6% 升至 16.8%。这些指标虽非完美，但方向性结论值得持续追踪。
未来方向：成本与接手实验
Dex 提出，随着模型能力增强，成本、耗时和 token 消耗将比单纯通过率更重要。他设想让强模型搭建前几个检查点，再由弱模型接手后续，以间接衡量代码可维护性。这种“降级接手”实验可能比静态指标更可靠，但需注意检测器目前仅支持 Python，跨语言验证仍需完善。
Q&A
SlopCodeBench 是什么？它和传统基准有什么不同？
SlopCodeBench（SCB）是威斯康星大学麦迪逊分校 Gabe Orlanski 实验室在 2026 年 3 月发布的长周期编程基准。它通过设置多个检查点，模拟真实开发中需求逐步演进的过程，模型需要不断接收新需求并在已有代码上迭代，而不是像传统基准那样一次性把整个问题摊开。
Dex Horthy 实测中，Opus 5、Sonnet 5、Opus 4.8 的严格通过率分别是多少？
在 Dex Horthy 的六小时实测中，Opus 5 的严格通过率为 24%（4/17），Sonnet 5 和 Opus 4.8 均为 6%（1/17）。
SCB 的严格通过标准是什么？为什么它比传统基准更严格？
严格通过不仅要求新增功能全部通过，还要求从之前检查点继承下来的所有回归测试也必须全部通过。这意味着如果模型在某个检查点留下缺陷，后续所有检查点都会失败，这模拟了真实项目中隐藏的坏设计会持续拖累后续迭代的情况。
SCB 用哪些指标来量化代码质量？
SCB 使用 41 项量化指标，分为六类：体量（代码行数、函数数等）、复杂度（圈复杂度、嵌套深度等）、重复度（克隆代码行数）、分解质量（单次调用函数、未使用变量等）、规则违规（静态检查错误、测试劣化规则等）、依赖图（传播成本、循环依赖等）。
Dex Horthy 的实测中，模型生成的代码质量劣化有多严重？
在三个模型生成的代码中，绝大多数代码行都至少触发一条劣化规则：Opus 4.8 为 98%，Opus 5 为 93%，Sonnet 5 为 89%。被标记为“啰嗦”的代码行占比随检查点推进持续走高，从第一关的约 65% 涨到第八关的约 80%。
Dex Horthy 对 SCB 的结论是什么？他对未来模型能力有何看法？
Dex 认为 SCB 印证了第一篇文章的判断：今天的模型还不能在无人值守的情况下“关灯”运行。但他将 SCB 视为一把可以持续追踪的尺子，如果未来模型能在类似 SCB 的基准上达到 80% 以上的严格通过率，他会对“放心关灯”感觉好很多。
Dex Horthy 提出了哪些改进 SCB 或未来实验的方向？
Dex 提出了几个改进方向：将九次测试完全并行跑以缩短时间；将检测器从 Python 移植到 TypeScript 等更多语言；探索更多评估维度，如对抗式评审或针对圈复杂度的确定性质量背压机制；以及一个实验设想：让强模型（如 Opus 5）搭建前几个检查点，然后看弱模型（如 Sonnet 5）能否顺利接手完成下一个检查点，以此间接衡量代码的可维护性。
