你让 AI 帮忙找 Bug，可能找得挺准；但你要让它自己修 Bug，代码可能“惨不忍睹”——最近，Arm 工程师、长期参与 Linux 内核开发的 Lorenzo Stoakes 就碰上了这么一件事。

为了加快 Linux 内核编译，他找来了大模型帮忙排查问题，结果 AI 还真没让他失望：隐藏在庞大构建流程中的多个性能瓶颈被揪了出来，连后续的构建、测试、调试和分析也一起包办了。但轮到 AI 写修复代码时，Stoakes 的评价却非常直接：“它生成了很多代码，其中很多都惨不忍睹。”

于是，一场看似“AI 帮程序员修 Bug”的工作，最后变成了另一种画风——AI 负责找问题，人类负责把 AI 写出来的代码重新收拾一遍。

好在，这一通折腾并没有白费。经过 Stoakes 大量审查、重写和人工验证后，最终提交的 23 个补丁让 Linux 内核构建速度出现了相当明显的提升：开启全部模块的构建最高快了 36%，增量构建最高快了约 70%，部分 noop 构建甚至快了约 90%。

Linux 编译慢，问题可能不是 CPU 不够多

对于 Linux 内核开发者来说，编译内核是一件再普通不过的事情：改完代码，编译 → 发现Bug，再改 → 重新编译、测试，然后继续改——问题是，Linux 内核实在是太大了。

现代 CPU 动辄拥有十几个甚至几十个核心，理论上可以同时处理大量编译任务。但实际情况并没有这么理想：Linux 内核的构建流程中，仍存在不少只能单线程执行的任务。

简单理解的话，就是电脑明明有一大群 CPU 核心在待命，但某些任务只能一个接一个处理。前面的任务没结束，后面的工作就只能排队，其他 CPU 核心也只能闲着。

Stoakes 这次做的事情，就是把这些“排队点”一个个找出来，然后想办法让更多工作并行执行。这并不是简单地修改某一个函数，而是涉及 Linux 构建系统中的多个关键组件。

最终，他提交了一组包含 23 个补丁的优化方案，涉及 Kbuild、kallsyms、modpost、objtool、mksysmap，以及 Linux 内核的 Rust 构建系统等多个环节。

特别之处在于：这一次，Stoakes 没有完全靠自己，而是让 AI 成为了他的一个重要帮手。

AI 找 Bug 很快，但代码写得让人“头疼”

Stoakes 并没有公开他用的是哪款 LLM。而对于这种规模庞大的工程，AI 的优势其实很明显：它可以快速翻查大量代码和构建信息，把可能值得关注的地方先筛出来。

根据他的描述，AI 主要参与了几个环节：首先分析构建流程、寻找性能瓶颈，然后尝试提出改进方案；后来，它还参与了构建运行、测试、调试和结果分析。

而真正让 Stoakes 感到头疼的地方是：AI 开始写代码了。

Stoakes 在补丁说明中用了一个相当直接的形容词——“hideous”，也就是“丑陋”、“惨不忍睹”。按照他的说法，LLM 生成了大量代码，其中相当一部分质量很差。因此，他对其中很多代码进行了重写，同时还大幅修改了提交信息、补丁说明和代码注释。

所以，这次优化对 Stoakes 而言，并不是一次“输入一句 Prompt，AI 自动写完 23 个补丁”的自动化开发。更像是 AI 先把一堆可能的答案扔到桌面上，然后工程师坐下来逐个检查：哪些思路靠谱，哪些代码能用，哪些必须重写，哪些干脆直接扔掉。

最终留下来的，才是能够进入 Linux 内核开发流程的补丁。

23 个补丁，换来了最高 90% 的提速

虽然过程有些狼狈、AI 代码也确实让 Stoakes 头疼，但好在它发现的 Bug 的确有价值。

经过 Stoakes 人工修改和验证后，他一共提交了 23 个补丁，核心目标就是减少构建过程中不必要的串行等待，提高不同任务之间的并行程度，最终也带来了相当可观的性能提升：

● 开启全部模块的 allmodconfig 构建速度最高提升 36%；

● 增量构建最高提升约 70%；

● noop 构建最高提升约 90%（可简单理解为“不需要真正重新编译大量内容”的构建场景，因此提升幅度尤其夸张）。

而且，这些提升并非只在某一台机器上出现。Stoakes 表示，在不同硬件以及不同内核配置下，都观察到了明显的构建速度提升。

对于普通用户来说，“快了 36%”可能只是一个看起来不错的数字，但对于每天反复编译、测试 Linux 内核的开发者来说，意义就完全不同了：他们可能一天之内反复修改代码、编译、测试，再修改、再编译，如果每轮构建都能少等几分钟，一天下来就是相当可观的时间。

AI 能帮忙，但“最后一公里”还是程序员的

有意思的是，Stoakes 并没有因为大量使用 LLM，就把最终验证也交给 AI。

他明确表示，应用这组补丁后，他亲自检查了生成的内核，包括构建是否正确、内核运行是否正常，以及性能提升是否真实存在。此外，由于整个开发过程中大量使用了 LLM，这些提交还带有 Assisted-by 标签，用于标明 AI 在其中参与了工作。

其实，Stoakes 的这个发现、或者说抱怨，放在 Linux 社区里并不罕见。

不久前，Linux 之父 Linus Torvalds 也经历了类似事件：他在排查 Intel Xe 显卡驱动的一个 Bug 时，AI 反复声称问题“不可能解决”，建议直接写报告了事。Linus 没放弃，继续让 AI 添加调试代码、分析结果，最终在 24 个调试补丁、18 次内核重启之后，找到了答案：一个本应写成 round_down() 的函数被错误地写成了 round_up()——整整只改了一行代码。

Linus 事后评价说，AI 确实在“干苦力活”方面帮了大忙，但它还是需要有足够经验和韧劲的人类去引导：“在这场漫长的排查中，AI 几乎承担了大量繁琐工作……虽然 AI 好几次准备放弃，但该给的功劳还是要给。”

这其实很能说明现在 AI 进入 Linux 内核开发后的一种现实状态：AI 可以参与，但不能替开发者承担最后的责任——尤其是在 Linux 内核这样的底层项目里，“代码能跑起来”远远不够。

一个补丁还要考虑性能、代码结构、可维护性、边界条件，以及是否符合项目长期形成的开发规范。没错，AI 可以很快生成一个看起来合理的方案，但最终能不能合入主线，还是需要真正熟悉内核的人来判断。

这也是为什么 Stoakes 明明已经让 AI 找到了瓶颈，却依然要花大量时间“收拾”它生成的代码。

所以，至少现在，AI 最擅长的可能不是替程序员写完代码，而是帮让他们更快找到“到底哪里出了Bug”。至于怎么修、该不该这么修，以及 AI 写出来的那堆“惨不忍睹”的代码最后该留下多少——这口锅，目前还得程序员自己背。

那么，对于 Stoakes 所说的这个问题，你是否有同感呢？

参考链接：https://www.phoronix.com/news/AI-To-Faster-Linux-Kernel-Comp