Claude 在 rsync 中增加了錯誤嗎？統計分析

2026 年 5 月底，rsync 專案因近期版本的回歸問題被歸因於使用 Claude，成為 AI 輔助程式碼辯論的焦點。然而，對 36 個 rsync 版本（v2.4.6 至 v3.4.3）的全面分布分析顯示，Claude 協助的版本在錯誤密度方面與歷史版本在統計上無顯著差異。

統計結果：Claude 與歷史基線比較

與歷史 rsync 版本的分布相比，Claude 協助的版本並未顯示出異常的錯誤率。分析使用了每 10 次提交的嚴重度加權錯誤指標（sev/10c），以確保關鍵漏洞的權重高於表面問題。

無統計異常： 精確排列測試得到的 p 值為 46%，意味著若從歷史記錄中隨機挑選兩個版本，其中有 46% 的情況會與 Claude 版本一樣多錯誤或更糟。
中位數表現： Fisher 精確檢驗（p 值 74%）證實 Claude 版本出現在歷史中位數錯誤率之上的可能性與其他任何版本相同。
分布範圍界定： 兩個 Claude 協助的版本（v3.4.2 與 v3.4.3）在四分位距（IQR）兩側分布：v3.4.2 完全沒有實際錯誤，而 v3.4.3 則略高於 IQR。兩者皆非負向異常值。
程式碼量與缺陷率： 雖然 Claude 協助的版本更改的程式碼行數顯著較多（平均 3,756 行，對比非 Claude 版本的 696 行，p=5%），但嚴重度加權錯誤的絕對數量並未增加（p=77%）。

為避免簡單錯誤計數的陷阱，分析採用了結構化的資料收集與嚴重度加權方法。

錯誤報告彙整自 GitHub issue、rsync Bugzilla 實例以及 rsync 郵件列表。錯誤歸屬於報告前最新發佈的版本，或 Bugzilla 中提及的特定版本。

每份錯誤報告皆由 Qwen 3 35B（擔任資深可靠性工程師）以 0–100 分的尺度評分。評分標準將錯誤從「資料遺失/損毀」(90–100) 到「表面/低影響」(10–29) 分類，功能請求與垃圾訊息則評為 0，並從錯誤計數中排除。

分析單位選擇了「發佈版」而非單一提交。此做法呼應批評者的主張——發佈版 變得更易出錯——並考慮到許多錯誤是多個提交交互的結果，或在發佈最終定稿前被後續提交修正。

資料顯示，對 rsync 品質下降的感知更像是社群媒體推動的敘事，而非實證證據。

值得注意的是，整個資料集中錯誤最多的版本是 v3.4.1——完全在 Claude 引入之前的發佈。其記錄為 39.39 sev/10c（9 次提交中有 59 個錯誤）。此版本並未引發類似的公眾譴責，暗示「AI 敵人」的存在比實際錯誤率更影響對 v3.4.3 的反應。

技術討論指出，回歸的增加並非因「vibecoding」所致，而是 AI 生成的安全報告激增。正如維護者 Andrew Tridgell 所說，大量 AI 支援的 CVE 報告迫使 rsync 的攻擊面快速且廣泛變更，這自然提升了回歸的可能性。

雖然統計分析未發現危害證據，但部分社群成員對方法論與 AI 程式碼的性質提出了關切：

樣本大小： 部分批評者認為僅有兩個資料點（Claude 版本）不足以得出明確結論。
歸屬偏差： 有人擔心在次要版本中引入的錯誤常被歸於存續最久的修補版，可能使 v3.4.1 的資料產生偏差。
質性下降： 部分開發者認為量化指標無法捕捉 AI 程式碼的「草率」，舉例說明荒謬的函式重新命名或不佳的 NULL 指標處理，雖未立即觸發錯誤，卻削弱長期可維護性。
「生鏽」的維護者： 有理論提出，代理式程式碼工具可能使人類維護者在基礎上「生鏽」，隨時間導致更多邊緣案例錯誤。

"導致變更量增加（從而回歸數量增加）的觸發因素是（主要）LLM 支援的安全議題湧入。也就是說，因果鏈為：LLMs $\rightarrow$ 更多已知安全議題 $\rightarrow$ 需要的變更量超過平常 $\rightarrow$ 回歸數量超過平常。" — jbert on Lobsters