八月的第二个周末，全球最大开源项目的掌门人坐在屏幕前，看着眼前这份候选版本的体量，敲下了一句注定要被载入开源史册的话。
"I can't say that I'm exactly thrilled about the size of this all, but it is what it is: the new normal."
“我不能说我对这一切的规模正好感到兴奋，但事情就是这样：这就是新常态。”
说这话的人，是Linux之父Linus Torvalds。而他口中那个让他“高兴不起来”的新常态，指向一个任何人都无法再回避的事实，AI驱动的代码审查，正在以机器的速度和规模，重新定义人类维护基础设施的方式。
▲ Mark Kretschmann在X上转发了Torvalds的这段表态，引发讨论
一个“本该安静”的周末，被AI改写了剧本
先说一个内核开发者都懂的常识：Linux内核每个大版本发布前，会经历多轮release candidate（候选版本）测试，从-rc1一路到-rc7甚至-rc8。越到后面，改动应该越少，就像飞机降落前的减速滑行，rc7通常意味着一切接近冻结，维护者们只盯回归bug，等着下周末按下发布按钮。
Linux 7.2-rc7却呈现出另一番景象。
8月9日，Torvalds在内核邮件列表（LKML）发出公告：rc7的体积异常庞大，海量修复散落在GPU驱动、声卡、网络协议栈、文件系统、架构代码等几乎每一个角落。而这些修复的来源，他用了一个让整个开源世界都竖起耳朵的表述，“许多来自各种AI工具的审查”。
▲ Phoronix用“又一个令人筋疲力尽的AI驱动周”作为标题
类似的情况一周前已经出现rc6时，Torvalds就用"huge"形容其体量，并称它即使按照“新常态”的标准衡量，也是近年来最大的候选版之一。到了rc7，他直接给出了一个定性判断：new normal。
这场意外正在固化成常态
▲ The Register的标题一针见血：AI让“巨大的”Linux内核更新成为新常态
53%的bug，人类审查员一个都没抓住
要理解这场“修复洪流”从何而来，必须回到2026年3月的一个关键节点。
Google内核工程师Roman Gushchin公开了一个名叫Sashiko的系统。它超出了传统lint工具或静态分析器的范畴，是一个面向Linux内核补丁的agentic AI审查系统，基于Gemini 3.1 Pro构建，能对发往内核邮件列表的补丁自动生成审查意见。
▲ Google工程师将Sashiko开源，定位为Linux内核的“AI审查员”
Gushchin给出了一个让所有人沉默的数字：在完全未经过滤的约1000个带Fixes:标签的近期上游问题上，Sashiko能发现其中53%的缺陷。
更惊人的信息藏在后面那句话里，
"100% of these issues were missed by human reviewers."
这些被AI抓出来的bug，百分之百被人类审查员漏掉了。
由此可见，Linux内核，这个驱动着全球服务器、云计算、Android手机、超级计算机的底层基础设施，几十年来都有大量bug在人类审查的缝隙中安然存活。这些遗漏更多源于代码量庞大、上下文复杂，以及每天涌入的补丁太多。人的注意力有限，AI则能持续扩大审查覆盖面。
到了8月，Sashiko的威力在具体子系统中得到了可指名的验证。HWMON（硬件监控）子系统维护者Guenter Roeck在拉取说明中直接写道：本周合入的大量修复中，多数是修复Sashiko报告的critical或high severity缺陷，竞态条件、计算错误、越界访问、整数溢出，一个比一个致命。
▲ HWMON子系统的修复直接标注：大多数来自Sashiko报告的高危bug
当机器开始以机器的速度审视人类的基础设施
这里有一个精妙而残酷的反馈回路
X用户Paul Schleifer写下了或许是整场讨论中最有洞察力的一段话：
“构建了基础设施的人，正在看着AI以机器规模审视这些基础设施，然后AI又吐出了机器规模的待改清单。我们无意间闯入了一个没人明确下令启动的反馈循环。”
▲ Paul Schleifer的长评论引发大量转发
这段话值得反复咀嚼 过去三十多年，Linux内核的质量保障依赖于一个人类规模的系统：维护者看补丁、reviewer提意见、CI跑测试、fuzzer找崩溃。这个系统很优秀，但它有一个天然的带宽上限，人一天能审多少行代码，能处理多少封邮件，能在多少个上下文之间切换。
现在，AI审查工具正在推高这个带宽上限。Sashiko只是其中一个玩家，Torvalds在邮件里特意用了"various AI tools"（各种AI工具）这个复数形式。网络/BPF子系统更早引入LLM审查，DRM子系统有Google的工具，还有一些没有公开品牌的内部扫描器在运转。
结果就是：机器找到的真问题，远远超过了人类来得及消化的速度。
“工具很好，但前提是它们真的有帮助”
故事如果只停在这里，那就是一篇简单的“AI赋能开源”报道。但真实世界永远比标题复杂得多
把时间拨回到2026年5月彼时的Torvalds正面对一场近乎灾难的信息过载。
▲ Torvalds痛批：AI工具让安全邮件列表变得“几乎完全无法管理”
他在内核更新中直接开火：私密安全邮件列表已经被AI驱动的缺陷报告搞得“几乎完全无法管理”。原因很讽刺，多个人用同一类工具扫同一批代码，在同一天报告同一批重复问题，却不附带任何修复补丁。
Torvalds的原话刀刀见血：
“AI工具应当提供实际帮助，别给维护者制造不必要的痛苦和无意义的装样子工作。”
“别做那种路过式的、随便扔一份缺乏理解的报告的人。”
这枚硬币有残酷的两面： 同样的AI能力，在一个场景下会形成淹没维护者的垃圾信息洪流，在另一个场景下则能抬高rc候选版的有效修复量。差异取决于使用工具的人是否愿意走完从“发现问题”到“解决问题”的全程。
Linux接受AI工具，也拒绝无责任自动化
7月，当社区围绕Sashiko和AI审查的边界展开激烈争论时，Torvalds做出了迄今为止最明确的表态：
“AI是工具，和我们用的其他工具一样。它显然有用。一年前是否有用还可以争论，现在不行了。”
“我会非常大声地忽略那些试图阻止别人使用AI的人。”
“想要反AI项目的人，可以fork，或者离开。”
这段话被各路媒体反复引用，因为它同时堵死了两个方向的极端说法：内核允许开发者使用AI，现有质量门槛仍然保留。Torvalds画出的线非常清晰，工具可以用，但人必须签字负责；速度可以快，但质量门禁不能降
▲ 有评论者强调，有经验的开发者仍承担审查责任，并用AI提高效率
这也解释了为什么在rc7体量如此“吓人”的情况下，Torvalds仍然决定不推迟7.2的发布。他在邮件里的原话是：
“目前看不到推迟7.2发布的价值。除非出现严重情况，否则预期下周末发布。”
他不兴奋，但他也不恐慌 因为那些海量修复虽然多，但每一个都很小、都经过了人类维护者的审查和签字、都解决了真实存在的问题。量变没有引发质变的失控，至少目前还没有。
开源世界的“新常态”，到底新在哪里
让我们跳出Linux内核，看看更大的图景。
内核资深维护者Greg Kroah-Hartman（GKH）在3月的一次访谈中，描述了一个令人印象深刻的拐点时刻：
“大约一个月前，世界切换了。我们开始收到真实且有用的AI辅助报告。”
▲ The Register标题：“AI bug报告一夜之间从垃圾变成了合法货”
他拿cURL项目做了一个残酷的对比：对于cURL这样的小团队，AI生成的垃圾报告已经多到迫使项目停发bug赏金。内核团队更大、更分布式，“目前扛得住”，但GKH清楚地知道，所有开源安全团队都在面对同一个拐点。
区别只在于：你的团队够不够大，能不能消化AI扔过来的真实问题。
当AI审查工具的能力跨过了“经常说对”的门槛，全球基础软件的维护成本结构就会发生根本性的变化。大项目缺的是合并带宽，小项目缺的是人力，但无论哪种，维护者过载的症状都一样。
▲ 也有人表达了对“一切最终变成AI slop”的担忧
没有人明确下令启动这个循环
让我们回到Torvalds敲下那行字的那个周末。
他面前是一份铺满驱动、文件系统、网络协议栈、架构代码的巨大diff。NFS、amdgpu、arm64、USB、hwmon、Rust binder、mm、netfilter，几乎每个你听说过的子系统都有改动，但没有任何一个巨型特性补丁，只有海量的一行级修复汇流在一起。
这幅画面本身就是一个隐喻：AI没有写出任何激动人心的新功能，但它照出了无数个人类三十年来没注意到的裂缝。
而Torvalds，这个构建了全球数字基础设施的人，正在学习与一种全新的节奏共处，机器规模的发现，人类速度的消化，以及一个谁也不知道终点在哪里的反馈循环。
"Not exactly thrilled."
高兴不起来，但也回不去了
这就是2026年，开源世界的新常态。
