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

By *Jonathan Corbet*, December 11, 2025
 Gemini translation
https://lwn.net/Articles/1049830/

维护者峰会 (Maintainers Summit)

2025年维护者峰会的第一个讨论话题已经酝酿多时：基于机器学习（Machine Learning，简称 ML）的工具在内核开发过程中应该扮演什么角色——如果确实有的话？虽然围绕这些工具存在相当多的争议，且担忧依然存在，但内核社区，或者至少是其高层维护者群体，似乎对于这些工具成为开发过程中的重要组成部分感到接受。 

Sasha Levin 通过引用他几天前发送到邮件列表的一份总结开启了讨论。他说，目前已达成一些共识，即补丁 (Patch) 的人类问责制至关重要，在创建补丁时使用大语言模型 (Large Language Model, LLM) 并不改变这一点。在没有人类参与的情况下，纯机器生成的补丁是不受欢迎的。维护者必须保留根据自己的判断接受或拒绝机器生成贡献的权力。此外，他表示，大家一致认为应当以某种方式披露工具的使用情况。 

仅仅是工具吗？

他向与会者问道：大家是否普遍同意，这些工具最终只是更多的工具而已？Steve Rostedt 表示，LLM 生成的代码可能会带来其他工具没有的法律顾虑，但 Greg Kroah-Hartman 回答说，现有的开发者原产地证书 (Developer Certificate of Origin, DCO) 流程（即 Signed-off-by 机制）应该能够涵盖法律方面的问题。Rostedt 同意提交者最终要对其贡献的代码负责，但他担心如果未来某天法院裁定某个模型侵犯了版权，而内核已经接受了它生成的代码，可能会导致大量的清理工作。 

Ted Ts'o 表示，人们担心版权问题，但即使没有这些工具，同样的问题也依然存在。例如，开发人员可能会绕过雇主要求的流程提交补丁，从而导致他们实际上无权提交这些补丁。他说，我们现在并不担心这个问题，而且它几乎从未真正发生过。Jiri Kosina 则认为，这些工具让代码编写变得非常容易，随着时间的推移，这个问题可能会变得更加严重。Dave Airlie 询问追踪人们正在使用哪些模型是否有意义。但他指出，LLM 放入补丁中的任何受版权保护的代码，很可能都来自内核 (Mainline，主线) 本身。 

Levin 提到，有人对 LLM 的使用及其对世界其他地区的影响提出了伦理方面的担忧。Arnd Bergmann 表示，区分正在使用的模型类型可能是有意义的。在本地运行自己的模型与使用第三方的工具是不同的。 

Linus Torvalds 插话道，他认为对话过于集中在利用 LLM 编写代码上，但目前在内核领域这种情况并不多见。因此，围绕 LLM 编写的代码所产生的任何问题目前都纯属假设。但是，这些工具 确实 被用于其他用途，包括识别 CVE 候选对象和稳定版后向移植 (Stable-backport) 候选对象，以及补丁审查 (Patch Review)。Torvalds 说，Andrew Morton 最近展示了一个机器审查补丁的例子，效果令人“震惊”；它发现了 Torvalds 对该补丁提出的所有问题，甚至还多发现了几个。 

Alexei Starovoitov 表示，在 Meta 内部，自动化工具在大约 60% 的情况下能产生高质量的评审意见，另外 20% 也有一些可取之处。只有不到 20% 的评审意见是误报 (False Positive)。Jens Axboe 补充说，他一直在用旧补丁进行测试，并看到了类似的结果。他把一个包含已知问题的五行补丁发给三位人类评审员，没有人发现 bug。但自动化工具发现了问题（测试中的一个条件反转）；“AI 总是能抓住这类东西”。 

Christian Brauner 询问在场有多少人在编程时使用 LLM；大约有四位开发人员举了手。Shuah Khan 对获取 LLM 的途径表示担忧；大部分工作都是在企业防火墙之后完成的。Ts'o 说，他一直在将 Chris Mason 为 Claude 编写的评审提示词 (Prompt) 用于 Gemini，效果通常很好，且成本相对较低。 

不过，Torvalds 指出，开发人员长期以来一直在抱怨缺乏代码评审；LLM 可能会解决这个问题。他说，目前它们还没有在写代码，尽管这在未来某个时刻也可能发生。一旦这些系统开始提交内核代码，我们确实需要自动化系统来评审所有这些代码。 

专有系统

Konstantin Ryabitsev 说他曾尝试使用其中的一些系统，但发现它们太贵了；他还担心对专有技术的依赖。Brauner 表示，这种使用必须得到雇主的支持，或者 Linux 基金会 (Linux Foundation) 可以尝试提供自动化评审服务。Ts'o 表示，成本取决于系统的使用方式。如果拉取整个内核并消耗大量标记 (Token)，那将非常昂贵。另一种方法是创建一套评审规则，将标记的使用量减少至少五倍。Khan 再次强调，并非所有开发人员都能平等地获得这项技术。 

Mark Brown 担心要求提交者通过专有工具运行补丁会引起一些人的反对。Axboe 建议评审工具应该由子系统维护者运行，而不是提交者。 

我（Jonathan Corbet）指出，20年前内核社区突然失去了对 BitKeeper 的访问权，这突显了依赖专有工具的风险。如果内核社区变得依赖这些系统，当不可避免的“撤垫子”发生时，开发将会受到影响。在某种程度上，如果背后的公司想要实现其营收目标，使用 LLM 的成本必然会大幅增加。 

然而，Torvalds 称这种担忧是“伪命题”。他说，我们今天并没有这些工具；如果它们明天消失了，社区只会回到现在的状态。同时，他说，我们应该利用科技行业愿意挥霍数十亿美元让人们使用这些工具的机会。即使这种情况只持续几年，它也能为社区提供帮助。 

Starovoitov 表示，他非常喜欢 BPF 社区从 LLM 系统中获得的评审意见。即使评审是错误的，它们也会提出很好的问题。更棒的是，开发人员会回答这些问题，尽管他们是在回答一个机器人；这些答案可以用来帮助模型在未来做得更好。但他承认，最近 GitHub 的一些问题导致了三天的停机；这“感觉非常糟糕”。他当时只能等待服务恢复，因为它在评审方面做得比他还要好。 

披露

Levin 将讨论转向了披露要求。有人提议使用 Assisted-by 标签来注明所使用的具体工具；该标签应该是针对所有工具，还是仅针对 LLM？Torvalds 表示他希望能看到指向 LLM 生成的评审的链接，但不需要特殊的评审标签。Ts'o 表示同意，认为人们需要查看评审以确定其是否合理，但他指出很多评审并没有公开。Starovoitov 回答说，BPF 子系统的评审是以邮件回复补丁的形式公开的。 

Kees Cook 说他不在乎具体使用哪个标签，他只想知道应该用什么；Torvalds 回答说根本不需要标签。这些信息可以直接放在变更日志 (Changelog) 中。Ryabitsev 建议将其放在 — 标记之后，这样它就不会出现在 Git 变更日志中，但 Bergmann 说他更希望在变更日志中看到这些信息。Torvalds 指责大家过度思考了这个问题，并表示最好去尝试看看什么行得通。社区应该鼓励披露工具使用情况，但不应制定关于如何披露的死板规定。 

Ts'o 表示，无论如何，不能指望提交者都披露他们使用的工具；有些人可能会撒谎。Dan Williams 表示，披露规则将明确表明社区重视这一领域的透明度。Levin 补充说，这些工具的一个优点是它们听话；如果在文档中加入披露规则，模型就会遵守。Williams 建议制定一条规则，要求所有变更日志都必须提到矮妖 (Leprechauns)。 

会议即将结束时，Levin 表示他将提交一个文档补丁，要求 LLM 工具添加 Assisted-by 标签，但不会努力强制执行该规则。关于该标签的细节进行了一些最终讨论，它显然会随着时间的推移而演变。 

LWN 评论概述

评论区针对内核开发引入 AI 工具展开了激烈辩论，主要集中在版权风险、学习本质以及资源分配三个方面。一位评论者指出，Ted Ts'o 低估了版权风险，因为 LLM 是在未经许可的情况下摄取海量代码训练的，这与以往的风险环境截然不同。另一位评论者反驳称，人类大脑也是通过摄取代码学习的，版权核心在于“复制”而非训练方式。此外，有意见尖锐地指出，如果 Linux 基金会有财力投入 AI 评审，理应优先资助人类维护者。他们认为，付费让维护者全职工作的效果远胜于现有的 LLM。总体而言，尽管开发者对 AI 捕捉细微 bug 的潜力感到兴奋，但对依赖专有系统和法律不确定性仍持高度戒备。 

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

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

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