2026 年 5 月，一位rsync用户升级到 3.4.3 版，发现运行多年的任务开始频繁失败。

他降回 3.4.1，一切恢复正常。

他打开 GitHub，准备看看最近改了什么。

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

AI？ rsync这么重要的基础软件，竟然让AI参与开发？！

很快，rsync 的 GitHub Issues 里多了一条标题简单粗暴的帖子：

“求求你，别用 AI 把这个软件毁了。”

无数人加入对 rsync 和作者 Andrew Tridgell 的口诛笔伐，争论异常激烈。

普通人可能不认识rsync，它是互联网界最常用的数据同步和备份工具，只要你在享受“快速、省流量、断点续传”的数据备份服务，大概率就有 rsync在背后默默立功。

作者Andrew Tridgell更是传奇，他不但发明了 rsync、还创建了Samba、Ardupilot，甚至无意间推动了 Git 的诞生。

如果把互联网基础设施比作一座城市，Andrew Tridgell 至少亲手修过三条高速公路。

那么，这样一个影响了整个互联网几十年的关键工具，为什么会陷入“AI 开发”的争议漩涡？

0 1

一个伟大算法的诞生

故事得从上世纪90年代说起。

那时候主要是拨号上网，网速只有几十K，慢得要死，还时不时掉线。

通过网络把一个大文件（比如100M）从一台电脑复制到另外一台电脑非常费劲。

更费劲的是，如果这个大文件只是发生了一点儿改变（比如1K），还得重新传整个文件（100M），这简直是一场灾难。

你可能会会想到：能不能只传输文件变动的部分？

这确实是个好想法，实现起来却很复杂，因为这个文件的改动可以发生在任何地方（开头，中间，结尾），改动可能是添加，删除，修改.....

到底该怎么做呢？

1996 年，正在澳大利亚国立大学读博的 Andrew Tridgell提出了一个叫做rsync 滚动校验算法，漂亮地解决了这个问题。

算法比较复杂，这里不再展开，只说说简单的过程：

1.接收端把文件切成固定大小的块，对每块计算两个校验码：一个微弱但计算极快的弱校验（Rolling Checksum），和一个强壮但计算慢的强校验（MD4/MD5），并将这些校验码发给发送端。

2.发送端用“滑动窗口”在自己的文件上逐字节移动，快速比对弱校验，一旦匹配成功，再比对强校验。

3.最终，发送端只把那些“无法匹配”的原始数据，以及匹配成功的块编号发送过去。接收端就能在本地把新文件“拼”出来。

这个算法最终成了Andrew博士论文《排序和同步的高效算法》的基础，这个论文也成为了分布式计算领域的经典文献。

Andrew 不仅理论功底深厚，写代码也是一流。

他只花了一周时间，就用 C 语言把算法变成了可用软件，发布了 rsync 0.1 版，定位为比 rcp 更高效的替代品，并以 GPL 协议开源。

rsync 本身足够优秀——同步快、流量省、易于脚本化，恰逢 2000 年前后互联网、Linux 和开源运动同时爆发，网站发布、服务器迁移、NAS 备份、镜像同步、灾备系统……数据备份和同步成了普遍刚需。

rsync 几乎成为唯一的选择，逐渐被集成进所有主流 Linux 发行版，成为标配工具。

0 2

意外催生Git

按理说，Andrew Tridgell 应该会一直维护 rsync。

但就在 rsync 逐渐流行起来的时候，他亲手创造的另一个项目——Samba，遇到了更大的挑战。

如果你在 Windows 上访问过 Linux 服务器的共享文件夹，背后大概率就是 Samba。

它让 Windows 和 Linux 两个原本互不兼容的世界，能够顺畅地共享文件。在互联网早期，这是一个影响力丝毫不亚于 rsync 的明星项目。

然而，随着微软不断升级企业网络技术，Samba 要兼容的东西越来越多，原有架构已经难以支撑未来的发展。

Andrew 意识到，与其不断修修补补，不如推倒重来。

于是，从 2002 年前后开始，他启动了 Samba 4 项目，从底层重新设计整个系统。

此后的十年里，Andrew 的主要精力都投入到了这场艰巨的重构工程中，而他亲手创造的另一个项目——rsync，则逐渐交给了 Wayne Davison 维护。

在此期间，Andrew 还无意间做了一件大事，间接促成了 Git 的诞生。

当时，Linux 内核团队使用一款名为 BitKeeper 的商业版本管理工具。它功能强大，但毕竟是闭源软件，这让很多开源开发者始终觉得别扭。

Andrew 也希望研究 BitKeeper 的协议，开发一个兼容客户端。

没想到，这一下触碰了 BitKeeper 作者 Larry McVoy 的底线。他认为 Andrew 违反了承诺，直接撤销了 Linux 社区的免费授权。

Linux 内核团队一夜之间失去了版本管理工具。

没有办法，Linus Torvalds 只能亲自下场。

于是，一个叫 Git 的新工具诞生了。

后来很多人开玩笑说：

Andrew Tridgell 虽然没有写 Git，却在 Git 的诞生过程中，推倒了第一块多米诺骨牌。

0 3

你竟然用AI 写代码？？

如果说 Andrew 发明了 rsync，那么 Wayne Davison 就是把 rsync 养大的人。

从 2002 年接手项目开始，Wayne 不断完善跨平台兼容性、网络同步能力和大规模目录处理，让 rsync 真正成为生产环境里的标准工具。

二十多年过去，他几乎把所有业余时间都投入到了这个项目。

但随着精力越来越有限，他想起了 Andrew 当年的一句话：

\"如果有一天需要帮忙，就告诉我。\"

2024 年 4 月，Wayne 联系了 Andrew，而 Andrew 也兑现了承诺，重新回到了 rsync 项目。

然而，迎接他的不是鲜花，而是 AI 带来的新挑战。

过去，一个月可能收到一份漏洞报告；如今，大模型可以批量扫描代码，生成海量安全报告。其中不少写得头头是道，却根本不存在漏洞。你不能全信，也不能不看。

与此同时，rsync 已经发展了近 30 年，测试体系却十分陈旧，自动化测试、代码覆盖率、持续集成等基础设施都需要重建。

于是，Andrew 选择借助 Claude。

不过，他后来专门回应了外界的质疑：Claude 写的绝大多数都是测试框架、测试用例和辅助代码，而核心设计、架构决策、代码审核和最终提交，始终由自己负责。

他说，自己会先完成整体设计，再把那些重复、繁琐的工作交给 AI。

最终发布的 rsync 3.4.3 中，确实出现了数百个带着 \"tridge and claude\" 签名的提交。

可当用户遇到 Bug，再打开 GitHub，发现是“tridge and claude”，这么重要的软件，Andrew竟然用AI写代码，竟然Vibe Coding，是可忍，孰不可忍！

于是，就出现了文章开头那一幕。

0 4

到底在害怕什么？

如今各大公司都在高调宣传“我们 xx% 的代码由 AI 生成”，而 Andrew 仅仅用 AI 辅助编写了测试，就招致如此猛烈的声讨。我想，原因无非两点：

1.Andrew的身份太特殊了。

rsync 是他写的，Samba 也是他写的。他是那种“活着的传奇工程师”，被视作传统工程精神的化身。

大家突然发现，连这样的人都开始用 Claude，心理落差可想而知。

2.Andrew 触碰了开源世界最敏感的那根神经。

很多开源开发者认为：编程不不仅仅是写代码，而是理解系统；

而 LLM 最大的问题恰恰是：它能写代码，但未必真正理解系统。

所以很多人天然反感用概率模型参与关键软件开发。

但是最深层的原因，我觉得大家其实在害怕未来。

那些大厂宣传“50%代码由 AI 生成”，我们反而没什么感觉，因为大家本来就把它当营销。

而Andrew不一样，现在很多人表面是在骂他，实际上是在表达一种焦虑：如果连 Andrew 这样的人都开始依赖 AI，那未来的软件工程会变成什么样？