2026 年 5 月底，开源社区因为一个 Mastodon 帖子陷入激烈争论：rsync 项目维护者 Andrew Tridgell（tridge）开始使用 Claude 辅助开发，部分版本包含大量 AI 生成的提交。批评者声称 "Claude 让 rsync 变得更糟"，GitHub 上出现标题为 "Please Do Not Vibe Fuck Up This Software" 的 issue，短时间内积累了 350+ 条评论，甚至包含针对维护者的暴力威胁插图。
然而，当研究者 Alexis Purslane 对 rsync 历史版本进行系统性统计分析后，数据讲述了一个截然不同的故事。
研究设计与方法论
分析覆盖了 rsync 从 v2.4.6 到 v3.4.3 共 36 个版本，其中仅 v3.4.2 和 v3.4.3 包含 Claude 生成的提交（分别为 9 个和 28 个）。研究采用 severity-weighted bugs per 10 commits（sev/10c）作为核心指标，而非简单的 bug 计数。
指标设计考虑了缺陷严重程度：使用 Qwen 3 35B 模型对每个 bug 报告按 0-100 分评分，其中 90-100 分为数据丢失 / 损坏级别，70-89 分为崩溃 / 挂起，50-69 分为功能回归，以此类推。评分后的 severity 值归一化到 0-1 区间后累加，再按提交数标准化。
这种设计的合理性在于：一个 CVE 安全漏洞与一个文档拼写错误不应等同对待。研究还采用两种统计检验方法：精确置换检验（exact permutation test）评估 Claude 版本在历史分布中的位置，Fisher 精确检验判断 Claude 版本是否更可能高于历史缺陷中位数。
核心发现：数据与感知的落差
统计结果呈现三个关键事实：
第一，Claude 版本在历史分布中完全正常。 v3.4.2 的 sev/10c 为 0.00（零真实 bug），位于历史分布的 0th 百分位；v3.4.3 为 3.29，位于 77th 百分位。两者分别位于四分位距（IQR）的两侧 —— 一个略低于下四分位，一个略高于上四分位，均非异常值。精确置换检验的 p-value 为 46%，意味着随机选取两个版本，有近一半概率得到与 Claude 版本相当或更差的缺陷率。
第二，Fisher 精确检验 p-value 为 74%，优势比（odds ratio）仅 1.06。 这表明 Claude 版本落入历史缺陷中位数以上的概率与其他版本无实质差异。从历史均值看，Claude 版本的平均 sev/10c（1.65）甚至低于非 Claude 版本（2.95）。
第三，最严重的版本反而与 AI 无关。 v3.4.1（无 Claude 提交）的 sev/10c 高达 39.39，是整个数据集的最高值 ——59 个 bug 仅 9 次提交，作为 v3.4.0 发布后的热修复版本。然而这个 "历史最差" 版本未引起任何关注，没有 300+ 评论的 issue，没有死亡威胁，也没有人呼吁迁移到 openrsync。对比之下，v3.4.3 的缺陷率仅为 v3.4.1 的 8%，却因 Claude 标签成为众矢之的。
社区反应的认知偏误
这场风波揭示了技术社区面对 AI 生成代码时的典型认知偏误。
确认偏误（Confirmation Bias） 表现最为明显：当用户遇到 v3.4.3 的回归问题时，看到提交中的 "Co-authored-by: Claude" 标签，立即建立因果关联。但实际上，该版本 3.29 的 sev/10c 在历史分布中并非极端值 —— 有 8 个历史版本得分更高。正如研究者指出的："唯一的区别是 v3.4.3 有一个大家已经决定憎恨的敌人。"
归因偏差 同样显著。批评者将近期 bug 归咎于 "vibe coding"，但 rsync 维护者 Tridge 在回应中解释：提交数量激增的真正原因是 AI 生成的 CVE 安全报告大量涌入，迫使项目快速修复攻击面。这不是 "Claude 问题"，而是 "更多安全工作" 的问题。
更深层的问题是 举证责任的倒置。批评者以 "Claude 让 rsync 更糟" 为默认前提，要求维护者证明清白；而当研究者提供系统性证据表明缺陷率并无异常时，又被指责 "样本量太小"、"需要更多数据"。这种双重标准使得 AI 辅助开发的辩护者陷入无法获胜的境地。
对工程实践的启示
这项研究为评估 AI 生成代码质量提供了可复用的方法论框架：
度量设计层面，severity-weighted 指标比简单计数更能反映用户影响。研究采用的 0-100 分级标准（数据丢失 > 崩溃 > 功能回归 > 轻微问题 > 外观问题）可直接迁移到其他项目。
统计检验层面，对于样本量较小的场景（如新工具引入初期），精确置换检验和 Fisher 精确检验比参数检验更合适。研究者也坦承分析的局限：无法控制提交复杂度、安全强度等变量，但这恰恰与批评者的粗糙指控相匹配 ——"钝器对钝器" 是公平的回应。
社区治理层面，研究提出了一个值得警惕的趋势：如果披露 AI 使用会招致如此强烈的负面反应，开发者可能选择隐藏 AI 辅助的事实。这将使社区失去重要的元数据，反而降低代码审查的针对性。正如 Hacker News 评论者所言："你们只会让人们在提交中禁用 Claude 署名以避免 drama。"
局限与未来方向
分析存在明确的统计局限。仅两个 Claude 版本的数据不足以构建预测模型或推断长期趋势。v3.4.3 发布时间尚短，可能存在未报告的 bug。此外，多数 bug 报告未指明具体引入的 commit，无法精确归因到 AI 生成代码还是人工代码。
然而，这些局限恰恰强化了研究的核心结论：在缺乏足够数据的情况下，"Claude 让 rsync 更糟" 的绝对化声明同样缺乏依据。如果批评者认为需要更多数据才能为 AI 辩护，那么他们也应该承认需要更多数据才能定罪。
对于正在考虑引入 AI 辅助开发的团队，rsync 案例提供了一个重要参照：当社区反应与数据出现巨大落差时，优先相信数据。v3.4.1 的教训表明，人类维护者同样会发布有缺陷的版本；v3.4.2 和 v3.4.3 的数据则表明，AI 辅助版本可以落在历史正常范围内 —— 既非奇迹，也非灾难，只是软件开发复杂现实的延续。
参考来源
- Alexis Purslane, "Did Claude Increase Bugs in rsync?", 2026-06. https://alexispurslane.github.io/rsync-analysis/
- Hacker News Discussion, "Did Claude increase bugs in rsync?", 2026-06. https://news.ycombinator.com/item?id=48411635
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。