本文永久链接 – 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 Horthy 撂下过一句很硬的话：没有好的基准能衡量一个模型维护代码库质量的能力。这句话当时是用来解释“为什么关灯工厂跑不通”的——测试能在几秒内给你反馈，但一份糟糕架构的代价要几个月甚至几年后才会显现，现有的基准测试大多是“一次性把问题交代清楚，看模型能不能一把解决”，根本没法评估这种拖后腿的长期代价。
这一篇，Dex 决定自己把这个坑填上。他没有继续空谈，而是找到了一个专门针对这个问题设计的新基准，并且亲自跑了一场六小时的实测。
这个新基准叫 SlopCodeBench（下文简称 SCB），是威斯康星大学麦迪逊分校 Gabe Orlanski 实验室在 2026 年 3 月发布的长周期编程基准。它想解决的正是 Dex 在第一篇里点名批评的那个毛病：哪怕是“更大更复杂”的基准，本质上依然是把整个问题一次性摊开给模型看，这和真实软件开发中“需求是逐步浮现的”完全不是一回事。
SCB 的解法是给每一个挑战设计多个“检查点”（checkpoint）：模型一开始并不知道完整的需求全貌，而是要随着代码库的演进，不断接收新的需求更新，在已有代码的基础上继续迭代——这更接近真实世界里一个功能需求从雏形到完善的过程，而不是一道摆在那里等你去解的孤立考题。
这个基准目前还远没有被“刷穿”：在论文发布时，用来测试的最强模型 GPT-5.4 和 Opus 4.6，严格通过率分别只有 11% 和 17%。换句话说，这是一个当下前沿模型也啃不太动的硬骨头。
光看论文数据不过瘾，Dex 干脆自己上手跑了一场实测。上周五，他让 Claude 从 SCB 的题库里挑出三道题，覆盖简单、中等、困难三个难度，一共 17 个检查点：
三个模型——Opus 5、Sonnet 5、Opus 4.8——被并行拉进同一场测试，每个检查点都用全新的上下文窗口，所有模型拿到完全相同的提示词，统一跑在 Claude Code 这套 harness 里。Dex 全程盯了六个小时。
他关心的核心指标是“严格通过”（strict pass）：不仅新增功能要全绿，从之前检查点继承下来的所有回归测试也必须全部通过。
这意味着如果某个模型在第 4 关搞砸了什么，哪怕后面几关的新功能做得再漂亮，只要那个遗留缺陷没被顺手修好，后续所有检查点都算不通过——这跟真实项目里“一个隐藏的坏设计会持续拖累后面所有迭代”是一个道理。
结果是：在全部 9 次测试跑动中，没有一个模型能在任何一道题里从头到尾全部通关，哪怕是标着“简单”难度的那道题。
最终成绩单出炉：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 的成本优势才开始显现。
除了“过没过关”这个二元结果，SCB 还在每个检查点结束后，用一套多达 41 项的量化指标去描摹代码质量的变化，大致可以归为六类：
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》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。