数据反击：185分HN爆帖用实证证明"Claude搞坏rsync"是一场数据驱动的乌龙

核心结论

上周一则"Mastodon帖子+GitHub Issue"引爆了开源社区：有人声称rsync项目使用Claude后bug激增，要求维护者"别再Vibe Coding搞坏这个软件"。GitHub Issue 350+评论，HN 80条回帖，死亡威胁和暴力幻想接踵而至。但有人真的去查数据了——开发者Alexis Purslane爬取了rsync所有历史版本的bug报告、Git提交记录和邮件列表，做了完整的统计分析。结果出乎所有人意料：Claude辅助的版本（v3.4.2和v3.4.3）在严重度加权bug率上位于历史分布的中段，没有任何统计异常。

背景：一场从零证据到死亡威胁的"反AI暴怒

2026年5月底，一则Mastodon帖子引爆了开源社区。帖子声称rsync升级后出现了回归问题，且该版本包含Claude辅助的commit。尽管没有任何技术证据，这篇帖子获得了数千次点赞和转发，传播到HN后引发81条评论。事情在5月30日达到顶点——有人直接在rsync仓库开了一个Issue，标题叫"Please Do Not Vibe Fuck Up This Software"。

这个Issue本身没有提交任何bug报告、没有任何技术内容，只是附了一张Mastodon帖子的截图。但它在短时间内积累了350+评论，评论内容从"合理的担忧"一路升级到暴力幻想——有用户发了My Little Pony风格的漫画，画的是自己掐住"项目清洁工"（暗指推动Claude commit的维护者）的脖子。大部分最极端的评论后来已被删除。

rsync项目的主维护者Tridge事后回应说："这些所谓的'互联网专家'的评论让我想直接去航海，而不是处理这些垃圾。"

分析核心：最坏的一次发布——早在Claude之前

Alexis Purslane建立了一套完整的分析框架：

• 数据源：GitHub Issue + Bugzilla + rsync邮件列表，约2000条bug报告
• 严重度评分：用Qwen 3 35B（零温度）对每条bug按0-100分评级
• 单位：severity-weighted bugs per 10 commits（sev/10c）
• 时间线：按committer date排序，每个release的commit范围精确对应

最关键的发现：rsync历史上最差的一次发布——严重度加权bug率最高的版本——完全是Claude引入之前的产物。那个版本bug频出，但没有AI可以骂，所以没有350条Issue评论，没有死亡威胁，也没有人威胁fork。维护者默默修好，一切如常。

混淆因素：Rustdesk来了，不是你Claude的错

很多人感觉到rsync变差并非空穴来风，但原因可能完全不是他们想的那样。HN用户zos_kia一语中的：

"粗略一看，这看起来是一个CVE安全修复暴露了自2007年以来就存在的编码错误。看到人们为了这个发疯，简直太滑稽了。"

Lobsters用户jbert更清晰地指出了因果链：

LLMs → 更多已知安全问题 → 需要比平时更多变更 → 比平时更多回归

Tridge本人在回应中也确认了这一点：大量AI生成的CVE报告迫使rsync进行大量快速的攻击面修复。这不是Claude写代码的问题，而是AI安全工具发现了太多漏洞、被迫加速修复的问题。任何大规模的代码变更都会引入回归，这在软件工程中是常识。

实际上，Claude release的commit数量并不多——v3.4.2只有121个commit，v3.4.3只有30个。对比rsync历史上从未被批评过的其他release（如v3.2.6有241个commit），Claude release反而是commit较少的。

但代码变更量（lines of code changed）确实大幅增加了。Claude release修改了更多行代码，但bug数量没有相应增加。翻译成人话：更多代码，同样bug——这不是变差了，这可能是变好了。

为什么人们感觉被骗了？

作者给出了一个尖锐但诚实的答案：不是因为rsync真的变差了，而是因为人们已经决定了要恨AI。

Tridge在回应中给出了一个值得深思的总结：

"对于那些说'我是某某大学博士，我告诉你LLM只是随机的统计工具、世界会因此崩溃'的人，我来告诉你：你们的信息已经过时了。软件工程的世界在过去几个月里发生了翻天覆地的变化。IT安全和面对海量漏洞报告的世界在过去几周内已经完全改变。去年学到的东西可能来自另一个星球……底线是，我的确知道LLM大致如何工作，但这并不意味着它们没有用。它确实意味着你需要谨慎——而我在我的能力范围内已经足够谨慎了。"

对AI Agent用户的实操启示

1. 数据比感受更可靠。当有人告诉你"AI搞坏了X"时，先问证据在哪里。不是质疑动机，而是要求方法论。没有拿数据的批评，和没有代码的产品宣言一样——都是空气。

2. "更多代码=更多bug"不一定是坏事。如果AI让你能写更多代码解决更多安全问题，bug的绝对数量上升是预期的。真正的指标是缺陷密度（bug/commit或bug/千行代码），不是bug总数。

3. 做好"AI羞耻"的心理准备。即使你的AI辅助代码质量不差，你也可能成为下一个被口诛笔伐的目标。提前准备好数据和回应——Tridge有数据支持所以能从容回应，而Mastodon帖子作者只需要一个截图就能掀起风暴。

4. 为AI commit添加署名是一把双刃剑。诚实地标注AI辅助commit可以推动透明度，但也给了"反AI猎巫者"现成的弹药。目前的环境下，选择透明标注可能会招致不必要的仇恨。

参考来源

原帖：https://alexispurslane.github.io/rsync-analysis/ HN讨论：https://news.ycombinator.com/item?id=48411635

相关阅读

• 如何用 Anthropic 开源框架搭建 AI 漏洞自动发现与修复管线：30 分钟完整教程
• AI 编程 Agent 怎么选？语言、模型、成本三维对比实测
• AI Agent 驱动内容自动化：n8n MCP 从零搭建指南