rsync 被指“AI 写坏了”：情绪很满，证据还不够

rsync 这场风波里，最扎眼的数字不是某个 bug，而是 46%。

一篇针对 rsync 版本历史的统计分析，把 36 个有 bug 数据的版本拉出来比较。结论很窄，也很关键：两个含 Claude 辅助提交的版本，并没有比历史版本异常更糟。随机抽两个版本，达到同等或更差水平的概率约 46%。

这不是给 AI 编程工具发免死金牌。它只回答一个问题：这次围攻是否已经证明 Claude 把 rsync 搞坏了？按目前数据看，没有。

发生了什么：Claude 出现在提交里，争议越过了工程边界

事情起于 rsync 新版本中出现 Claude 辅助提交。随后 GitHub、Hacker News、Mastodon 上的讨论升温，有人把它概括成“vibecoding 搞坏基础软件”。

问题是，讨论很快不只是在问代码质量。它滑向了对维护者的围攻和骚扰。

这对 rsync 用户当然不是小事。rsync 是备份、同步、生产脚本里常见的基础工具。这里出 bug，代价可能不是“体验不好”，而是数据同步失败、自动化任务异常、恢复链路变脆。

所以怀疑 AI 辅助提交，很正常。

但怀疑不是定罪。工程世界要看复现、影响范围、严重度、回归路径。不能看到 Claude 字样，就自动把所有坏味道归给 AI。

数据说了什么：两个 Claude 版本都不是离群点

这篇分析做的事很朴素：不争论 AI 有没有灵魂，不争论程序员手艺会不会被稀释，只看版本级数据。

它使用 36 个有 bug 数据的 rsync 版本，比较含 Claude 辅助提交的版本和历史版本。核心指标是 sev/10c：按严重度加权后的 bug 数，再除以提交数，折算成每 10 次提交的 bug 严重度。

结论很直接：两个 Claude 版本都不是离群点。精确置换检验 p 值约 46%。Fisher 检验也没有发现 Claude 版本更容易落在历史中位数之上。

这里最反常的是 v3.4.1。

它没有 Claude，却是一个刺眼的异常版本：59 个 bugs，9 次 commits。任何想证明“Claude 之后 rsync 才变坏”的说法，都绕不开这个对照点。把它从基线里随手剔除，不叫严谨，叫清理不方便的事实。

不过，这份分析也不能神化。

它不是同行评审论文，也不是最终裁决。bug 归因按 release 做，不是逐 commit 追责；严重度由 Qwen 3 35B 打分，本身会带来模型判断争议；Claude 版本只有 v3.4.2 和 v3.4.3 两个，样本太少。

所以稳妥结论只有一句：现有版本级数据未显示 Claude 版本异常明显。

这句话听起来保守，但已经足够挡住一种过度指控：目前没有证据证明 Claude 让 rsync 变坏。

真正该看什么：不是反 AI 表态，而是工程证据链

我不太买账的是，把“我讨厌 AI”包装成 bug report。

担心 LLM 辅助开发增加维护风险，这很合理。代码看似能跑，审查成本后移；维护者合入速度可能更快；基础设施项目一旦出错，用户承担尾部损失。

这些都是真问题。

但真问题要用真办法处理。对 rsync 用户来说，合理动作不是立刻迁移，也不是盲目信任。更现实的是：生产环境延后升级一两个补丁周期，盯回归报告和发行说明；对关键同步链路补测试，尤其是备份恢复路径。

对开源维护者和使用 LLM 的基础设施项目来说，动作也很具体：标清哪些提交有 AI 辅助，要求更强 review；把 AI 参与的改动纳入回归测试；遇到问题按 commit、测试、复现步骤追责，而不是按工具标签判刑。

接下来最该观察的变量只有两个。

一是有没有可复现的回归被明确追到 Claude 辅助提交。没有这一步，“AI 写坏了”就只是口号。

二是项目会不会补上更透明的审查流程。包括测试覆盖、合入规则、AI 辅助披露，以及问题出现后的 revert 机制。

孔子说，“众恶之，必察焉。”很多人都讨厌一件事，越要查。群体愤怒最擅长把相关性磨成因果，把不安磨成罪名。

开源世界本来就是不对称关系：用户多，责任重，资源少。再叠一层 AI 文化战争，issue 区就容易从协作现场变成审判广场。

这才是 rsync 风波最难看的地方。

如果 Claude 真的引入了回归，就拿 commit、测试、复现步骤把它钉住。该 revert 就 revert，该补测试就补测试。这样软件会变好。

如果只是看到 Claude 就开骂，结果不会是更安全的开源。结果更可能是维护者减少透明度，少说工具使用，少碰争议改动。

模型写不写代码，已经不是唯一问题。关键是人有没有把关，项目有没有证据链，社区还愿不愿意按工程规则说话。