全网怒火：350条评论和一张暴力画作
事情是从一张截图和一句指控开始的。
2026年5月底，有人在Mastodon上发帖，声称自己升级rsync后遇到的回归问题，与新版中出现了Claude（AI）的代码提交相关。没有证据，只有相关性。但互联网的怒火，从来不需要确凿证据。
帖子被点赞上千次，涌入Hacker News，点燃了81条评论的愤怒。然后，火势蔓延到了GitHub。一个名为 “Please Do Not Vibe Fuck Up This Software” 的issue被创建。注意，它没有附带任何bug报告，只是一张批评截图。
然而就是这个issue，涌入了超过350条评论。从技术讨论，滑向对项目维护者的指责、咒骂，最终演变成赤裸裸的网络暴力。
最令人震惊的是，其中一位用户甚至贴出了“小马宝莉”风格的画作，描绘自己扼死“推动了Vibe代码提交的项目管理员”。
一场针对开源维护者的“猎巫行动”，在“AI毁灭世界”的恐慌叙事下，拉开了序幕。
核心指控：Claude让稳定的工具变糟了
在Hacker News的讨论中，愤怒的情绪形成了一个简单、绝对的指控：
“人们非常有理由愤怒，一个非常稳定、备受信赖的工具，开始立刻走下坡路……这一切都是因为主开发在Vibe Coding这个软件。”
—— Hacker News用户 fao_
“AI是认知投降”、“AI是可卡因”、“AI是工艺的丧失”……指控铺天盖地。核心论点只有一个：rsync中引入Claude代码，导致了软件质量的显著下滑。
但有意思的是，在一片情绪的怒吼中，也有人提出了一个冷静的问题：
“如果有人真的做了一个每次发布后的回归时间表（如果可能的话），看看数字最近是否真的上升了，那会很有趣。”
—— Lobsters用户 boramalper
另一位用户附和：“我也很想看到这样的图表。虽然这不能说明全部……但至少是我们可以客观衡量的东西。”
这篇文章，就是那张图表。
硬核反击：用数据检验指控
一位名叫Alexis的工程师，决定不再争论“Vibe”，而是直面最尖锐的问题：从数据上看，Claude参与的版本，bug真的异常多吗？
他花了几天时间，分析了rsync从v2.4.6到v3.4.3共36个有bug数据的版本。其中只有两个版本包含Claude的代码提交：v3.4.2（9个Claude提交）和v3.4.3（28个Claude提交）。
他采用了一个“暴力但公平”的指标：每10个提交的加权bug数（sev/10c）。每个bug都通过一个语言模型（Qwen 3 35B）被打分（0-100），分数越高代表问题越严重（数据丢失/崩溃=90分，功能回归=50分，文档错误=15分）。
然后，他进行了两种统计检验：
- 精确排列检验：从历史版本中随机抽取2个版本，计算它们的平均bug率有多高，然后看“Claude版本组”的表现在这个分布中的位置。
- 费舍尔精确检验：看Claude版本是否更倾向于落在历史bug率的中位数以上。
结果如何？
数据真相：最糟糕的版本，与AI无关
结论是颠覆性的。
精确排列检验的p值高达46%。 这意味着，随便从历史中抽两个版本，有46%的概率会得到和Claude版本一样差甚至更差的结果。Claude版本的表现，完全在历史正常波动范围内。
费舍尔精确检验的p值是74%。 Claude版本落在中位数以上的可能性，和其他版本几乎没有区别（比值比1.06）。
更直观的是那张分布图：Claude版本（绿色点）一个略低于中间50%区域，一个略高于它，把历史区间的“腰部”框得刚刚好。它们都不是异常值。
两个Claude版本（绿点）框定了历史版本bug率的中间区间，均非异常值。
然后，最讽刺的反转来了。
在翻查历史数据时，Alexis发现了一个“盲目的清晰”：rsync历史上bug率最高的版本，是v3.4.1。它的每10提交加权bug数高达39.39，是Claude版本v3.4.3的12倍。
这个版本，完全没有Claude参与，是纯人类开发的。但当时，没有GitHub issue下的300条咒骂，没有死亡威胁，没有要分叉项目的叫嚷。维护者发布了一个糟糕的热修复版本，然后修好了它，仅此而已。
“唯一让v3.4.3特别的，是它提供了一个‘所有人都已经决定去恨的敌人’。”
深层原因：愤怒不是关于代码，而是关于AI
如果数据无法支持指控，那人们排山倒海的愤怒从何而来？
Hacker News用户zos_kia指出了一个技术上的混淆：导致变更量增大的，是一个存在了近20年（2007年）的老编码错误，它因为一个安全修复而被暴露出来。
Lobsters用户jbert则点出了更完整的因果链：
“导致变更量（以及随之而来的回归）增加的触发因素，是大量（主要是AI生成的）安全问题报告涌入。……因果链是：LLM → 更多已知安全问题 → 需要比平时更多的变更 → 比平时更多的回归。”
本质上，这不是一个“Claude问题”，而是一个“安全工作量激增问题”。项目维护者Andrew Tridgell（Tridge）在回应中也证实，是AI生成的CVE报告洪水迫使他们进行了大量快速的、防御性的代码修改。
然而，在情绪的风暴眼中，这些事实已经不重要了。
“我不否认他尝试了。我只是否认聊天机器人擅长写代码；事实上，它们不擅长。如果作者用一种保留了所需特性和功能的思维模型来手工处理这些安全错误，那么他们本可以引起更少的回归……”
—— Lobsters用户 Corbin
你看，争论已经从“证据”滑向了“信仰”。对方用一种先验的、定义式的、不看数据的逻辑，直接宣告了AI有罪。
最终回应：世界已经变了
面对这场凭空而来的风暴和无证据的指控，Tridgell本人给出了最终回应。他的话，既是一个技术老兵的务实看法，也是对那些沉迷于空谈的“专家”的犀利反击：
“……对于那些说‘我是某某大学的博士，我告诉你LLM只是会编造一切的随机工具，如果使用它们世界会崩溃’的人，我在这里告诉你，你已经过时了。在过去的几个月里，软件工程的世界发生了翻天覆地的变化。在网络安全和维护软件以应对洪水般报告的世界，在过去几周里已经彻底、完全改变了。你在去年学到的关于这些东西的任何知识，都像是来自另一个星球……”
“底线是，我确实（大致）知道LLM是如何工作的，但这并不意味着它们没有用。这确实意味着你必须谨慎，但我很谨慎，或者在我想要去航海而不是处理来自所谓互联网专家的垃圾洪水的情况下，尽可能地谨慎。”
【锐评】： 一场精心策划的“数据打脸”证明，对AI最猛烈的声讨，往往和代码质量无关，而和人类需要找到一个情绪靶子有关。
参考链接：
https://alexispurslane.github.io/rsync-analysis/