数据分析 · 2026年6月 一项简单的分布分析，针对每个带有漏洞数据的rsync版本。没有复杂的内容，只回答一个问题：克劳德协助的版本是否异常多漏洞？ 仓库：RsyncProject/rsync 方法：每10次提交中的漏洞数量，精确置换检验 0 ·免责声明：如何使用AI帮助 为了避免“这只是克劳德在为克劳德辩护”、“AI废话”、“可能都是幻觉”等指控，我决定可能值得解释一些有关此报告创建的关键点： 所有指标、方法论和数据来源都是我独自选择的，咨询了我的妻子，她拥有宾州州立大学的统计学硕士学位。方法论直接基于我妻子的建议：她指出，尝试比较前后的每十行代码中的漏洞数量可能会受到噪声的影响，因为克劳德之后的样本数量较少，并且出于类似原因，尝试建立某种线性回归模型来确定不同变量的相对影响可能也不会奏效。她特别告诉我，查看克劳德后版本在历史分布中的位置，以及从历史分布中我们获得像“糟糕”或更糟的版本的可能性，可能是最好的做法。我在这方面花了好几天，甚至在创建GitHub仓库之前就花了两天时间，并至少对报告进行了重写，以使用更好的方法（考虑到我妻子上面提到的反馈）。这是我个人大量的手动认知努力。用于提取数据、将其整理到DuckDB数据库文件中、在该数据库上构建视图，然后对该数据进行统计分析的脚本，确实是由GLM 5.1编写的，最终报告网页上的HTML和大部分原始文字也是如此。然而，至关重要的是，本报告中的所有数字、统计数据、卡片和图表都是由运行统计分析的Python脚本自动生成的，从而避免了数字中的任何幻觉或不一致性。在Hacker News上发布后，几乎没有收到关于文章实际内容的实质性反馈、讨论或回应，我决定用自己的声音重写所有文字。如果有人抱怨我的冗长或句子结构——因为他们通常这样做，这也是我最初让AI写文字的原因之一——他们可以去死。如果你想复制这里的数据和结果，并检查它们是如何计算的，你可以在这里找到仓库。我故意让管道能够完全从零开始端到端运行，因此你可以看到整个管道的全过程，没有神秘的数据库内容迫使你相信我没有篡改或搞错数据。如果你想对数字生气，先去那里看看。1 ·背景：rsync愤怒 2026年5月底，rsync引起了轩然大波。首先，一个没有证据的Mastodon帖子指出了特定用户在升级到包含克劳德提交的版本后所经历的回归之间的虚假相关性。该帖子浏览了未知次数，但即使是点赞和转发也轻松突破了千次，并且获得了显著的关注——正如所有虚假的反AI仇恨一样——得到了来自32个用户的58条回复。有人愤怒地谈论“认知投降”，却没有证据；另有人建议将rsync加入著名的开源废料黑名单。从那里，它传播到了Hacker News，评论81条，充满了混合的恐惧、愤怒和嘲讽，表示这最终证明了没有人可以安全使用LLM。在所有这些评论中，有一条特别的评论进一步推动了回归和漏洞是由克劳德造成的观念。2026年5月30日，这一愤怒紧急聚集成一个焦点：一个题为“请不要搞砸这个软件”的GitHub问题，针对rsync仓库开启。它附上了一张批评项目使用克劳德的Mastodon帖子截图。就是这样。没有漏洞报告，没有技术内容，也没有试图判断担忧是否真实或合理的尝试；仅有350多条评论，从深思熟虑的担忧到公开的骚扰（大多数最严重的不合理和明显暴力的评论后来被删除；几乎没有人想要保留它们）。起源的GitHub问题。原始帖子是Mastodon批评的截图，没有漏洞报告，没有技术内容。它目前已经积累了329条评论。该讨论迅速升级，从“软件是免费的，如果你不喜欢，那么就分叉或滚开”到：“仅仅因为你给无家可归者提供免费的汤，并不意味着你可以在里边撒尿”。该讨论没有止步于言辞。