Rsync争议：AI辅助开发与“氛围编码”辩论

AI生成的提交与稳定性危机

最近对Rsync的更新，特别是3.4.3版本，因包含数百个由Claude（一个大语言模型）撰写的提交而受到批评。主要担忧在于AI生成的更改速度超过了人类维护者有效审计代码的能力，导致核心功能出现回退。

社区成员指出了具体的回退案例，以此证明在关键工具中使用AI辅助开发的风险：

• 绝对路径失败：诸如GitHub Issue #922等问题表明，在某些场景下rsync已无法使用绝对路径。
• 链接模式损坏： GitHub Issue #915 突出了链接模式功能的失败。

批评者认为，这些提交的规模加上对测试框架的全面重写，对一次“错误修复”而言不成比例，并为数百万系统依赖的工具引入了不可接受的风险。

维护者的视角：效率与严谨

Rsync的维护者为使用AI辩护，特别是将测试套件重构为Python，声称这一过程并非盲目的“氛围编码”，而是一次有计划的项目基础设施现代化努力。维护者表达了在承担关键工具维护职责的同时，希望有更多时间航海的个人愿望，暗示AI工具能够实现本可能被忽视的必要维护。

此番辩护在开发者社区中引发了分歧：

• 支持AI集成：一些有经验的工程师认为，LLM是快速原型化想法和处理诸如CI/CD更新等样板任务的必备工具，并将反弹视为意识形态驱动的部落式反应。
• 反对AI集成：另一些人认为，对于关键系统软件而言，代码的“氛围”毫无意义，唯一重要的是正确性。他们建议，如果维护者无法承担此类软件所需的严格人工审查，就应当辞职。

AI驱动开发的人力成本

除了技术回退之外，这场争议还凸显了开源维护者的心理压力。Rsync的维护者遭遇了大量公众反弹和“喷子”攻击，引发了关于管理高风险项目的志愿者心理健康的讨论。

审视行业现状的软件工程师指出了职业体验的转变。一位工程师形容当前环境是“一种悲惨的生活”，他们现在需要审查大量机器生成的代码，这些代码缺乏人类编写软件的架构连贯性，尽管报酬仍然很高。

综合：糟糕代码的“维恩图”

社区讨论的一个关键洞见是，LLM生成的代码常被批评的原因——架构差、缺乏规划、测试不足——正是人类代码写得差的同样原因。因此，争论可能并非关于工具（LLM）本身，而是关于在使用AI绕过批判性思考和严格验证时，软件工程过程的根本失效。