【编辑观察】最近各位是不是都爱用 AI 小助手写代码或查错？虽然效率确实高了不少，但在真正的底层硬核开发甚至操作系统级别的项目里，AI 到底够不够格当“赛博打工人”？今天咱们就来看看，一位 Linux 内核开发大佬是怎么被 AI 代码“折磨”的。

找Bug小能手：AI 精准揪出性能瓶颈

对于 Linux 内核开发者来说，日常工作就是无限循环的“改代码 → 编译 → 发现Bug → 再改”。但由于 Linux 内核体量实在太庞大，即使现代电脑动辄拥有几十个 CPU 核心，在构建流程中依然有很多只能“单线程排队”的串行任务。前面的任务卡着，后面的核心就只能干瞪眼。

为了加快编译速度，长期参与 Linux 内核开发的 Arm 工程师 Lorenzo Stoakes 决定摇人——不对，是摇 AI 来帮忙。

不得不说，AI 在“翻旧账”和找问题上真没让他失望。面对庞杂的构建信息，这位没有披露名字的大模型迅速筛出了暗藏在流程中的多个性能“排队点”，甚至把后续的运行构建、测试、调试和分析环节也一并包办了。

但就在 Stoakes 以为可以进入“输入一行 Prompt，AI 自动改完代码”的摸鱼时间时，画风却突变了……

代码“惨不忍睹”：最终还得人类来擦屁股

当 AI 开始写代码时，Stoakes 感到了一阵头疼。他在提交的补丁说明中，用了一个非常直接且充满感情的词来形容 AI 写出的代码——“hideous”（丑陋至极、惨不忍睹）。

事实证明，尽管 AI 生成了大量代码，但能用的寥寥无几，其代码结构和质量根本达不到 Linux 内核极其严苛的标准。

于是，这场本该是“AI 帮程序员修 Bug”的自动化美梦，最终变成了**“AI 负责在图纸上乱画，工程师坐下来逐行重写”**的苦力活。Stoakes 不得不对其中大部分代码进行了回炉重造，顺带把提交信息、补丁说明和代码注释也彻头彻尾地大修了一遍。

折腾没白费：编译最高疯狂提速 90%

虽然过程狼狈，连呼 AI 代码“辣眼睛”，但好在 AI 找出来的 Bug 确实句句在理。

在经过 Stoakes 本人大量审查、重写代码，并手动验证了构建正确性和内核运行状态后，他最终提交了一组包含 23 个补丁的优化方案。这次优化的核心目标就是干掉不必要的串行等待，把多核并发利用到极致。

成绩单非常亮眼，而且在不同硬件和内核配置下都获得了实打实的提速：

  • 开启全部模块的 allmodconfig 构建，速度最高提升 36%
  • 增量构建，速度最高提升约 70%
  • noop 构建（不需要真正重编大量内容的情况），速度最高狂飙约 90%

别看这些只是数字，对于天天和内核打交道的开发者来说，每天不用趴在桌边多等那几十分钟编译，绝对是实实在在的幸福！

最后一公里，依然属于程序员

其实，被 AI “军训”的并不止 Stoakes 一个人。前不久，Linux 之父 Linus Torvalds 在排查 Intel 显卡驱动 Bug 时，被 AI 连声忽悠称“这题超纲，不可能解决”，甚至劝他干脆直接写份报告放弃。最终 Linus 靠自己死磕 18 次重启，才发现只是一个函数该写 round_down() 却写成了 round_up()，只改了一行代码就搞定了。

Linus 事后的评价也极具代表性：AI 确实适合干翻找日志、排查基本线索的“苦力活”，但到了最后排雷拔引信的时候，必须由有经验的程序员亲自操刀。

在底层开发领域，“代码能跑起来”只是最低要求，怎么兼顾性能、结构、可维护性和社区规范才是重头戏。目前的 AI，绝对是一个绝佳的副驾和雷达，但想让它独自握方向盘？至少现在这口天降大锅，依然得靠我们程序员自己含泪背下！