rsync 中 Claude 辅助开发的分析

执行摘要：缺陷数量在统计学上没有增加

与历史版本相比，rsync 中 Claude 辅助开发并未导致缺陷数量在统计学上显著增加。 对 36 个版本（v2.4.6 到 v3.4.3）的分布分析显示，包含 Claude 提交的发布版本处于缺陷密度的正常历史范围内。具体而言，精确排列检验（exact permutation test）得出的 p 值为 46%，这意味着随机选择的历史版本中，有近一半的时间其缺陷程度会与 Claude 辅助发布的版本一样多甚至更多。

"rsync 愤怒事件"与数据需求

2026 年 5 月，在 Mastodon、Hacker News 和 GitHub 上出现了一波批评浪潮，原因是有人声称 rsync 维护者使用 Claude（一种 LLM）引入了该稳定工具的回归问题。这在 GitHub issue #929 "Please Do Not Vibe Fuck Up This Software" 中达到顶峰，该 issue 吸引了超过 350 条评论。批评者认为，“vibecoding”——即依赖 LLM 而缺乏严谨的人工思维模型——正在导致软件质量下降。

为了超越轶事证据，研究人员进行了一项技术分析，以确定 Claude 辅助发布的版本相对于项目的历史记录是否异常多缺陷。

方法论：严重程度加权缺陷密度

为了确保公平比较，分析使用了单一的归一化指标：每 10 次提交中的严重程度加权缺陷数 (sev/10c)。这种方法可以防止轻微的界面问题与关键的数据丢失缺陷被同等对待。

数据收集与评分

  • 来源： 缺陷报告汇集自 GitHub issues、rsync Bugzilla 实例以及 rsync 邮件列表。
  • 归属： 缺陷被归属于在报告提交前发布的最新版本，或 Bugzilla 中明确指出的版本。
  • 严重程度评分： 一个语言模型（Qwen 3 35B）充当高级可靠性工程师，根据严格的评分标准对每个缺陷进行评分，范围从 0 到 100。评分范围从 0（功能请求/垃圾信息）到 90–100（静默数据损坏或远程代码执行）。
  • 归一化： 最终指标计算方式为：(Σ severity/100 ÷ total_commits) × 10。

为什么以版本为分析单位

分析以版本而非单个提交为单位，解决了归属问题。大多数缺陷报告不会指出特定的提交，且许多缺陷是随着时间推移由多个提交共同作用产生的。此外，批评者的观点是在版本层面提出的，因此这也是测试最合适的基准。

关键发现

分布分析

两个版本包含 Claude 提交：v3.4.2 和 v3.4.3。它们相对于历史分布的表现如下：

  • v3.4.2： 0.00 sev/10c（第 0 百分位数）。该版本没有任何实际缺陷。
  • v3.4.3： 3.29 sev/10c（第 77 百分位数）。虽然有所上升，但并非离群值；有八个历史版本得分更高。

统计检验

  • 精确排列检验： p 值为 46% 表明 Claude 组不是极端的离群值。没有信号表明 Claude 会使版本质量变差。
  • Fisher's Exact Test： p 值为 74%，意味着 Claude 发布的版本比任何其他版本更有可能落在历史中位数之上（赔率比 1.06）。
  • 阶段检查： 当将分析限制在 v3.x 时代（其平均缺陷率高于 v2.x）时，Claude 发布的版本仍处于中游或更好。

代码量 vs. 缺陷量

在比较变更的代码行数 (LoC) 与缺陷数量时，出现了一个有趣的差异：

  • 变更行数： Claude 发布的版本平均变更了 3,756 行，而 Claude 非发布版本平均变更了 696 行（p=5%）。
  • 缺陷数量： 尽管代码变更量显著更高，但 Claude 发布的版本平均仅有 5.6 个严重程度加权缺陷，而非 Claude 发布版本平均为 14.9 个（p=77%）。

这表明，虽然 Claude 可能增加了变更的量，但它并没有增加缺陷的绝对数量。

Pre-Claude 离群值

数据揭示，在采样历史中缺陷最多的版本是 v3.4.1，其中不包含任何 Claude 提交。该版本记录了 39.39 sev/10c（9 次提交中包含 59 个缺陷）。该版本是在 v3.4.0 发布后的第二天作为热修复版本发布的。分析指出，这一极端离群值并未引发类似的社交媒体愤怒，这表明对 v3.4.3 的抵触情绪是由 AI 的存在而非实际的缺陷率驱动的。

讨论与反驳点的综合分析

回归问题的因果因素

Hacker News 和 Lobsters 上的技术讨论表明，感知到的缺陷增加并非由 Claude 的编码能力引起，而是由 AI 生成的安全报告激增导致的。

变更量增加（以及随之而来的回归问题增加）的触发因素是（主要是）由 LLM 赋能的安全问题涌入。即，因果链是：LLMs → 更多已知的安全问题 → 需要比平时更多的变更 → 更多比平时更多的回归问题。 — jbert on Lobsters

维护者 Andrew Tridgell 证实，大量的 AI 生成的 CVE 报告迫使 rsync 对其攻击面进行快速且广泛的变更，这自然增加了回归的风险。

批判性观点

尽管有统计学发现，一些批评者认为定量分析是不充分的：

  • 定性影响： 一些用户认为缺陷的 nature（性质）比速率比更重要。如果软件的感知质量下降，无论 sev/10c 指标如何，该工具都变得“更差”。
  • 样本量： 批评者指出，仅从两个 Claude 辅助发布的版本进行结论是统计学上效力不足的。
  • LLM-Specific Errors： 引用了一些 Claude 编写的提交中引入了细微的性能损耗（例如，强制所有分配使用 calloc），这可能通过标准测试但可能影响系统效率。

维护者结论

Andrew Tridgell 为使用 LLM 作为对现代安全景观的必要适应，辩护了这一做法，并表示，报告的数量变化改变了软件维护的性质，报告的 正确性 正在被谨慎对待，尽管使用了 AI 工具。

Sources