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 迴避批判性思考與嚴格驗證時，軟體工程流程的根本失敗。