夜雨聆风同一周内，Linux 内核两个相互独立的子系统——网络和音频——相继出现由 AI/LLM 工具驱动的大量修复提交。网络子系统维护者说"疯狂还在继续，看不到尽头"；音频子系统维护者说"这在预期之中"。内核文档已经为此新增了一节"负责任的 AI 使用"指南。
开源社区面对 AI 代码生成工具的方式，和十年前面对自动化测试工具的方式很不一样：不是拒绝，而是陷入了某种措手不及的消化状态。
两个子系统，一周之内
5 月 21 日，Linux 7.1 开发周期的网络子系统固定更新合并进了主线。负责这个子系统的 Jakub Kicinski 在 pull request 的说明里写道：
"Craziness continues with no end in sight. Even discounting the driver revert this is a pretty huge PR for standards of the previous era. I'd speculate — we haven't seen the worst of it, yet."
这份 PR 包含大量安全相关修复：栈信息泄露（tap_ioctl 的 SIOCGIFHWADDR）、UAF 读写（af_unix 流等待路径）、TCP ISN 预测修复……规模"按照以前的标准算是相当大的"。Kicinski 注意到这些修复大量来自 AI/LLM 工具扫描后上报的 bug，包括一个名为 Sashiko 的工具，以及近期曝光的 Dirty Frag（CVE-2026-43284 / CVE-2026-43500）等系列漏洞背后的 AI 辅助分析链条。
5 月 22 日，音频子系统维护者 Takashi Iwai（SUSE）提交了本轮的音频修复 pull request，开头写道：
"As expected, we still continue receiving lots of small fixes."
他专门提到，音频邮件列表本月收到的 "assisted-by" 补丁——格式是 Assisted-by: Claude Code 或 Assisted-by: GPT-5.5——数量明显上升。
两个子系统，时间间隔不到 24 小时，描述的是同一个现象。
AI 驱动补丁的三个核心来源
目前可以确认的工具来源有几条线：
Sashiko：一个由安全研究员开发的 AI 驱动漏洞扫描工具，专注 Linux 内核代码。Dirty Frag 系列漏洞（通过 zero-copy/splice 进行 page cache 污染）部分是由它发现的。在 batman-adv（网状无线网络）和 netfilter 子系统里，Sashiko 的报告直接推动了"大量小型安全性修复"。
Claude Code / GPT-5.5：这些工具的使用者——多为个人开发者或小团队——扫描内核某个模块的代码后提交修复。补丁格式规范，在提交信息里注明 Assisted-by:，符合内核社区对 AI 辅助提交的新要求。
Anthropic 的大规模漏洞挖掘项目（Project Glasswing）：Anthropic 在本周发布了初步数据，Project Glasswing 计划一个月内协助约 50 家合作伙伴发现了一万多项严重且高危的安全隐患，而团队利用 Glasswing 在 Mozilla Firefox 150 的测试中发现并修复了 271 个漏洞，其中部分已通过正常渠道提交给上游项目。虽然内核不是唯一目标，但大方向是一致的。
Kicinski 特别写了一句值得注意的话：
"Good news, I guess, is that so far we haven't seen many (any?) cases of 'AI reported a bug, we fixed it and a real user regressed'."
这意味着目前的修复质量还可以——AI 报告的 bug 经维护者确认后修复，没有引入新的回归。但他的语气更像是在说"目前还没出问题"，而不是"已经建立了信心"。
内核文档加了一节：负责任的 AI 使用
与此同时，Linux 7.1 开发周期的文档更新里新增了一节内容：《What Qualifies As A Security Bug, Responsible AI Use》，明确指导贡献者在使用 AI 工具辅助内核开发时应遵守的规范。
这个更新的出现本身就说明了问题：内核社区已经认识到 AI 辅助提交不会停止，需要建立明确规范，而不是简单拒绝。
规范的核心是"AI 工具可以辅助发现问题，但提交者必须理解、验证、并为自己提交的补丁负责"。把 AI 输出的代码直接粘贴进邮件列表是不被接受的；注明 Assisted-by: 是对 AI 辅助的诚实披露，不是免责声明。
恶意投毒与规模冲击的性质差异
2021 年，明尼苏达大学的研究人员故意向 Linux 内核提交包含漏洞的"Hypocrite Commits"，测试内核社区的安全审查能力。Linus Torvalds 和内核团队盛怒之下封禁了来自该机构的所有贡献。
当时的问题是恶意投毒：有人故意引入错误。
现在的情况是规模冲击：AI 工具大量发现真实存在的 bug，并以前所未有的速度提交修复。维护者面对的不是恶意，而是工作量。Kicinski 估计目前网络子系统的 PR 规模"按以前的标准算是相当大的"，而他自己预测"最糟糕的情况还没到"。
两件事的性质完全不同，但都揭示了同一个结构性问题：内核社区的审查能力是线性的，而 AI 工具的输出能力不是。
上游高频合并对下游生态的溢出效应
FreeBSD 社区同期也出现了类似情况。FreeBSD 15.1-RC1 的发布说明里提到"AI 发现的安全问题数量增加"，这一轮 RC 的修复量明显高于往期。
华为、中科院软件所、统信等深度参与 Linux 内核开发的机构，以及维护 OpenCloudOS、openEuler 等下游发行版的团队，都会受到这波 AI 补丁潮的间接影响：上游合并更快但更密集，下游的 rebase 和测试周期要相应调整。
更长远的问题是：AI 工具可以发现漏洞，但理解漏洞的影响范围、判断修复是否正确、确保修复不引入回归——这些仍然需要深度理解内核代码的人来完成。Kicinski 的"庆幸目前还没有真实用户回归"，背后是人工审查在支撑。
当 AI 提交的补丁速度超过维护者的审查速度，下一阶段的问题就不再是"AI 能不能找 bug"，而是"谁来审查 AI 提交的修复"。
