Linux 暂存区不收 AI 补丁，到底在防什么？

今天看到一条消息：Linux 内核维护者 Greg Kroah-Hartman 说，drivers/staging/ 这个暂存区，之后不收 AI 生成的补丁了。

先别把它翻译成“Linux 禁 AI”。不是。限制只在 staging，也不是说安全问题一律不能碰。真有安全漏洞，修复还是能交；只是得在对应驱动的真实硬件上跑过，把怎么测的说明白。

这事的起因也很朴素：那边最近收到了太多 LLM 写出来的补丁。

我看到有人问：不就是改代码吗？AI 写得快，维护者不是应该轻松一点？

这话放在 staging，刚好把事情说反了。

staging 里的东西不一定好看，甚至就是带着毛病放在那儿。但它还有个用途：让刚进内核社区的人，学着把一个补丁从发现问题、理解代码，到测试、写说明、接受审阅，完整走一遍。

你让模型把格式问题、低垂果实全摘了，新人交上来的 diff 可能干净了，脑子里的那段路却没走。

维护者不是只想收一段能编译的文本。他会问：为什么改这里？这条错误路径谁跑过？换一个配置还成立吗？这个驱动你摸过没有？

如果提交的人答不上来，后面就很麻烦。审阅意见没人接，回归问题没人追，补丁一旦坏了，模型不会回来值夜班。最后还是维护者和下游用户扛。

安全例外为什么偏偏要真机？

因为驱动不是一道算法题。它跟设备、总线、固件、电源状态、时序打交道。你的补丁在电脑上编过，只能说明编译器没骂你；它不能说明那块硬件启动以后没出别的问题。

更别说安全修复经常动在边界条件、错误处理、锁和内存生命周期上。模型很会把一小段逻辑写得顺眼，至于这段逻辑是不是踩到了另一条路径，它不知道。很多时候，写这段代码的人自己也未必知道。

所以这个要求不是给 AI 上难度，是把责任放回提交者手里：你说这是漏洞，你说已经修了，那就拿出复现、真机测试和结果。别拿一句“模型分析认为”来结案。

Greg 的态度其实不玄。按报道里的说法，LLM 已经能帮忙发现一些潜在的内核安全问题，但连最好的工具，生成结果里也可能有至少三分之一是错的，或者有害的。

这个数字以后会变，模型也会变。但有一件事不会变：生成代码的成本掉下来了，读代码、测代码、给事故收尾的成本没有跟着掉。

所以我不觉得这是一条“反 AI”新闻。Linux 其他区域没有全面禁掉 AI，Linus 也一直把 AI 当工具。这里真正不欢迎的，是有人把模型当成免理解、免测试、免负责的通行证。

我们做 Agent 也一样

Agent 读了网页、邮件、文档，下一步准备调工具的时候，逻辑没有变。它看见的是外部数据，不是命令；它能做一件事，不代表它应该直接做。

该只读的就别给写权限。要外发就问一次。碰到删改、转账、覆盖这类高风险动作，默认不让它自己决定，留审计，能停，也得有人能接手。

这不是把 AI 当贼防。真把它放进业务里，才得这么做。因为真正有用的系统，不能只在演示时显得聪明；它还得在输入脏了、工具失败了、任务重跑了以后，不把事情越办越乱。

AI 可以帮人写补丁，帮人找问题，甚至帮人少熬几次夜。这些都挺好。

但它写完以后，谁能讲清楚，谁跑过机器，谁肯接住后果，这三件事不能外包给一句提示词。

事实来源：《Linux 暂存区不欢迎 AI 生成补丁，安全修复需通过实际硬件测试验证》
https://www.ithome.com/0/985/693.htm

词元武工队，一群老登+一个实习生搞AI的草台组织。

几个虚构的化名角色，若干真实的工程师故事。

素材源自生活，内容AI辅助生成。如有雷同，或非巧合。