整理 | 郑丽媛
出品 | CSDN（ID：CSDNnews）
作为 Linux 之父，也是 Linux 内核最终的维护者之一，Linus Torvalds 已经很少亲自下场，为某个具体的硬件驱动写补丁了。
所以，当他上周亲自修复 Intel Xe 显卡驱动中的一个 Bug 时，本身就已足够令人意外。更何况，这个 Bug 的排查过程堪称“兴师动众”：为了找到问题，Linus 一共折腾了 24 个补丁、重启内核 18 次。
而最终的答案，却只是一行代码：一个原本写成 round_up() 的取整操作，应该改为 round_down()。
而真正让这次 Bug 修复迅速出圈的是，Linus 坦言：在这场漫长的排查中，AI 几乎承担了大量繁琐工作，甚至最后的 Commit 提交说明也是 AI 写的。
于是，一场关于 AI Coding、Linux、开源治理以及“程序员到底该不该夸 AI”的争论，也随之炸开了锅。
一场“地狱级”调试，最后只改了一行代码
事情发生在 Intel Xe 内核显卡驱动中。Linus 使用 Battlemage G21 显卡时，遇到了一个Bug：驱动对一部分内存边界的处理出现了偏差，导致原本不应该作为普通可用显存分配的 CCS（Compute Command Streamer）相关存储区域，被错误地暴露为可用 vRAM。
结果就是，硬件可能向本不该使用的内存区域写入数据。
如果这块内存恰好被分配给 GPU 页表，后果就会非常严重；就算没那么“倒霉”，也可能会随机破坏位图等数据，出现偶发性的屏幕异常——而这次最明显的症状，就是 GDM 显示管理器不断崩溃、重启，进入循环。
Linus 最终发现，这个 Bug 根源可追溯到一次 CCS 偏移量计算：代码将地址向上取整到了 128KB 边界，而实际上应该向下取整，即错误的取整方向导致一小块本应保留的内存被“多算”进了可用显存范围。
最终修复本身相当“简单”：把 round_up() 改成 round_down()。然而，找到这一行代码的过程，却一点都不简单。
AI：我建议放弃；Linus：继续查
Linus 在 Commit 中给出了一个非常有意思的描述。他将这次经历称为“debug session from hell”，即一场“地狱级调试”，同时也明确表示，AI 在其中“提供了巨大帮助”，承担了大量繁琐工作。
不过，这个 AI 助手没有想象中那么“配合”。
Linus 透露，调试过程中 AI 曾多次想要放弃：“我本想称它为不知疲倦的好帮手，但这 AI 好几次直截了当地说‘这不可能，无解了，咱们直接写个报告吧’。”他对此调侃道：“我猜，训练这玩意儿的人，大概没我这么倔。”
于是，这场人机协作变成了一种颇有意思的模式：AI 想放弃但 Linus 不让，并强制 Push 它继续，AI 就按要求添加调试代码、分析结果，再根据新的结果扩大或缩小排查范围。
最终，为了定位一个只需修改一行代码的问题，Linus 增加了 24 个用于补充调试信息的补丁，还进行了 18 次内核启动测试，就连最终的 Commit 说明也是 AI 写的：
“虽然 AI 好几次准备放弃，但只要我坚持继续，它就会不断添加调试代码，并认真分析结果。所以，该给的功劳还是要给，上面这段 Commit 信息也是让AI帮我写的。”
Linus 没点名是哪款 AI，反而成了焦点
有意思的是，Linus 在整个 Commit 中始终没有透露自己究竟使用了哪一款 AI。这很快也引发了网友调侃。
有人认为，这反而是一件好事：“他没有点名具体工具，因为我们都知道，如果他说出来，接下来会发生什么。”还有网友根据 AI 在调试过程中表现出的“多次宣告问题无解”、“直接表示不知道后面该怎么做”等行为，说自己大概能猜到是哪个 AI 工具了。
相比“到底是哪款 AI”，还有另一个问题值得关注：为什么 Linux 社区里，Linus 用 AI 会引起如此强烈的反应？——答案是，Linus 最近与 AI 的关系，本就已经相当敏感。
今年以来，他已多次公开表达自己对 AI 工具的支持态度，并。与此同时，Linux 内核近期也出现越来越多由 AI 辅助代码审查发现的问题和修复，这让维护者不得不面对 AI 带来的效率提升，以及随之而来的额外审查压力。
因此，当 Linus 不仅使用 AI，还在 Commit 中专门写下“AI 帮了大忙”时，部分社区成员彻底不淡定了。
社区炸锅：为啥要夸工具？Linus 带头违反 AI 政策了？
在评论区，不少人对 Linus 此举表现出了强烈反感。
一位网友直接质问 Linus：“我从没见过厨师夸菜刀、建筑工人夸砖头的，凭什么你修个 Bug 就要夸 AI？工具什么时候需要被夸奖了？”——在他看来，Linus 公开肯定 AI 的行为，已经不只是个人使用工具，而是在为 AI 进行免费宣传。“以前对你创建 Linux 和 Git 的那份敬意，现在随着你越来越无底线地吹这些东西，正在一点点消失。”
还有人翻出了 Linux 内核官方的 AI 编码助手政策文档，指出该文档明确要求 AI 贡献必须包含 Assisted-by 标签进行归属标注，并规定提交者须对 AI 生成的所有代码承担全部法律责任：“说白了，Linus 这已经‘违反了 Linux 自己的 AI 政策’。”
甚至，还有人进一步质疑 Linux 的 QA 流程：“我大半辈子都在搞嵌入式，实在想不通这种 Bug 当初是怎么被合入代码库的。更离谱的是，居然没有一个确定性的 QA 流程能让它提前暴露出来，非要搞出这么一场‘地狱级调试’的大戏。”
除此之外，部分网友也把矛头指向了 AI 更广泛的社会成本。“聪明人本来靠自己也能解决的问题，现在靠 AI 加速解决了——但为此付出的代价是污染水源、毒化空气、腐蚀大众的认知能力。这一切是否值得，只有时间能给出答案。”
而这些情绪背后，实际上是 AI 进入开源世界后越来越明显的一种分裂：
一边认为：能发现 Bug、能提高效率，AI就是好工具。
另一边则担心：AI 工具本身的效率提升，是否正在把成本转移给维护者、环境和整个技术社区？
不过，其实从这次就可以看出，其实 Linus 用 AI 的方式并不是大家想象的“AI 自动编码”：AI 没有独立解决问题，甚至多次判断问题无法解决，最终坚持排查方向、判断实验结果、决定继续还是停止的人，还是 Linus 自己。
至少目前看来，无论喜欢还是厌恶，在 Linux 内核的开发流程中，AI 的身影已经越来越难以忽视。对此，你又是什么看法呢？
参考链接：https://www.phoronix.com/news/Linus-Torvalds-Debug-AI
最后，说一件事
2026 奇点智能技术大会与C++及系统软件技术大会 终于要和大家见面了。
11 月 20-21 日·北京，奇点智能研究院联合 CSDN，把两场技术大会放在了同一个时空里：
奇点智能技术大会（始于 2016）——聊大模型、AI Native、企业级 AI 落地、多模态与世界模型；
C++ 及系统软件技术大会（始于 2005）——聊现代 C++ 演进、AI 算力与推理优化、高性能低时延系统。
为什么要放在一起？因为我们越来越相信——上层 AI 应用的爆发，离不开底层系统软件的支撑；而底层技术的演进方向，也正在被 AI 重新定义。
这次大会汇聚 70+ 位技术专家、18 个主题、1000+ 同行到场。
如果你也在这些方向上做研究、做产品、做工程，别错过。
