Claude 真的增加了 rsync 的 Bug 吗？——一项定量分析

0 · 免责声明：AI 辅助的使用方式

为了避免被指责为“Claude 替自己辩护”“AI 垃圾”“全是幻觉”等，我认为有必要解释一下这份报告的几个关键点：

所有指标、方法论和数据来源均由我本人选择，并咨询了我的妻子（她拥有宾夕法尼亚州立大学统计学硕士学位）。方法论直接基于我妻子的意见：她指出，试图简单地比较前后每十行代码的 Bug 数量容易受到噪声影响，因为包含 Claude 的版本样本量太少；同样，构建线性回归模型来评估不同变量的相对效果也可能不可行。她明确告诉我，最好的方法是观察引入 Claude 后的版本在历史分布中的位置，并计算从历史分布中得到与这些版本一样“差”或更差版本的概率。

我花了几天时间，在创建 GitHub 仓库前就花了两天，并且根据上述反馈对整个报告至少进行过一次大的重写。这耗费了我大量手工认知劳动。获取数据、整理到 DuckDB 数据库、构建数据库视图以及进行统计分析所使用的脚本，确实是由 GLM 5.1 编写的；HTML 和你正在看的最终报告页面的许多原始文本也是它写的。但关键在于，本报告中的所有数字、统计量、图表和图形都是由运行统计分析的 Python 脚本直接模板化生成的，从而避免了任何数字上的幻觉或不一致。

在 Hacker News 上发布后，几乎没有收到对文章实际内容的实质性输入、讨论或回应，我决定用自己的语言重写所有文本。如果有人抱怨我的冗长或句子结构——就像他们通常做的那样，这也是我最初让 AI 写文本的原因之一——他们可以去死。如果你想复制这里的数据和结果，并检查它们是如何计算的，可以在此处找到仓库。我有意让整个流程可以从头到尾完全重新运行，这样你就可以看到完整的端到端流程，没有神秘的数据库 Blob 迫使你相信我没有篡改数据。如果你对数字有意见，请先查看那里。

1 · 背景：rsync 风波

2026 年 5 月下旬，rsync 爆发了争议。首先，一个没有证据的 Mastodon 帖子指出，某个用户升级到某个版本后遇到的回归与该版本包含 Claude 提交之间存在虚假相关性。该帖子的查看次数不详，但点赞和转发轻松超过数千，并且获得了显著关注——就像所有虚假的反 AI 仇恨一样——收到了来自 32 个独特用户的 58 条回复。有人毫无证据地怒斥“认知投降”；另有人建议将 rsync 添加到著名的“开源垃圾”黑名单中。

随后，争议蔓延到 Hacker News，有 81 条评论，充满了恐惧、愤怒以及洋洋得意，声称这最终一劳永逸地证明了没有人可以安全地使用 LLM。其中有一条评论特别推助了“回归和 Bug 是由 Claude 引起的”这一观点。

2026 年 5 月 30 日，这场沸腾的愤怒汇聚成一个焦点：一个针对 rsync 仓库的 GitHub Issue，标题为“请不要用 Vibe 编程搞砸这个软件”。它附上了一张 Mastodon 帖子的截图，批评该项目使用 Claude。就这样。没有 Bug 报告，没有技术内容，没有尝试确认担忧是否真实合理；只有 350 多条评论，从深思熟虑的关切到直接的骚扰（最恶劣、不合理和暴力的评论大多已被删除，很少有人想到保存它们）。

这个 GitHub Issue 是这一切的起点。原始帖子是一张 Mastodon 评论的截图，没有 Bug 报告，没有技术内容。它已经积累了 329 条评论。讨论很快升级，从“软件是免费的，不喜欢就分叉或滚开”到“你虽然给流浪汉免费汤，不代表你可以往里面撒尿”。讨论不止于言语。最终，一名用户发布了现在已被删除的评论，其中包含自己掐死“推送了 Vibe 编程提交的项目清洁工”的小马宝莉图画，从而升级为暴力幻想描绘。

完成互联网愤怒周期后，这个 Issue 又传播回 Hacker News，产生了数百条更多评论。一些人试图引用引入 Claude 后的回归数量——“Linux Mint Timeshift 工具有一个 Issue 记录了 rsync Issues 页面上当前打开的许多回归，这些回归都是在 Vibe 编程之后引入的”——作为情况变得更糟的证据。其他人指出这些回归并非由 Claude 引起，作为回应，目标又被移动了。

核心主题是一再重复的中心主张：Claude 辅助开发将 Bug 引入了一个先前稳定的工具。AI 是认知投降，是毒品，是技艺的丧失，用户因此有理由愤怒：

人们非常合理地愤怒，一个非常稳定、值得信赖的工具开始立即走下坡路……仅仅因为主要开发者正在 Vibe 编程这个软件。 ——fao_ 在 Hacker News 上

然而，这个问题不一定只能基于——讽刺地——感觉来解决。这是可以在一定程度上进行实证检验的事情。有些人甚至指出了这一点：

在 Lobste.rs 上，作为对 Tridge 本人发布的中等文章的回应，终于有像 boramalper 这样的用户开始要求某种证据：

如果有人真的画出一个每次发布后回归的时间图表（如果可能的话），看看最近数量是否真的上升，那会很有趣。 ——boramalper 在 Lobsters 上

用户 bitshift 回复道：“我也很想看到这样的图表。它不会完全有决定性……但至少我们可以有某种客观的东西来衡量。”

本分析就是那个图表。或者，鉴于数据的局限性（见上一节），尽力而为的结果。

2 · 执行摘要

• 包含 Bug 数据的 36 个版本，范围从 v2.4.6 到 v3.4.3
• 2 个版本包含 Claude 提交：v3.4.2（9 个 Claude 提交，严重性加权 Bug 密度 0.00）和 v3.4.3（28 个 Claude 提交，严重性加权 Bug 密度 3.29）
• 两个 Claude 版本分别位于四分位距（IQR）的两侧：v3.4.2 低于 IQR，v3.4.3 高于 IQR。两者都不是离群值。
• 精确置换检验 p 值 = 46%：随机选择任意 2 个版本，有 46% 的概率会获得与 Claude 版本一样差或更差的结果。这是可用的最强检验，没有发现任何显著差异。
• Fisher 精确检验 p 值 = 74%：Claude 版本落在历史中位数以上的可能性并不比其他版本更高（优势比 1.06）。
• 历史均值是 Claude 均值的 1.8 倍（2.95 vs 1.65 严重性加权 Bug 密度）
• v3.4.1（59 个 Bug / 9 个提交，无 Claude）是一个离群值，但它属于基线——它是一个版本，分布已经包含了它。

3 · 指标

本分析使用单一指标：严重性加权的每 10 次提交 Bug 数量（sev/10c）。每个 Bug 被归一化为 0-1 的严重性分数（其 LLM 分配的严重性除以 100），然后将这些分数按版本求和，而不是简单计数。原始 Bug 计数也在表中显示以供参考，但所有统计检验都基于 sev/10c。

sev/10c = (Σ 严重性/100 ÷ 总提交数) × 10

提交如何分配到版本

默认分支上的每个提交都按提交者日期排序，以产生顺序时间线。每个 git 标签指向该时间线中的特定提交。一个版本的范围是前一个标签和它自己标签之间的所有提交。预发布标签（“pre”、“rc”）不作为边界跳过，而是吸收到其最终版本中。每个提交恰好属于一个版本。

Bug 如何被发现并分配到版本

Bug 报告来自三个来源：rsync 仓库中的 GitHub Issue（通过 GitHub REST API 收集）、rsync Bugzilla 实例（通过 API 收集）以及 rsync 邮件列表。GitHub Issue 和邮件列表 Bug 归属于报告该 Bug 之前发布的最新版本。对于 Bugzilla，每个条目有一个“Version”字段明确说明该 Bug 报告针对哪个版本，因此 Bug 归属于该版本。

严重性评分

为了控制 Bug 严重性——正如有人所说，按钮拼写错误和 CVE 不应被平等对待——每个 Bug 报告都按 0-100 的尺度进行了严重性评分。评分者是 Qwen 3 35B，一个小的开源语言模型，被提示为评估实际影响的高级可靠性工程师。每个 Bug 报告的标题和正文文本（截断至 3000 个字符）以及以下评分标准提供给模型：

分数范围	类别	描述
90–100	数据丢失/损坏	静默数据损坏或丢失。用户的文件或备份出错，他们可能直到为时已晚才发现。允许远程代码执行或未授权访问的安全漏洞。
70–89	崩溃/挂起/备份失败	rsync 崩溃、挂起或以破坏自动备份或 cron 作业的方式失败。数据未损坏但备份丢失。导致 rsync 在生产中无法使用的高 CPU 或内存使用。构建或编译失败——如果 rsync 无法从源码构建，用户根本无法安装。这是一个阻塞问题，不是小不便。至少评分 70。暴露敏感数据的安全漏洞。
50–69	功能回归	功能回归——曾经能用的东西不再能用，但有变通方案。足以中断生产工作流的性能回归。可见的错误输出（错误、文件名错误）但不损坏数据。
30–49	轻微回归	带有简单变通方案的轻微功能回归。错误消息令人困惑但操作仍成功。间歇性测试失败。在非主流平台上的可移植性问题。
10–29	外观/低影响	外观问题、文档错误、轻微的 UX 烦恼。仅影响测试而不影响用户的问题。
0	功能请求	如果 Issue 是请求新功能、更改默认行为或打包建议——无论多么合理——它就不是 Bug。评分为 0。
0–9	非真实 Bug	垃圾、离题、重复。与 rsync 明显无关或为空/无意义的 Issue。

所有三个 Bug 来源——GitHub Issue、Bugzilla 和 rsync 邮件列表——都被评分。Bugzilla 和邮件列表报告只有标题（无正文），因此模型仅从标题进行评分。模型被指示在正文没有提供足够信息时依赖标题并倾向于范围中间（40-60）。模型还被要求通过结构化输出（JSON Schema）仅输出严重性整数，因此没有需要解析的自由文本响应。评分在温度为 0 的情况下进行以确保确定性——相同输入始终产生相同输出。分数为 0 的 Issue（功能请求、垃圾、关于 AI 的离题言论、空提交）默认从 Bug 计数中排除。这很重要，因为某些版本在 GitHub 上吸引了大量噪声。例如 v3.4.2 提交了 4 个 Issue；实际上，所有这些 Issue 都是针对 AI 的离题言论，因此最终 Bug 计数为 0。