一条标题为「Please Do Not Vibe Fuck Up This Software」的 GitHub issue，把 rsync——这个陪伴 Unix 用户近三十年的同步工具——推到了开源社区的风暴中心。维护者 tridge 在项目中引入 AI 辅助开发后，新版本出现了增量备份失败、CPU 占用异常飙升等回归问题。社区愤怒的表面是 bug，底层是信任。
事故现场：增量备份坏了，CPU 烧了
rsync 的核心价值在于增量传输——只搬运文件中真正变化的部分，而不是整份拷贝。这个特性依赖滚动校验算法（rolling checksum）的精确实现，差一个字节偏移，整个增量逻辑就会退化为全量传输，甚至更糟：反复比对不匹配的块，CPU 旋即飙升。
用户报告的问题恰恰击中了这条命脉：
- 增量备份场景下，本应只传输差异块，实际却触发了全量重传；
- 大文件同步时 CPU 占用从正常的个位数百分比跳到接近 100%，机器几近卡死。
这类回归在 rsync 的历史上极为罕见。过去二十多年，rsync 以稳定著称，每次发布前都有严格的跨平台测试矩阵。而这一次，问题出在代码本身——被引入的那段代码，据社区追溯，带有明显的 AI 生成痕迹：变量命名风格不一致、边界条件处理粗糙、注释措辞与项目既有风格脱节。
"Vibe Coding" 为什么在 rsync 上特别致命
所谓 vibe coding，指的是开发者凭直觉和 AI 对话式交互快速产出代码，不做深度审查就合入主干。在原型项目、个人脚本里，这或许无伤大雅。但 rsync 不是原型——它是一个被全球数百万服务器依赖的基础设施组件。
三个致命因素叠加：
算法精度不可妥协。 rsync 的滚动校验算法（Adler-32 变体 + 强校验 MD4/MD5）对实现精度要求极高。校验窗口滑动时，每一步的进位与退位必须严格对应字节流偏移。AI 生成的代码在描述上"看起来对"，但细节偏移——比如窗口边界少减一个旧字节——会导致校验值系统性偏差，增量匹配全面失败。
性能敏感路径不容试错。 rsync 的核心循环处理的是 GB 级文件流，每多一次无效比对就是海量 CPU 浪费。AI 倾向于生成"防御性代码"——多加一层检查、多套一个循环——在普通应用里这是好事，在 rsync 的热路径上就是灾难。
回归测试覆盖不足。 tridge 合入 AI 代码时，显然没有跑完完整的增量回归测试套件。rsync 的测试本就依赖特定文件构造（比如精心设计的几乎相同的大文件对），AI 生成代码的同时，并没有 AI 生成对应的测试用例。
用数据说话：验证你的 rsync 是否受害
如果你正在运行近期版本的 rsync，以下命令可以快速检测增量传输是否退化：
# 1. 构造测试环境：两个仅差一个字节的大文件
dd if=/dev/urandom of=/tmp/srcfile bs=1M count=100
cp /tmp/srcfile /tmp/dstfile
# 在目标文件中间修改一个字节
printf '\xff' | dd of=/tmp/dstfile bs=1 seek=50000 conv=notrunc
# 2. 正常增量传输应只传输极少量数据
# --stats 会输出总传输字节数
rsync -av --stats /tmp/srcfile /tmp/dstfile
# 3. 检查输出中的 "Total transferred file size"
# 正常值应接近 1 字节（或一个块的大小，通常 ~700-1024 字节）
# 如果接近 100MB，说明增量逻辑已退化为全量传输
# 4. 同时观察 CPU 占用
# 正常增量同步 CPU 应在几秒内完成
# 如果 rsync 进程 CPU 长时间 100%，校验循环可能出了问题
time rsync -av --stats /tmp/srcfile /tmp/dstfile
预期结果：Total transferred file size 应在 KB 级别以内，耗时应在 1-2 秒。如果传输量接近源文件大小或耗时数十秒以上，你的 rsync 版本大概率存在回归。
进一步，你可以对比不同版本：
# 安装已知稳定版本（如 3.2.7）做对照
# macOS: brew install rsync@3.2.7 或从源码编译
# Linux: 从 https://rsync.samba.org/ 下载稳定版编译
# 编译特定版本做 A/B 测试
curl -O https://rsync.samba.org/ftp/rsync/src/rsync-3.2.7.tar.gz
tar xzf rsync-3.2.7.tar.gz
cd rsync-3.2.7
./configure && make
# 使用编译出的二进制
./rsync -av --stats /tmp/srcfile /tmp/dstfile
开源信任的裂痕：比 bug 更难修复
这条 issue 激起的愤怒，远超一个普通 bug 报告的烈度。原因在于它同时踩中了三根红线：
透明度缺失。 维护者没有在 commit message 或 PR 描述中标注"此变更由 AI 辅助生成"。社区是在出问题后反向追溯才发现的。在开源协作中，变更的可审查性是信任基石——你不需要每行都手写，但你必须让审查者知道哪些行需要额外警惕。
审查标准降级。 AI 生成的代码需要比手写代码更严格的审查，因为它的错误模式与人类不同——AI 会在"看起来专业"的表面下隐藏系统性偏差。而实际发生的是相反：AI 代码被以更低的标准合入，仿佛"AI 写的=已验证的"。
维护者权威的双刃剑。 tridge 是 rsync 的原创作者，在社区拥有极高声望。这反而让问题更棘手——他的合入决定几乎不会被二次质疑，直到用户在生产环境中受害。权威人物使用 AI 时的疏忽，比普通贡献者的疏忽破坏力更大，因为它直接动摇了"这个项目有人把关"的集体信念。
给维护者的实操清单
无论你是否使用 AI 辅助编码，以下规则能帮你避免类似的信任崩塌：
## AI 辏助开发合入检查清单
1. **标注来源**
- commit message 中明确写出哪些部分由 AI 生成、使用了什么模型
- 例：`feat: optimize checksum rolling window (core logic co-written with Claude 3.5, manual review by @tridge)`
2. **加倍审查**
- AI 代码的审查强度应为手写代码的 2x
- 重点检查：边界条件、数值精度、热路径性能、与既有风格的一致性
- 必须有人逐行解释每一段 AI 生成代码的语义，而不是"看起来对就过"
3. **测试先行**
- 每个 AI 生成的功能变更必须附带对应的测试用例
- 测试用例本身应由人工编写或严格审查
- 性能敏感路径必须做基准对比（benchmark before/after）
4. **渐进合入**
- AI 代码先进入实验分支或 feature flag 保护
- 不直接合入稳定分支，给社区审查窗口
5. **回滚预案**
- 合入前准备好一键 revert 的干净 commit
- 监控生产反馈，48 小时内无负面报告再视为稳定
信任一旦碎了，光修 bug 不够
rsync 的这场风波最终大概率会以 bug 修复告终——回归问题会被定位、补丁会被提交、新版本会发布。但社区信任的修复周期远长于代码修复周期。
对 tridge 而言，最有效的补救不是"我以后不用 AI 了"——那是在回避问题。真正需要的是建立一套透明的 AI 使用规程：标注、审查、测试、渐进合入。让社区看到，AI 代码进入 rsync 的门槛比手写代码更高，而不是更低。
对所有开源维护者而言，这件事是一面镜子：你的项目越重要、你的声望越高，你对 AI 辅助的每一次轻率合入，就越可能成为下一次信任危机的导火索。代码可以 revert，信任不能。