最近 Arm 工程师、长期参与 Linux 内核开发的 Lorenzo Stoakes 的一件事在技术圈传得挺广。据报道他为了加快 Linux 内核编译找来大模型帮忙排查构建流程里的性能瓶颈。AI 找问题找得挺准也顺带参与了构建、测试、调试和结果分析可到了让它写修复代码这一步评价相当直接——“hideous”翻译过来就是惨不忍睹。最终他大量重写了 AI 生成的代码连提交信息、补丁说明和注释也改了不少。把事情拆开看AI 干得好的和干不好的这件事之所以引人注意是因为它把 AI 编程的能力边界摆得很清楚AI 擅长的在庞大的代码库和构建信息里快速翻找把值得关注的点先筛出来。这属于信息检索 模式识别正好是当前模型的强项。AI 不擅长的写出能进主线、经得起长期维护的补丁。据报道AI 生成了大量代码其中相当一部分质量很差最后只有一部分被留下。好消息是这一通折腾并没有白费。据报道经过人工审查、重写和验证后Stoakes 一共提交了 23 个补丁让 Linux 内核构建速度明显提升开启全部模块的 allmodconfig 构建最快提升约 36%增量构建最快提升约 70%noop 构建最快提升约 90%可以简单理解成不需要真正重编译大量内容的场景所以提升幅度尤其夸张。这组优化涉及 Kbuild、kallsyms、modpost、objtool、mksysmap 以及 Rust 构建系统等多个环节核心思路是减少构建流程里只能串行执行的排队点让更多任务并行跑。换个说法编译慢未必是 CPU 核心不够而是有些活儿只能一个接一个干其他核心在旁边干等。这个道理放在我们自己的构建、打包、测试流程里其实同样成立。这不是孤例类似的情形在 Linux 社区并不少见。据报道Linus Torvalds 排查 Intel Xe 显卡驱动的一个 Bug 时AI 一度反复声称问题不可能解决建议直接写报告了事。他没放弃继续让 AI 添加调试代码、分析结果最终在 24 个调试补丁、18 次内核重启之后定位到只是一个函数把round_down()写成了round_up()——一行代码的事。另一个方向上的压力来自量。有报道称AI 审查工具能以极低成本扫描整个内核源码短时间内吐出大量补丁和漏洞报告维护者每天要处理的报告数量明显上升审查负担反而更重了。此前 Linus 的表态大意是AI 就像编译器一样是个工具重点不在于禁止而在于评审机制和维护者的判断力。说到底这些讨论指向的是同一个问题当生成代码的成本趋近于零判断哪段代码该留的能力反而更值钱了。对普通开发者的现实意义我们写业务代码碰到的是同一类问题只是规模小一点。几点可以直接用上把 AI 用在对的环节。找 Bug、读陌生代码、写测试用例、生成样板代码、解释报错——这些收益高、风险低。让它直接改核心逻辑尤其是涉及并发、内存管理、边界条件的地方就要非常谨慎。“能跑不等于能留”。业务代码也一样一个改动要考虑可读性、边界处理、后续维护和团队规范。AI 生成的代码看起来合理但不一定符合你项目长期形成的约定。人工验证这步省不掉。上面那位工程师在应用补丁后亲自检查了构建是否正确、内核运行是否正常、性能提升是否真实存在。放到业务里至少要做到关键路径有测试改动有人 review。注意标识和合规。大规模使用 LLM 的提交Linux 社区会加Assisted-by之类的标签标明 AI 参与其中。团队内部也可以先约定哪些场景允许用 AI、生成的代码要不要标注、出了问题谁负责。这几条早点说清楚比事后扯皮强。结尾AI 现在最擅长的更像是帮你更快找到问题在哪而不是替你写完最后那一段。找问题可以交给它怎么修、该不该这么修、留下的代码最后由谁背锅——目前还得是写代码的人。你在工作里用 AI 写代码遇到过找得准、改得烂的情况吗评论区聊聊。