GitHub上Rsync项目的一个issue（#929）标题为"请不要搞砸这个软件的氛围"，内容主要是导航菜单和GitHub平台功能链接，包括AI编程、开发者工作流和应用安全等产品功能。

以下是经过编辑整理后的中文内容摘要，保留了核心讨论内容并删除了无关的导航和界面元素：

标题：请勿用AI随意破坏rsync软件
来源：GitHub Issue #929 @ RsyncProject/rsync
时间：2026年5月30日

核心争议

用户@II-Paulus-II提交Issue，抗议开发者近期使用AI工具大规模修改rsync代码（两个月内修改286个文件，新增2.1万行代码），导致多个兼容性问题。配图中显示社区成员抱怨"AI编写的补丁破坏了稳定工具"。

主要问题

1. 兼容性破坏：

   • 硬依赖Linux 5.6+的openat2系统调用（#924）
   • Darwin系统编译失败（#896）
   • --delete-missing-args等功能异常（#910）

2. 测试套件争议：
   有提交将Shell测试套件重写为Python（+5,414/-4,637行），引发对测试覆盖率的担忧。

社区反应

• 支持方：
  @ranidspace指出："rsync本应是只需安全更新的稳定工具，AI改写引入不必要风险"（获160赞）
  @broman表示："在取证工作中依赖rsync，AI介入导致工具需额外审查"（获128赞）

• 反对方：
  @ppowo批评："Issue跟踪器不是发泄情绪的场所"（获20赞但遭255反对）
  @stsquad建议："不满意可以fork项目"（获13赞但遭118反对）

解决方案

1. 版本回退：
   @lgarron提供Homebrew回退到v3.4.1的方案（具体步骤）

2. 替代工具：
   多位用户推荐OpenBSD的openrsync，该工具已是macOS默认实现。

深层讨论

• @dogtopus分析：实际核心代码变更约+3273/-572行，但AI未能正确处理系统调用兼容性
• @SomeAspy警告："AI泡沫破裂后，我们将难以区分人工代码与AI生成的低质代码"
• @jgr0sz反驳："开源精神不应屈服于追求统计指标的开发模式"

编辑说明：
1. 保留技术细节和代表性观点，删除重复性争论
2. 省略GitHub界面元素、用户头像等非内容信息
3. 补充超链接方便查证
4. 采用技术文档的简洁表述风格

总结评论观点：

1. 对AI修改代码的质疑（评论6,12）

• "Why try comparatively experimental crap when your fortune and reputation is made..."（为何要在成熟稳定的项目上尝试实验性改动）
• "You have a rock solid piece of software...Why is there a need of AI in here?"（已有稳定可靠的软件为何需要AI介入）

2. 对维护者处境的同情（评论10,4）

• "don't jump to demonize a volunteer especially when not many have jumped in to help"（不要指责志愿者，尤其当缺乏他人帮助时）
• "Must be bad for maintainers stress levels"（肯定增加了维护者的压力）

3. 对问题严重性的讨论（评论8,9）

• "Did anyone actually debug the issue?"（是否有人真正调试过这个问题）
• "Few things can trigger me more...replacing all var with let"（最令人恼火的是看到"代码现代化"这类无实质改进的提交）

4. 替代方案建议（评论12,5）

• "create a parallel fork...and keep the OG untouched"（应该创建并行分支保留原版）
• "good timing with OpenRsync"（OpenRsync的出现时机很好）

5. 沟通方式批评（评论6,13）

• "incredible obnoxious...Bad attitude, bad faith"（问题开启方式令人反感）
• "Another entitled user demanding something..."（又一个提出无理要求的用户）

注：所有评论均无评分显示。主要争议集中在AI代码修改的合理性（反对为主）和维护者处境（理解为主）两个方面。