本文永久链接 – https://tonybai.com/2026/07/28/why-software-factories-fail-part-3-slopcodebench-opus-5-benchmark

大家好，我是Tony Bai。

导读： “没有好的基准能衡量可维护性”——这是 Dex Horthy 在系列第一篇里的判断。这一次，他食言了，但食言的方式是拿出证据打自己脸：一个叫 SlopCodeBench 的新基准，用“边写边加需求”的方式模拟真实开发，逼模型在几十个检查点里持续维护同一份代码。Dex 亲自把 Opus 5、Sonnet 5、Opus 4.8 拉进来跑了六个小时，最终成绩单是：最强的 Opus 5，严格通过率只有 24%。

文章要点：

  • Dex 在系列第三篇里承认：Part 1 说“没有好的可维护性基准”这句话不完全对，新基准 SlopCodeBench（简称 SCB）就是他要介绍的答案；
  • SCB 的设计专门针对 Part 1 提出的痛点：传统基准一次性把整个问题摊开，SCB 则用“检查点”机制模拟真实开发中需求逐步演进的过程；
  • 基准本身还远没被打穿：论文公布时最强模型 GPT-5.4、Opus 4.6 的严格通过率分别只有 11%、17%；
  • Dex 亲自用三道题、17 个检查点，把 Opus 5、Sonnet 5、Opus 4.8 拉进一场六小时的真人测评：最强的 Opus 5 拿到 24% 严格通过率，其余两个模型只有 6%；
  • 更扎心的数据在质量指标上：几乎所有模型生成的代码里，超过 90% 的代码行都会触发“劣化探测器”；Opus 5 生成的代码复杂度指标虽然更低，但函数数量是 Opus 4.8 的 5 倍；
  • Dex 给出的结论并不悲观也不乐观：这个信号印证了 Part 1 的判断——今天的模型还不能在无人值守的情况下“关灯”运行，但至少现在有了一把可以持续追踪的尺子。

开场：Part 1 立的 flag，Part 3 亲自来打

在系列第一篇里，Dex Horthy 撂下过一句很硬的话：没有好的基准能衡量一个模型维护代码库质量的能力。这句话当时是用来解释“为什么关灯工厂跑不通”的——测试能在几秒内给你反馈，但一份糟糕架构的代价要几个月甚至几年后才会显现，现有的基准测试大多是“一次性把问题交代清楚，看模型能不能一把解决”，根本没法评估这种拖后腿的长期代价。

这一篇，Dex 决定自己把这个坑填上。他没有继续空谈，而是找到了一个专门针对这个问题设计的新基准，并且亲自跑了一场六小时的实测。

SlopCodeBench 是什么：把“问题一次性摊开”这个老毛病治好

这个新基准叫 SlopCodeBench（下文简称 SCB），是威斯康星大学麦迪逊分校 Gabe Orlanski 实验室在 2026 年 3 月发布的长周期编程基准。它想解决的正是 Dex 在第一篇里点名批评的那个毛病：哪怕是“更大更复杂”的基准，本质上依然是把整个问题一次性摊开给模型看，这和真实软件开发中“需求是逐步浮现的”完全不是一回事。

SCB 的解法是给每一个挑战设计多个“检查点”（checkpoint）：模型一开始并不知道完整的需求全貌，而是要随着代码库的演进，不断接收新的需求更新，在已有代码的基础上继续迭代——这更接近真实世界里一个功能需求从雏形到完善的过程，而不是一道摆在那里等你去解的孤立考题。

这个基准目前还远没有被“刷穿”：在论文发布时，用来测试的最强模型 GPT-5.4 和 Opus 4.6，严格通过率分别只有 11% 和 17%。换句话说，这是一个当下前沿模型也啃不太动的硬骨头。

Dex 的六小时真人测评：三题十七关

光看论文数据不过瘾，Dex 干脆自己上手跑了一场实测。上周五，他让 Claude 从 SCB 的题库里挑出三道题，覆盖简单、中等、困难三个难度，一共 17 个检查点：

  • circuit_eval（电路仿真，简单难度，8 个检查点）
  • database_migration（数据库迁移，中等难度，5 个检查点）
  • dynamic_config_service_api（动态配置服务 API，困难难度，4 个检查点）

三个模型——Opus 5、Sonnet 5、Opus 4.8——被并行拉进同一场测试，每个检查点都用全新的上下文窗口，所有模型拿到完全相同的提示词，统一跑在 Claude Code 这套 harness 里。Dex 全程盯了六个小时。

他关心的核心指标是“严格通过”（strict pass）：不仅新增功能要全绿，从之前检查点继承下来的所有回归测试也必须全部通过。

这意味着如果某个模型在第 4 关搞砸了什么，哪怕后面几关的新功能做得再漂亮，只要那个遗留缺陷没被顺手修好，后续所有检查点都算不通过——这跟真实项目里“一个隐藏的坏设计会持续拖累后面所有迭代”是一个道理。

结果是：在全部 9 次测试跑动中，没有一个模型能在任何一道题里从头到尾全部通关，哪怕是标着“简单”难度的那道题。

成绩单：Opus 5 拿下 24%，其他两个只有 6%

最终成绩单出炉：Opus 5 拿到了 4/17 的严格通过率，约合 24%——比 SCB 论文里 Opus 4.6 的 17% 高不了太多。Opus 4.8 和 Sonnet 5 都只拿到 1/17，约合 6%，而且巧的是，两者通过的都是同一道题（database_migration 的第一关）。

Opus 5 拿下的 4 个通过检查点，是 circuit_eval 开局的前三关，加上 database_migration 的第一关。也就是说，即便是表现最好的模型，也只是在最简单的开局阶段站稳了脚跟，越往后走，缺陷就越是不断累积。

Dex 自己的解读是：这个 24% 左右的通过率，印证了他在第一篇里的直觉——对于真实形态的软件工程工作，一个问题接一个问题地推进，今天的模型还不能在没有人类介入的情况下“关灯”运行。

值得一提的是，测试过程中也观察到一些有趣的细节：Sonnet 5 在第一个检查点的花费比另外两个模型更高，但等到第一道题快做完、工作从“从零搭建”转向“日常维护”时，它反而成了三者中最省钱的一个——这似乎说明一旦基础框架搭好、后续工作变成维护性质，Sonnet 5 的成本优势才开始显现。

Slop Meter：41 项指标怎么量化“代码变烂”

除了“过没过关”这个二元结果，SCB 还在每个检查点结束后，用一套多达 41 项的量化指标去描摹代码质量的变化，大致可以归为六类：

  • 体量：代码行数、文件数、函数数、方法数、类数、语句数，以及每个检查点新增和删除的行数
  • 复杂度：圈复杂度的均值、最大值和离散程度，落入“高”和“极高”复杂度区间的函数占比，复杂度的集中程度，最大嵌套深度，函数平均长度
  • 重复度：克隆代码行数，以及克隆行占源码总量的比例
  • 分解质量：只被调用一次的函数、纯粹的转发包装函数、未使用的变量，每个符号平均占用的代码行数
  • 规则违规：静态检查报错数量，其中有多少可以自动修复，命中“测试劣化规则”的次数，以及被标记为“啰嗦”的代码行占比
  • 依赖图：一次改动会在多大范围内产生连锁反应（传播成本）、循环依赖的规模，以及依赖关系的“熵”——Dex 特别提到，这一项他觉得是最有意思的

Dex 对这套指标的态度算得上审慎：他坦言自己还不完全相信“靠 lint 规则就能把代码里的劣化揪出来”这件事，因为目前还没法用确定性的方式去精确量化某个检查点的代码到底“能不能维护”，但这些指标的变化方向大体上是靠谱的，值得持续追踪。

越写越多：正确率提升的代价是代码量暴涨

对比三个模型在完成同一批任务时写下的代码量，会发现一个不算意外但很扎眼的现象：更高的通过率是拿“写更多代码”换来的。

刨除测试代码，仅看生产代码量，Opus 5 相对 Opus 4.8 的实际膨胀幅度大约是 1.8 倍。

Dex 的猜测是，这里边有相当一部分是“昂贵但没换来多少实质提升”的啰嗦表达，至于这究竟是模型本身的行文习惯问题，还是这批题目本身就足够难、值得写这么多代码，他表示还需要进一步挖掘。

几乎每一行都在报警：跨语言对照实验更扎心

如果说前面的复杂度指标还只是“方向大致正确”，那接下来这组数据就直接得多：在三个模型生成的代码里，绝大多数代码行都至少触发了一条“劣化规则”。三道题目上的平均触发率分别是——Opus 4.8 为 98%，Opus 5 为 93%，Sonnet 5 为 89%。而且被标记为“啰嗦”的代码行占比，会随着检查点推进持续走高：从第一关的约 65%，一路涨到第八关的约 80%，哪怕是表现最好的 Opus 5 也不例外。

Dex 自己也承认，这多少说明部分质量指标的判定可能偏严格了一些。为了交叉验证，他还专门做了一个跨语言实验：SCB 目前的检测器只支持 Python，他让 GPT-5.6-Sol 帮忙给 TypeScript 也整理出一套对应的检测规则——数量上只有 76 条，远不及 SCB 原生 Python 库的 200 多条，但已经能看出一些方向性的结论：在“关灯”状态下由 Opus 5 生成的代码，每千行代码触发的劣化规则数量，是 HumanLayer 自家那个“99%由 AI 生成、但经过仔细人工评审”的 TypeScript 代码库的 11 倍还多——也就是多出了整整十倍。

Dex 也提醒这个结论还有不少需要打问号的地方，比如规则数量不对等、还没有做严格的对照校验，但这个数字本身已经足够说明问题。

复杂度只涨不跌：谁在“摊大函数”，谁在“堆小函数”

Dex 说自己已经靠“感觉”念叨了模型会让代码库随时间劣化这件事将近一年，这次终于有了数据支撑：在所有测试里，没有一个模型能做到全程不增加复杂度。

三个模型走的是两条不同的路子。

Opus 5 虽然平均复杂度最低，但它同时也写下了大约 2000 个函数——本质上是靠“拆成很多小函数”来压低单个函数的复杂度分数。

而 Sonnet 5 和 Opus 4.8 则更多是靠“把已有函数改大”来应对不断增加的新需求：Opus 4.8 走到极端，八个检查点里复杂度涨了 70%，其中最差的一个函数圈复杂度达到了 93。

代码重复率上，三者也出现了分化：Opus 4.8 的重复率从 4.6% 一路涨到 16.8%，拐点出现在第三关附近——大致正是新需求开始和最初设计打架的地方；另外两个模型的重复率则是先涨后回落。相比之下，Opus 5 的重复率几乎持平，只从 2.41% 微涨到 2.64%。

Dex 在第一篇里画过一张图，说“提升代码库长期质量”这件事在模型代际之间几乎没什么进展，如果愿意把“重复率”当作一个金标准指标来看，那么这次的数据或许可以说明，最近三个月模型确实有了一点点边际改善——但他也强调这是个“大大的如果”，多数软件架构专家大概都不会同意这事能被一刀切地下定论。

更好的裁判长什么样：渐进式验证 + “降级接手”实验设想

代码质量指标虽然有意思，但 Dex 认为它们讲不出完整的故事——而且这些指标本身也很容易被模型“钻空子”应付过去。

他提出了一个更有说服力的判断标准：就像 SWE-bench 这类基准之所以能成为“评价模型能不能一次性解决一个软件问题”的好裁判，是因为它精准对应了真实工作里那个“颗粒度”；同理，“能不能通过一个逐步展开的需求规格里的所有验证”，才是评价“模型能不能长期维护一个代码库”更贴近现实的考法。逻辑很直接：一个代码库一旦变得难以维护，后续检查点自然会开始接连失败，所以更高的严格通过率本身，就是模型能造出“可维护代码库”的信号。

他还提到，随着 Fable、Sol 这类前沿模型展现出越来越强的调试和逆向工程能力，未来光看“过没过关”可能不够了，成本、耗时、token 消耗这些维度的权重会变得更重要——因为再糟糕的代码库，足够强的模型或许也能连蒙带猜地啃下来，但一个真正结构良好的代码库，理应能让后续的开发工作变得更短、更省 token。而且和“十五分钟解决一个 SWE-bench 问题”比起来，“跨越八个检查点搭建一整个功能”虽然慢得多，但它可以完全无人值守地跑完，最后再用一套确定性的行为验证器打分——在 Dex 看来，这比“找另一个模型来评判这份代码干不干净”这种评价方式靠谱得多。

最后，他抛出了一个我很期待被跑起来的实验设想：让 Opus 5、Fable 5 或 GPT-5.6-Sol 这类顶尖模型负责搭建前面若干个检查点，然后看 Sonnet 5、GPT-5.6-Terra 这类相对没那么强的模型能不能顺利接手，完成下一个检查点。

这个设计的巧妙之处在于，它把“强模型的代码到底维不维护得住”这件事，转化成了一个可以被间接测量的信号——一个较弱的模型能不能读懂并续写前 N 关的代码，某种程度上就反映了前 N 关的代码到底写得够不够干净。

信号已经出现，但离“能放心关灯”还差得远

综合这一切，Dex 给出的判断和第一篇一脉相承：SlopCodeBench 提供的信号，印证了他此前“凭感觉”给出的判断——对于真实形态的软件工程工作，一个问题接一个问题地推进，今天的模型还不能被信任在没有人类介入的情况下“关灯”运行。

他把 SCB 当作一把接下来要持续盯着的尺子：在第一篇里他说过，自己不会把代码库押注在 Frontier Code、SWE-Marathon 或 DeepSWE 这些基准上；但如果未来哪天，模型能在一个被妥善“隔离于训练集之外”的类似 SCB 的基准上跑到 80% 以上，他会对“放心关灯”这件事感觉好上不少。

至于这一天什么时候到来，他表示不愿意去猜——因为“什么时候”远没有“有没有一个靠谱的信号能告诉你它正在发生”来得重要（当然，前提是没有人“不小心”拿测试集去做了训练）。

Dex 也坦率列了一堆“如果重来会怎么做”的改进方向：把三个模型 × 三道题目的九次测试完全并行跑，原本六小时的实验其实一到两小时就能跑完；把目前只支持 Python 的检测器移植到 TypeScript 等更多语言（他打趣说，Python 大概率是比大多数语言更容易“变馊”的语言）；除了严格通过率和缺陷总数，还可以探索更多维度，比如叠加“对抗式评审”或针对圈复杂度的确定性质量背压机制，看看结果会不会不一样；当然，最让他期待的，还是前面提到的那个“强模型代码交给弱模型接手”的实验。

小结

三篇文章走到这里，逻辑闭环已经相当完整：第一篇诊断出“模型学不会可维护性”这个病灶，同时留下一句“没有好基准”的遗憾；第二篇给出“把评审前移到规划阶段”的处方；第三篇则亲自下场，用一个专门为这个问题设计的新基准，把第一篇的直觉判断变成了可以量化、可以持续追踪的数字。答案依然不算乐观——即便是最强的 Opus 5，严格通过率也才 24%——但至少，行业现在有了一把看得见刻度的尺子，可以诚实地记录下模型到底进步了多少，而不必再只靠“感觉”说话。

参考资料

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。