📜 事件起因

事情的直接导火索是，一位用户在 GitHub 上为 rsync 提交了 Issue，标题是 "Please Do Not Vibe Fuck Up This Software"。该用户发现，在维护者使用 AI（大语言模型, LLM）辅助开发后，新的版本出现了如增量备份失败、CPU 占用率飙升等严重的“回归问题”，这引发了社区对项目稳定性的普遍担忧。

⚖️ 两方观点

在 Hacker News 的评论区，关于此事的讨论非常激烈，主要分为两种声音：

• 批评者认为：使用 AI 编程这种方式太过轻率，将一个稳定且被广泛信赖的基础设施工具当成了“实验场”。他们认为这破坏了项目的可靠性。
• 支持者则指出：维护者 tridge (真名 Andrew Tridgell) 并非普通开发者，他实际上是 rsync 算法和 Samba 的原创作者，是一位非常资深且值得信赖的程序员。支持者认为，他近期的工作主要由修复 6 个严重的 CVE（公共漏洞披露）安全漏洞 驱动，而非随意添加新功能，因此过程中的问题不应简单归咎于使用 AI。

🔍 深层矛盾

1. 开源维护者的困境

维护者 tridge 透露，rsync 在很长一段时间里都是他一个人的项目，面临着巨大的维护压力。特别是近期，提交的 AI 安全问题报告的数量“疯了一般地增长”，而他作为唯一的维护者，必须负责审查这些需要保密的漏洞报告。这让他陷入了一个两难的境地：他感觉像是在对抗蜂拥而至、用 AI 找漏洞的“脚本小子”（不成熟的攻击者），于是自己也用 AI 来修复漏洞，结果却引发了更多的问题。

2. 技术社区与AI的紧张关系

这起事件也反映了一个更深层次的矛盾：技术社区对 AI 的不信任与 AI 工具快速普及之间的冲突。许多用户担心，AI 生成的代码会削弱开发者对代码的批判性思考，最终破坏他们长期依赖的稳定系统。

🌊 更广泛的影响

rsync 引发的这场风暴并非孤例，它正与科技行业的多个趋势形成共振：

• 行业趋势：这起事件是科技界对“Vibe Coding”（一种依赖AI生成代码的编程风格）广泛反思的一部分。类似的讨论也出现在其他领域，例如近期一篇分析 GrapheneOS 服务器架构的文章，就因被怀疑是 AI 生成而遭到社区的强烈质疑。
• 行业规范：一场关于开源项目应该如何接纳 AI 的讨论正在各社区蔓延。据统计，目前已有至少 3 个知名项目（如 Flathub 和 Zig 等）明确更新了社区规范，表态反对或严格限制使用 AI 生成的代码。

https://news.ycombinator.com/item?id=48342705