Parsimony：一个衡量AI编程智能体添加多少代码的开源基准
Parsimony是一个开源基准，用于衡量AI编程智能体在解决任务时添加了多少代码，而不仅仅是它是否解决了任务。它复用了现有基准已发布的补丁，统计语法级别的“编码单元”而非代码行数，并减去删除的代码，得出一个净数值，可在DeepSWE Python、JavaScript、TypeScript和Go、SWE-bench Verified、SWE-bench Live Lite以及SWEeper-Bench PHP的排行榜上跨模型进行比较。
该项目声明的动机是，现有基准衡量解决率和成本，但不惩罚多余的代码，这从长远来看会使代码库更难维护。
Parsimony如何对补丁评分
Parsimony统计编码单元——语法元素，如语句、调用、比较、名称和字面量——而非代码行数。统计语法元素意味着将代码压缩到更少的行数不会得到奖励，并且由于删除了代码会被减去，报告的数值是净值：净单元 = 新增 − 删除。
Parsimony不执行任何操作。每个已发布的补丁被应用到任务的代码上，每个更改文件的两个版本都会被解析。测试、文档和生成的文件不计入统计。通过/失败结果取自源基准的已发布结果；测试不会重新运行。
该项目的“方法”部分指出“仅测量Python”，尽管该网站也发布了JavaScript、TypeScript、Go和PHP排行榜。这是源页面中明显的不一致，而非文档化的限制。
排行榜与可复现性
Parsimony发布了七个排行榜：DeepSWE Python、DeepSWE JavaScript、DeepSWE TypeScript、DeepSWE Go、SWE-bench Verified、SWE-bench Live Lite（列为“Live Python”）和SWEeper-Bench PHP。
每个排行榜都链接到项目GitHub仓库中的报告和清单，并且每个都附带清单和数据集的SHA-256哈希。例如，DeepSWE Python清单哈希为c16b15f80c140ffb4f0a548886962dda4173a02893a65b7faa1d6796940ecf65，其数据集哈希为41a44998c70248e0a3e2a4cf43a8838b70248537d1f3a458838f2f7e09ecef8a。自运行排行榜还记录了使用的DeepSWE提交：0b9fabbb63b9104d678fe965e1632f2dd9eaa2ea。
DeepSWE Python结果：34个任务上的26个模型
主要的DeepSWE Python排行榜涵盖34个DeepSWE任务上的26个模型，每个模型有136次尝试（每个任务四次尝试）。模型按其解决任务上的平均净添加单元数排名，最低者居前。该网站还报告了包含失败尝试的第二个平均值、取自DeepSWE的解决率，以及日期为2026-10-08的Artificial Analysis Intelligence Index，这是一个外部评分，按模型和推理努力程度匹配，不影响排名。
网站的表格未标注其数字列；下面的标签遵循网站自身对排名指标和解决/测量计数的解释。
| 排名 | 模型 | 平均净单元（排名指标） | 平均净单元（含失败尝试） | 解决率 | AA Intelligence Index | 已测量 |
|---|---|---|---|---|---|---|
| 1 | Gemini 3.1 Pro Preview (high) | 1479.5 | 1156.3 | 8.1% | 29.7 | 11/11 |
| 2 | Claude Fable 5 (xhigh) | 1557.5 | 1509.1 | 74.3% | — | 97/101 |
| 3 | Gemini 3.5 Flash (high) | 1621.5 | 1707.6 | 29.4% | 32.6 | 38/40 |
| 4 | Claude Opus 4.8 (max) | 1621.9 | 1592.2 | 63.2% | 41.8 | 83/86 |
| 5 | Kimi K3 (max) | 1641.2 | 1601.1 | 67.6% | 43.6 | 89/92 |
| 6 | Claude Sonnet 5 (max) | 1665.9 | 1563.5 | 59.6% | 38.2 | 78/81 |
| 7 | Claude Sonnet 4.6 (high) | 1684.5 | 1587.9 | 29.4% | — | 36/40 |
| 8 | Qwen3.8 Max (xhigh) | 1697.8 | 1770.5 | 55.1% | 45.4 | 74/75 |
| 9 | GLM-5.2 (max) | 1733.2 | 1591.3 | 41.9% | 33.7 | 53/57 |
| 10 | Kimi K2.7 Code | 1737.3 | 1600.1 | 24.3% | 25.8 | 32/33 |
排名榜底部由Muse Spark 1.1 (xhigh)占据，排名第26，平均净单元为2562.3，解决率为52.9%，以及Muse Spark 1.2 (xhigh)排名第25，净单元为2484.1，解决率为50.7%。Claude Opus 5 (max)排名第23，净单元为2183.4，解决率为74.3%。
排行榜上有两个模型没有Artificial Analysis评分：Claude Fable 5 (xhigh)和Claude Sonnet 4.6 (high)。
自运行模型显示但不参与排名
Parsimony还显示了一组淡化的模型，作者在DeepSWE Python任务的前3-10个上亲自运行，使用pi用于OpenAI模型，Claude Code用于Anthropic模型，并使用每个任务自己的测试进行评分。这些运行明确未经验证且不参与排名。
在该组中，GPT-6 Luna (high)显示最低平均值，为1076.3净单元，解决率为15.0%，测量尝试为3/3；GPT-6 Astra (high)显示1103.0净单元，解决率为66.7%，测量尝试为4/4。GPT-5.6 Sol (high)同时出现在自运行组和已发布排行榜中；网站指出，作者的运行添加的代码是其已发布运行的0.88倍。
指标的既定限制
Parsimony自己的“限制”部分异常坦诚地说明了该数字不代表什么。
- 更小并不总是更好：单元衡量大小，而非可读性或设计。
- 编写更多代码的模型也倾向于解决更多任务，在包含26个或更多模型的排行榜上，Spearman相关性为0.33–0.60。
- 每个模型使用相同的智能体mini-SWE-agent，但智能体仍然影响编写多少代码。
该网站用同一函数的两个实现来说明大小与可读性之间的区别。一个基于循环的has_negative设置found标志，和一个单行的any(value < 0 for value in values)版本返回相同的结果，但只有一个是简短的。
社区反应：简洁性与可读性
Hacker News的讨论对将低单元数视为良好代码的代理提出了反驳。最直接的反对意见是，在作者自己未排名的运行中获胜的模型生成的代码难以阅读。
“一方面，我完全同意我们应该尝试衡量和减少LLM倾倒入我们代码库的冗长。另一方面，Astra‘赢得’这个基准对我来说并不是一个好信号，因为在我看来Astra生成的代码基本上不可读。Astra在玩代码高尔夫。我自己明确的偏好是，我宁愿要Claude的过度注释和测试，也不要Astra的难以理解。” — fastball
第二条讨论线要求实用技术而非衡量。一位评论者直接询问是否有人有方法减少智能体生成代码的复杂性和冗长，将其框定为代码质量问题而非基准测试问题。
第三个主题是指标覆盖。一位评论者要求将圈复杂度作为支持性的可读性指标，称他们越来越发现与AI相关和AI编写的代码存在此问题。另一位质疑更少的编码单元是否真的意味着人类阅读补丁的审查工作更少。
第四个主题是模型覆盖。一位评论者认为基准应包括普通人可以在本地运行的最佳编码和写作模型——点名Qwen 3.8 27B，在Q4下大约需要28GB RAM，作为当前候选——以便开放权重与领先商业模型之间的差距可见。同一位评论者指出，本地模型已经比一年多前可用的更好，并同样比较了文本到图像和文本到语音模型。
一位评论者完全否定了前提，认为一旦人们理解向量空间运作的规模，代码量将不再重要，并且复杂性对AI系统来说不是什么大问题。
一位表示会收藏该基准的评论者从衡量角度阐述了价值：你无法管理你不衡量的东西，将衡量移到抽象语法级别消除了注释和格式化的噪音层。他们补充说，他们希望听到更多实际经验，因为该领域的启发式方法仍为优化代码生成和流水线留有余地。
添加你自己的基准
Parsimony接受外部结果。用户下载示例文件，填写自己的代码大小数字，然后打开它以获得相同的图表和表格；文件保留在浏览器中。格式和共享说明记录在项目仓库的docs/custom-benchmarks.md中。
Sources
相关
- Dispatch
- Dispatch
- Dispatch
- Dispatch
- Dispatch