他寫的軟件支撐著整個互聯(lián)網(wǎng)，如今卻因?yàn)?AI 被罵慘了 !

2026 年 5 月，一位rsync用戶升級到 3.4.3 版，發(fā)現(xiàn)運(yùn)行多年的任務(wù)開始頻繁失敗。

他降回 3.4.1，一切恢復(fù)正常。

他打開 GitHub，準(zhǔn)備看看最近改了什么。

然后愣住了，最近的36個提交，作者幾乎都是：tridge and claude

AI？ rsync這么重要的基礎(chǔ)軟件，竟然讓AI參與開發(fā)？！

很快，rsync 的 GitHub Issues 里多了一條標(biāo)題簡單粗暴的帖子：

“求求你，別用 AI 把這個軟件毀了。”

無數(shù)人加入對 rsync 和作者 Andrew Tridgell 的口誅筆伐，爭論異常激烈。

普通人可能不認(rèn)識rsync，它是互聯(lián)網(wǎng)界最常用的數(shù)據(jù)同步和備份工具，只要你在享受“快速、省流量、斷點(diǎn)續(xù)傳”的數(shù)據(jù)備份服務(wù)，大概率就有 rsync在背后默默立功。

作者Andrew Tridgell更是傳奇，他不但發(fā)明了 rsync、還創(chuàng)建了Samba、Ardupilot，甚至無意間推動了 Git 的誕生。

如果把互聯(lián)網(wǎng)基礎(chǔ)設(shè)施比作一座城市，Andrew Tridgell 至少親手修過三條高速公路。

那么，這樣一個影響了整個互聯(lián)網(wǎng)幾十年的關(guān)鍵工具，為什么會陷入“AI 開發(fā)”的爭議漩渦？

0 1

一個偉大算法的誕生

故事得從上世紀(jì)90年代說起。

那時候主要是撥號上網(wǎng)，網(wǎng)速只有幾十K，慢得要死，還時不時掉線。

通過網(wǎng)絡(luò)把一個大文件（比如100M）從一臺電腦復(fù)制到另外一臺電腦非常費(fèi)勁。

更費(fèi)勁的是，如果這個大文件只是發(fā)生了一點(diǎn)兒改變（比如1K），還得重新傳整個文件（100M），這簡直是一場災(zāi)難。

你可能會會想到：能不能只傳輸文件變動的部分？

這確實(shí)是個好想法，實(shí)現(xiàn)起來卻很復(fù)雜，因?yàn)檫@個文件的改動可以發(fā)生在任何地方（開頭，中間，結(jié)尾），改動可能是添加，刪除，修改.....

到底該怎么做呢？

1996 年，正在澳大利亞國立大學(xué)讀博的 Andrew Tridgell提出了一個叫做rsync 滾動校驗(yàn)算法，漂亮地解決了這個問題。

算法比較復(fù)雜，這里不再展開，只說說簡單的過程：

1.接收端把文件切成固定大小的塊，對每塊計算兩個校驗(yàn)碼：一個微弱但計算極快的弱校驗(yàn)（Rolling Checksum），和一個強(qiáng)壯但計算慢的強(qiáng)校驗(yàn)（MD4/MD5），并將這些校驗(yàn)碼發(fā)給發(fā)送端。

2.發(fā)送端用“滑動窗口”在自己的文件上逐字節(jié)移動，快速比對弱校驗(yàn)，一旦匹配成功，再比對強(qiáng)校驗(yàn)。

3.最終，發(fā)送端只把那些“無法匹配”的原始數(shù)據(jù)，以及匹配成功的塊編號發(fā)送過去。接收端就能在本地把新文件“拼”出來。

這個算法最終成了Andrew博士論文《排序和同步的高效算法》的基礎(chǔ)，這個論文也成為了分布式計算領(lǐng)域的經(jīng)典文獻(xiàn)。

Andrew 不僅理論功底深厚，寫代碼也是一流。

他只花了一周時間，就用 C 語言把算法變成了可用軟件，發(fā)布了 rsync 0.1 版，定位為比 rcp 更高效的替代品，并以 GPL 協(xié)議開源。

rsync 本身足夠優(yōu)秀——同步快、流量省、易于腳本化，恰逢 2000 年前后互聯(lián)網(wǎng)、Linux 和開源運(yùn)動同時爆發(fā)，網(wǎng)站發(fā)布、服務(wù)器遷移、NAS 備份、鏡像同步、災(zāi)備系統(tǒng)……數(shù)據(jù)備份和同步成了普遍剛需。

rsync 幾乎成為唯一的選擇，逐漸被集成進(jìn)所有主流 Linux 發(fā)行版，成為標(biāo)配工具。

0 2

意外催生Git

按理說，Andrew Tridgell 應(yīng)該會一直維護(hù) rsync。

但就在 rsync 逐漸流行起來的時候，他親手創(chuàng)造的另一個項(xiàng)目——Samba，遇到了更大的挑戰(zhàn)。

如果你在 Windows 上訪問過 Linux 服務(wù)器的共享文件夾，背后大概率就是 Samba。

它讓 Windows 和 Linux 兩個原本互不兼容的世界，能夠順暢地共享文件。在互聯(lián)網(wǎng)早期，這是一個影響力絲毫不亞于 rsync 的明星項(xiàng)目。

然而，隨著微軟不斷升級企業(yè)網(wǎng)絡(luò)技術(shù)，Samba 要兼容的東西越來越多，原有架構(gòu)已經(jīng)難以支撐未來的發(fā)展。

Andrew 意識到，與其不斷修修補(bǔ)補(bǔ)，不如推倒重來。

于是，從 2002 年前后開始，他啟動了 Samba 4 項(xiàng)目，從底層重新設(shè)計整個系統(tǒng)。

此后的十年里，Andrew 的主要精力都投入到了這場艱巨的重構(gòu)工程中，而他親手創(chuàng)造的另一個項(xiàng)目——rsync，則逐漸交給了 Wayne Davison 維護(hù)。

在此期間，Andrew 還無意間做了一件大事，間接促成了 Git 的誕生。

當(dāng)時，Linux 內(nèi)核團(tuán)隊(duì)使用一款名為 BitKeeper 的商業(yè)版本管理工具。它功能強(qiáng)大，但畢竟是閉源軟件，這讓很多開源開發(fā)者始終覺得別扭。

Andrew 也希望研究 BitKeeper 的協(xié)議，開發(fā)一個兼容客戶端。

沒想到，這一下觸碰了 BitKeeper 作者 Larry McVoy 的底線。他認(rèn)為 Andrew 違反了承諾，直接撤銷了 Linux 社區(qū)的免費(fèi)授權(quán)。

Linux 內(nèi)核團(tuán)隊(duì)一夜之間失去了版本管理工具。

沒有辦法，Linus Torvalds 只能親自下場。

于是，一個叫 Git 的新工具誕生了。

后來很多人開玩笑說：

Andrew Tridgell 雖然沒有寫 Git，卻在 Git 的誕生過程中，推倒了第一塊多米諾骨牌。

0 3

你竟然用AI 寫代碼？？

如果說 Andrew 發(fā)明了 rsync，那么 Wayne Davison 就是把 rsync 養(yǎng)大的人。

從 2002 年接手項(xiàng)目開始，Wayne 不斷完善跨平臺兼容性、網(wǎng)絡(luò)同步能力和大規(guī)模目錄處理，讓 rsync 真正成為生產(chǎn)環(huán)境里的標(biāo)準(zhǔn)工具。

二十多年過去，他幾乎把所有業(yè)余時間都投入到了這個項(xiàng)目。

但隨著精力越來越有限，他想起了 Andrew 當(dāng)年的一句話：

"如果有一天需要幫忙，就告訴我。"

2024 年 4 月，Wayne 聯(lián)系了 Andrew，而 Andrew 也兌現(xiàn)了承諾，重新回到了 rsync 項(xiàng)目。

然而，迎接他的不是鮮花，而是 AI 帶來的新挑戰(zhàn)。

過去，一個月可能收到一份漏洞報告；如今，大模型可以批量掃描代碼，生成海量安全報告。其中不少寫得頭頭是道，卻根本不存在漏洞。你不能全信，也不能不看。

與此同時，rsync 已經(jīng)發(fā)展了近 30 年，測試體系卻十分陳舊，自動化測試、代碼覆蓋率、持續(xù)集成等基礎(chǔ)設(shè)施都需要重建。

于是，Andrew 選擇借助 Claude。

不過，他后來專門回應(yīng)了外界的質(zhì)疑：Claude 寫的絕大多數(shù)都是測試框架、測試用例和輔助代碼，而核心設(shè)計、架構(gòu)決策、代碼審核和最終提交，始終由自己負(fù)責(zé)。

他說，自己會先完成整體設(shè)計，再把那些重復(fù)、繁瑣的工作交給 AI。

最終發(fā)布的 rsync 3.4.3 中，確實(shí)出現(xiàn)了數(shù)百個帶著 "tridge and claude" 簽名的提交。

可當(dāng)用戶遇到 Bug，再打開 GitHub，發(fā)現(xiàn)是“tridge and claude”，這么重要的軟件，Andrew竟然用AI寫代碼，竟然Vibe Coding，是可忍，孰不可忍！

于是，就出現(xiàn)了文章開頭那一幕。

0 4

到底在害怕什么？

如今各大公司都在高調(diào)宣傳“我們 xx% 的代碼由 AI 生成”，而 Andrew 僅僅用 AI 輔助編寫了測試，就招致如此猛烈的聲討。我想，原因無非兩點(diǎn)：

1.Andrew的身份太特殊了。

rsync 是他寫的，Samba 也是他寫的。他是那種“活著的傳奇工程師”，被視作傳統(tǒng)工程精神的化身。

大家突然發(fā)現(xiàn)，連這樣的人都開始用 Claude，心理落差可想而知。

2.Andrew 觸碰了開源世界最敏感的那根神經(jīng)。

很多開源開發(fā)者認(rèn)為：編程不不僅僅是寫代碼，而是理解系統(tǒng)；

而 LLM 最大的問題恰恰是：它能寫代碼，但未必真正理解系統(tǒng)。

所以很多人天然反感用概率模型參與關(guān)鍵軟件開發(fā)。

但是最深層的原因，我覺得大家其實(shí)在害怕未來。

那些大廠宣傳“50%代碼由 AI 生成”，我們反而沒什么感覺，因?yàn)榇蠹冶緛砭桶阉?dāng)營銷。

而Andrew不一樣，現(xiàn)在很多人表面是在罵他，實(shí)際上是在表達(dá)一種焦慮：如果連 Andrew 這樣的人都開始依賴 AI，那未來的軟件工程會變成什么樣？