林纳斯·托瓦兹（Linus Torvalds）于8月17日发布了 7.2 版 Linux 内核（Linux kernel），并表示收到的修复数量仍“比我希望的更多”。7.2 是内核史上最繁忙的开发周期之一，新增近600,000行代码。为弄清内核开发社区的变化，相关统计显示：7.2 共有16,418个非合并提交进入主线，超过7.1，成为史上第二繁忙的版本，仅6.7的提交更多，但6.7主要来自合并 bcachefs 开发历史，7.2 的增长更广泛。这些提交由2,652名开发者贡献，高于7.1的2,479名纪录。

Linus Torvalds 于 8 月 17 日发布了 7.2 内核，他在此之前表示，涌入的修复数量仍然“比我希望的要多”。事实上，7.2 是内核史上最繁忙的开发周期之一，新增了近 60 万行代码。现在不妨看一些统计数据，以了解内核开发社区正在如何变化。

7.2 主线共合入了 16,418 个非合并提交，超过了（已经很繁忙的）7.1 版本；事实上，这是内核史上第二繁忙的版本。只有 6.7 版本 合入了更多提交，但 6.7 的提交量主要由合并 bcachefs 开发历史所主导，而 7.2 的提交量则分布得更广泛。

这些提交由 2,652 名开发者贡献，比此前的纪录（7.1 的 2,479 人）大幅增加。如果回看 Git 时代以来开发者参与情况的历史，结果如下：

（这张图，以及这里的许多信息，都来自仅订阅者可用的 LWN Kernel Source Database。）在这段整个历史中，趋势很明显：每个版本贡献代码的开发者数量随时间增加。但那条线的斜率已经明显改变。

参与 7.2 开发最活跃的开发者如下，首先按变更集（changesets）统计：

| 按变更集（changesets） | 变更集数 | 占比 | |---|---:|---:| | Uwe Kleine-König | 151 | 0.9% | | Rosen Penev | 146 | 0.9% | | Ian Rogers | 138 | 0.8% | | Johan Hovold | 133 | 0.8% | | Arnaldo Carvalho de Melo | 131 | 0.8% | | Chuck Lever | 129 | 0.8% | | Eric Dumazet | 121 | 0.7% | | Ville Syrjälä | 115 | 0.7% | | Johannes Berg | 112 | 0.7% | | Krzysztof Kozlowski | 110 | 0.7% | | Thorsten Blum | 108 | 0.7% | | Namjae Jeon | 106 | 0.6% | | Christoph Hellwig | 104 | 0.6% | | Sean Christopherson | 100 | 0.6% | | Jakub Kicinski | 96 | 0.6% | | SJ Park | 94 | 0.6% | | Mike Rapoport | 91 | 0.6% | | Dmitry Baryshkov | 87 | 0.5% | | Eric Biggers | 86 | 0.5% | | Rafael J. Wysocki | 78 | 0.5% |

按修改行数（changed lines）统计：

| 按修改行数（changed lines） | 修改行数 | 占比 | |---|---:|---:| | Matthew Stewart | 83587 | 8.4% | | Hawking Zhang | 62893 | 6.3% | | Miguel Ojeda | 38979 | 3.9% | | Ian Rogers | 31949 | 3.2% | | Darren Ye | 20843 | 2.1% | | Ethan Nelson-Moore | 16893 | 1.7% | | Harry Wentland | 15233 | 1.5% | | Uwe Kleine-König | 13803 | 1.4% | | Ingo Molnar | 13649 | 1.4% | | Chuck Lever | 10172 | 1.0% | | Eric Biggers | 10067 | 1.0% | | Jakub Kicinski | 9449 | 0.9% | | Rodrigo Siqueira | 7749 | 0.8% | | Johannes Berg | 7110 | 0.7% | | Arnd Bergmann | 7085 | 0.7% | | Emil Tsalapatis | 6810 | 0.7% | | Vivek Aknurwar | 6544 | 0.7% | | Rob Clark | 6490 | 0.6% | | Sabrina Dubroca | 6401 | 0.6% | | Svyatoslav Ryhel | 6072 | 0.6% |

Uwe Kleine-König KSDB 是 7.2 版本中贡献提交最多的开发者，他的工作是对驱动子系统进行清理。Rosen Penev KSDB 贡献了一长串由 LLM 编写的 bug 修复，涉及架构相关代码、驱动、网络、crypto 等多个子系统。Ian Rogers KSDB 在用户态 perf 工具上做了大量工作，Arnaldo Carvalho de Melo KSDB 也是如此。Johan Hovold KSDB 做了许多改进，主要集中在 SPI 和 USB 子系统。

Matthew Stewart KSDB 延续了添加大量机器生成的 amdgpu 头文件的悠久传统，因此在“修改行数”一栏位居榜首；Hawking Zhang KSDB 也做了类似的工作。Miguel Ojeda KSDB 将 Rust zerocopy crate 引入了内核源码。Darren Ye KSDB 添加了 MediaTek mt8196 音频驱动。

7.2 中带有 Tested-by 标签的提交刚过 8%，而 48% 的提交带有 Reviewed-by 标签。尤其是 review 标签，在最近几个版本中呈现出轻微下降趋势：

这种下降是否反映了实际 review 工作量的减少，目前还很难说。无论如何，本周期最活跃的测试者和评审者如下，首先按 Tested-by 统计：

| 开发者 | Tested-by 数 | 占比 | |---|---:|---:| | Dan Wheeler | 117 | 7.0% | | Luiz Capitulino | 54 | 3.2% | | James Clark | 44 | 2.6% | | Sarthak Sharma | 44 | 2.6% | | Venkat Rao Bagalkote | 32 | 1.9% | | Tommaso Merciai | 27 | 1.6% | | David Riley | 27 | 1.6% | | Jie Gan | 27 | 1.6% | | Geert Uytterhoeven | 25 | 1.5% | | Arthur Kiyanovski | 25 | 1.5% | | Marek Szyprowski | 25 | 1.5% | | Randy Dunlap | 24 | 1.4% | | Shivaprasad G Bhat | 24 | 1.4% | | Rinitha S | 21 | 1.3% | | Vitaly Prosyak | 20 | 1.2% |

按 Reviewed-by 统计：

| 开发者 | Reviewed-by 数 | 占比 | |---|---:|---:| | Konrad Dybcio | 231 | 2.2% | | Dmitry Baryshkov | 225 | 2.1% | | Andy Shevchenko | 175 | 1.7% | | Geert Uytterhoeven | 171 | 1.6% | | Krzysztof Kozlowski | 152 | 1.5% | | Frank Li | 147 | 1.4% | | Ilpo Järvinen | 145 | 1.4% | | Christoph Hellwig | 143 | 1.4% | | Jan Kara | 121 | 1.2% | | Christian König | 120 | 1.1% | | Linus Walleij | 116 | 1.1% | | Alex Deucher | 105 | 1.0% | | Simon Horman | 102 | 1.0% | | Jeff Layton | 101 | 1.0% | | Ido Schimmel | 94 | 0.9% |

Dan Wheeler KSDB 凭借处理 AMD 图形驱动补丁的工作，一如既往地位居测试者榜首。在 review 方面，Konrad Dybcio KSDB 为 231 个改动添加了他的标签，Dmitry Baryshkov KSDB 标记了 225 个；这两人往往都专注于 Qualcomm 设备的驱动和 devicetree 文件，在 7.1 周期也同样位居该列表前列。

我们能够识别出的、支持 7.2 内核开发工作的雇主共有 249 家；其中最活跃的是，首先按变更集（changesets）统计：

| 按变更集（changesets） | 变更集数 | 占比 | |---|---:|---:| | (Unknown) | 2743 | 16.7% | | Intel | 1512 | 9.2% | | Google | 1191 | 7.3% | | Red Hat | 873 | 5.3% | | AMD | 813 | 5.0% | | Qualcomm | 767 | 4.7% | | (None) | 743 | 4.5% | | NVIDIA | 535 | 3.3% | | Meta | 441 | 2.7% | | (Consultant) | 429 | 2.6% | | SUSE | 358 | 2.2% | | Renesas Electronics | 328 | 2.0% | | IBM | 307 | 1.9% | | Kylin | 278 | 1.7% | | NXP Semiconductors | 264 | 1.6% | | Oracle | 245 | 1.5% | | Arm | 222 | 1.4% | | BayLibre | 203 | 1.2% | | Microsoft | 201 | 1.2% | | Bootlin | 194 | 1.2% |

按修改行数（changed lines）统计：

| 按修改行数（changed lines） | 修改行数 | 占比 | |---|---:|---:| | AMD | 224121 | 22.4% | | (Unknown) | 103861 | 10.4% | | Google | 102565 | 10.3% | | Qualcomm | 59021 | 5.9% | | Intel | 53661 | 5.4% | | Red Hat | 51559 | 5.2% | | Meta | 38635 | 3.9% | | (None) | 28218 | 2.8% | | NVIDIA | 27417 | 2.7% | | MediaTek | 22025 | 2.2% | | NXP Semiconductors | 17692 | 1.8% | | BayLibre | 15972 | 1.6% | | Oracle | 12233 | 1.2% | | Microsoft | 11786 | 1.2% | | Renesas Electronics | 11103 | 1.1% | | Linaro | 10209 | 1.0% | | (Consultant) | 9362 | 0.9% | | IBM | 9205 | 0.9% | | Texas Instruments | 8398 | 0.8% | | SUSE | 8350 | 0.8% |

这一次最显著的变化，可以说，是未知归属开发者的大幅增加。这至少在一定程度上反映了持续涌入内核社区的新开发者浪潮。

新开发者及其工具

前两个内核版本都曾创下首次贡献开发者数量的纪录；7.2 再次打破了这一纪录，有 613 名此前未在这里出现过的贡献者 KSDB。这里的趋势同样很明显：

最活跃的新开发者是 Bryam Vargas KSDB，他贡献了 43 个提交，修复了 input、NVMe、F2FS、AppArmor、Landlock、SELinux、NTFS、WiFi、ATA、SCSI、网络、Ceph 和 Thunderbolt 等子系统中的问题。正如以前在这里观察到的那样，即使是一名经验丰富的内核开发者，也很难在单个开发周期内深入这么多子系统——至少，如果他们想弄懂自己在做什么的话。而一个此前未知的开发者做到这一点，往好了说也令人惊讶。不过，Vargas 的补丁并没有带 Assisted-by 标签，因此我们只能相信，这项工作是在没有 LLM 辅助的情况下完成的。

总体而言，7.2 中有 1,111 个改动（不到总数的 7%）带有 Assisted-by 标签——相比 7.1 的 301 个大幅增加。不过，7.2 中 LLM 辅助补丁的真实数量肯定远高于此。许多开发者并不提供这些标签（经常——但并非总是——因为不了解规则），维护者很少询问是否使用了 LLM，而且至少有一名维护者在应用补丁时会主动去掉这些标签。准确跟踪使用 LLM 辅助开发的提交或许最终是不可能的，但有时感觉内核社区并不够在意，没有真正去尝试。

LLM 使用在内核开发中产生影响的另一个方面是补丁评审。7.2 中有 252 个补丁带有 Reported-by 标签，致谢 Sashiko review system KSDB；有 568 个提交在 changelog 中提到了 Sashiko。不过，其他 LLM 也明显被用于查找内核 bug，并产生了实际影响。

7.2 版本包含 4,830 个带有 Fixes 标签的提交，表明它们修复了由先前提交引入的 bug。要看看这一增长有多显著，可以看下面这张图，它是以前在这里见过的一张图的更新版（最近一次是在 6.17 开发周期）：

粗绿线绘制了每个版本中包含 Fixes 标签的提交数量，粗棕线则是后续提交中被 Fixes 标签指认的提交数量。交叉点位于 5.9，这表明从该版本开始，内核社区修复的 bug 开始多于引入的 bug。不过，这个结论不会一直成立；要识别和修复所有 5.9 之后引入的 bug 还需要很多年，这条线也会随之移动。

不过，图中真正值得留意的部分在右侧：在多年大致持平之后，带有 Fixes 标签的提交数量急剧增加。看来，这就是当大量的人开始把 LLM 用于查找现有软件中的 bug 时会发生的情况。这将是一个值得关注的有趣趋势。bug 的数量不可能是无限的——即使在内核中也是如此——因此 bug 检测和修复的速度最终必然会下降。现有的 bug 会被修复，而 LLM 评审也会减少新引入 bug 的数量。至少，希望如此。

如果这种下降并没有发生，那就会有一些有趣的问题需要回答。看起来相当清楚的是，LLM 的普及让一些原本没有能力编写内核补丁的人也能够创建补丁了。如果这是真的，那么不难推断，在许多情况下，这些补丁的提交者并不完全理解这些补丁的作用。也许 LLM 已经足够好，以至于不再需要这种理解，但也可能是，我们正在堆积一堆从来没有人真正理解、却在未来几年需要维护的代码。

Linux 内核面向生产使用，而不是研究或实验。但目前，一场大规模实验正在内核的开发流程和社区上进行。这个社区在其 35 年历史中多次吸收了新的流程和工具，而且几乎肯定这次也能找到办法做到。但这种吸收过程并不总是一帆风顺。

与此同时，有近 14,000 个非合并变更集存放在 linux-next 仓库中，等待被拉取进入 7.3 版本；其中超过 1,100 个包含 Assisted-by 标签。近期这些版本的高活跃度看起来短期内不会结束。和往常一样，请继续关注 LWN，我们将跟进下一个开发周期（以及之后的周期）。

多数人不信任所谓“缺陷修复翻倍”的统计口径，并强烈批评 AI、LLM 生成的低质补丁、氛围编程与机器生成代码膨胀，认为这正把面向生产的 Linux 内核变成实验场、拖累维护与质量；少数人则承认 AI 代理能自动完成复现、调试和修复，从而加快缺陷修复并降低上报的缺陷数。分歧主轴是：AI 究竟是内核开发的效率工具，还是正在以缺乏对照的方式把生产级内核当成一场大规模实验。

指出标题被编辑夸大，文章本意是批评内核开发中的 AI 实验

• 原帖标题本是“7.2 内核开发统计”，却被改成暗示自 2026-04 以来缺陷修复数翻倍多的说法；原文末段其实强调 Linux 内核面向生产使用，而不是研究或实验，但如今其开发流程和社区正被人进行大规模实验。有人要求不要编辑化标题，随后标题已被修正。（少数人） > Linux 内核面向生产使用，而非研究或实验，但其开发流程与社区正被一场大规模实验所改变。（@05kqhg）

质疑缺陷统计缺乏对照，无法据此量化 AI 影响

• 这类统计短评的最大问题是没有对照组；历史数据并不可比，因为背后资助方的激励已经改变。若要量化 LLM 的真实影响，需要在没有 LLM 的情况下有同等资金推动补丁数量作为对照。（少数人）

认为 AI 生成的低质补丁与氛围编程正在拖累内核质量和维护

• 内核和整个开源生态现在必须面对大量 AI 生成的粗糙补丁与拉取请求，回应者往往也只是代理；这让维护者甚至不想再向外部贡献开放项目。（较多人）
• 更严重的是内核里已出现氛围编程：生成的粗糙建议中被发现存在竞态条件，而 Linus 似乎容忍这种质量下滑，甚至有人认为需要新的领导层。（较多人） > 对内核的氛围编程已成严重问题，生成的粗糙建议里已发现竞态条件，而 Linus 似乎容忍这种质量下滑。（@VCFundedGenYer）
• 机器生成的 amdgpu 头文件已经膨胀到有人呼吁该设上限。（少数人）

讽刺把内核报错直接丢给 AI 解决

• 有人贴出 Atlantic 网卡电源管理恢复失败并返回 -12 的日志，模仿求助口吻让 AI“搞定这个，谢谢”，讽刺盲目把内核调试交给 AI 的风气。（少数人）

承认 AI 代理能自动修复缺陷，但外部代理的大型拉取请求难以评审

• 在自己项目中，把 AI 代理指向缺陷报告后，代理能完成复现、调试和修复，人类只需评审，缺陷修复因此更快、更自动化；同时因为用户自己的代理会绕过问题而不上报，库的未关闭缺陷数反而下降，短期感觉不错。但他人 AI 代理发来的拉取请求常是巨大代码倾倒，难以评审。（少数人）

认为 Linus 已像接纳 Rust 一样顺滑地接纳 AI

• 评论者承认，虽然没预料到 Linus 会如此顺滑地接纳 AI，但想到内核已经纳入 Rust，其实早该想到会有这一天；整体结果并不让人意外。（少数人）

有价值的补充

• Greg KH 曾发布视频讨论 LLM 生成内容的洪流，并在 HN 上有对应讨论；他大量回击这类内容，并要求提交者给出补丁，而不只是缺陷报告。（由 @zdw 指出）
• 若要用生存分析评估 AI 引入缺陷的影响，需注意缺陷在被发现前并不为人所知，因此并不是标准的生存分析；有人同时询问是否有可公开获取的数据集及链接。（@dash2）
• 有 Slackware 用户提醒：从 7.3-rc7 升级后 /dev/input/events 丢失，键盘和鼠标只能在控制台使用，他已回退到 7.2.10，实际结果可能因人而异。（@tosti）