Claude 是否增加了 rsync 中的 bug？

原文 ↗ Hacker News 讨论 ↗

rsync / Claude 问题的范围

  • 几位评论者指出，rsync 的提交数量出现了巨大飙升，并且安全加固速度很快，这主要是由大量（通常由 AI 生成的）安全报告推动的。
  • 一些用户遇到了严重回归问题（例如增量备份损坏、CPU 占用过高），于是将 rsync 锁定在旧版本。
  • 也有人指出，在 LLM 出现之前的版本中同样发生过回归和严重 bug，而且 rsync 一直以来都是一个复杂、难以测试的 C 代码库。

bug 的统计分析

  • 所链接的文章分析了“每 10 次提交中的 bug 数”，后来又借助基于 LLM 的严重程度评分扩展到了多个版本。
  • 主要观点是：带有 Claude 归因的两个版本都完全落在历史波动范围内，即使按严重程度加权，看起来也并没有异常多 bug。
  • 批评者认为：
    • “Claude 版本”的数据集只有两个点；这项研究的统计功效不足。
    • 以每次提交的 bug 数衡量会掩盖严重程度，也会遮蔽提交量的大幅激增。
    • 不显著的 p 值表示“没有差异的证据”，而不是“没有差异的证据就是差异不存在”。
  • 支持者回应说，这仍然比最初“Claude 搞坏了 rsync”这类指控背后的严谨性更高，而后者大多只是轶事。

代码质量与具体回归

  • 讨论中的一个例子：有一次改动实际上把许多分配改成了 calloc，之后因内存/CPU 回归而被回退。维护者说这个决定是他们做出的，不是 Claude，但确实出现了一个 AI 共同作者标签。
  • 一些人将这一变化及类似改动视为“AI slop”和过度 churn 的典型；另一些人则认为这只是面对大量报告、在高压下进行的仓促安全工作，不论使用了什么工具。

开发中的 LLM 与归因

  • 许多开发者表示，LLM 确实能显著提升生产力，尤其是在样板代码、测试和重构方面，但生成的代码必须像审查初级开发者那样审查。
  • 审查者抱怨 AI 生成的 PR 往往很大、很嘈杂，也难以推理，从而增加了审查负担。
  • 关于提交归因存在激烈争论：
    • 一方希望明确标注 LLM，以便判断风险、审查方式和版权来源。
    • 另一方认为，无论使用什么工具，人类提交者都要负责；未披露 LLM 使用并不天然构成“欺诈”。

对 AI 写作和社区行为的反应

  • 文章最初由 LLM 写的散文引发了强烈反弹；许多人把它称为“AI slop”，并表示仅凭这一点就降低了他们的信任。
  • 作者后来用手工重写了散文；一些人随后觉得可读性好多了，另一些人则仍然持怀疑态度，因为最初的选择和可见的 AI 工具痕迹。
  • 多条评论哀叹这场愤怒的毒性、对维护者的人身攻击，以及 OSS 用户中日益增长的理所当然感。