夜雨聆风
“这东西（AI）的训练者，骨子里大概没有我这么倔。”Linus Torvalds
Linux 之父 Linus Torvalds 的电脑，突然黑屏了。
屏幕一片漆黑，系统底层却还在疯狂狂奔，图形桌面的显示管理器（GDM）在后台陷入了死循环：启动、崩溃、再启动、再崩溃。
在开源界，Linus 平日主要负责审查和合并各子系统维护者提交的代码，极少亲自下场写底层驱动补丁。但这一次，幽灵 Bug 砸中了 Linux 掌门人自己的主力机。
这一次，Linus 还请来了一位当红助手：人工智能（AI）。
然而，在这场被 Linus 称为“来自地狱的调试任务”中，戏剧性的一幕发生了：AI 几次在海量日志和硬件死锁面前举了白旗，斩钉截铁地告诉 Linus：“这个问题在逻辑上是无解的、不可能修复的，我们还是放弃吧，老老实实写一份故障报告算了。”
▲ 开发者社群热议：连 AI 在 Linus 面前都不准放弃
换作普通开发者，可能真的就提单走人了。但站在它对面的，是 Linux 的缔造者。
Linus 根本不吃这一套他顶回了 AI 的放弃建议，逼着大模型继续给内核“插桩”、分析日志、重构补丁。
整整 24 个调试补丁，18 次内核强行重启，耗时一整天。
最终，Linus 在错综复杂的显存深渊里，揪出了那个潜伏两年的根因。修复方案短得令人窒息：
仅仅把代码里的一个 round_up()（向上取整），改成了 round_down()（向下取整）。
仅此一行，黑屏瞬间消失，系统起死回生。
显存里的“幽灵房客”：一行代码为何能让电脑黑屏？
为什么仅仅改动一个取整方向，就能引发一场显示灾难？
要理解这个 Bug，我们不需要成为显卡专家。你可以把显卡上的显存（VRAM），想象成一座巨大的智能仓储大厦。
▲ Linus 在 Commit 留言中用第一人称记录了这场“地狱级调试”
在这座大厦里，绝大部分货架都是公开对外出租的，用来存放游戏画面、桌面壁纸、浏览器窗口等数据。但是，现代 Intel 显卡为了节省传输带宽，自带了一套超高速的数据压缩机制（即 Flat CCS，压缩控制状态）。
这套压缩系统就像大厦的“物业机房”，必须在显存的最底端或者最顶端划出一块独立区域，专门存放硬件级别的压缩元数据。
显卡驱动的职责，就是精确丈量出物业机房的边界，并告诉系统内存分配器：“外来租客的货架，到这条红线为止，绝对不准越界！”
问题就出在两年前的一行代码上
当时 Intel 工程师为了迎合硬件规格书里关于“对齐到 128KB”的描述，写下了一个 round_up()（向上取整）。
在 Linus 的这台机器上，硬件保留区的起始物理地址落在两个 128KB 对齐点之间。代码本该在边界处向内收缩，把多出来的碎角直接划给保留区，确保安全；然而，一个向上取整，反而把分界线向外推了一把。
这一推，直接把原本属于硬件专用机房的 2KB 危险空间，当成普通显存大摇大摆地“租”给了操作系统。
▲ 最终进入 Linux 主线的修复 Commit：818bebeb63dd
灾难随即降临：
- 硬件根本不知情
：显卡压缩引擎以为这块区域依然归自己所有，在开机瞬间就霸道地往里面写入压缩标记（形如 0xcccc...的特征字节流）。 - 系统刚好踩中地雷
：冷启动时，负责画桌面的 Mesa 图形引擎，恰巧把最核心的三级页表（显存导航图）放进了这被错误出租的 2KB 里。 - 关键指针被硬件抹杀
：合成器刚准备绘制第一帧画面，一查导航图，指针全被硬件篡改了，瞬间遭遇内存段错误崩溃。 - 桌面陷入死循环
：GDM 发现桌面崩溃，立刻重启它；重启后又分配到这里，再次崩溃，用户在屏幕前看到的，就是死一般的无尽黑屏。
页表踩中这块区域会导致黑屏；普通图片踩中时，症状可能只是屏幕上随机闪烁的花屏。这种极度随机、硬件与软件交错践踏内存的特性，让它成了极难追踪的“幽灵 Bug”。
逼疯 AI 的 18 次重启：大模型为什么会喊“不可能”？
在常规认知里，大模型不知疲倦、知识渊博，但在真实的底层内核战场上，它暴露了最大的致命伤。
Linus 在提交记录中毫不避讳地还原了当时的真实场景：
“这是一场来自地狱的调试会话，AI 承担了绝大部分繁重枯燥的苦活，帮了大忙。
我原本想称它为‘不知疲倦的助手’，但事实上，AI 好几次直接断言这个问题是无解的、在逻辑上不可能解决，甚至建议我就此打住，去写一份故障报告。”
▲ Linus 在 dri-devel 邮件列表中向 Intel 驱动团队详细复盘
AI 为什么会绝望？
因为大模型的本质，是基于人类历史中位水平的经验概率来做预测的。
当 AI 面临这样一种死局：驱动代码看起来逻辑完全自洽、寄存器读取完全符合手册规范、硬件断言测试甚至全部绿灯通过，但现实中的物理机器却在冷启动时必定黑屏崩溃，
在平均水平的程序员语料库里，这种情境下的概率最优解通常只有两条：要么是 Intel 显卡硅片硬件损坏，要么是底层架构存在不可调和的逻辑缺陷，结论自然是：“无法修复，建议提 Issue 放弃。”
但 Linus 是离群值他深知代码与硬件之间从来没有玄学，只有逻辑的偏差。
“我怀疑，训练这些模型的人，骨子里大概没有我这么倔。”Linus 调侃道
Linus 坚决拒绝了 AI 的“认输”请求。他把 AI 按在执行层上：既然逻辑推不出来，我们就用物理测试把它逼出来！
Linus 下令，AI 写调试插桩代码； 编译内核，真机重启； 抓取崩溃瞬间的内存倾倒； 把被践踏的内存原始 HexDump 甩给 AI 分析； 排除嫌疑分支，再写下一个探针补丁。
▲ 开发者 Rupert Davies 点评：是人在辅助 AI，而非 AI 替代人类
整整 24 个补丁轮番上阵，经历了 18 次冷启动的残酷试错。当 Linus 终于在被释放给系统的显存页里，读出那一串显眼的 0xcccc 硬件压缩特征码时，真相大白了。
硬件与规范均无异常，错误发生在边界计算上：代码把安全防线往悬崖外移了一格。
把 round_up() 拍扁成 round_down()，所有风暴在瞬间平息。
最后，Linus 展现了他独有的黑色幽默与公道：他把最终撰写 Commit Message（提交说明）的任务，完完整整地交给了刚才数次劝他放弃的 AI。
从“讨厌AI垃圾报告”到“把AI当骡子使”：Linus 的技术清醒
这场戏剧性的调试战役既是一次经典的底层除虫，也给狂热的 AI 时代上了一堂生动的“人机协同示范课”。
就在几个月前，Linus 还曾对 AI 表达过极大的愤怒。
2026 年春季，全球大量所谓“AI 开发者”利用大模型批量扫描 Linux 内核源码，不加甄别地生成了成千上万份煞有介事的“安全漏洞报告”，铺天盖地砸进内核维护者的邮箱。
Linus 当时痛批这种行为是“毫无意义的空转”，投机者只负责点一下生成键，却把极其昂贵的辨别成本、代码审查成本甩给了人类维护者。
而在 2026 年 7 月，Linus 又在邮件列表里表明态度：Linux 不应被定义为反 AI 项目；持异议者可以自己 Fork 分支AI 是工具，它是否有用早已有答案
从反感 AI 生成的无脑垃圾，到在业余音频项目里体验 Vibe Coding，再到如今在内核级疑难杂症中亲自使唤 AI，Linus 用这一连串行动划清了一条极其硬核的技术界线：
- AI 是绝顶的“苦力加速器”
：它可以在几秒钟内为你写出繁琐的内核探测宏、格式化复杂的内存转储日志、甚至为你起草规范的工程文档。 - AI 永远不能替代“责任中枢”
：大模型缺少直觉与物理实体的痛苦感，也缺乏穿透表象的死磕意志。一旦遇到非典型的极端深水区，它会本能地按照训练概率劝你退缩。
▲ 开发者 Ali Kutlusoy 指出：成熟开发者把 AI 当工具，并且能看懂最终结果
这正是当下许多沉迷于“一键生成全栈项目”的浮躁风气所缺失的清醒。
如果完全依赖 AI，这个 Intel Xe 显卡的致命 Bug 将被永远打上“硬件不可解”的标签，沉睡在代码堆里；而如果完全拒绝 AI，即便强如 Linus，也可能要在无穷无尽的模板代码编写中多消耗数倍的精力。
顶级开发者会谨慎使用 AI
他们只是把 AI 当作一把功率奇大却偶尔会犯傻的电锯，手柄永远死死握在人类手中，切向代码最深处的神经中枢。
正如开源社区在那条爆火推文下写下的那句神评：
“在代码的世界里，连人工智能都不被允许在 Linus Torvalds 面前轻言放弃。”
