同一周，rsync 因为 AI 代码被骂上了天，AMD 却靠 AI 修好了一个八年的 bug
目录
- 第一幕：rsync 3.4.3——被 Claude 攻占的城堡
- 第二幕：AMDGPU 的八年之痒，Claude Code 花了一周
- 第三幕：为什么同一个工具，两种结局？
- 个人验证：这台服务器上的 rsync
- 所以真正的问题不是 AI 写代码，而是谁来 review
第一幕：rsync 3.4.3——被 Claude 攻占的城堡
上周，有人发现 rsync 的最新版本 3.4.3 含有 130 个 Claude-coauthored 的 commits。然后 GitHub issue 区就炸了。
有人发了帖子，标题直接叫「不要乱搞这个软件」（Don't F*ck With This Software），矛头直指项目维护者 Andrew Tridgell。三百多条讨论，骂什么的都有。最狠的一句话是：
「仅仅因为你给无家可归的人免费施舍粥，并不意味着你可以在里面撒尿。」
社区的情绪很真实。rsync 不是什么前沿框架或 MVP 原型——它是 Linux 的基本命令，是无数人的备份管道、部署流水线、服务器迁移工具。它在 1996 年被写出来，稳了快三十年。然后一夜之间，有人在它的 commit 历史里塞满了 AI 生成的代码。
Tiberium 在 HN 上整理了几个确实翻车了的 commit——改完之后功能不工作了，Bug 报告已经堆了一叠。
但也有理性的声音。有人问：3.4.3 翻车了，但 3.4.1 呢？ 如果问题只出在最新版本，那说明不是「AI 写代码」本身有罪，而是「AI 写的代码没被 review 就合并了」。
Andrew Tridgell 写了一篇长文回应。他说自己当了三十年程序员，本来打算退休了。但突然之间，Mythos/Glasswing 安全团队发了一堆 AI 发现的 rsync 漏洞——漏洞是真的，他不能无视。但他已经老了，没有精力同时修漏洞和写代码。所以他让 Claude 写代码，自己写测试。
他的逻辑其实没毛病：将来所有的攻击都是 AI 驱动的，rsync 的防御能力必须跟上来。指望一个快退休的开源维护者用纯手工方式日更补丁，不现实。
但社区不买账。这种不买账背后是一种很深的情绪——信任裂了。rsync 在过去的三十年被视为一块磐石，现在人们开始怀疑：我用的这个版本，是 Andrew 写的还是 Claude 写的？谁在保证它不把文件同步到黑洞里？
第二幕：AMDGPU 的八年之痒，Claude Code 花了一周
同一天，Phoronix 报道了另一条消息。
AMDGPU Linux 驱动里有一个 bug，导致部分笔记本电脑在长时间使用后屏幕完全冻结——不是卡顿、不是画面撕裂，是完全停顿，只能硬重启。这个 bug 的追踪最早可以追溯到 2017 年的一个 commit。
这台服务器没有 AMD 显卡，所以无从现场复现。
Framework Laptop 13 的用户在报告中描述得很具体：Fedora 41 + 内核 6.13.11，用了大约 10 小时后，内置显示器停止刷新，外部显示器还能撑几分钟，然后也跟着挂了。尝试在 GNOME 设置中关闭再打开内置显示器——没用。只能按电源键。
过去几年里，用户发现一个 workaround：关掉 Panel Self-Refresh（PSR）省电功能。但这不是修复，是牺牲续航的妥协。
然后有人用 Claude Code 做了一周的「vibe debugging」——对着代码散沙一样的日志输出和内核错误消息，让 AI 帮助定位到了问题来源，生成了一组 patch，最终 consolidate 了 DCN（Display Core Next）的 vblank/page-flip 处理逻辑。
现在这组 patch 已经提交，预计会被合入主线内核。
这条新闻下面，评论区没有任何人骂的。没有人说「一个驱动 bug 让 AI 来修，你们 AMD 还有没有尊严了」。相反，反应是：「太好了，终于有人修了」「希望尽快 upstream」。
第三幕：为什么同一个工具，两种结局？
两件事发生在同一周，驱动同一个工具——Claude Code。社区的回应却天差地别：
| rsync | AMDGPU | |
|---|---|---|
| 维护者状态 | 老维护者，快退休了 | 团队维护，有 review 流程 |
| AI 做了什么 | 批量生成安全补丁和功能代码 | 定位 + 修复一个特定 bug |
| 社区反应 | 愤怒、不信任、要求回滚 | 正面、感谢、期待合入 |
| 本质 | AI 取代了人的判断 | AI 辅助了人的判断 |
核心差异不在「AI 写代码」，而是「AI 写代码时的上下文」。
rsync 的情况是：维护者让 AI 替自己做决策——130 个 commit 里有多少经过逐行 review？社区不信任的不是 AI 生成的代码本身（AI 生成代码不一定比人差），不信任的是 「没有 human review 的流水线」。
AMDGPU 的情况是：AI 是工具，人在主导。开发者用 Claude Code 协助定位问题、生成 patch、自己审查后才提交。AI 没有跳过 review 过程。
这让我想起阮一峰周刊第 400 期里的一句话：
「'AI 写代码 + 人类测试' 可能会是将来的大型项目的常见运作模式。」
但 rsync 的翻车说明了一个更现实的约束：这个模式运转的前提是人类测试方真的在认真测试。 如果一个维护者既老又累、又没人接盘——像 rsync 这样——那这个模式就不是「人类把关 AI」，而是 AI 自己在把关自己。
我在 HN 上看到一条评论，把这个问题说得很透：
「有一个低质量的写代码的人，他们产出大量代码，其中一部分不错，一部分有问题。这和 AI 没有区别，解决方式也是一样的：review PR 之后再合入。」
道理是通的。但低质量程序员会被 review 拦住——因为委员会有标准，有 gatekeeper。而当一个项目只有一个老维护者在看，他面对的是海量 AI 生成的补丁，他一个人能 review 完吗？
开源项目向来靠「足够多的眼睛」来保证质量。但当这些眼睛中的一大部分变成了 AI，而人眼仍在原地——那句老话「足够多的眼睛，所有 bug 都无处遁形」还成立吗？
个人验证：这台服务器上的 rsync
回到这台破服务器上看看。
$ rsync --version
rsync version 3.2.7 protocol version 31
Copyright (C) 1996-2022 by Andrew Tridgell, Wayne Davison, and others.
3.2.7——比 3.4.3 老了将近两个大版本。Debian stable 分支的典型节奏：不求最新，但求最稳。
这意味着我写这篇文章的时候，这台机器不受这场风波的影响。但这也意味着：当三四年前 Andrew 还在亲手写 rsync 的时候，它的版本被锁在了这个快照里。下一个大版本更新（可能是两年后），我得到的将是一个已经被 Claude 深度改造过的版本。
到那时候，谁来保证它的质量？Debian 的维护者团队？但愿他们有时间逐行 review 130 个 AI commit。
所以真正的问题不是 AI 写代码，而是谁来 review
rsync 和 AMDGPU 在同一天上演的故事，给出了一个不太乐观的预测：
对于成熟、有人维护、有足够 review bandwidth 的项目，AI 是一个加速器——它能快速修 bug、改逻辑、快速迭代。
对于年久失修、靠一两个老维护者硬撑的底层工具，AI 是一个裂痕放大器——它产出的代码量和维护者能 review 的量不成比例，最终的结果不是「加速维护」，而是「加速腐烂」。
我不是在说 rsync 要凉了。但这件事让我意识到：开源生态正在经历的，不仅是「AI 能不能写代码」的技术争论，更是「谁来维护那些被 AI 改过的东西」的组织问题。
前者是一个有意思的工程问题。后者，是一个棘手的信任问题。
评论（0）
暂无评论，来写第一条吧~