大语言模型（LLMs）几乎已能完美生成代码，但故事并未结束。代码形式正确，不代表没有引入不必要的抽象、重复或糟糕决策。每个新功能有时会让代码行数（LOC）暴涨，在每月增加数百万行代码的项目里，人类很难跟上。代理（agents）也处理不了这些代码邋遢。作者从物理背景出发，在埃雅仁迪尔（Earendil）负责衡量代码邋遢程度，先查文献，再看其他公司怎么做；行业凭感觉。

LLM 生成代码已近乎完美，但这不是故事的终点。代码形式正确，不代表它没有引入不必要的抽象、制造重复，或者整体上做出糟糕决策。这不是什么惊人发现——大多数 vibe-code 过项目的人都意识到，每加一个功能有时会导致代码行数（LOC）爆炸。

这导致人类能动性丧失，因为在每月增加数百万 LOC 的项目里，人类很难跟上。有人可能说这根本不是问题，因为他们信任 agent 去处理。坏消息是：agent 也处理不了这些垃圾代码。

我出身物理背景，习惯用实验/定量的方式解决问题。刚到 Earendil、接到测量代码 sloppiness 的任务时，我的本能是先深入文献，再看看其他公司在做什么。

坦白说，除了少数有洞见的研究论文，我对目前行业如此“凭感觉”感到失望。在研究和 X 上，我不断被“端到端编码代理”“不只是建议代码——它直接发布”“没有人类成本的人类级评估”之类信息轰炸。这些说法像所有好故事一样，都有一丝真实。

LLM 能写出几乎完全正确的代码，因为代码可扩展、可验证。让 LLM 生成代码，再用隐藏测试检查，就能得到清晰的奖励信号。相比之下，检查代码的“sloppiness”往往需要人类直觉和品味，通常极其困难。说明这一点最好的方式，是过一遍测量 slop 的可能方法。

AI 作为裁判：这可能是行业里最常见的代码质量评估方式，但据我观察它很少有效。最天真的做法——让模型给代码从 1 到 10 打分——基本等于随机数生成器。更复杂的方法——给裁判模型两个方案 A 和 B，让它决定更喜欢哪个——缺点在于，当你给方案改名时，模型会改变偏好。我有点开玩笑，较大模型身上这种效应没那么明显，但要点仍然成立。让 LLM 评判自己写的代码，不能替代正规评估。虽然有一些用评分标准或让 LLM 写测试的有趣方法，但离真正消除 slop 还很远。

人类裁判 AI：如果忽略软件工程师质量存在巨大差异这一事实，这是保证代码保持人类可读的最佳方案。缺点是，它无法扩展到训练 AI，也无法用于多模型提供商和测试框架的大规模基准。

最简单的方法：在我的研究和测试中，单纯看 LOC 的变化量，竟然是出奇有效的 sloppiness 指标，但有个讽刺的附加条件：一旦我们开始针对它优化，它就不再是有意义的度量（Goodhart 定律）。

接下来两个度量由论文 SlopCodeBench 介绍给我，看起来很有前景，因为它们能很好地区分遗留代码库和 LLM slop。

Verbosity：试图测量重复和不必要冗长行的数量。

$$ V e r b o s i t y = \frac{\mid \text{AST}-\text{Grep}\textrm{ }\text{flagged}\textrm{ }\text{lines} \cup \text{clone}\textrm{ }\text{lines} \mid}{L O C} $$

Erosion：试图测量代码库的质量有多大比例集中在少数又大又复杂的函数里。

$$ m a s s \left(\right. f \left.\right) = C C \left(\right. f \left.\right) \sqrt{S L O C \left(\right. f \left.\right)} $$

这里 f 是函数，SLOC 是源码行数，CC(f) 是函数的圈复杂度。

$$ E r o s i o n = \frac{\underset{f : \textrm{ } C C \left(\right. f \left.\right) > 10}{\sum} m a s s \left(\right. f \left.\right)}{\underset{f}{\sum} m a s s \left(\right. f \left.\right)} $$

Erosion 就是圈复杂度大于 10 的函数质量，除以所有函数质量的比例。

看 SlopCodeBench 评估中生成代码的平均 verbosity 和 erosion，再和一组成熟仓库比较，差距明显。仓库的平均 verbosity 是 0.15 ± 0.06，agent 代码是 0.33 ± 0.10。Erosion 方面，仓库是 0.31 ± 0.17，agent 是 0.68 ± 0.20。Agent 代码平均约为人类代码的两倍冗长和侵蚀。我随后调查了自己一些 vibe-code 项目，很多 verbosity 高达 0.4，erosion 高达 0.75，所以这些结果可能不只是评估产物。

回到为什么 agent 不能（真正）自己处理 slop，需要看 SlopCodeBench 的评估。其他编码基准一开始给 agent 完整指令列表，然后用一组隐藏测试要求程序通过；SlopCodeBench 反其道而行。它创建多轮指令和测试迭代，检查点之间模型上下文被清除，从而更接近人类实际使用编码 agent 的迭代过程。结果是糟糕的编码决策随时间累积，对于严格 solve rate——所有检查点都必须通过所有测试——即使最先进的模型也只有 0% 通过率。这对任何每天愉快地加上万甚至几十万 LOC 的人都是警告。当然，老生常谈的警告仍在：测试可能过严，或某个问题陈述略有歧义，但总体趋势成立。

探索这些指标后，希望你现在更清楚为什么评估代码 sloppiness 如此困难，以及为什么人类直觉和品味仍然以隐式或显式方式嵌入评估。

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

1. 这让我想起一句话：“用代码行数衡量编程进度，就像用重量衡量飞机制造进度。”
2. 我不想强迫任何人审查数百万 LOC，只为得到一份不断变化的模型提供商排名。
3. 规则是一组通过 AST-Grep 实现的手工启发式方法，这再次说明其中的人为因素。
4. 不过一个有名的、氛围很重的开源项目在两个指标上都不高，可能因为函数耦合度极高，或者大量无关函数拉低了平均值。
5. 尚未在 Fable 5.1 或 Astra 上测试，但测了 GPT 5.6 sol xhigh 等。

社区对“编码已被人工智能解决”普遍质疑，多数人指出人工智能代码在架构全局性与长期维护上积累技术债，仅有少数人认为编码本就已解决或渣代码未来无足轻重；同时，用代码行数、圈复杂度等量化“渣度”的基准获较多认可，但警惕优化导致奖励黑客。

编码远未解决，正确性只是底线而全局架构质量才是核心

• 较多人指出当前模型在效率、安全、可维护等高质量属性上很差，正确性仅是前提而非特性；编码只是软件开发一环，设计与规格未解，软件可靠性无保障。代理写局部渣可需时修，但全局技术债如关注分离、分层接口需全局重构，当前缺乏度量。实战中人工智能擅单功能，复杂系统设计并入易成意大利面。
• > 正确性不是特性而是最低要求，当前模型在高效安全可维护上相当糟糕（@danbruc）

“编码已解决”至多是在无限成本下的幻觉，现实约束强

• 较多人表示即便前沿模型可解，令牌成本令企业退回人力更划算；讽刺人工智能公司仍雇工程师说明未解；有人称90%易问题早解但剩10%硬骨头零进展。
• > 假设编码是已解决问题简直无稽，除非冷聚变实现，否则熵增难敌（@toddwprice）

用自动化指标度量“渣代码”是积极方向，但需防奖励黑客

• 较多人赞赏以迭代轮次正确率、代码行数变更、圈复杂度等量化代理累积错误，模拟上下文擦除的基准更真实。有人依此建架构审查代理学LCOM等。但一旦优化行数指标，模型会代码高尔夫。建议用独立基线模型交叉评估迭代防自读乱码。
• > 变更行数是意外有效的渣度指标，但一旦把它当硬指标优化便会失效（@cjalmeida）

人类代码本就渣，人工智能只是延续或放大无须浪漫化前大模型时代

• 较多人提醒前人工智能时代企业代码低质普遍，模型训练于人类渣代码，原本多数代码就是从网上抄的。
• > 很多人类写的企业级代码在人工智能自动化前就质量低下（@scronkfinkle）

渣代码未来可能无关紧要，代码将成一次性产物

• 少数人设想若软件自写，渣不重要，代码像提示结果可丢弃重生成，测试套件关键；有人调侃不如去解决意识。编码是建心智模型良法，但若重速度轻理解则另说。
• > 代码将变成像人工智能提示结果般的一次性东西，满足需求就跑，新需求来了重做（@RickJWagner）

“X已解决”叙事本身可疑，问题空间永动态

• 少数人反感“编码解决”说法，指出解决预设静态空间，新情况总现，癌症都不能全消；代码抽象概念永无止境，未来代码量更巨。
• > 这类“编码解决”的轰炸式叙事该消停，新程序新问题总会出现（@neptvn）

有价值的补充

• 艾伦·凯早在本世纪初就称编程为“流行文化”，呼应如今行业凭氛围行事（@vanschelven）。
• 有开发者构建Valknut工具，发现除局部复杂度外需信息论组织原则指导代理结构，且在25万行以下项目影响不大，近百万行才显著，产品保质期随模型代际缩短（@CuriouslyC）。
• 有读者设计分层架构基准：从计数器到商店等域，用L1-L8功能级别观测大模型在同步、离线、授权等全局属性的糟烂，计划用变更行数组合性等算“架构分数”并绑定预算代理（@technoplato）。
• 编码不仅是程序运行，更是团队间分发心智模型；若人工智能持有模型则人提示经有损通道，软件质量依赖开发者翻译业务语言（@conqrr）。