Linus Torvalds 已经很少亲自下场给具体硬件驱动写补丁了。所以当他上周亲手修一个 Intel Xe 显卡驱动 Bug 时，本身就很罕见；更罕见的是这场排查的阵仗——24 个补丁、18 次内核重启，最后的答案却只是一行代码：把 round_up() 改成 round_down()。
而真正让这件事出圈的，是 Linus 坦言：这场"地狱级调试"里，大部分繁琐工作都是 AI 干的，连最终 Commit 说明都是 AI 写的。于是，关于 AI Coding、Linux 开源治理、以及"程序员该不该夸 AI"的争论，在社区里彻底炸开。对关注 AI 工程的人来说，这可能是"人在回路调试"最真实的一次现场演示。
一个让显示管理器崩溃循环的 Intel Xe 驱动 Bug
Bug 出在 Intel Xe 内核显卡驱动里。在 Battlemage G21 显卡上，驱动对内存边界的处理出现偏差：原本不该作为普通可用显存分配的 CCS（Compute Command Streamer）相关存储区域，被错误暴露为可用 vRAM。硬件可能向不该写入的内存区域写入数据；如果这块内存恰好被分配给 GPU 页表，后果会很严重，就算运气好也可能随机破坏位图、出现偶发性屏幕异常。最明显的症状是 GDM 显示管理器不断崩溃、重启、陷入循环。
修复只需一行，找到它却用了 24 个补丁、18 次重启
根因追溯到一次 CCS 偏移量计算：地址被向上取整到 128KB 边界，而正确做法是向下取整。错误的取整方向让一小块本应保留的内存被"多算"进可用显存范围。修复本身简单到极致——把 round_up() 改成 round_down()。但为了定位这一行，Linus 加了 24 个补充调试信息的补丁，做了 18 次内核启动测试。
AI 想放弃，Linus 不让
这场人机协作最有意思的地方在于分工。Linus 称这次经历为"debug session from hell"（地狱级调试），明确表示 AI 提供了巨大帮助、承担了大量繁琐工作。但这个 AI 并不"听话"：它好几次直截了当地说"这不可能、无解了，咱们直接写个报告吧"。Linus 调侃说，训练它的人大概没他这么倔。于是模式变成：AI 想放弃，Linus 强制它继续，AI 按要求加调试代码、分析结果，再根据新结果扩大或缩小排查范围。连最终的 Commit 说明也是 AI 写的，Linus 明确把功劳记在它头上。
用的是哪款 AI？未点名反而成了焦点
Linus 全程没有透露自己用了哪款 AI，这本身就成了话题。有人觉得这是明智之举——一旦点名，接下来会发生什么可想而知；也有人根据 AI"多次宣告问题无解""直接表示不知道下一步怎么办"的表现，猜了个八九不离十。更深的问题在于：为什么 Linus 用 AI 会引发这么强的反应？今年以来他多次公开支持 AI 工具，明确反对把 Linux 变成"反 AI"阵地；而内核里由 AI 辅助代码审查发现的问题也越来越多。当项目创始人不仅用 AI、还在 Commit 里专门写下"AI 帮了大忙"，部分社区成员觉得这是踩线了。
政策、QA，以及被摊开算的成本账
争论分好几层。一派引用内核官方 AI 编码助手政策：要求 AI 贡献必须带 Assisted-by 归属标注，提交者须对 AI 生成的全部代码承担法律责任——按这标准，Linus 相当于违反了自己项目的 AI 政策。另一派攻击 QA 流程：一个一行取整错误怎么过的代码评审、合并进驱动？为什么没有确定性的测试提前把它暴露出来？还有一派把矛头指向 AI 更广泛的社会成本：聪明人本可以自己解决的问题，现在靠 AI 加速解决了，代价却是能耗、水耗，以及一位评论者说的"腐蚀大众的认知能力"。分歧的本质很简单：一边看到的是更快发现 Bug 的工具，另一边担心 AI 的效率提升正在把成本悄悄转嫁给维护者、环境和整个社区。
这暴露了 AI 编程的真实工作方式
最重要的一点其实和"用的哪款模型"无关。这不是"AI 自动驾驶式写代码"——AI 没有独立解决问题，它甚至多次判断问题无解；坚持继续排查、判断实验结果、决定何时停止的，始终是 Linus 本人。这才是 2026 年 AI 辅助工程的真实样貌：一个不知疲倦、但偶尔气馁的 AI 干粗活，人掌握判断、方向与最终结果。同时这也是一个清晰的信号：AI 正在进入核心基础设施的维护——那种一行取整错误就可能让数百万台机器内存损坏的代码。这与 全程直播训练 535B 大模型 是同一类信号：AI 正从"写 demo"走向"维护所有人依赖的系统"。
工程师能带走的三条经验
第一，把 AI 当调试副驾驶而不是预言机：给它带插桩的构建、让它收窄排查范围，但方向判断和终止决定留在人手里。第二，把"这不可能"当作一条数据而不是结论——Linus 正是顶着这种输出继续推进的。第三，归属要诚实：遵守项目对 AI 贡献的政策（内核要求 Assisted-by 标注），作为提交者对所有 AI 生成代码负责。另外，如果这次事件暴露了你自己 QA 的薄弱点，就趁早补上：一个能活过评审的一行边界错误，通常说明缺的不是 AI，而是边界测试。这也是观察 AI Agent 从个体智能走向系统智能 的一个绝佳案例。
FAQ
Linus Torvalds 到底用了哪款 AI 修 Bug？
他没有点名。根据 AI"多次宣告问题无解"的表现，网友各有猜测；Linus 刻意不提，连描述整个过程的 Commit 说明都是 AI 写的。
这次修 Bug 一共用了多少补丁、重启了多少次？
24 个调试补丁、18 次内核重启，最终只改一行代码：把 Intel Xe 驱动的 CCS 偏移量计算从 round_up() 改成 round_down()，这个取整方向错误让保留内存被误当成可用 vRAM，导致显示管理器崩溃循环。
在 Linux 内核里用 AI 算违规吗？
不算禁用，但有规则：内核 AI 政策要求 AI 贡献带 Assisted-by 归属标注，且提交者对 AI 生成的代码负全部法律责任。Linus 这次事件引发的争论，核心就是公开夸 AI 是否越过了政策想划的那条线。
