最近 Linux 内核社区关于 AI 生成补丁的讨论又有了新变化staging 子系统的维护者明确表示将不再接受由大语言模型LLM生成的补丁真正的安全修复除外。这条规则一出立刻让不少用 AI 工具辅助写内核代码的开发者重新思考自己的工作方式。本文会从 Linux 内核 staging 子系统的定位讲起分析 LLM 补丁为什么会被拒收、新政策到底如何执行然后带大家完整走一遍标准的内核补丁提交流程最后给出工程层面的最佳实践。无论你是刚接触内核开发的学生还是已经在用 AI 辅助写代码的后端工程师这篇文章都值得收藏。1. 背景staging 子系统与补丁审查机制1.1 staging 子系统是干什么的Linux 内核源码里有一个特殊目录drivers/staging。它不是一个普通的驱动目录而是内核中的“暂存区”。很多新驱动、新硬件支持代码在刚提交时往往还不够规范代码风格不一致、缺少文档、存在未完成的 TODO、甚至有一些临时调试逻辑。如果直接并入内核主线的正式子系统会给后续维护和代码评审带来很大压力。于是内核社区设置了 staging 区域让这些“有潜力但还没打磨好”的代码先进入内核通过社区共同参与逐步清理等代码质量达标后再迁移到正式的子系统目录。简单理解就是drivers/staging 是一个“待清理区”。提交到这里的代码允许不完美但必须能编译。维护者、贡献者通过一轮轮补丁把代码变干净。清理完成后驱动会被移出 staging进入正式子系统。staging 子系统的维护者是 Greg Kroah-Hartman他也是 Linux 内核稳定分支的主要维护者之一。正因为 staging 在整个内核流程中承担“过渡”职责它对补丁质量有一种特殊的敏感这里最容易收到低质量、批量生成的“清理补丁”。1.2 补丁审查机制如何运转Linux 内核的补丁审查本质上是一条邮件列表驱动的流程而非像 GitHub 那样依赖 PRPull Request。一位贡献者需要基于某个内核 tree 创建分支修改代码。使用git format-patch将提交生成补丁文件。使用git send-email把补丁发送到对应子系统的邮件列表。维护者和其他开发者审阅补丁给出Reviewed-by、Acked-by或修改意见。修改后发送 v2、v3 版本直到被接收。整个过程中维护者的时间是最稀缺的资源。每天有大量补丁涌入内核邮件列表如果其中混入大量“AI 生成的无关紧要改动”会严重占用维护者的精力导致真正有价值的补丁被埋没。2. LLM 补丁浪潮问题产生的原因2.1 什么是 LLM 补丁所谓 LLM 补丁指的是使用 ChatGPT、GitHub Copilot、Claude 等大语言模型工具生成或辅助生成的补丁。LLM 在理解自然语言和生成代码方面确实很强它可以根据一段代码上下文生成“看起来正确”的修改。于是很多开发者尝试让它批量处理 staging 中那些不太规范的代码统一变量命名、调整缩进、修注释、删除多余空行等。从表面看这些任务很简单LLM 也能生成像模像样的 diff。但问题恰恰出在“看起来像模像样”上。2.2 LLM 补丁的典型问题根据内核社区反馈LLM 生成的补丁常见问题可以归纳为四类。第一类是“无事找事”的风格修复。LLM 会把 A 风格的代码改成 B 风格但内核代码风格本身有明确规范很多改动只是“换一种写法”并没有任何实际收益。这类补丁不仅没有提升代码质量反而增加了评审负担。第二类是编译能过、逻辑不对。LLM 训练数据里包含大量内核代码但它并不真正理解硬件寄存器的含义、锁的持有条件、内存生命周期。它可能生成一段语法正确、类型匹配的代码但实际上调用了一个并不存在的 API或者把操作顺序写错了。第三类是提交信息与改动内容脱节。LLM 生成的 commit message 往往非常“正式”但仔细读会发现它描述的内容和代码改动并不一致。这会让后续维护者很难从提交记录里判断这次修改的真实意图。第四类是签名与来源问题。内核补丁要求必须包含Signed-off-by行表示提交者对该补丁有合法授权、并同意开发者原创证书Developers Certificate of Origin。LLM 生成补丁时开发者很难确认代码是否来自受版权保护的训练数据这带来了一定的法律和合规风险。2.3 新政策的核心内容面对这些情况staging 子系统的维护者明确表态不再接受由 LLM 生成的补丁除非是真正的安全修复。准确理解这句话需要注意两点拒绝的对象是“由 LLM 生成的补丁”而不是“使用 AI 辅助工具开发的补丁”。前者指大段代码由 AI 自动产出并提交后者可以理解为人类开发者用 AI 做代码审查、查文档等辅助工作。例外是“真正的安全修复”。如果补丁修复的是真实存在的、可利用的安全漏洞那么即使生成方式有 AI 参与也会被认真对待。但前提是它必须被证明是安全和正确的不能拿“安全修复”当幌子提交垃圾补丁。这条政策本质上是在告诉开发者内核社区欢迎你贡献代码但前提是你真正理解你提交的每一个改动。3. 政策拆解哪些补丁会被拒收哪些可以豁免3.1 被拒收的补丁类型根据社区讨论和 staging 子系统的既定规则以下几类补丁大概率会被直接拒收。纯风格类补丁只改空格、缩进、换行、注释大小写不改变任何逻辑行为。批量重命名补丁把变量名从foo_bar改成fooBar之类的大规模重命名却没有解释必要性。无意义重构补丁把if (ret 0)改成if (!ret)把while (1)改成while (true)这类改动纯属制造 diff。依赖臆想 API 的补丁代码里调用了内核中不存在的函数或结构体字段这种补丁如果维护者没有及时发现甚至会导致编译失败。提交者无法解释的补丁维护者一旦追问“为什么这样改”提交者答不上来这说明补丁很可能不是自己写的。为了更直观下面看一个典型的“LLM 风格补丁”和真正的修复补丁对比。这是一段典型的无意义改动--- a/drivers/staging/gpio/foo_gpio.c b/drivers/staging/gpio/foo_gpio.c -42,7 42,7 static int foo_gpio_probe(struct platform_device *pdev) struct foo_gpio *priv; - int ret; int ret 0; priv devm_kzalloc(pdev-dev, sizeof(*priv), GFP_KERNEL);这段改动的唯一变化是给ret加了初始值0。但紧接着下一行ret devm_kzalloc(...)就会给ret赋值所以这个初始化没有任何意义还掩盖了“变量未初始化就使用”的真实问题。这类补丁内核社区已经收到过很多。而一个真正有价值的修复是这样的--- a/drivers/staging/foo/foo_net.c b/drivers/staging/foo/foo_net.c -210,7 210,7 static int foo_net_rx(struct foo_dev *dev, u8 *buf, size_t len) if (len dev-rx_buf_size) return -EINVAL; - memcpy(dev-rx_buf, buf, len); memcpy(dev-rx_buf, buf, min(len, dev-rx_buf_size)); return len; }这个补丁在复制数据前增加了长度检查修复了一个真实的缓冲区溢出风险。它不仅有明确的问题描述还解决了实际的安全隐患。3.2 为什么安全修复可以豁免安全修复补丁被单独豁免原因很直接安全漏洞的修复窗口非常宝贵。如果某个漏洞已经在被利用那么时间每多过去一天影响范围就可能扩大一天。但这并不意味着“用 LLM 编一个安全补丁就能蒙混过关”。内核社区对安全补丁的审查同样严格而且通常会更严格修复必须准确定位漏洞根因。修复不能引入新的问题。补丁需要附上漏洞分析和复现说明。最终合入前往往还要经过多位维护者确认。换句话说安全修复具有“紧急性”和“真伪可验证性”两个特点。一个真正修复了漏洞的补丁无论出自人类还是 AI社区都会认真对待但提交者必须能讲清楚漏洞原理和修复思路这不是 LLM 随便生成一段 diff 就能糊弄过去的。3.3 维护者如何识别 LLM 补丁很多人好奇维护者怎么判断一个补丁是不是 LLM 生成的其实并不难内核维护者见过大量补丁识别 LLM 补丁有几条常用线索。批量特征同一账号在短时间内提交大量风格类似的清理补丁并且每个补丁都只改动几行。上下文缺失补丁修改了某个函数但提交信息里完全没有解释硬件行为或函数调用关系。风格过度规范LLM 生成的代码往往“过于标准”缺少真实内核代码中常见的那种上下文牵连和历史包袱。沟通表现维护者在邮件列表里追问细节时提交者回答含糊、无法给出具体的测试结果或逻辑推演。所以想靠 LLM 批量混提交基本逃不过维护者的眼睛。4. 内核补丁提交实战从准备环境到发送补丁这一节我们完整走一遍标准的内核补丁提交流程。无论你是不是用 AI 辅助都建议按照这个流程来。4.1 准备开发环境与内核源码首先准备一台 Linux 环境安装必要的工具sudo apt update sudo apt install git build-essential libncurses-dev flex bison sudo apt install git-email libssl-dev然后拉取 staging 子系统的内核源码树。这里要提醒一下内核源码树非常大建议只拉取最新分支并启用浅克隆加速git clone --depth 1 \ git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git cd staging git remote add linux-next \ git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git克隆完成后建议先创建一个自己的开发分支不要在主干上直接修改git checkout -b dev/cleanup-foo-driver4.2 编写补丁格式与提交信息内核补丁有一套非常严格的格式规范。每个补丁必须是一个独立的逻辑单元即“一个补丁只做一件事”。修改代码后用git add和git commit提交提交信息推荐使用下面的模板staging: foo: fix possible buffer overflow in foo_net_rx The length of incoming data is checked before copying, but the second memcpy does not use the same bound. Use min(len, dev-rx_buf_size) to avoid copying beyond the buffer. Signed-off-by: Zhang San zhangsanexample.com需要注意的是commit message 的第一行是主题必须以“子系统名模块名简述”的格式开头不要用多余符号和过长描述。主题后面空一行再写正文最后必须有Signed-off-by行。4.3 使用 checkpatch.pl 做静态检查内核源码自带一个补丁风格检查脚本scripts/checkpatch.pl提交补丁之前一定要跑一遍。先把补丁生成出来git format-patch -1这会生成一个类似0001-staging-foo-fix-possible-buffer-overflow.patch的文件。然后执行检查./scripts/checkpatch.pl --strict --no-tree 0001-*.patch正常输出类似total: 0 errors, 0 warnings, 0 checks, 10 lines checked如果存在问题会看到类似下面的提示ERROR: code indent should use tabs #45: FILE: drivers/staging/foo/foo_net.c:23: int ret; WARNING: line over 80 characters #58: FILE: drivers/staging/foo/foo_net.c:34: if (foo_bar_baz_very_long_function_name(...) another_check())检查通过后再交叉编译一下涉及的驱动模块确保改动不会破坏构建make ARCHx86_64 defconfig make drivers/staging/foo/ 21 | tail -204.4 生成与发送补丁检查无误后重新生成补丁并发送到目标邮件列表。先配置 git 发件人信息git config --global user.name Zhang San git config --global user.email zhangsanexample.com git config --global sendemail.smtpserver smtp.example.com git config --global sendemail.smtpserverport 465 git config --global sendemail.smtpencryption ssl git config --global sendemail.smtpuser zhangsanexample.com然后使用git send-email发送补丁。staging 子系统的补丁应发送到对应的驱动列表同时抄送 staging 维护者git send-email \ --to linux-kernelvger.kernel.org \ --cc driverdev-devellinuxdriverproject.org \ 0001-*.patch发送之后请耐心等待。评审周期可能是一两天也可能是几周。如果维护者给出修改意见请在原邮件线程中回复并发送 v2 补丁git commit --amend git format-patch -v2 -1 git send-email --in-reply-to原邮件Message-ID 0001-*.patch5. 常见问题与排查思路5.1 典型问题清单问题现象常见原因解决思路补丁被 NACK改动没有实际价值或属于 LLM 生成的批量风格修改先理解代码逻辑做有实际价值的修改后再提交checkpatch.pl 报错代码风格不符合内核规范根据报错逐项修改提交前务必检查发送后没有回复邮件列表地址错误、主题不清晰或补丁内容太小确认收件列表完善提交信息等待 1-2 周后礼貌询问维护者要求发 v2第一版存在逻辑或风格问题根据评审意见修改并在回复中逐条说明处理方式补丁被怀疑是 AI 生成大量提交同类风格补丁且提交者无法解释改动停止批量生成只在理解代码后提交真正有价值的改动5.2 被拒后如何重新提交补丁被拒并不是世界末日几乎所有内核开发者都经历过多次被拒。关键是搞清楚被拒的原因。如果维护者给出了具体意见按照意见逐条修改并在 v2 中说明每一条的修改方式。如果维护者没有给出意见可以在邮件列表中礼貌请求更多反馈。但要注意内核社区的沟通讲究直接和简洁不要长篇大论更不要情绪化。6. 最佳实践与工程建议6.1 给内核贡献者的建议对于想参与内核贡献的开发者尤其是新手我有几条很务实的建议。第一不要追求补丁数量。提交 10 个无意义的清理补丁不如提交 1 个真正解决问题的补丁。维护者更看重的是代码质量和提交者对代码的理解。第二提交之前先读文档。内核源码中的Documentation/process/submitting-patches.rst详细描述了补丁提交规范建议完整读一遍。第三从真实的 TODO 和 FIXME 入手。staging 代码中往往有大量 TODO 注释这些是原作者留下的任务线索。从这些点切入比漫无目的地改风格更有价值。第四一定要在真实环境或至少 QEMU 虚拟机中测试你的改动。任何没有经过测试的补丁都不应该发到邮件列表。6.2 给 AI 辅助开发者的建议我并不是反对用 AI 辅助开发。实际上AI 工具在代码审查、文档查询、错误解释方面非常有用。但关键是定位可以让 LLM 解释一段内核代码的逻辑帮助你理解。可以让 LLM 帮你审查自己的补丁找出潜在问题。可以让 LLM 帮你检查 commit message 的英文表达。但不要直接让 LLM 生成大段补丁然后原样提交。如果你确实想用 LLM 辅助生成补丁请务必做到以下三点理解每一行改动的含义能够回答维护者的追问。用 checkpatch.pl 和编译验证生成结果。在 commit message 中如实描述改动意图而不是照搬 LLM 的输出。6.3 安全修复补丁的特殊流程如果你的补丁属于安全修复那么流程会略有不同。除了标准的补丁格式外还需要注意在提交信息中明确指出漏洞类型、影响范围和利用条件。如果涉及 CVE 编号可以在邮件主题中注明。对于敏感漏洞社区可能要求先走安全邮件列表securitykernel.org进行协调披露而不是直接公开。安全修复同样需要经过Signed-off-by和完整的代码审查。需要特别强调的是以“修复安全漏洞”为名提交 LLM 生成的伪修复补丁是一种非常危险的行为。它不仅会消耗维护者大量精力还会破坏社区对提交者的信任。7. 总结Linux 内核 staging 子系统拒绝 LLM 补丁本质上是内核社区在 AI 时代对代码质量的一次重新校准。AI 工具能生成语法正确的代码但内核代码的价值在于对硬件、内存、并发和异常路径的深刻理解这些恰恰是 LLM 难以真正掌握的。对于普通开发者来说这件事带来的启示很简单AI 可以成为非常强大的辅助工具但它替代不了你对代码的理解。真正能让你在内核社区立足的不是提交了多少补丁而是每次提交都能清晰解释“为什么这样改、测试过什么、解决了什么问题”。如果你正准备给内核提交第一份补丁不妨先找一个自己真正感兴趣的驱动花时间读懂它的代码然后从一个 TODO 注释开始。等你的补丁被Acked-by的那一刻你会觉得之前投入的时间全部值得。下次你在给内核提交补丁之前不妨先问自己一句这个改动我真的理解了吗