LWN：讨论内核开发中使用 LLM 助手！

关注了就能看到更多这么棒的文章哦～

On the use of LLM assistants for kernel development

By Jonathan Corbet
August 7, 2025
Gemini flash translation
https://lwn.net/Articles/1032612/

从某些方面来看，至少内核社区（kernel community）里来自人工智能驱动的软件开发工具（AI-driven software-development tools）的冲击还是相对比较小的。目前还没有大量直觉式编写（vibe-codeding）的内存管理补丁（vibe-coded memory-management patches）涌现出来——至少暂时还没有。但内核开发（kernel development）终究是软件开发，而这些工具可能会改变软件开发的方式。在公司积极推动开发者使用这些工具的这个时代，内核圈子中对此话题的关注度日益提升也就不足为奇了。目前，关于基于大型语言模型（LLM）的工具如何融入内核开发社区，存在着许多持续的讨论。

可以说，当前这场辩论始于 这篇文章，内容是 Sasha Levin 在六月北美开源峰会（Open Source Summit North America）上的一次演讲；他利用 LLM 生成内核补丁（kernel patch）的做法，令包括接受该补丁的维护者在内的一些开发者感到惊讶。此后，David Alan Gilbert 发布了 一个补丁，提出了在内核开发中披露 LLM 使用情况的要求。Levin 则发布了 他自己的一系列补丁，重点是为编程助手（coding assistants）提供配置和使用指南。这两份提交都引发了超出其原本相对狭窄目标的讨论。

Gilbert 建议使用一个新的补丁标签（patch tag），Generated-by，来标识用于创建内核补丁的工具；这个标签不仅适用于 LLM 生成的补丁，也适用于像 Coccinelle 这样长期被接受的工具所生成的补丁。Levin 则建议使用现有的 Co-developed-by 标签，但他特意指出，LLM 不应 添加通常与 Co-developed-by 标签同时要求的 Signed-off-by 标签。无论哪种方式，其建议都是在任何由基于 LLM 的工具生成的补丁的标签部分（tags section）中添加相关信息。

A step back

尽管大部分讨论直接跳入了这些补丁的细节，但一些开发者显然认为，首先有一个更根本的问题需要回答：内核社区是否愿意接受 LLM 开发的补丁？Vlastimil Babka 回复 称 Levin 的补丁集（patch set）“为时过早”，并指出在尝试正确配置 LLM 之前，有必要先为人类制定规则：

因此，如果没有这样的策略（policy），我担心仅仅合并这些补丁本身就会传递出一个信息，即内核现在正式接受使用编程助手完成的贡献，并且这些助手会根据配置文件（configuration files）做正确的事情，而使用助手的开发者无需再操心其他事情，因为一切都已由配置涵盖。

Lorenzo Stoakes 表示，首先需要一份“官方内核 AI 策略文档（official kernel AI policy document）”，并建议最好在维护者峰会（Maintainers Summit）（将于十二月举行）上进行讨论。他同意 Babka 的观点，即在没有此类策略的情况下合并这些补丁，等同于公开声明内核社区欢迎 LLM 生成的补丁。

一些开发者表达了担忧，认为这些工具将被用于生成提交者自己都不理解的补丁，并且这些补丁可能包含比平时更多的隐蔽 bug（subtle bugs）。David Hildenbrand 担心，他最终会遇到那些只是简单地将他的问题提交给最初生成补丁的工具的贡献者，因为他们自己无法解释代码。他还指出了 QEMU 项目 采用的策略，该策略实际上禁止了在该项目中进行 LLM 生成的贡献。Al Viro 将 基于 LLM 的工具描述为“倍增器（force multiplier）”，对于多年来一直提交他们不理解的机器生成补丁（machine-generated patches）的众多开发者而言。

而 Mark Brown 则 建议，无论内核策略如何，这些工具都将被使用：

我也担心提交者（submitters）无论我们说什么都会默默地使用这些东西，从这个角度来看，鼓励人们对此公开透明是值得的，这样在审查发送的变更（changes）时就可以将其考虑在内。

Levin 的 观点 是，内核目前的策略是“我们接受代理生成（agent generated）的贡献，除了对普通人类的要求外，没有任何其他要求”；他的目标是弄清楚这些额外要求应该是什么。还应该指出的是，一些开发者显然认为这些工具是有帮助的；例如，Kees Cook 反对 任何形式的禁令，称其“既无用，也不现实，更不可强制执行”。在其他地方，他 评论 说“这些工具终于变得有趣了”。

Disclosure

如果内核项目要禁止 LLM 生成的代码，那么接下来的讨论就变得没有意义了（moot），但这似乎是一个不太可能的结果。如果假定会有（更多）LLM 生成的代码进入内核，那么就会出现一些问题，首先就是工具使用情况的披露。Gilbert 和 Levin 都提议添加补丁标签来记录这种使用。不过，有几位开发者不同意这个想法；Konstantin Ryabitsev 表示，这些信息应放在补丁系列（patch series）的封面信（cover letter）中，而不是放在标签中。目前工具生成的代码就是这样描述的，他认为没有理由改变这种做法。Jakub Kicinski 认为，关于工具的信息“只在审查期间才相关”，因此将其放入补丁更新日志（patch changelogs）中“不过是为相关工具免费广告（free advertising）”。

然而，共识观点（consensus view）似乎倾向于将工具信息包含在补丁本身中。Cook 最初 倾向于 将工具信息排除在标签之外，但后来 承认，如果需要追溯（track down）由特定工具创建的所有补丁，这些信息将很有用。Steve Rostedt 表示，这些信息对于发现特定工具引入的 bug 模式可能很有用。Laurent Pinchart 指出，规范化的补丁标签（formalized patch tags）对于追查任何版权相关问题（copyright-related problems）也很有用。Gilbert 评论 说，披露“能让那些担心我们机械霸主（mechanical overlords）行为的人有所了解”。

如果采取必须披露工具使用的立场，那么下一个问题必然是：界限应该划在哪里？Levin 问道，例如，使用代码补全工具（code-completion tool）是否需要披露。其他人提到了使用编译器诊断（compiler diagnostics）来发现问题，或使用语言敏感编辑器（language-sensitive editors）。显然，在某个点上，要求披露是毫无意义的，但目前还没有就这个点达成共识。Rostedt 提出 的一个可能的规则是：“如果人工智能为你创建了任何算法（algorithm），那么它必须被披露”。

与此同时，Levin 首次尝试用 Co-developed-by 标签披露 LLM 使用情况的 补丁，引来了 Andrew Morton 的 一句有趣的回复，他似乎没有关注这场对话。Hildenbrand 回应 说，一个新的标签，比如 Assisted-by，会更合适；Ryabitsev 也 提出了这个建议。

Copyright and responsibility

LLM 生成代码的版权状态（copyright status）是许多开发者关注的问题；如果 LLM 生成的代码最终受到某个人的版权主张（copyright claim），将其纳入内核可能会使项目面临未来的 SCO 诉讼情景（SCO-lawsuit scenario）。当然，这是一个远超内核社区的问题，很可能需要全球范围内的多年法庭纠纷（court battles）才能解决。然而，在此期间，维护者将被要求接受 LLM 生成的补丁，并且必须在法律程序走完之前做出决定。

Levin 指出 了 Linux 基金会关于生成式 AI（generative AI）的指南，称这是内核社区目前默认遵循的策略。简而言之，该指南建议开发者应确保工具本身不对其生成的代码施加限制，并且代码不包含任何已存在的受版权保护的材料（pre-existing, copyrighted material）。Levin 建议以此文档作为判断提交内容版权状态的起点，但该指南的帮助程度有限。

Michal Hocko 问道，维护者如何才能知道那份“相当模糊”的指南中建议的条件是否已得到满足。Levin 的 回答 反映了讨论中几次出现的一个主题：这就是补丁提交者所应用的 Signed-off-by 标签的作用。通过应用该标签，提交者表明该补丁是对内核的合法贡献（legitimate contribution）。与任何其他补丁一样，贡献者在添加该标签之前需要确保自己非常有把握（on solid ground）。

这种推理不仅延伸到版权状态，还延伸到补丁在所有层面的责任。Rostedt 建议 明确签署（signoff）也表明提交者 理解 代码并能修复其中的问题。Viro 说，对于任何补丁，无论其来源如何，“必须有人能够处理对其提出的积极提问（active questioning）”。Levin 补充道：“人工智能不会自行发送补丁——人类才会”，因此，补丁背后的人类将最终对其内容负责。

这种推理有其道理，但可能无法完全安抚紧张的维护者。提交 LLM 生成补丁的人，不太可能比维护者更有能力判断其作品的版权状态。与此同时，维护者多年来不得不处理那些明显不理解自己在做什么的贡献者提交的补丁；文档化这些贡献者必须理解编码工具的输出，似乎不太可能减缓这种泛滥。Hildenbrand 这样表达了他的担忧：“我们不能一边抱怨维护者工作过载（maintainer overload），一边又鼓励人们用更多此类东西来轰炸我们。”根据在其他领域所见，低质量补丁（low-quality patches）的流量出现数量级增长（order-of-magnitude increase）并不会令人惊讶；事实上，Greg Kroah-Hartman 表示，这已经在发生了。

More discussion

最终结果是，如何将基于 LLM 的开发工具整合到内核项目的工作流程（workflow）中，这个问题可能会在社区讨论中占据相当长一段时间的重要位置。虽然这些工具可能带来好处，包括发现人类难以察觉的模式以及耐心生成测试代码，但它们也可能带来版权问题、bug 和额外的维护者压力。使用这些工具的压力不会消失，即使当前人工智能泡沫最终破裂，似乎也不太可能改变这一点。

在 2025 年维护者峰会（Maintainers Summit）的 议题征集（call for topics） 发布后的几毫秒内，就出现了两个关于内核工作流程中 AI 工具问题的独立提案（分别来自 Stoakes 和 Jiri Kosina）；这些提案引发的讨论，到本文发布时肯定会取得显著进展。看来，不需要 LLM 也能生成大量的文本。换句话说，这场对话才刚刚开始。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～