💬 NLP

SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks

该论文提出了 SlopCodeBench 基准，通过评估智能体在长周期迭代任务中的表现，揭示了现有代码智能体在扩展过程中代码质量会持续退化（表现为冗余度增加和结构侵蚀），且当前模型均无法完整解决此类任务，表明现有的单次通过率基准严重低估了迭代开发中的扩展鲁棒性。

原作者： Gabriel Orlanski, Devjeet Roy, Alexander Yun, Changho Shin, Alex Gu, Albert Ge, Dyah Adila, Frederic Sala, Aws Albarghouthi

发布于 2026-03-27

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Gabriel Orlanski, Devjeet Roy, Alexander Yun, Changho Shin, Alex Gu, Albert Ge, Dyah Adila, Frederic Sala, Aws Albarghouthi

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文讲述了一个关于AI 编程助手（Coding Agents）的有趣故事。简单来说，它发现了一个令人担忧的现象：AI 写的代码，刚开始可能还行，但一旦让它反复修改和扩展，代码就会变得越来越“烂”，最后完全无法维护。

为了让你更容易理解，我们可以把这篇论文的核心内容想象成**“盖房子”和“装修”**的故事。

1. 背景：以前的测试太“假”了

想象一下，以前我们测试一个建筑工人（AI）的能力，通常是给他一张图纸，让他盖一栋小房子。如果房子盖好了，没塌，我们就说：“这工人真棒，满分！”

但这有个大问题：现实中的软件开发不是一次性盖完就结束，而是需要不断扩建、装修、加楼层的。
以前的测试只看了“第一栋房子”盖得对不对，却没看当业主说“我要加个地下室”、“我要把厨房改成开放式”时，这个工人会不会把原来的房子拆了重盖，或者把新墙砌歪了。

2. 新实验：SlopCodeBench（“垃圾代码”大挑战）

为了测试 AI 在长期、反复修改任务中的表现，作者们设计了一个新实验，叫 SlopCodeBench。

什么是"Slop"？在中文里，我们可以把它想象成"代码垃圾"或"代码淤泥"。就像你往一杯清水里不断倒泥沙，水最后会变得浑浊不堪。
实验过程：
1. 给 AI 一个初始任务（比如：写一个能搜索 Python 代码的工具）。
2. AI 写好了。
3. 然后，作者们不断给 AI 加新任务（比如：“现在要支持 JavaScript 了”、“现在要支持 C++ 了”、“现在要能自动修复代码了”）。
4. 关键点：AI 必须基于自己之前写的代码进行修改，不能推翻重来，也不能有人类专家帮它重构。
5. 就这样反复进行 5 到 8 轮，直到任务变得非常复杂。

3. 发现了什么？（AI 的“退化”过程）

实验结果非常惊人，就像看着一个原本整洁的房间，随着不断添置杂物，最后变成了垃圾堆。

A. 没人能坚持到底

在测试的 11 种最先进的 AI 模型中，没有一个是能从头到尾完美完成所有任务的。

最好的模型，在最终阶段的通过率也只有 17.2%。
这意味着，随着任务变难，AI 写的代码越来越容易出错，甚至完全跑不通。

B. 两个核心指标：代码变“胖”了，结构变“烂”了

作者们发明了两种方法来衡量代码有多“烂”：

啰嗦度（Verbosity）
- 比喻：就像你让 AI 写日记。刚开始它写得很精炼。后来，它开始重复说同样的话，或者为了做一件小事，写了三页纸的废话。
- 现象：AI 写的代码里充满了重复的、没用的代码行。就像为了挂一幅画，先盖了一栋楼，再修一条路，最后才挂上去。
- 数据：在 90% 的测试中，AI 的代码变得越来越啰嗦。
结构侵蚀（Structural Erosion）
- 比喻：想象一个原本结构清晰的图书馆。刚开始，书分类很清晰。后来，为了放新书，AI 把书直接堆在过道上，或者把几本重要的书塞进同一个巨大的箱子里，导致那个箱子重得搬不动。
- 现象：AI 倾向于把所有复杂的逻辑都塞进同一个巨大的函数里，而不是拆分成小模块。这就像把整个房子的承重墙都压在一根柱子上，一旦这根柱子断了，整个房子就塌了。
- 数据：在 80% 的测试中，这种“结构坍塌”现象越来越严重。

C. 和人类程序员比，AI 差远了

作者们找了一些人类程序员维护了很久的真实开源项目（比如著名的 scikit-learn 等）做对比。

人类：随着时间推移，代码质量基本保持稳定，或者只有微小的波动。
AI：随着迭代次数增加，代码质量断崖式下跌。
结论：AI 写的代码比人类写的代码啰嗦 2.2 倍，而且结构混乱程度高得多。

4. 为什么提示词（Prompt）没用？

作者们想：“如果我们告诉 AI‘请写得简洁一点’、‘请先规划再写’，会不会好点？”

结果：刚开始确实好了一点（就像给房间做了大扫除）。
但是：一旦开始第二轮、第三轮修改，AI 又回到了老路上，代码质量继续下跌。
比喻：这就像你给一个习惯乱扔东西的人说“请保持整洁”，他刚开始会听，但一旦忙起来，他又开始乱扔了。简单的“口头提醒”无法改变他缺乏长期规划能力的本质。

5. 总结与启示

这篇论文告诉我们一个残酷的真相：

目前的 AI 编程助手，擅长“从零开始”写一段代码，但非常不擅长“长期维护”和“迭代开发”。

现状：我们现在的测试方法（只看第一次能不能跑通）太片面了，掩盖了 AI 在长期任务中会“自毁”的事实。
未来：如果我们要让 AI 真正像人类工程师一样工作，不能只靠让它“多试几次”，而是需要教会它如何设计一个能抗揍的架构，或者在每次修改时强制它进行“代码重构”。

一句话总结：
现在的 AI 编程助手就像是一个**“一次性天才”**，它能帮你盖好第一间小屋，但如果你让它接着盖第二层、第三层，它大概率会把房子盖歪，最后变成一堆无法居住的“代码垃圾”。我们需要找到方法，让它学会像人类一样，懂得“未雨绸缪”和“长期规划”。

SlopCodeBench 论文技术总结

1. 研究背景与问题定义

现有的编程智能体（Coding Agents）基准测试（如 SWE-bench）主要采用**单次射击（Single-shot）**的评估模式，即让模型根据完整规范生成代码，并仅通过测试通过率（Pass Rate）来衡量其能力。然而，这种评估方式存在严重缺陷：

忽视迭代性：软件开发本质上是迭代的，代码在通过当前测试后，往往难以在未来需求变更中进行扩展。
掩盖质量退化：当前的基准测试无法捕捉代码在多次修改后产生的“技术债务”。大语言模型（LLM）倾向于生成冗长（Verbose）的代码，并在多次迭代中累积反模式（Anti-patterns），导致代码结构逐渐恶化，这种现象被称为"Slop"（代码垃圾）。
缺乏架构约束：现有迭代基准要么将任务分解为依赖有序的子问题（掩盖了架构决策的后果），要么基于真实仓库的历史提交（模型无需承担早期设计决策的代价）。

核心问题：当前的智能体在长周期、多轮次的代码扩展任务中，是否具备维持代码质量和架构健壮性的能力？现有的通过率指标是否系统性地低估了这种失败模式？

2. 方法论：SlopCodeBench

为了解决上述问题，作者提出了 SlopCodeBench (SCBench)，这是一个语言无关的基准测试，旨在评估智能体在动态规范下扩展自身代码的能力。

2.1 基准设计原则

SCBench 包含 20 个独立问题，共 93 个检查点（Checkpoints）。其核心设计原则包括：

无预设内部接口：仅规定外部行为（CLI 或 API 边界），不规定内部函数签名或库 API，迫使智能体做出架构决策。
隐藏测试套件：智能体只能看到规范描述和示例，无法直接访问测试代码，必须自行推断边缘情况。
黑盒与语言无关：通过 CLI 或 API 交互评估，不依赖特定语言生态。
自我迭代：智能体必须基于自己上一轮生成的代码进行修改和扩展，早期架构决策的后果会直接传导至后续步骤。

2.2 评估流程

输入：每个检查点提供更新后的规范（Specification）。
过程：智能体接收当前规范及上一轮的工作空间（Workspace），生成新的工作空间。
反馈：仅通过测试套件验证正确性，不提供对话历史上下文，模拟开发者回归项目的真实场景。
示例任务：以 code_search 为例，从仅支持 Python 的精确/正则匹配开始，逐步增加多语言支持、AST 模式匹配、自动修复等功能。早期硬编码语言逻辑的决策会导致后期重构成本剧增。

2.3 质量度量指标

除了传统的通过率，SCBench 引入了两个轨迹级（Trajectory-level）的质量指标：

冗长度 (Verbosity)：衡量冗余或重复代码的增长。
- 通过 137 条 AST-Grep 规则检测浪费代码模式。
- 计算克隆代码（Clone Lines）与总代码行（LOC）的比率。
- 公式： $Verbosity = \frac{\{AST-Grep 标记行 \cup 克隆行\}}{LOC}$
结构侵蚀 (Structural Erosion)：衡量复杂度在少数高复杂度函数中的集中程度。
- 定义每个可调用对象的“复杂度质量”： $mass(f) = CC(f) \times \sqrt{SLOC(f)}$ ，其中 $CC $是圈复杂度，$ SLOC$ 是源代码行数。
- 侵蚀率定义为：高复杂度（$CC > 10$）函数所占的总质量份额。
- 该指标捕捉了“大函数”（God Functions）不断膨胀的现象。

3. 实验设置

模型：评估了 11 个前沿模型（包括 Anthropic 的 Sonnet/Opus 系列，OpenAI 的 GPT-5 系列 Codex，以及 GLM 等）。
环境：每个检查点在独立的 Docker 容器中运行，重置会话状态，仅保留工作目录。
提示策略：对比了基础提示（Just-solve）、反垃圾提示（Anti-Slop，禁止冗余和过度工程）和先规划后编码（Plan-First）策略。
人类基准：选取了 48 个维护良好的 Python 开源仓库（按 GitHub Star 分级）作为人类代码质量的参照系。

4. 关键结果

4.1 极低的端到端解决率

无一模型能完整解决：在 11 个模型中，没有任何一个智能体能够端到端地完整解决任何一个 20 个问题。
通过率极低：最高单检查点严格解决率仅为 17.2%（Opus 4.6）。随着检查点推进，包含回归测试的严格通过率在最终检查点降至 0.5%。
成本与收益不成正比：随着任务推进，平均每个检查点的成本增长了 2.9 倍，但正确率并未提升。

4.2 代码质量显著退化

普遍退化：在 80% 的轨迹中，结构侵蚀率上升；在 89.8% 的轨迹中，冗长度上升。
复杂度集中：高圈复杂度函数的平均数量从 4.1 激增至 37.0，最大圈复杂度从 27.1 升至 68.2。
对比人类代码：
- 智能体生成的代码比人类维护的仓库冗长 2.2 倍。
- 智能体代码的结构侵蚀程度显著高于人类代码（0.68 vs 0.31）。
- 趋势差异：人类代码的指标随时间保持平稳或缓慢增长，而智能体代码的指标随迭代次数单调恶化。

4.3 提示干预的局限性

初始质量可提升：使用“反垃圾”或“先规划”提示可以显著降低初始的冗长度和侵蚀率（例如初始冗长度降低约 33%）。
无法阻止退化：尽管起点更低，但退化斜率（Slope）并未改变。一旦智能体开始基于自身代码进行迭代，质量退化速度与基础提示组几乎一致。
无正确性提升：改善代码质量并未带来通过率的显著提升，反而在某些情况下增加了成本或降低了通过率。

5. 主要贡献与意义

提出了首个长周期迭代基准：SlopCodeBench 填补了现有基准在评估“代码扩展鲁棒性”方面的空白，揭示了单次通过测试无法反映的长期架构风险。
量化了“代码垃圾”的积累：通过引入“冗长度”和“结构侵蚀”指标，首次系统性地量化了 LLM 在迭代开发中产生的技术债务。
揭示了当前智能体的设计缺陷：结果表明，当前最先进的编程智能体缺乏软件工程所需的设计纪律（Design Discipline）。它们倾向于局部最优解（通过当前测试），却牺牲了未来的可维护性。
挑战了现有评估范式：证明了单纯依赖 Pass Rate 的基准测试会系统性地低估失败模式。未来的评估必须关注代码在长期演化中的质量轨迹，而不仅仅是初始生成的正确性。

6. 结论

SlopCodeBench 的研究结果表明，当前的 AI 编程智能体在面对长周期、需求演变的迭代任务时，表现出的能力远未达到实际软件工程的要求。它们生成的代码不仅冗长，而且结构迅速恶化，导致代码库变得难以维护。尽管提示工程可以暂时改善初始代码质量，但无法从根本上阻止这种退化趋势。未来的研究需要探索能够强制执行结构纪律的训练方法或工具，而不仅仅是优化单次生成的正确性。