数据分析显示Claude辅助开发未显著增加rsync缺陷

数据分析·2026年6月对每个包含缺陷数据的rsync版本进行简单的分布分析。不复杂，只回答一个问题：Claude辅助的版本是否异常地充满缺陷？

为了避免被指控“这只是Claude在为Claude辩护”、“AI垃圾”、“可能全是幻觉”等，我决定解释一下这份报告的几个关键点：- 所有指标、方法和数据来源均由我和我妻子（拥有宾夕法尼亚州立大学统计学硕士学位）共同选择。

- 方法直接基于我妻子的建议：她指出，由于Claude后的样本数量少，试图比较前后每十行代码的缺陷数可能受噪声影响太大；同样，构建线性回归模型来评估不同变量的相对影响可能也行不通。

她特别告诉我，最好的方法是观察Claude后的版本在历史分布中的位置，以及从历史分布中得出与Claude后版本一样“差”或更差的版本的可能性有多大。

- 我花了几天时间，甚至在创建GitHub仓库之前就用了两天，并且至少对报告进行了一次重大重写，以采用更好的方法（基于我妻子的反馈）。

这对我来说是大量的手动认知工作。- 用于获取数据、整理到DuckDB数据库文件、在数据库上构建视图、然后对数据进行统计分析的脚本，确实是由GLM 5.1编写的，包括你现在看到的最终报告网页的HTML和大部分原始散文。

- 然而，关键在于，本报告中的所有数字、统计量、卡片和图表都是由运行统计分析的Python脚本自动模板化的，从而避免了数字中出现幻觉或不一致的可能性。

- 在Hacker News上发布后，几乎没有收到关于文章实际内容的实质性意见、讨论或回应，我决定用自己的语气重写所有散文。如果有人抱怨我啰嗦或句子结构——就像他们通常做的那样，这也是我最初让AI写散文的原因之一，其他原因因模板化而过时——他们可以去死。

- 如果你想复制这里的数据和结果，并检查它们是如何计算的，可以在这里找到仓库。我有意让整个流程可以完全从头到尾运行，这样你就能看到完整的端到端流程，没有神秘的数据库二进制文件迫使你相信我没有篡改或搞砸数据。

如果你想对数字发火，先看看那里。2026年5月下旬，rsync爆发了。

首先，一篇毫无证据的Mastodon帖子指出，某个用户升级到某个版本后遇到的回归与该版本包含Claude提交之间存在虚假相关性。该帖子的观看次数未知，但点赞和转发轻松超过数千，并获得了显著关注——就像所有虚假的反AI仇恨一样——有来自32个独立用户的58条回复。

有人毫无证据地愤怒于“认知投降”；另一个人建议将rsync加入著名的开源垃圾软件黑名单。随后，它传播到Hacker News，共有81条评论，充满了恐惧、愤怒和欢呼，声称这最终证明了没有人可以安全使用LLM。

其中一条评论进一步推动了“回归和缺陷是由Claude造成的”这一观点。2026年5月30日，这场迅速蔓延的愤怒突然汇聚成一个焦点：一个针对rsync仓库的GitHub问题，标题为“请不要搞砸这个软件”。

它附上了一张Mastodon帖子的截图，批评该项目使用Claude。仅此而已。没有缺陷报告，没有技术内容，没有尝试实际确认担忧是否真实或合理；只有350多条评论，从深思熟虑的担忧到彻底的骚扰（大多数最恶劣、不合理和暴力的评论已被删除；

很少有人想到要保留它们）。帖子并未止于言语。

正如反AI用户的典型情况，它最终升级为暴力幻想。一位用户发布了一条现已删除的评论，其中包括《小马宝莉》风格的图画，画中他们勒死了“推送vibecoded提交的项目清洁工”：完成互联网愤怒循环后，这个问题又传播到Hacker News，产生了数百条评论。

一些人试图指出Claude引入后的回归数量——“Linux Mint Timeshift工具有一个开放的问题，记录了当前在rsync问题页面上打开的许多回归，这些回归仅在vibecoding之后引入”——作为情况更糟的证据。

其他人则指出这些回归并非由Claude引起，作为回应，目标又被移动了。一次又一次，核心主题是一个中心主张，到处重复：Claude辅助开发将缺陷引入了以前稳定的工具。

AI是认知投降，是可卡因，是技艺的丧失，用户因此愤怒是合理的：“人们非常合理地愤怒，一个非常稳定、值得信赖的工具开始立即走下坡路……这一切都是因为主要开发者正在对该软件进行vibecoding。

”——fao_ on Hacker News然而，讽刺的是，这并不一定是一个只能基于“感觉”来解决的问题。这至少在某种程度上是可以经验检验的。有人甚至指出了这一点：在Lobste.rs上，

作为对Tridge本人发布的Medium文章的回应，终于有一些用户如boramalper开始实际以某种方式要求证据：“如果有人真的在每次发布后（如果可能的话）做一个回归的时间图表，看看这个数字最近是否真的上升了，那会很有趣。

”——boramalper on Lobsters用户bitshift回复：“我也很想看到这样的图表。它不会完全有信息量……但至少我们可以衡量一些客观的东西。”这个分析就是那个图表。或者，考虑到数据的限制，尽可能做到最好（参见上一节）。

- 包含缺陷数据的36个版本，跨越v2.4.6到v3.4.3- 2个版本有Claude提交：v3.4.2（9个Claude提交，0.00 sev/10c）和v3.4.3（28个Claude提交，3.29 sev/10c）- Claude版本在相反方向包围了IQR：

v3.4.2低于IQR，v3.4.3高于它。两者都不是异常值。- 精确排列检验p值=46%：随机选择任何2个版本，46%的情况下你会得到同样差或更差的分数。这是最强的可用检验，结果不显著。

- Fisher精确检验p值=74%：Claude版本不比任何其他版本更可能高于历史中位数（优势比1.06）。- 历史均值是Claude均值的1.8倍（2.95 vs 1.65 sev/10c）- v3.4.

1（59个缺陷/9个提交，无Claude）是一个异常值，但属于基线——它是一个版本，且分布已经包含了它。该分析使用单一指标：每10次提交的严重性加权缺陷数（sev/10c）。

每个缺陷被标准化为0-1的严重性分数（LLM分配的严重性除以100），这些分数在每个版本中求和，而不是简单计数缺陷。表中也显示了原始缺陷计数以供参考，但sev/10c驱动所有统计检验。

sev/10c = (Σ severity/100 ÷ total_commits) × 10默认分支上的每个提交按提交者日期排序，以生成顺序时间线。每个git标签指向此时间线中的特定提交。一个版本的范围是前一个标签和其自身标签之间的所有提交。