AI代码随时间退化，威斯康星大学基准：冗余为人类代码的2.3倍

威斯康星大学麦迪逊分校发布了一个新基准，名叫 SlopCodeBench（arXiv 2603.24755）。大多数编程基准只测 AI 的一次性任务完成度，它测的是另一件事：需求不断变化时，代理生成的代码会变成什么样。代理要在多个检查点扩写自己之前写的代码。没有聊天历史，面对的是整个代码库。这更接近 Claude Code 在真实项目里的实际用法。

基准覆盖 15 个模型，包括 Opus 4.5、4.6、4.7 和 Sonnet 4.6，共 36 个任务。

结果分两层看。

一是质量。结构侵蚀，指代码复杂度中过度复杂函数所占的比例。冗余度，指被标记为浪费模式或复制粘贴克隆的行所占的比例。77% 的运行中结构侵蚀在增加，75.5% 的运行中冗余度在增加。多数情况下，AI 代码随时间退化，不是变好。

二是退化的程度。代理生成的代码比 473 个人类维护的 Python 仓库中的代码冗余 2.3 倍。有个具体案例：某个任务里，Opus 4.7 的 main() 函数在 8 个检查点中，圈复杂度从 13 涨到 92，行数从 38 涨到 240，每一步都在恶化。

整体完成度同样有限。没有任何模型完全解决 36 个任务中的任何一个。最佳严格检查点解决率是 14.8%，由 GPT 5.5 取得；Opus 4.6 的核心测试通过率最高，67.3%。

研究者试过用提示词阻止退化。“反冗余”和“先计划”两句提示，开始时能把初始冗余度和侵蚀砍掉约三分之一。但退化没有停下。代价是每个检查点成本平均增加约 12%。这两类提示只在 GPT 模型上测试过，对 Opus 和 Sonnet 是否有效，没有数据。

评论区里，开发者们也在聊这个问题。AI 生成的代码喜欢加包装函数，喜欢给显而易见的代码写注释。有人推测，缺少聊天历史是退化因素之一：真实开发里上下文常在，哪怕只有最近几轮对话，也不容易出现反复重写和半途放弃的模式。还有人问，能不能让 AI 审计自己的代码来找效率问题。研究没测过这个思路。

有开发者希望这类基准被纳入强化学习训练。另一句来自一线使用者的描述更直接：让代理维护或修复它自己写出来的代码，是一场噩梦。