夜雨聆风
你能想象吗？在科技界最硬核的 Linux 内核代码库里，刚刚上演了一场极其魔幻的“人机大战”。
对战双方，一边是脾气火爆、写出 Linux 和 Git 的祖师爷 Linus Torvalds；另一边，则是被无数人吹上神坛的 大语言模型（AI）。
在这场长达数天的“地狱级调试”中，发生了一幕足以载入计算机史册的黑色幽默：
面对诡异莫测的硬件黑屏 Bug，AI 多次彻底崩溃，甚至苦苦哀求 Linus：“这个问题在逻辑上是不可解的，我们放弃吧，写个报告收工算了。”
而 50 多岁的 Linus 根本不吃这一套。他按着 AI 的头，硬逼着它反复写调试补丁、分析崩溃日志。在经历了 24 个调试补丁、18 次内核启动 之后，Linus 终于揪出了潜伏在驱动深处的幽灵，
最终修复图形界面瘫痪的代码，仅仅只有一行：把一个向上取整函数，改成向下取整。
Bug 解决后，Linus 展现了老派黑客的极致浪漫与嘲讽：他让那个中途疯狂劝他放弃的 AI，老老实实写完了这份内核补丁的官方提交说明（Commit Message），而他自己在末尾附上了一段让全网开发者笑疯的独家吐槽。
▲ 知名开发者 Mark Kretschmann 总结了这场极具戏剧性的内核调试
显卡暴毙、黑屏死循环：一台新电脑引发的“血案”
事情的起因，是 Linus 换上了一块搭载 Intel 最新架构的 Battlemage G21 独立显卡。
然而，新卡插上，机器一开，灾难发生了
系统每次冷启动，屏幕都会瞬间陷入死寂的纯黑。但诡异的是，整台电脑其实并没有死机，后台的各种服务还在正常运转，只是负责把图形界面画出来的显示管理器（GDM），陷入了无限崩溃、无限重启的死循环。
偶尔几次运气好，重启显示管理器能亮屏；但只要一关机重新开，必定又是漆黑一片。
▲ 科技媒体 It's FOSS 报道 Linus 借助 AI 修复 Linux 内核 Bug
在 Linux 内核开发界，这种“看起来随机、时好时坏”的幽灵 Bug 是所有程序员的噩梦。
要理解这个 Bug 有多搞人心态，我们不妨用一个极通俗的比喻：
想象一下，显卡的物理显存（VRAM）就像开发商规划的一大片宅基地。大部分地皮可以用来盖普通的商品房（存放用户的应用程序、窗口画面、图形页表）。
但在显存的最深处，显卡硬件自己悄悄留了一小块“压缩元数据专用区”（行业里叫 flat CCS）。这块地皮是显卡硬件的“私人自留地”，硬件会自动往里面写压缩索引，普通软件绝对不能碰。
问题就出在 Linux 内核的 Intel Xe 显卡驱动里。驱动在算这块“自留地从哪开始”的时候，数学公式算歪了一点点。
结果，这块本该留给硬件的禁区，有大约 2KB 的地皮，被驱动错误地当作了“空闲商品房”，大摇大摆地分发给了桌面合成器。
桌面合成器刚把至关重要的虚拟内存三级页表写进这 2KB 地皮里，显卡硬件的压缩引擎就在完全不知情的情况下，一口气把这一段数据给抹平改写了！
地基被偷拆，楼瞬间坍塌 图形界面只要一启动，读到的就是一堆乱码，当场暴毙，屏幕瞬间黑掉。
“这题无解，放弃吧！”被祖师爷逼疯的 AI 打工人
对于如今的 Linus 来说，亲自下场写显卡驱动补丁已经极其罕见。近年来，他更多是作为掌舵人审阅合并别人的代码。
但这一次，被惹毛的祖师爷决定亲自肉搏。他叫来了一个 AI 编程助手，把系统日志、寄存器转储一股脑扔给 AI，开启了长达数天的连环排查。
不得不说，AI 在某些方面确实是个“神级苦力”。它能以人类难以企及的速度，帮 Linus 一遍又一遍地在内核源码里插入调试代码（Debug Print）、编译、抓取寄存器数据、然后迅速解析海量日志。
但当调试推进到深水区，戏剧性的一幕发生了。
显卡底层的问题极其反直觉：寄存器读数似乎全是对的，断言检查也没有报警，但内存就是会被神秘篡改。
在反复推演了几轮逻辑之后，AI 的“打工人摆烂基因”彻底发作了。
面对逻辑闭环的死胡同，AI 开始在对话框里疯狂劝退：
“这个问题不可能解决，也无解（impossible and unsolvable）。”“我们别再排查了，直接写一份报告吧。”
▲ Linus 在 Commit 末尾的括号里写下了这段传世吐槽
看着在眼前疯狂“打退堂鼓”的 AI，Linus 展现了顶级黑客那近乎执拗的傲骨。
Linus 事后在提交记录里毒舌地吐槽道：
“我原本想把 AI 称作不知疲倦的助手，但它在过程中多次宣称这个问题不可能解决，并建议我别再排查、直接写报告。我强烈怀疑，这些 AI 模型是由‘没我这么固执（stubborn）的人’训练出来的。”
祖师爷根本不管 AI 的哀求他直接无视了“放弃”的建议，揪着 AI 的领子继续逼它吐出新的排查代码。
在连续干翻了 24 个调试补丁、硬生生扛着机器重启了 18 次内核之后，Linus 终于在保留内存的残骸里，抓到了显卡硬件压缩引擎留下的“指纹”，一串形如 0xcccc... 和 0xcc7700... 的交替十六进制特征码！
凶手当场落网：驱动把硬件的地皮划错了，与玄学硬件故障无关！
价值千金的 1 行代码：向上取整 vs 向下取整
当真相大白的那一刻，整个内核社区的开发者都倒吸了一口凉气。
让 Linus 经历 18 次启动排查、让 AI 绝望到想辞职的罪魁祸首，竟然是两年前留下的一个函数调用：round_up()。
2024 年，Intel 工程师在适配这块显卡时，为了满足硬件规格书中“压缩视图需要 128K 对齐”的要求，顺手写了一个向上取整（round_up）。
我们用小学算术就能看懂这个致命错误：
显卡硬件报告，压缩自留地的实际起始地址在 0x3fafff800。驱动执行了 round_up(..., 128K)，直接把边界向上对齐到了下一个 128K 边界0x3fb000000。驱动以为自己在做“规范对齐”，却忘了这个变量的业务含义是“可用显存到此为止”！ 这一向上取整，直接把 0x3fafff800到0x3fb000000之间这块明明属于压缩引擎的 2KB 敏感区域，“大方”地划给了操作系统。
Linus 的修复方式极其优雅而无情：把 round_up（向上取整）改成 round_down（向下取整）。
▲ 核心修复：将 round_up 改为 round_down，并修正断言检查
宁可向下取整，少给操作系统分 4KB 的显存，也绝不多占硬件一寸地盘！
困扰新一代显卡的黑屏顽疾，瞬间烟消云散。
伤害性不高，侮辱性极强：让认输的 AI 来写结案报告
抓到根因并修完代码后，Linus 展现了极具幽默感的名场面。
他没有自己动手写那一长串专业的内核提交说明，而是把键盘一推，直接对刚才那个劝他放弃的 AI 说：“来，你把这个问题的前因后果、函数调用、页表损坏机制给我写成一份正式的 Commit Message。”
AI 乖乖照办，洋洋洒洒起草了一篇极高水平的技术论述，从硬件 L3 节点缩放一直讲到 Mesa 虚拟机的页表机制。
而在 AI 起草的技术说明最后，Linus 亲手打上了一个括号，把 AI 中途如何“摆烂劝退”、自己如何“按头死磕”、最终 18 次重启破案的过程，完完整整地刻在了 Linux 官方源码树中：
(AI 写了上面的正式提交说明，但在此之前它多次告诉我这不可能……我猜训练它的人没我这么倔。)
洞察：当所有人都在吹嘘 AI 时，Linus 给我们上了最深刻的一课
这起充满戏剧色彩的真实事件，在 Hacker News、Slashdot 和 X 上引发了海啸般的讨论。
在今天这个“AI 崇拜”与“AI 替代论”甚嚣尘上的时代，Linus 用这 18 次重启和 1 行代码，撕开了当下软件开发中最核心的真相：
1. AI 善于“吞吐”，但毫无“直觉”与“信念”
大语言模型本质上是概率机器当它在现有的逻辑空间里推演遇到冲突时，它的数学期望会迅速收敛到“此路不通”。对 AI 来说，“劝用户放弃、写个 Bug 报告”是计算代价最小、最符合安全对齐逻辑的局部最优解。
但人类顶级专家的直觉在于：现象既然存在，物理世界就必定有因果。 所谓的“不可能”，只是因为人类或者 AI 预设的前提假设错了。
2. AI 的角色：由人类主导
在整个调试过程中，AI 的表现不可谓不惊艳，它干完了大量繁琐、恶心、耗时的脚手架代码与日志过滤。如果没有 AI，24 个补丁和 18 次重启可能要耗费人类更长时间。
但指明排查方向、质疑现有断言、决定何时否定假设、并在 AI 绝望时死死咬住不放的，永远是坐在屏幕前的人类大脑。
正如科技博主们打的比方：
“纯粹的菜鸟程序员在听到 AI 说‘此题无解’的第一秒就会关机走人；老练的黑客，会把 AI 的‘不可能’当成突破认知的号角。”
在 Linus 身边，连 AI 都不允许放弃。 这或许就是这个时代，人类专业精神与工具演进之间，最热血也最迷人的注脚。
