Rsync 争议：Vibe Coding 与核心基础设施的脆弱性

开源社区目前正陷入一场激烈的辩论，起因是有人针对 rsync 提交了一个 GitHub issue。rsync 是 Unix 生态系统中应用最广泛且最受信任的工具之一。这场争议的核心在于“vibe coding”的概念——即使用大语言模型 (LLMs) 根据通用意图而非严谨的手动规范来生成大量代码的做法——以及这种做法是否应该出现在作为全球基础设施基石的软件中。

冲突的核心是一个 GitHub issue (Issue #929)，该 issue 指责维护者让 AI “vibe fuck up” 了软件。这种反弹是即时的，并在 Hacker News 上引发了关于遗留系统中 AI 的伦理、开源维护的负担以及软件回归问题的更广泛讨论。

反对在核心工具中使用 AI 的理由

对于许多开发者来说，rsync 代表了一类不应受实验性方法论影响的软件。因为它被用于关键的备份和系统迁移，单次回归的成本可能是灾难性的。主要的论点是，对于一个已经“赢了”的工具——意味着它是行业标准且运行可靠——没有理由用 AI 生成的代码进行豪赌。

批评者指出，海量的变更量是一个危险信号。一位评论者注意到惊人的代码变动量 (churn)，暗示在短时间内修改了数千行代码，这对于一个成熟的项目来说是不寻常的。

"You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does its job... Why do we need AI here?"

此外，人们对那些不增加功能价值、仅将旧语法替换为新语法的“现代化”提交也感到深切的挫败感（例如，在 JavaScript 上下文中将 var 替换为 let，或 C 语言中类似的风格转变），因为这些更改往往会掩盖实际的 bug，并使 git bisect 变得极其困难。

维护者的困境

相反，社区的很大一部分成员为维护者辩护，强调了管理遗留开源项目的艰巨现实。这些工具中的许多是由少数志愿者维护的，他们多年来一直请求帮助，但很少得到广泛社区的回应。从这个角度来看，使用 AI 来处理“琐事”或扩展测试套件被视为不是懒惰，而是一种必要的生存策略。

一些人认为，愤怒是放错了地方，应该关注代码的 review 而非代码的 source。如果引入了 bug，失败在于 QA 流程或缺乏同行评审，无论最初的补丁是由人类还是 AI 编写的。

"If the code is good, bug free, and easily understood, who the f*ck cares? If a maintainer just accepts any code, without review or control, humans, just as well as 'AI:s' can submit crappy code."

“Vibe Coding” 现象

这次事件让“vibe coding”一词成为了焦点。它描述了从传统工程——即每一行代码都经过推理——向迭代提示 (prompting) 过程的转变，开发者通过与 AI “vibe” 直到输出看起来可以工作为止。虽然这可以加速原型设计，但社区正在质疑其在内存安全和边缘情况处理至关重要的底层 C 代码中的可行性。

讨论甚至提出了增加新的 GitHub 元数据的建议，例如使用“AI-generated code”标签来警告用户与“vibe”贡献相关的潜在风险。

替代方案与前进之路

随着一些人的信任动摇，社区对替代方案的兴趣重新抬头。OpenRsync 被频繁提及，作为那些希望避免受 AI 影响的版本的一个更安全的避风港。

最终，rsync 争议为 AI 时代提供了一个了警示故事。它突显了一种根本性的紧张关系：既希望现代化并维护陈旧但必不可少的代码库，又必须绝对要求运行互联网的工具保持稳定性。这究竟是暂时的恐慌，还是我们信任二进制文件的模式发生了系统性转变，仍有待观察，但批评者的共识很明确：当涉及到操作系统的核心工具时，“vibe” 无法替代规范。