Linus Torvalds 于当地时间 10 月 4 日发布了 Linux 7.3 的第六个测试版（rc6）。在邮件列表中，他特别提到一个变化：随着人工智能与大语言模型（LLM）越来越多地参与内核开发，「AI 新常态」已经成为当前 Linux 开发周期的一部分。

本周回归「正常」节奏

相比前一周较为特殊的代码变更统计，本周整体恢复常态，驱动修复重新占据大头。Torvalds 表示，本周没有出现异常情况，代码变更统计已回到「约一半来自驱动修复」的常见状态。驱动侧涉及图形处理器（GPU）、网络、USB、TTY、IIO（工业输入/输出）、音频等多个子系统，整体呈现分散修复的特征。

他同时指出，本次提交数量也处于正常范围，只不过这是新的「AI normal」——大量小型错误路径处理修复正在进入内核代码树。此前几个 Linux 7.3 测试版同样出现了较多由人工智能或大模型发现问题、或辅助生成的补丁，使整个开发周期的修复活动明显更活跃。

除了驱动，还改了什么

除驱动修复外，Linux 7.3-rc6 还包含常规架构更新，其中主要与 KVM（基于内核的虚拟机）相关；核心网络代码也有修复，文件系统方面以 SMB 客户端工作为主，同时加入了一批新的内核自测（selftests）。

硬件支持方面，本版加入了对 Turtle Beach VelocityOne Race 方向盘与踏板系统的支持。该设备此前在 Linux 下只能进行基础的人机接口设备（HID）输入且存在一些问题，此次通过 hid-universal-pidff 驱动补上相应设备编号后，可获得更完整支持。该套件面向赛车模拟游戏，海外售价约 649 至 700 美元（按当前汇率约合 4355 至 4697 元人民币）。

与此同时，Linux 7.3 撤回了此前加入的 Logitech Bolt 接收器 HID++ 支持，原因是用户反馈问题过多。相关 HID 更新还包含英特尔 THC 驱动的缓冲区溢出修复，以及其他设备支持与缺陷修复。

AI 如何走进内核开发

Linux 7.3 整个开发周期已多次出现人工智能与大模型参与代码审查和缺陷发现的情况。在 rc3 阶段，就有大量 AI/LLM 相关修复进入代码树；到了 rc4 与 rc5，开发者仍在持续处理 AI 发现的问题，同时也出现了部分由 AI 辅助生成的内核补丁。

不过 Torvalds 并未因此认为 7.3 开发出现异常。他使用「AI normal」一词，实际是在描述一种已成常态的开发模式：AI 工具带来更多代码检查、缺陷发现与补丁提交，同时也意味着维护者要处理更多细碎的修复工作。

发布时间表与下游影响

Torvalds 表示，下周恰逢年度维护者峰会与 Linux Plumbers Conference，他本人及多名维护者都将出差，因此 rc7 的代码统计可能有所不同，但预计不会影响 Linux 7.3 的发布时间表。按照目前进度，稳定版预计在 10 月中旬发布。

对下游发行版而言，这一时间节点已有直接影响：Canonical 此前已将 Ubuntu 26.10 的目标内核从 Linux 7.2 调整为 Linux 7.3，因此 7.3 稳定版的发布时间，也将决定后续 Ubuntu 26.10 的最终内核基础。

对长期跟踪内核的开发者来说，7.3 周期释放出的信号很清楚：AI 辅助不再是个别实验，而是已经嵌入到日常的代码审查与缺陷修复流程里。当「AI normal」成为常态，如何平衡自动化带来的效率与维护者的人工把关，将是接下来若干个内核版本都要面对的课题。

主角：25 万行的 CReSS 气象代码

论文的案例对象是 CReSS，一套用 Fortran 写成的遗留天气模拟代码，规模超过 25 万行。这类程序不是普通的旧代码——它们是长期通过与观测数据反复比对、在领域研究中积累起科学可信度的资产。把它们搬到以 GPU 为核心的高性能计算系统，既要适配新架构，又不能丢掉原有的科学有效性。

工作流：先验证，再移植

研究团队设计了一套「以验证为中心」的 AI 辅助工作流。智能体先抽取代码里的 OpenMP 并行区域，再从有物理意义的模拟状态生成基于数据转储的内核基准，接着施加 OpenACC 变换完成 GPU 化，最后通过和参考数据的逐元素比对做数值校验。

换句话说，每一步移植都要能「对账」：新代码算出来的结果，必须和原来的老代码逐点一致，否则就不算成功。

结果：162 个内核通过验证，整体提速 5.1 倍

在以真实台风模拟为案例的测试中，这套工作流为 162 个目标内核产出了通过数值验证的 GPU 实现，并在可接受的工时范围内，拿到了应用级 5.1 倍的加速。

这意味着，原本在 CPU 上跑得很吃力的长期天气模拟，有望在不牺牲科学准确性的前提下显著提速。

意外收获：揪出 5 处数值隐患

更值得关注的是，工作流在验证环节发现了 5 个内核出现了数值偏差——根源在于浮点运算与内建函数的差异，包括阈值敏感的分支发散，以及相消效应带来的精度损失。这些问题在肉眼比对下极难发现，却被「逐元素对账」机制捕捉到，并反馈给了程序开发者。

启示：AI 移植不只是写代码

论文指出，大规模科学代码的 AI 辅助移植，难点不在代码生成本身，而在贯穿多轮会话的上下文管理、运行时状态的重建，以及从微小的静态分析疏漏中恢复。

对这类需要严格数据对账的遗产系统来说，真正关键的不是「让 AI 把代码改完」，而是设计一套以验证为先的工作流。AI 在这里更像是严谨的工程搭档，而不是甩手就用的自动转换器。

来源：arXiv:2608.13122（Tetsuya Hoshino 等，2026）