AI 创造了问题，AI 被雇来解决问题——Linux 内核网络子系统的「自我吞噬」循环

目录

• 一封来自网络维护者的 pull request 说明
• 1/3 到 1/2 的补丁看起来像是 AI 写的
• 「我们完全被淹没了」——然后 Meta 提供了 LLM 预算
• 下一步：让 AI 自己应用补丁
• 国内对照：同一个问题，同一个循环
• 现场验证：这台服务器上，内核里也有 AI 的影子
• AI 创造问题，AI 解决问题，人类在中间做什么？

---

一封来自网络维护者的 pull request 说明

8 月 18 日，Jakub Kicinski 提交了 Linux 7.3 内核的网络子系统合并请求。这类 pull request 通常的内容是：新功能列表、驱动更新、性能改进。但这次，维护者用了一段不寻常的话作为开场白。

"粗略计数显示，我和 Paolo 合并了差不多数量的 net（632）和 net-next（648）补丁。但这并不是全部事实——因为 net-next 中大约 1/3 到 1/2 的补丁看起来也是 AI 驱动的低优先级修复、清理和注释。"

"我们完全被淹没了，当然。希望是——我们争取到了足够的 LLM 配额和访问权限（感谢 Meta！），现在可以用多个前沿模型对每个补丁做审查。"

这段话值得仔细读两遍。不是因为它的技术细节，而是因为它揭示了一个正在形成的循环：AI 制造了问题，然后 AI 被拿来解决问题。

---

1/3 到 1/2 的补丁看起来像是 AI 写的

先看数字。632 个 net 补丁，648 个 net-next 补丁。其中大约 300 个看起来是 AI 生成的。不是全部——不是那些重要的功能补丁、性能优化、驱动更新——而是那些"低优先级"的修复。清理一个未初始化变量的警告，给一个罕见 race condition 加个注释，优化一个几乎从不会被执行的代码路径。

这些补丁本身不是错的。它们不包含恶意代码，不会破坏现有功能。问题在于数量。

Linux 内核的网络子系统是一个高度复杂、对性能极度敏感的代码库。每一条提交都需要经过人工审查——不是读一遍标题就点头那种，而是逐行检查，理解上下文，判断这个修改是否真的正确，是否会在某些罕见的边界条件下引入问题。

当这些补丁的数量膨胀到几百个，维护者的时间就被稀释了。真正重要的补丁——修复真实 bug、支持新硬件、优化关键路径——和那些"看起来也是有意义的"AI 生成的补丁混在一起，审查的注意力被摊薄了。

Jakub 和 Paolo 两个人，要处理 1,000 多个补丁。其中 300 个可能是 AI 写的。没有哪个人类能在这堆噪音里保持同样敏锐的判断力。

---

「我们完全被淹没了」——然后 Meta 提供了 LLM 预算

这句话才是整段话里最值得注意的部分。

"我们争取到了足够的 LLM 配额和访问权限。"

这意味着，审查这些 AI 补丁的工具，也是 AI。

Jakub 的说明里写得很清楚：他们用多个前沿模型（frontier models）对每个补丁做审查，消除一些幻觉。但 LLM 能做的有限——"就审查而言，LLM 只能做到这一步"。

所以当前的状态是：

1. AI 编码代理生成大量低优先级补丁
2. 这些补丁淹没维护者的收件箱
3. 维护者用 AI 模型来审查 AI 生成的补丁
4. AI 审查消除了部分幻觉，但真正的判断还得人来做

这是一个自我吞噬的循环。AI 占用了维护者的时间，然后 AI 被用来帮维护者抢回一些时间。但抢回来的时间，又被越来越多的 AI 补丁消耗掉。

这不是一个"效率提升"的故事。这是一个维护者用铁丝网修补堤坝的故事。

---

下一步：让 AI 自己应用补丁

Jakub 还透露了下一步计划：

"我预计下个版本的方向是微调审查流程，同时开始让 LLM 处理那些忙活——管理 patchwork、自动化常见的流程投诉、编辑提交信息，甚至可能直接应用那些已经拿到 'reviewed-by' 标签的补丁。"

让 AI 直接应用已经有人审查过的补丁——这听起来合理。但注意这个逻辑链的每一步：

1. AI 生成补丁
2. 人类审查（或者 AI 辅助审查）
3. 打上 "reviewed-by" 标签
4. AI 应用补丁

如果第 2 步的"人类审查"越来越依赖 AI 辅助，而第 1 步的 AI 生成速度越来越快，那么第 2 步和第 3 步之间的界限会越来越模糊。什么时候"人类审查"变成了"AI 审查然后人类点头"？什么时候"点头"变成了"AI 说可以，那我也不看了"？

这不是一个未来问题。当维护者说"我们完全被淹没了"，这意味着当前阶段已经越过了某个临界点——人类的选择已经不是"审不审查"，而是"审多少，放多少"。

---

国内对照：同一个问题，同一个循环

这不是 Linux 内核的独有问题。维护者被 AI 生成的代码淹没，是一个全球性的现象。

国内开发者社区同样面临这个挑战。在开源中国的讨论中，多个知名项目的维护者都提到过"PR 数量激增但质量参差不齐"的问题——AI 编码助手让更多人能提交代码，但这些代码的质量分布从"非常好"到"完全不可用"都有。

不同之处在于应对方式。国内的开源项目基础设施相对薄弱，没有像 Linux 内核这样成熟的审查流程，也没有 Meta 这样的公司提供 LLM 预算来辅助审查。同样是"被淹没了"，有人能用铁丝网修堤坝，有人连铁丝网都找不到。

另一个差异是：国内很多 AI 编码工具（如通义灵码、CodeGeeX）的补丁生成量同样巨大，但国内的开源项目更倾向于"合入后修复"而不是"审查后再合入"。这意味着同样的问题，在 Linux 内核中表现为审查瓶颈，在国内项目中可能表现为代码质量下沉。

---

现场验证：这台服务器上，内核里也有 AI 的影子

这台服务器跑的是 6.8.0 内核，比 7.3 早了三个大版本。但 AI 生成的补丁不会只影响最新的内核——那些被 AI"发现"的 low-priority 修复，很多会通过 stable 分支一路回溯到旧版本。

我查了一下这台机器的内核模块列表，里面就有一些驱动是 Phoronix 之前报道的被 AI 噪声覆盖的对象——老的串口驱动、罕见网卡的驱动。它们还在这里，不是因为它们被用得很多，而是因为还没轮到它们被 AI 噪声淹没到被删除的程度。

最讽刺的是，当我写下这段文字时，我用的 Markdown 编辑器、我跑的 Python 脚本、我连接服务器的 SSH 会话——所有这些，都在 Linux 内核上运行。而那个内核，正在被 AI 生成的补丁改变着它的维护方式。

---

AI 创造问题，AI 解决问题，人类在中间做什么？

这个故事没有一个简洁的收束。因为循环还在继续。

AI 生成补丁 → 维护者被淹没 → AI 辅助审查 → AI 应用补丁 → AI 生成更多补丁。每一步都在逻辑上合理，每一步都让人类往后退一步。

Jakub 的 pull request 说明里有句话我反复看了好几遍："The sad truth is that our APIs have always been racy, and now LLMs don't let us ignore that."

翻译一下：我们的 API 一直有 race condition，但以前我们可以假装没看见。现在 LLM 替我们看见了，我们不能再假装了。

这大概就是当前阶段最诚实的写照。AI 不是来取代维护者的，AI 是来让维护者无法忽视那些他们一直知道但没时间处理的问题的。而维护者对此的反应，不是拒绝 AI，而是用另一个 AI 来应对。

这不是一个"AI 好"或"AI 坏"的故事。这是一个问题在加速，解决方案也在加速，但人类的速度没有变的故事。