Claude是否增加了rsync中的bug？

# Claude 是否增加了 rsync 中的 Bug 数量？ 来源：https://alexispurslane.github.io/rsync-analysis/ 数据分析 · 2026年6月 对每个有 Bug 数据的 rsync 发布版本进行了简单的分布分析。没啥复杂的，只回答一个问题：那些由 Claude 辅助生成的发布版本是否异常地充满 Bug？ 仓库:RsyncProject/rsync (https://github.com/RsyncProject/rsync) 方法: 每10次提交的 Bug 数量，精确排列检验 ## 0 · 免责声明：AI 辅助的使用方式 为了避免被指责为“这只是在为 Claude 辩护”、“AI 垃圾内容”、“可能全是幻觉”等等，我决定最好解释一下本报告创建过程中的几个关键点： - 所有指标、方法论和数据来源均完全由我本人选择，并与我的妻子（她拥有宾夕法尼亚州立大学的统计学硕士学位）共同商议。 - 方法论直接基于我妻子的意见：她指出，仅比较 Claude 辅助开发前后的每十行代码 Bug 数量，可能会因 Claude 辅助开发后的样本量太少而受到过多噪音影响，并且出于类似原因，尝试构建某些线性回归模型来确定不同变量的相对影响也可能无法奏效。她特别告诉我，最好的方法是观察 Claude 辅助开发后的发布版本在历史分布中的位置，以及从历史分布来看，我们有多大可能性会遇到与 Claude 辅助开发后一样“糟糕”或更糟的发布版本。 - 我花了几天时间，甚至在创建 GitHub 仓库之前就花了两天，并且根据上述我妻子的反馈，对报告进行了至少一次重大的全面重写，以采用更好的方法论。这对我个人来说需要付出大量的*手动和认知努力*。 - 用于获取数据、将其整理到 DuckDB 数据库文件中、在该数据库上构建视图，然后对这些数据进行统计分析以及你现在看到的最终报告网页的 HTML 和大部分原始散文，确实是由 **GLM 5.1** 撰写的。 - 但至关重要的是，**本报告中的所有数字、统计数据、卡片和图表均由运行统计分析的 Python 脚本直接模板化生成**，从而避免了数字出现任何幻觉或不一致的可能性。 - 在将此文发布到Hacker News (https://news.ycombinator.com/item?id=48411635)并几乎未收到关于文章*实际内容*的任何实质性意见、讨论或回应后，我决定用自己的语气重写所有散文。如果有人抱怨我的啰嗦或句子结构——就像他们通常做的那样，这也是我最初让 AI 写散文的原因之一，此外还有其他因模板化而变得多余的原因——那么他们可以滚蛋了。 - 如果你想复制这里的数据和结果，并检查它们是如何计算出来的，你可以在[此处](https://github.com/alexispurslane/rsync-analysis/)找到仓库。我特意使整个流程可以从头到尾完全重新运行，这样你就可以看到端到端的整个流程，中间没有神秘的数据库 blob 强迫你相信我没有篡改或搞砸数据。如果你想对这些数字感到不满，请先查看那里。 ## 1 · 背景：*rsync* 引发的众怒 2026年5月下旬，rsync 项目突然爆火。首先，在Mastodon 上发布了一条毫无证据的帖子 (https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345332213390)，指出某用户升级到某个版本后遇到的性能回退与该版本包含 Claude 提交之间存在虚假关联。该帖子的具体浏览量未知，但点赞和转发量轻松过千，并获得了极大关注——就像所有虚假的反 AI 仇恨言论一样——收到了来自 32 个独立用户的 58 条回复。有人毫无证据地怒斥“认知投降”；另一个人建议将 rsync 添加到著名的 open-slopware (https://codeberg.org/small-hack/open-slopware) 黑名单 (https://en.wikipedia.org/wiki/Index_Librorum_Prohibitorum) 中。随后，此事传播至Hacker News (https://news.ycombinator.com/item?id=48334021)，获得81条评论，充满了混合的恐惧、愤怒以及关于这最终一劳永逸地证明了没有人可以安全使用 LLM 的炫耀。在所有这些评论中，有一条特定评论 (https://news.ycombinator.com/item?id=48334270) 进一步助长了性能回退和 Bug 是由 Claude 导致的观点。 2026年5月30日，这场逐渐升温的愤怒最终汇聚到一个焦点：一个名为“请不要用‘Vibe Coding’搞砸这个软件” (https://github.com/RsyncProject/rsync/issues/929) 的 GitHub Issue，针对 rsync 仓库提出。该 Issue 附带了一张 Mastodon 帖子的截图，批评该项目使用 Claude。仅此而已。没有 Bug 报告，没有技术内容，没有试图实际确定担忧是否真实或合理；只有**超过 350 条**评论，从深思熟虑的关切到公然骚扰不等（大部分最过分、最不合理和最暴力的评论已被删除；很少有人想到要将它们保存下来）。 GitHub 问题截图 引发这一切的 GitHub Issue。原始帖是一张 Mastodon 批评的截图，没有 Bug 报告，没有技术内容。此后已积累了**329 条**评论。Hacker News 讨论帖截图 讨论迅速升级，从“软件是免费的，如果你不喜欢，请 fork 或滚开”发展为：“你给无家可归的人免费施汤，不代表你就可以往里面撒尿。”讨论并未止于言语。正如反 AI 用户的典型行为 (https://www.msn.com/en-us/news/technology/animator-jorge-gutierrez-got-death-threats-over-ai-then-he-quit/ar-AA24ph6X) 那样，最终升级到了暴力幻想。一位用户发布了一条现已删除的评论，其中包含一张《我的小马驹》风格的图片，描绘了自己扼住“推送了 Vibecoded 提交的项目杂工”的脖子： 暴力威胁图片 用户发布的描绘对 rsync 维护者实施暴力的图画，这是将 Issue 从激烈辩论升级为骚扰的多个威胁之一。随着互联网愤怒周期的完成，这个 Issue 又传播到了Hacker News (https://news.ycombinator.com/item?id=48342705)，产生了数百条更多评论。有人试图 (https://news.ycombinator.com/item?id=48346124) 指出引入 Claude 后的回归数量——*“Linux Mint Timeshift 工具有一个开放的 Issue，记录了 rsync Issue 页面上当前开放的许多回归问题，这些都是在‘vibecoding’之后才引入的”*——以此为证据表明情况更糟了。其他人则指出 (https://news.ycombinator.com/item?id=48348708) 那些回归问题并非由 Claude 导致，作为回应，目标（论点）再次被改变。一遍又一遍，核心主题是一个中心主张，到处重复：Claude 辅助开发曾在一个以前稳定的工具中引入了 Bug。AI 是认知投降，是毒品，是技艺的丧失，因此用户有理由感到愤怒： > 人们非常合理地愤怒，一个*非常稳定、备受信赖的工具*，已经开始立刻走下坡路……**完全是因为主要开发者在使用‘vibecoding’开发那个软件。** — fao_ 在 Hacker News 上 然而，这并不必须仅仅依靠——讽刺的是——“直觉”来解决。这是可以，至少在某种程度上，通过经验来检验的。有些人甚至指出了这一点： 在 Lobste.rs 上，回应Tridge 本人为此发布的中等文章 (https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0)，终于有一些用户，比如 `boramalper`，开始真正要求提供证据： > 如果有人能实际制作一个在每次发布后（如果可能的话）回归问题的时间图，看看最近数量是否真的增加了，那会很有趣。 — boramalper 在 Lobste.rs 用户 `bitshift` 回复道：*“我也很想看到这样的图表。它不能完全说明问题……但至少我们可以测量一些客观的东西。”* **本分析就是那张图表。** 或者，嗯，是在给定数据限制条件下（见上一节）所能做到的最好的结果。 ## 2 · 执行摘要 - **46 个包含 Bug 数据的发布版本，** 涵盖 v2.4.6 到 v3.4.3 - **2 个版本包含 Claude 提交：** v3.4.2（9个Claude提交，0.80 bugs/10c）和 v3.4.3（28个Claude提交，6.76 bugs/10c） - **两者均落在历史分布的中间 50%** 区间内 - **精确排列检验 p 值 = 46%：** 如果你随机挑选任意 2 个版本，有 46% 的概率会得到同样糟糕或更差的结果 - **历史均值是 Claude 组均值的 2 倍**（7.59 vs 3.78 bugs/10c） - **未检测到状态转变：** 游程检验 p=0.123，序列与随机性一致 - **v3.4.1（102 个 Bug / 9 次提交，无 Claude）** 是一个异常值，但属于基准线的一部分——它是一个发布版本，分布已经将其纳入其中 ## 3 · 衡量指标 本分析使用单个指标：**每 10 次提交的 Bug 数量**（bugs/10c）。对于每个发布版本，将其归因的 Bug 数量除以其范围内的提交次数，再乘以 10。这消除了版本规模的影响。 bugs/10c = (Bug数量 ÷ 总提交次数) × 10 ### 如何将提交分配给发布版本 默认分支上的每次提交都按提交者日期排序，以产生一个时间线。每个 git 标签指向此时间线中的特定提交。一个发布版本的范围是其前一个标签与其自身标签之间的所有提交。预发布标签（“pre”、“rc”）作为边界被跳过，并合并到其最终发布版本中。每次提交恰好属于一个发布版本。 ### 如何查找 Bug 并将其分配给发布版本 Bug 计数来自三个来源： 1. rsync 仓库中的 GitHub Issues（通过 GitHub REST API 整理）， 2. rsync 的 Bugzilla 实例（通过其 API 收集）， 3. 以及 rsync 邮件列表。 GitHub Issues 和邮件列表中的 Bug 被归因于 Bug 报告提出之前最近发布的那个版本。对于 Bugzilla，每个条目都有一个“版本”字段，明确说明该 Bug 是针对哪个版本报告的，Bug 被归因于该版本。 ### 为什么以版本为分析单位 为什么按版本分组提交，按版本分组 Bug，然后通过中间变量版本来确定 Claude 提交与 Bug 之间的相关性（或缺乏相关性）？这有两个原因。 首先，因为批评者提出的主张本身也是以版本为单位的：即在某个版本中包含任何 Claude 提交会使整个版本在整体上变得明显更易出错，而不仅仅是说 Claude 编写的提交可能会引入更多 Bug。后者是一个不同的指标，因为*同一版本中后续的 Claude 或人类编写的提交可能会纠正这些 Bug*，这样在版本发布时就不会有人注意到，总体上也不会影响用户；此外，正如其他地方所述，重要的是要切中批评者的主张点。如果这能迫使他们使自己的主张更加细致入微——或者以其他方式改变目标——那么*任务就完成了*。 其次，这是一个归属问题：绝大多数 Bug 并没有明确说明是哪个提交导致的，因为这样做需要大量的研究和分析，而相比直接“向前修复”，这往往是不值得的，即使进行了*那种*分析（比如通过 `git bisect`），也不一定能产生有用的结果，或者任何结果。许多 Bug 可能是由多个提交的组合导致的，这些提交在时间上往往相隔很远，很难说清楚是哪个提交真正引入了这个 Bug。或者，一个提交可能同时揭示了其他提交引入的多个潜在 Bug，等等。 ### 为什么是 Bug 和提交？ 批评者的主张是简单化、绝对化和普遍化的：暴露于 Claude 的版本中 Bug 率上升了。因此，最诚实的回应就是分析他们声称的确切内容：Bug、提交、版本和 Claude 暴露的提交。如果 Claude 相关的版本位于历史分布的中间位置，那么举证责任就转移到了批评者身上，他们需要解释为什么这个特定的中间位置比之前所有其他中间位置更糟糕。即使最终结果是促使对话转向对版本中 Bug 的*质量*、*类型*和*用户影响*进行更细致的讨论，那也已经是支持 AI 人群的重大胜利，并迫使反 AI 人群改变目标。然后，我们可以在此基础上进行进一步的分析。球现在在反 AI 一方的场上。 ### 这种方法不做的事情 我知道这个指标无法控制提交的复杂性、安全强度或 Bug 严重性。它无法区分一行代码的拼写错误修复和一个 CVE 补丁。它是一个粗糙的工具。但批评者的指控同样粗糙：“Claude 让情况变得更糟。”回应这种指控正需要一个粗糙的工具。以牙还牙。 ## 4 · 结果 ### Claude 辅助开发的版本 在我们进行更深入的分析之前，先看看这两个 Claude 版本本身，对它们有个感性的认识： ### v3.4.2 0.80 bugs/10c 4 个 Bug · 50 次提交 · 9 个 Claude 提交 第31百分位（在35个中排名第11） ### v3.4.3 6.76 bugs/10c 23 个 Bug · 34 次提交 · 28 个 Claude 提交 第74百分位（在35个中排名第26） 如果这对你来说看起来不像一个危险信号，那么你的感觉是对的。 ### 精确排列检验 所以问题是：是 Claude 辅助开发的版本异常地充满 Bug，还是仅仅因为运气不好，你也可以轻松地从历史分布中抽出一组同样糟糕的版本？从统计上回答这个问题的方法是**精确排列检验** (https://en.wikipedia.org/wiki/Permutation_test)，它列举所有两个版本的组合，并询问：其中有多大比例的平均 Bug 率与我们实际观察到的一样差或更差？这个比例就是被检验假设的 p 值。 46% 精确排列检验的 p 值（单侧，备择假设 H1：Claude 组均值 > 历史均值） 在 595 个可能的两版本历史组合中，有 271 个的平均 bugs/10c 大于等于 3.78。接近一半。Claude 版本正好位于排列分布的中间位置——它们一点也不极端。 检验统计量：每组平均 bugs/10c · Claude 组均值：3.78 · 历史均值：7.59 这个 p 值告诉我们的是，“Claude 让版本更糟糕”这个假设，至少到目前为止，其预测能力大约相当于抛硬币：如果你闭上眼睛随机挑选 2 个版本，几乎有一半的概率会得到同样糟糕或更差的结果。Claude 组并没有什么异常之处。 ### 费舍尔精确检验 排列检验会问：随机一组版本得到像 Claude 组那样差得分的可能性有多大？但还有另一种方式提出问题：Claude 辅助开发的版本是否比非 Claude 版本更有可能落在历史中位数之上？这是一个教科书式的 2×2 列联表，其标准检验是**费舍尔精确检验** (https://en.wikipedia.org/wiki/Fisher%27s_exact_test)。 ≤ 中位数> 中位数非Claude1817Claude11 74% 单侧 p 值（备择假设 H1：Claude 更可能高于中位数） 费舍尔精确检验问的是：如果我们在历史中位数（1.67 bugs/10c）处将所有版本一分为二，Claude 版本是否显著更有可能落在其上部的区域？p 值为 74%，答案是明确的不。优势比为 1.06——本质上就是 1:1。Claude 版本并不比其他任何版本更有可能高于中位数。 优势比：1.06 · 中位数：1.67 bugs/10c ### 分布情况 如果你还不信服，这里有一个视觉辅助工具，显示了这些版本在之前所有版本分布中的位置： 中间 50% v3.4.2 位于中间 50% ✓ v3.4.3 位于中间 50% ✓