这周的 Linux 内核社区，同时发生了三件事。放在一起看特别有意思：全世界最强的一批程序员，相当于替所有正在用 AI 写代码的人，做了一场"AI 代码到底能信到什么程度"的极限实验。
一、AI 帮内核编译提速 90%，但它的代码"惨不忍睹"
Arm 工程师 Lorenzo Stoakes 想给 Linux 内核编译提速。这活儿不好干——内核太大了，构建流程里藏着大量只能单线程执行的"排队点"，CPU 几十个核只能干等着。他把大模型拉进来帮忙，AI 还真争气：隐藏在庞大构建流程中的多个性能瓶颈被一个个揪了出来，连后续的构建、测试、调试和分析也一并包办了。36氪
但轮到 AI 写修复代码，画风就变了。Stoakes 在补丁说明里用了一个非常直接的词：“hideous”（惨不忍睹）——AI 生成的代码大量质量很差，他动手重写了其中很多，提交信息、补丁说明和代码注释也全被大幅改过。CSDN
好在折腾没有白费。经过大量审查、重写和人工验证，最终合入的 23 个补丁让内核构建明显提速：开启全部模块的构建最高快了 36%，增量构建最高快了约 70%，部分 noop 构建甚至快了约 90%，且在不同硬件和内核配置下都成立。36氪
值得一提的是，由于开发过程中大量使用了大模型，这批补丁都带着 Assisted-by 标签——明确标注 AI 在其中参与过工作。36氪
一句话总结这场协作：AI 负责找问题，人负责把 AI 写出来的代码重新收拾一遍。折腾，但真提速了。
二、Linus 本人也被 AI"劝退"过
差不多同一时间，Linus Torvalds 排查 Intel Xe 显卡驱动 bug 的经历也被翻了出来。8 月 21 日，他往内核里合了一个补丁，改动只有一行：一个本该写成 round_down() 的函数被错写成了 round_up()。但找到这一行之前是漫长的拉锯：AI 反复声称问题"不可能解决"、建议直接写报告归档，Linus 没放弃，继续让 AI 添加调试代码、分析结果——24 个调试补丁、18 次内核重启之后，答案才浮出水面。知乎36氪
Linus 事后的评价很公道：在这场漫长的排查中，AI 几乎承担了大量繁琐工作，虽然它好几次准备放弃，但该给的功劳还是要给——前提是有足够经验和韧劲的人类在引导。还有个细节最说明问题：18 次重启换来的那 1 个词，AI 自己没找出来，它建议过归档，是 Linus 一遍遍把它推回"继续挖"。36氪知乎
这也不是内核社区第一次直面 AI 的渗透。8 月宣布 7.2-rc7 时，Linus 在发布邮件里写下"Another week, another -rc"，坦言自己对这个规模谈不上兴奋，但现实就是这样：新常态下必然伴随着大量修复，其中相当一部分来自各种 AI 工具的审查。CSDN
三、AI 漏洞猎人，把维护者淹了
前两件算好消息，第三件就没那么轻松了。AI 驱动的漏洞扫描工具正在 4000 万行内核代码里日夜扫荡，Linux 一个版本周期内的漏洞记录已逼近 2000 条。知乎
Greg Kroah-Hartman 在 2026 年 Kernel Recipes 大会上放了一张图：CVE 四年翻了四倍。但代码量并没有翻四倍——这两个数字一对比，结论只有一个：CVE 增长不是因为 Linux 突然变得不安全，是因为扫描器突然变得勤快。知乎
代价由维护者承担。网络子系统维护者 Jakub Kicinski 在 Linux 7.3 开发周期直言"我们已经彻底忙不过来了"：他统计的 648 个 net-next 补丁中，约三分之一到一半与 AI 驱动的修复等有关。有作者形容得又损又准：一个人每周要从 200 多个 AI 生成的补丁里挑出真正该合并的，剩下的要么扔回去要么扔进垃圾桶——这不是开发，这是垃圾分类。CSDN知乎
更麻烦的是，AI 的扫描结果里混着大量低优先级问题、不知名驱动代码里的可疑点，甚至纯 AI 幻觉；确实有真成果——今年已有 CVE 明确标注"由 AI 辅助静态分析发现"并获 Intel Product Security 确认——但淘金只能靠维护者自己。AI 负责发现，不负责"负责"。知乎
四、三条线拼起来，是同一个规律
把这三件事放在一起，能看出一个特别清晰的模式：AI 把"发现"的成本打到接近零，但"验证、修复、担责"的成本原封不动留给了人。
Stoakes 的实验里，AI 找瓶颈又快又准，但 23 个补丁能合入主线，靠的是他逐行重写和亲自验证；Linus 的调试里，AI 干苦力一流，但"该往哪个方向死磕"的判断来自人；CVE 洪水里，扫描一夜吐出一串可疑点，但确认一个 CVE 需要读代码、查历史、写补丁、回邮件——前者是算力成本，后者是注意力和判断力成本。开源世界最缺的不是算力，是注意力；当注意力被海量 CVE 稀释，真正危险的漏洞反而可能被淹没在噪音里。知乎
一句话：瓶颈已经从"写"转移到了"审"。
五、而你，每天都在复刻这个实验
你可能不写内核，但这周微博和知乎上的讨论说明，用 Claude Code、Cursor、Codex 的人都在面对同一道题。有篇今天更新的专栏说得扎心：你上一次从头到尾读完 AI 改的代码是什么时候？没人答得上来——嘴上说着不能全信，手上点的是"全部接受"。AI 写代码的速度涨了一百倍，人读代码的速度一点没变。知乎
数据也站在维护者这边：Veracode 通过分析 100 个大模型在 80 个编程任务上的生成结果发现，AI 生成代码在约 45% 的情况下引入了安全漏洞。宝玉xp 这两天转了 137 次的微博则提醒了另一件事：代码只是软件的中间产物，需求理解、抽象设计、验证、上线后维护才是完整交付——恰好这些是 AI 最弱的环节。知乎微博
六、但也别急着写成"AI 无用论"
Linus 今年 5 月有个绝妙类比：听到有人宣称自己 99% 的代码由 AI 编写，他随即拿编译器打了个比方——他们的代码 100% 是编译器写的，但他们从来不这么说。程序早就经过工具生成，只是过去人们不这样谈论它。知乎
Claude Code 的核心建设者 Boris Cherny 也讲过类似的家族史：祖父用穿孔卡，父亲写汇编，到他这代用 Java、JavaScript 和 Python——编程的抽象层级总是在上升。他自己的工作从在编辑器里写代码，变成同时运行多个 Claude，再变成编写自动运行的循环；他用一句话描述现在的工作：“My job is to write loops”。知乎
所以内核社区的真实态度也不是反 AI——Linux 内核社区不是一刀切反 AI，立场很清晰：AI 是工具，不是替代维护者判断的捷径。他们反的是"未验证的 AI 输出"直接灌进主线。这个分寸，就是普通人最该抄的作业。知乎
七、抄作业：三条可以直接用的线
结合内核社区的做法和这周讨论里沉淀的经验，如果你正在用 Claude Code、Cursor、Codex 这类工具，建议这么划线：
把"诊断"和"开方"拆成两步。 Stoakes 的成功模式就是让 AI 先找瓶颈、做分析、跑测试，人来决定怎么修——那场协作的最终画风是：AI 负责找问题，人类负责把 AI 写出来的代码重新收拾一遍。别让 AI 一口气生成"最终版"直接合入：它找问题的可信度，远高于它改问题的可信度。36氪
读 diff 要有仪式感，交叉审查有技巧。 有工程师分享了一个实用招数：AI 写完代码先提交 git，把提交指纹复制下来，新开一个会话让 AI 以审查者身份重新过一遍这个提交——用 AI 审 AI，但"按下合并键"的必须是你。生产环境的代码，不妨学学内核的 Assisted-by：标注清楚哪些部分 AI 深度参与，将来审计时能快速定位。知乎
分清场景：苦力活放心交，边界条件亲自看。 加调试代码、翻日志、写测试、重构样板，AI 干得又快又好；但权限校验、并发、超时降级、幂等重试这些"AI 不知道你的业务背景"的地方，正是那 45% 漏洞率的重灾区，人必须在场。
八、值得继续盯的信号
接下来几个月有两个观察点。一是 Linux 内核会不会正式出台 AI 提交政策：小众开源项目 Turso 已经因为受不了 AI 提交而关掉了 bug 赏金计划，这跟全球最顶级的开源工程扛不住 AI 补丁洪水，是同一个问题的两个切面。知乎
二是各大 AI 编程工具会不会把"可审查性"做成默认能力——自动生成变更摘要、强制 diff 确认。这两个信号任何一个落地，都意味着"AI 写、人审"从个人习惯变成基础设施。
内核用三十多年证明了一件事：代码可以被任何工具写，但责任只能有人背。AI 时代，这条线没有变，只是被画得更清楚了。
