最近有两条新闻，单看哪条都没毛病，放在一起看，很多人就迷糊了。
7月中旬，Linus Torvalds 本人在内核邮件列表（LKML）上放话：Linux 不是那些反 AI 项目之一，谁要是对这个有意见，可以按开源的方式把项目 fork 出去，或者干脆走人。36氪
三周之后，8月3日，Linux 内核维护者、Linux 基金会研究员 Greg Kroah-Hartman 宣布：内核暂存区 drivers/staging/ 今后不再接收 AI 生成的补丁。IT之家
一边是"不满意的可以滚"，一边是"这里不收 AI 代码"。于是不少文章直接写成了"Linux 开始封杀 AI"。
这其实是个误读。把这半年发生的事情按顺序捋一遍你会发现，这两件事非但不矛盾，甚至是同一件事的两面——而这件事，跟每个用 AI 写代码的人都有关系。
先补时间线：这半年 Linux 内核社区到底发生了什么
今年4月，吵了几个月之后，Linus 和内核维护者们把 Linux 内核第一套 AI 辅助代码规则定了下来，核心就三条：
第一，AI 不能署名"Signed-off-by"。这个标签代表提交者对《开发者原创证书》（DCO）的法律确认，只能由人签——哪怕补丁完全是 AI 写的，法律责任也在你本人，不在 AI，也不在 AI 厂商。36氪
第二，用了 AI 就要标注"Assisted-by"，格式是"工具名:模型版本[分析工具]“，让所有人知道这次提交里 AI 参与了多少。36氪有意思的是，这个标签最初讨论过更重的"Generated-by”，最后选了更中性的"Assisted-by"——社区明确不想把 AI 参与污名化，只要求透明。
第三，人类负全责。代码审没审、许可证合不合规、以后出 bug 谁背锅，全在提交者身上。规则文档里还专门提了2021年明尼苏达大学那档子事——研究人员故意往内核里提交带缺陷的补丁做实验，结果整个学校的后续贡献被社区封禁，至今还是反面教材。
规则落地的同时，另一件事在悄悄加速：AI 开始疯狂挖内核漏洞。内核维护者 wtarreau 在 LWN 上晒过自己的邮箱：两年前每周收到2-3份漏洞报告，去年涨到每周约10份，到今年变成每天5-10份，而且"大部分还是对的"。量子位最离谱的是，他开始看到两个互不相识的人提交同一份漏洞报告——唯一的解释就是一大批本来不做安全的人，开始拿 AI 挖洞了。Greg 自己随手试了试相关工具，得到约60个补丁，其中三分之二基本正确，三分之一修复方向不对。36氪他的原话是：“这些工具是有用的，我们不能装看不见。”
到了6月，一个叫 Sashiko 的项目在社区里火了起来——这是一套专门给内核做代码审查的 AI 智能体，模拟维护者的完整审查流程，由 Meta 内核工程师主导开发、Linux 基金会托管。知乎争议很快来了。
7月14日，开发者 Laurent Pinchart 在邮件列表提出：维护者如果要拿 Sashiko 的审查意见去联系补丁作者，应该先自己逐条验证这些 AI 结论，他还引用了软件自由保护组织（SFC）给开源社区的 LLM 使用建议。36氪Roman Gushkin 立刻反对：如果用之前必须完整验证每一条，那这个工具"帮助维护者"的初衷就没了——问题应该直接问：Linux 到底是不是一个原则上反对大模型的项目？
Linus 就是在这个上下文里下场的。他的表态很硬：Linux 不是反 AI 项目，有人不接受可以 fork，或者走人。开源派但同时他也说了另一句常被忽略的话：他会"大声无视那些试图阻止别人使用 AI 的人"——你爱用不用，但别来要求别人反对。
再然后，就是8月3日 Greg 的 staging 新规。顺带一提这个大背景：整个7月，Linux 内核曾在24小时内发布440个高危 CVE 公告，创了纪录。知乎2026上半年 Linux 主动披露的 CVE 达到2308个，位居所有项目榜首——AI 挖洞的海啸，是真实存在的。知乎
staging 到底在防什么
看懂了时间线，再看 staging 新规，就知道它防的根本不是"AI"。
首先，staging 这个目录的定位就很特殊。里面的驱动代码质量本来就参差不齐，它存在的意义之一，是让刚进内核社区的新人拿它练手：从发现问题、读懂代码，到测试、写说明、接受审阅，完整走一遍补丁流程。IT之家你让模型把格式修正这种"低垂果实"全摘了，新人交上来的 diff 是干净了，但脑子里那段路没走过。维护者问一句"这条错误路径你在真机上跑过吗"，答不上来，后面审阅意见没人接、回归问题没人追，补丁坏了模型也不会回来值夜班。
其次，Greg 给安全修复留了口子——不是"AI 相关一律不收"。安全补丁还能交，但必须在对应驱动的真实硬件上完成测试，并详细说明测试过程。IT之家驱动不是算法题，它跟设备、总线、固件、电源状态、时序打交道，在电脑上编译通过只说明编译器没骂你，说明不了硬件启动后没问题。这要求的本质是：你说这是漏洞、你说你修好了，那就拿出复现和真机测试结果，别用一句"模型分析认为"结案。
所以这条新规翻译过来就一句话：在生成成本趋近于零的时代，读代码、测代码、给事故收尾的成本并没有跟着降，谁提交，谁把这些成本接住。
不是翻脸，是分工
现在回头看那两条"矛盾"的新闻。
Linus 回答的是立场问题：Linux 是技术项目，不以价值观划界，工具好不好用看效果，不搞原则性禁令。注意，他说的是"Linux 不是反 AI 项目"，而不是"AI 写什么都收"——他从来没给 AI 输出开过绿灯，质量不过关的补丁，人写的照样挨骂。
Greg 管的是成本问题：staging 是新人训练营，恰恰是最经不起 AI"代练"的地方；同时他作为稳定版维护者，每天直面 AI 报告的海啸，比谁都清楚"三分之二对"意味着还有"三分之一错"要人来兜底。
一个守门的人说"工具随便用，我看结果"，一个管具体子系统的人说"这块地的规则得这么定"。这在内核社区不是第一次出现，也不会是最后一次——子系统维护者本来就有权限给自己的一亩三分地立规矩。真正统一的底层逻辑其实只有一条：AI 可以参与，责任不能外包。
回头看，Linus 自己的态度变化也挺说明问题。2024年他还说市场上大概90%的 AI 叙事是营销炒作。36氪到了今年7月，他的说法是"AI 是否有用已经毫无疑问，怀疑的人可能根本没真正用过"。从"90%是炒作"到"毫无疑问"，中间隔的不是立场反转，而是 AI 在内核漏洞发现、补丁检查、代码审查里交出了可以验证的结果。
这件事跟你有什么关系
如果你只是想在内核邮件列表的瓜里找个结论，那结论已经有了。但如果你自己也用 AI 写代码，这套正在成形的规则其实很值得对照：
想给 Linux 内核提交补丁的人：AI 可以用，但记住三件事——Signed-off-by 只能你自己签，用了 AI 就老老实实写 Assisted-by 标签（工具名、模型版本、辅助分析工具），出了任何问题你负全责。staging 目录就别拿纯 AI 输出刷存在感了，那是目前明确关门的地方；安全修复想走例外通道，先把真机测试结果备齐。
给其他开源项目投稿的人：内核这套"披露+担责"正在变成一种模板，但各项目尺度不同，有的项目完全有权按自己的维护能力拒收 AI 贡献——SFC 的建议里写得很清楚。36氪动手前先翻项目的贡献文档，比被拒了再吵体面得多。
日常靠 AI 编程的普通开发者：内核社区吵了半年，最后落点不在"AI 行不行"，而在"谁能讲清楚谁写的东西"。这个逻辑在任何团队都成立——生成代码的成本掉了，但评审、测试、背锅的成本没掉。用 AI 没问题，把"这段代码我能解释、我测过、出事我接"当成提交前的自检项，你比大多数只会复制粘贴的人走得远。
最后给几个值得持续关注的信号：一是 staging 这个试点会不会扩散到其他子系统——如果有更多维护者跟进类似规则，说明社区在往"分区治理"走；二是 Linux 基金会托管的 Sashiko 会被多少维护者真正采纳，它是"AI 帮人审代码"这条路的试金石；三是 Assisted-by 这类披露格式会不会被其他项目借鉴，成为事实标准。
Linux 用了35年回答"开源能不能做出最好的操作系统"，现在它在回答一个新问题：当写代码的成本趋近于零，人类协作的规则要怎么改。这半年的每一步，都是答案的一部分。
