你让AI帮忙找Bug，可能定位很准；但要是让它自己修复Bug，代码可能“惨不忍睹”——最近，Arm工程师、长期参与Linux内核开发的Lorenzo Stoakes就遇到了这种情况。
为了加速Linux内核编译，他请来大模型协助排查问题，结果AI果然没让他失望：隐藏在庞大构建流程中的多个性能瓶颈被识别出来，连后续的构建、测试、调试和分析也一并处理了。然而，当AI开始编写修复代码时，Stoakes的评价相当直白：“它生成了很多代码，其中许多都惨不忍睹。”
于是，一场看似“AI帮程序员修Bug”的工作，最终演变成了另一种模式——AI负责找问题，人类负责把AI写出的代码重新整理一遍。
好在，这一番努力没有白费。经过Stoakes大量审查、重写和人工验证后，最终提交的23个补丁让Linux内核构建速度有了显著提升：开启全部模块的构建最高快了36%，增量构建最高快了约70%，部分noop构建甚至快了约90%。
对于Linux内核开发者来说，编译内核是再常见不过的事：改完代码，编译→发现Bug，再改→重新编译、测试，然后继续改——问题是，Linux内核实在太庞大了。
现代CPU通常拥有十几个甚至几十个核心，理论上可以同时处理大量编译任务。但实际情况并不理想：Linux内核的构建流程中，仍存在不少只能单线程执行的任务。
简单理解的话，就是电脑明明有一大群CPU核心待命，但某些任务只能一个接一个处理。前面的任务没完成，后面的工作就只能排队，其他CPU核心也只能闲置。
Stoakes这次做的事，就是把这些“排队点”逐一找出来，然后想办法让更多工作并行执行。这并非简单修改某一个函数，而是涉及Linux构建系统中的多个关键组件。
最终，他提交了一组包含23个补丁的优化方案，涉及Kbuild、kallsyms、modpost、objtool、mksysmap，以及Linux内核的Rust构建系统等多个环节。
特别之处在于：这一次，Stoakes没有完全靠自己，而是让AI成为了他的重要帮手。
Stoakes并未公开他使用的是哪款LLM。对于这种规模庞大的工程，AI的优势很明显：它可以快速翻查大量代码和构建信息，把可能值得关注的地方先筛选出来。
根据他的描述，AI主要参与了几个环节：首先分析构建流程、寻找性能瓶颈，然后尝试提出改进方案；后来，它还参与了构建运行、测试、调试和结果分析。
而真正让Stoakes感到头疼的地方是：AI开始写代码了。
Stoakes在补丁说明中用了一个相当直接的形容词——“hideous”，也就是“丑陋”、“惨不忍睹”。按照他的说法，LLM生成了大量代码，其中相当一部分质量很差。因此，他对其中很多代码进行了重写，同时还大幅修改了提交信息、补丁说明和代码注释。
所以，这次优化对Stoakes而言，并不是一次“输入一句Prompt，AI自动写完23个补丁”的自动化开发。更像是AI先把一堆可能的答案扔到桌面上，然后工程师坐下来逐个检查：哪些思路靠谱，哪些代码能用，哪些必须重写，哪些干脆直接丢弃。
最终留下的，才是能够进入Linux内核开发流程的补丁。
虽然过程有些波折、AI代码也确实让Stoakes头疼，但好在它发现的Bug的确有价值。
经过Stoakes人工修改和验证后，他一共提交了23个补丁，核心目标就是减少构建过程中不必要的串行等待，提高不同任务之间的并行程度，最终也带来了相当可观的性能提升：
而且，这些提升并非只在某一台机器上出现。Stoakes表示，在不同硬件以及不同内核配置下，都观察到了明显的构建速度提升。
对于普通用户来说，“快了36%”可能只是一个看起来不错的数字，但对于每天反复编译、测试Linux内核的开发者来说，意义就完全不同了：他们可能一天之内反复修改代码、编译、测试，再修改、再编译，如果每轮构建都能少等几分钟，一天下来就是相当可观的时间。
有趣的是，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
本文来自微信公众号“CSDN”，整理：郑丽媛，36氪经授权发布。
+1.5万 
