Parsimony 开源：AI 编程模型到底写了多少代码，终于有了新算法

10 月 13 日，开源项目 Parsimony 在 Hacker News 的 Show HN 页面公开，引发了开发者对 AI 编程评测方式的讨论。它提出了一个看似简单、但长期被行业忽略的问题：一个 AI 编程模型在完成任务时，究竟新增了多少代码？

Parsimony 是一个用于衡量 AI 编程模型代码增量的开源基准，它关注模型在真实代码库中产生的新增、修改和删除，而不只是任务是否通过测试。

这不是又一个 SWE-bench 变体，也不是单纯统计模型输出了多少行代码。Parsimony 的价值在于，它试图把模型的实际代码产出从工程师的工作流里单独拆出来：模型写了多少，重复了多少，返工了多少，最后留下了多少真正进入代码库的变化。

在 AI 编程工具已经能够一次生成数百甚至数千行代码的今天，这个问题比模型排行榜上的又一个百分点更重要。因为代码写得更多，不等于交付得更多；PR 合并得更快，也不等于系统变得更可靠。

代码行数早就失效，但代码增量仍然有用

代码行数是衡量软件生产力的低效指标，因为它无法区分有效逻辑、重复代码、自动生成的样板代码和后来必须删除的错误实现。

同样是新增 500 行代码，可能代表三种完全不同的结果：

• 一个模型为复杂功能补齐了 500 行测试和业务逻辑；
• 一个模型生成了 500 行无法复用的重复代码；
• 一个模型先生成 500 行错误实现，随后又删除其中 400 行。

传统的 LOC，也就是 Lines of Code，只能告诉我们文件变长了多少，不能说明软件质量提高了多少。Parsimony 关注的 code delta，则是代码在一次任务前后发生的实际变化，通常包括新增行、删除行和修改行。

代码增量是指一次开发任务中，代码库从初始状态到最终状态之间发生的新增、删除和修改的总变化。它比单纯的输出长度更接近模型对仓库产生的实际影响。

这里的关键不是把代码增量重新包装成一个万能分数，而是把它作为一个中间层指标：它连接了模型的生成行为和最终的软件工程结果。

模型是否通过测试，可以衡量功能正确性；代码增量可以衡量模型为完成任务实际改变了什么；而变更失败率、线上事故和后续返工，才是更接近业务价值的结果。三者放在一起，才能看清一个模型到底是在解决问题，还是在制造更多需要人来收拾的问题。

Parsimony 具体在测什么

Parsimony 的核心方法，是在固定任务、代码仓库和初始状态后，记录模型完成任务前后的代码差异，并把这些差异与测试结果、补丁质量和任务完成情况一起观察。

从评测逻辑上看，它至少试图回答四个问题：

1. 模型生成了多少新增代码？ 这反映模型直接产出的代码规模。
2. 模型删除或重写了多少代码？ 这能暴露返工、试错和不稳定实现。
3. 最终保留下来的代码占比是多少？ 这比一次性输出长度更接近有效产出。
4. 这些变化是否完成了任务？ 代码增量必须和测试、功能正确性以及仓库状态结合起来看。

这套方法与常见的代码生成评测有明显不同。传统评测更像考试：给出一个问题，模型提交答案，系统判断测试是否通过。Parsimony 更像观察一次真实开发：模型需要在已有代码库里定位文件、理解上下文、修改实现、运行测试，并最终提交一个可审查的变更。

换句话说，前者主要测模型会不会答题，后者开始测模型会不会改代码。

为什么只看通过率不够

测试通过率只能证明当前测试覆盖到的行为没有失败，不能证明代码足够简洁、可维护，也不能证明模型没有引入隐藏问题。

一个模型可能通过全部测试，但仍然存在以下问题：

• 为一个小功能修改了大量无关文件；
• 复制了已经存在的工具函数，而不是复用现有抽象；
• 生成了超过需求范围的配置、文档和依赖；
• 通过硬编码绕过了测试，而不是实现通用逻辑；
• 使用复杂的临时方案，增加后续维护成本；
• 在代码库中引入重复逻辑，短期通过测试，长期提高返工概率。

Parsimony 并不能单独判断这些代码是不是好代码，但它可以把异常代码变更暴露出来。例如，在任务要求只修改一个解析器的情况下，如果模型最终新增了 1200 行代码，且其中 70% 来自重复实现，那么测试通过率就不能再被视为充分证据。

这也是 Parsimony 与 SWE-bench 一类基准的互补关系：SWE-bench 更适合观察模型能否修复真实项目中的问题，Parsimony 更适合观察模型用多大规模的代码变化来完成修复。一个模型既可能有较高的任务通过率，也可能依赖非常庞大的补丁才能完成任务。两者对工程团队的含义完全不同。

与常见 AI 编程指标相比，Parsimony 处在什么位置

不同指标回答的是不同问题，不能把它们混成一个排行榜分数。

| 指标 | 主要衡量内容 | 能回答的问题 | 主要盲点 | |---|---|---|---| | 代码生成量 | 模型输出了多少代码 | 模型产出是否足够快 | 无法判断代码是否有效 | | PR 数量 | 团队合并了多少变更 | 交付流程是否更活跃 | 忽略 PR 规模和审查成本 | | 测试通过率 | 代码是否满足已有测试 | 功能是否基本正确 | 测试覆盖不到隐藏缺陷 | | SWE-bench 得分 | 模型能否解决真实仓库任务 | 模型是否具备修复能力 | 不直接衡量补丁规模和返工 | | 代码增量 | 任务前后代码发生了多少变化 | 模型实际改了什么 | 不能单独代表质量或业务价值 | | 变更失败率 | 发布后需要回滚、热修复或补丁的比例 | 代码是否真正稳定 | 通常需要 60 至 90 天才能观察 |

Parsimony 最重要的地方，不是提供一个新的单一数字，而是把评测从模型输出端推进到代码库状态端。模型在聊天窗口里生成了 3000 行代码，并不等于仓库最终接受了 3000 行代码。中间可能经过删减、重写、测试失败和人工修复，最终留下的代码增量才更值得分析。

这对模型比较意味着什么

代码增量会改变我们比较 AI 编程模型的方式。过去，开发者通常会问哪个模型的 benchmark 得分更高；未来还需要问，哪个模型能用更小、更稳定、更容易审查的补丁完成同一项任务。

一个理想的编程模型，不应该只是把复杂任务拆成大量代码，而应该理解现有架构，找到最接近问题根源的修改位置。它应该知道什么时候复用已有函数，什么时候新增抽象，什么时候不应该修改代码。

从这个角度看，模型的优势可以拆成三类：

• 生成能力：能不能写出语法正确、功能基本可运行的代码；
• 仓库理解能力：能不能找到正确的模块、接口和依赖关系；
• 变更控制能力：能不能用尽可能小的、可审查的补丁完成任务。

前两项已经被大量基准覆盖，第三项却长期缺少公开、可重复的衡量方式。Parsimony 的出现，正好击中了这一空白。

对于代码审查者来说，小并不天然等于好，但无关变更越多，审查成本通常越高。一个 80 行、只触及两个相关文件的补丁，往往比一个 600 行、同时改动配置、依赖、测试和业务逻辑的补丁更容易验证。Parsimony 提供的代码增量数据，可以帮助团队进一步分析这种审查负担。

AI 编程的瓶颈，正在从生成转向审查

AI 编程工具最早解决的是写代码慢，行业现在面对的却是审查、调试和维护变慢。

一项针对 1255 个工程团队的研究显示，高 AI 采用率团队中，每名开发者合并的 PR 数量增加了 98%，但 PR 审查时间也增加了 91%。这个结果说明，AI 确实提高了代码生成速度，但组织的整体吞吐量并没有同步增长，瓶颈正在从编写阶段转移到审查阶段。

另一组来自工程实践的观察是，AI 生成代码的逻辑错误概率可能达到人工代码的 1.75 倍，涉及提权路径的代码风险甚至高出 322%。这些数字并不意味着 AI 编程工具不可用，而是说明代码产量不能作为生产力的代理变量。

代码审查时间是一项被严重低估的成本。模型生成一个大型补丁时，开发者并不是免费获得了代码，而是获得了一份需要理解、验证和承担责任的候选实现。如果补丁规模不断扩大，团队可能在编辑器里节省了时间，却在 Pull Request 页面和线上故障处理中付出了更多时间。

这也是 Parsimony 对企业有实际意义的地方。团队可以按模型、项目、任务类型和开发阶段统计代码增量，并进一步关联以下指标：

• 每个 PR 的审查时长；
• 代码变更后的静态分析告警数量；
• AI 生成代码的后续修改比例；
• 代码合并后的回滚和热修复数量；
• 任务完成所需的模型调用轮次；
• 代码提交后 30 天、60 天和 90 天内的返工量。

这些数据结合起来，才可能判断模型是在减少工程师工作量，还是把工作量转移到了后续阶段。

不要把 Parsimony 当成新的唯一答案

Parsimony 的局限也很清楚：代码增量仍然不是软件价值。

一个大型重构任务可能天然需要修改数千行代码，不能因为补丁大就判定模型表现差。相反，一个只改动 10 行的补丁也可能引入严重安全漏洞。对于生成测试、迁移数据库、更新类型定义等任务，合理的变更规模本来就不同。

此外，代码删除量也不能简单视为浪费。模型删除冗余逻辑、清理过时接口和压缩复杂实现，可能是高质量行为。真正需要观察的是变更与任务目标之间的关系，而不是机械追求最少行数。

因此，Parsimony 更适合被理解为一个诊断工具，而不是优化目标。团队不应该要求模型把每个补丁压缩到最小，而应该把异常大的增量、异常高的返工率和异常低的有效代码保留率标记出来，交给工程师进一步检查。

还需要注意评测污染问题。如果模型提前见过某个仓库、任务描述或补丁，代码增量结果就可能失去参考价值。公开基准需要明确记录仓库版本、任务版本、模型版本、上下文范围和工具权限，否则不同实验之间很难公平比较。

对开发者和团队的实际意义

对个人开发者来说，Parsimony 提供了一种更实用的模型选择视角。不要只看模型能不能一次生成完整功能，还要看它是否习惯于先理解项目，再做局部修改。对于日常工作，能够稳定地产生小而准确的补丁，通常比偶尔生成一整套看似完整但需要大幅返工的代码更有价值。

对团队来说，可以先从三个动作开始：

1. 在代码评审系统中记录 AI 参与的 PR，并保存初始状态和最终状态之间的差异。
2. 按模型和任务类型统计新增、删除、修改行数，以及审查时间和后续返工情况。
3. 用 60 至 90 天的变更失败率验证短期指标，避免把即时产量误认为长期收益。

这里尤其要避免把指标变成绩效考核。只要代码增量被直接绑定到个人排名，工程师和模型都会被激励去制造更多可计数的变更，而不是解决更重要的问题。正确做法是把这些数据用于模型评估、流程改进和风险识别。

结语：AI 编程需要从产量叙事转向变更叙事

Parsimony 的出现，说明 AI 编程评测正在从模型会不会写代码，转向模型如何改变已有系统。

这一步很重要。今天的模型已经不缺生成代码的能力，真正稀缺的是对上下文的理解、对架构边界的尊重，以及对变更规模的控制。一个模型如果每次都需要大范围重写代码才能完成小任务，哪怕它的测试通过率很高，也未必适合进入大型生产代码库。

截至 2026 年 10 月，AI 编程工具的竞争焦点已经不只是速度和模型参数规模。谁能用更少的无关改动完成更可靠的任务，谁就更接近真正的工程生产力。Parsimony 还不是衡量这一问题的最终答案，但它把一个长期被营销数据掩盖的问题摆到了台面上：AI 写了多少代码，不如它最终让代码库发生了多少必要变化。

参考来源

• Parsimony 项目介绍：开源 AI 编程代码增量评测基准 —— 项目公开信息与代码增量评测思路。
• 千亿参数开源模型编程能力深度解析 —— 关于代码模型上下文规模与编程能力评测的背景资料。
• 100 万亿 Token 看懵硅谷：全球一半算力写代码 —— AI 编程工具采用率与开源模型生态背景资料。
• 超越 GPT-4.1：阿里开源 Qwen3-Coder —— 开源代码模型能力和 Agent 编程趋势资料。