如果编程已被解决，接下来呢？——量化代码冗余度

LLM在生成代码方面几乎做到了完美，但这还不是全部。代码形式上正确，并不意味着它没有引入不必要的抽象、制造重复，或者整体上做出错误决策。

这并不是一个突破性的观察，大多数做过vibe编码项目的人都意识到，每增加一个功能有时会导致代码行（LOC）的爆炸式增长。

这导致人力能动性丧失，因为在每月增加数百万信用额度的项目中，人类很难跟上。有人可能会说这根本不是问题，因为他们信任代理人能处理这些问题。

我有个坏消息，代理人其实也无法应对这些粗糙的处理。

我有物理背景，一直采用实验/定量的方法来解决问题。当我刚加入Earendil，负责研究如何衡量代码的粗糙时，我的本能是先深入研究文献，然后再看看其他公司都在做什么。

坦率地说，除了几篇有见地的研究论文外，我对目前行业看起来过于“氛围化”感到失望。在我的研究和X研究中，我不断被诸如“端到端编码代理”、“不仅仅建议代码——它直接发布代码的人工智能”或“无人类成本的人类层面评估”等信息轰炸。

这些故事和所有好故事一样，其中确实有一点真实成分。

LLM能够写入几乎完全正确的代码。这是因为代码的可扩展性和可验证性。让大型语言模型生成代码，然后通过隐藏测试检查代码，从而得到明确的奖励信号，是相当简单的。

与此形成鲜明对比的是，检查代码的“粗糙性”通常需要人类的直觉和品味，而且总体来说是一项极其困难的任务。我认为最好的说明方式是通过分析可能的“slop”测量方法来说明原因。

作为评委的人工智能：这可能是行业中评估代码质量最常见的方法，但根据我的观察，这种方法很少奏效。最天真的做法，即在1到10分的尺度上询问模型代码的质量，基本上等同于随机数生成器。

更复杂的方法，即试图给模型两个解A和B，然后让它自己决定更喜欢哪一个，这也存在模型的缺点改变其偏好，当你重新命名解时。我这里有点开玩笑，而且在大模型中影响没那么明显，但主要观点依然成立。

让大型语言模型评判它们写的代码，不能替代真正的评估。尽管评分标准或大型语言模型写测试有一些有趣的方法，但它们离真正消除粗糙还差得远。

人类评判AI：如果我们忽略软件工程师质量差异巨大，这将是确保代码保持人类可读性的最佳方案。缺点是这在训练人工智能或与多个模型提供者及工具之间进行大型基准测试时不可扩展。

最简单的方法：在我的研究和测试中，仅仅根据LOC数量的变化来衡量马虎，实际上是一个出乎意料的有效指标，讽刺的是，如果我们开始为此进行优化，它就会变得如此不再是有意义的衡量标准.

接下来的两项措施是报纸介绍给我的SlopCodeBench看起来很有前景，因为他们能够很好地区分遗留代码库和LLM代码堆积。

冗长度：试图测量重复且冗长的行数。

冗长度=LOC∣AST-Grep标记线∪克隆线∣

侵蚀：试图测量代码库中有多少质量集中在几个大型复杂函数中。

mass（f）=CC（f）SLOC（f）

这里 f 是函数，SLOC 是代码的源行，CC（f） 是圆复合复杂度功能。

侵蚀=∑fmass（f）∑f：CC（f）>10mass（f）

侵蚀则是圆复杂度大于10的函数质量与所有函数质量的比。

如果我们看SlopCodeBench评估中生成代码的平均冗长度和侵蚀度，并与一组已建立的代码库进行比较，两者之间有明显差异。平均来说，代码库的冗长度为0.15±0.06，代理代码的冗长度为0.33±0.10。

侵蚀方面，代码库的冗长度为0.31±0.17，代理代码为0.68±0.20。代理代码的平均冗长度和侵蚀程度大约是人类代码的两倍。随后我自己研究了一些氛围编码项目，很多项目的冗长度高达0.4，侵蚀度高达0.75，所以这些结果很可能并非评估的假象。

回到为什么代理自己（实际上）无法处理这些垃圾的观点，我们需要看看SlopCodeBench的评估。与其他编码基准不同，这些基准测试在开始时给代理完整的指令列表，然后有一组隐藏测试，程序需要通过，而它们则相反。

它们创建了多轮指令和测试迭代，在检查点之间会抹去模型的上下文。从而更接近一个迭代过程，就像人类实际使用编码代理一样。结果是，错误的编码决策会随着时间积累，并且在严格的破解率下，所有测试都必须在所有检查点通过，即使是最先进的模型也达到0%的通过率。

这对那些每天愉快添加数万甚至数十万次LOC的人来说，应该是一个警示信号。显然，通常会有关于考试过于严格或问题表述略显模糊的警告，但总体趋势依然存在。

在探索这些指标时，我希望你现在能更清楚地了解为什么评估代码粗心度会很困难，以及为什么人类的直觉和品味仍然被隐性或显性地融入评估中。

我还想探索一些有前景的其他方向，比如函数的耦合性、代码流转、内聚力等等。如果你正在做评估并愿意交流，我很乐意：sebastian@earendil.com

1. 这让我想起那句谚语：“用代码行来衡量编程进展，就像用重量衡量飞机建造进度一样。”
2. 我不想强迫任何人审查数百万个LOC来获得不断变化的模型供应商排名。
3. 这方面的规则是一套手工制作的启发式方法，通过以下方式实现。AST握把这再次体现了这一切的人性面貌。
4. 虽然一个以氛围强烈著称的开放项目在这两个指标上得分都不高，可能是因为函数耦合度极高，或者是大量无关函数降低了平均值。
5. 还没在Fable 5.1或Astra上测试过，但在GPT 5.6、sol xhigh等上测试过。