评估编程智能体，也要算新增代码的账

两个编程智能体修好同一个问题，一个新增模块、重试封装和配置项，另一个只改条件并删掉冗余代码。测试都通过，维护负担却可能相差很大。开源基准 Parsimony 想把这笔账摆出来：在解决率和生成成本之外，比较模型完成任务时净增加了多少代码。

目前能确认什么

根据现有节选，Parsimony 读取已有基准公开的补丁，直接采用其测试通过结果，不重新运行任务。文章重点讨论 SWE-bench Verified，其解决率记录任务是否修复成功，无法区分补丁规模。

它统计的并非代码行数，而是「代码单元」（coding units），例如语句、调用、比较、名称或字面量。净增量等于新增单元减去删除单元，注释、格式、标点和名称长度不计入；测试文件、文档和生成文件也被排除。节选中的 Verified 榜单只衡量 Python。

排名还会参考其他模型在相同任务上的净增量，避免直接拿不同任务集合比较。但 README 将它定位为实验性的代码规模比较，且不同条目的 agent 版本并不完全一致。

它提供的是补丁规模视角，不能直接当作编程能力排名。

我的判断

对程序员最实用的改变，是在智能体补丁审查中，把「为什么需要增加这些实现」作为固定问题。修一个条件判断，却引入通用模块和配置开关，就需要解释新增抽象解决了什么问题。

但净增量不能成为越低越好的指标。复杂修复可能需要更多代码，压缩成难读的一行也会增加审查成本；删除与新增相抵后，净值还可能掩盖较大的改动范围。

选模型时，我会把解决率与代码净增量并排看，不凭后者直接淘汰模型。至于其他语言如何计数、重构如何影响排名、统一 agent 版本后差异是否仍成立，现有节选没说清，需要完整方法文档和可比结果才能判断。