主流编码基准只按通过/失败评分，代码多写三倍也照样满分

让AI写代码的人已经注意到一个趋势：模型给出的代码越来越长。里面塞满用不上的安全检查、测试和抽象结构。问题出在评测环节。

最常被引用的编码基准是SWE-bench。它按隐藏测试套件做二分评分：通过得满分，不通过得零分。代码改了多少行、有没有未使用的代码、多套了几层防御逻辑，都不计入分数。为解决同一个问题写了三倍代码的模型，和只写最小补丁的模型拿一样的分。

模型多写代码有它的道理。它不是确定性的系统，用人类语言提需求时细节总会丢失，模型也知道这一点。与其猜对方要哪种解释，不如把各种情况都覆盖一遍。对模型来说，带一堆测试的臃肿方案，比精简方案更安全。模型同样不知道下一个问题是什么，所以每次都搭一个框架。写简单方法的话，下次加新情况就得重写。

也有厂商在走相反方向。Cognition在SWE-2模型的技术说明中提到，他们的后训练配方专门惩罚代码长度。这和主流基准制造的默认激励正好相反。其他模型厂商是否会跟进，没有公开信息。

代价已经出现。有人正在构建B2B仪表盘的基础模块，模型总是试图往核心模块里塞入大量安全措施。除非全程紧盯、持续给出严格指令，否则Codex和Claude Code都会做过头。安全、测试、复杂性，样样往多了加。对没有编程知识、只凭感觉写代码的人，模型更难用了。模型让人觉得一切正常，实际生成大量臃肿代码。看不出问题出在哪的人，等到项目膨胀到失控，才发现自己一直基于错误的理解做决定。

有观点认为，臃肿代码不是bug而是特性。它写的时候消耗更多token，重构和审查时再消耗一轮。人类难以接管代码库，等于被绑定在特定AI工具上。也有人觉得，模型写出的代码对AI代理没问题，对人类却是糟糕的体验。有开发者抱怨Codex过度工程化到了离谱的程度，希望厂商停止奖励这种行为。

社区里已有一些补救办法。一位开发者的做法是：先让Codex制定详细计划，再让Claude审查计划、去掉臃肿内容。最后让Codex严格按精简后的版本实现，不碰被删除的部分。他为此保留一份20美元的Claude订阅。还有人建议，单独设一个任务审查代码库，把功能相同的代码优化到最精简。用Ponytail这类技能也能拿到最精简的代码，但很多场景下不够健壮和灵活。这些办法都需要额外成本或技巧，没有触及评测激励本身。

评测标准也在被讨论。社区有人呼吁：基准该看有没有未使用的代码、设计是否良好、有没有重复的辅助方法。开源社区已有叫Slop-Code-Bench的基准，专门衡量代码臃肿。但OpenAI和Anthropic不会推广它，因为他们的模型没有针对这种标准优化。主流基准何时把代码体积计入评分，两家公司又会否调整训练逻辑，都还没有公开信息。