Linux 内核社区正在探讨如何将大型语言模型（LLM）工具整合到其开发流程中。这场讨论的核心议题包括如何披露 AI 的使用、如何处理 版权归属，以及最重要的——谁来承担责任。尽管这些工具有潜在的好处，但它们也带来了关于代码质量、维护者负担和法律风险的严峻挑战，社区目前尚未就此达成共识。
争论的起点
内核社区关于 AI 工具的讨论，源于开发者 Sasha Levin 使用 LLM 生成了一个内核补丁，而接收该补丁的维护者对此并不知情。这一事件引发了广泛关注，并催生了两种不同的提案：
- David Alan Gilbert 提议： 引入一个新的补丁标签
Generated-by，用于明确标识由工具（不仅限于 LLM）生成的代码。 - Sasha Levin 提议： 使用现有的
Co-developed-by标签，但强调 LLM 不应像人类合作者那样添加Signed-off-by签名。
无论采用哪种方式，核心思想都是在补丁中明确标注 LLM 工具的使用情况。
一个更根本的问题：我们应该接受 AI 补丁吗？
在深入讨论技术细节之前，一些开发者认为需要先回答一个更基本的问题：内核社区是否应该从一开始就接受 LLM 生成的补丁？
如果没有先制定相关政策，仅仅合并这些配置会传达一个信息：内核现在正式接受由编程助手完成的贡献，而开发者无需再关心其他问题。
许多开发者担心，这些工具会催生大量提交者自己都无法理解的补丁，其中可能包含难以发现的微妙错误。QEMU 项目已经明确禁止了 LLM 生成的贡献。另一位开发者则将这些工具形容为“力量倍增器”，只会让那些本就提交着自己看不懂的机器生成补丁的开发者变本加厉。
然而，完全禁止似乎也不现实。有开发者认为，无论内核政策如何，这些工具都会被私下使用。因此，鼓励大家公开诚实地披露使用情况，反而更有利于审查。
披露、版权与责任
假设社区最终会接受 LLM 生成的代码，那么随之而来的是一系列实际问题。
如何披露？
虽然有少数人认为工具信息应放在补丁系列的封面信中，但主流观点倾向于在补丁本身中包含明确的标签。
- 支持的理由：
- 有助于追踪由特定工具引入的 错误模式。
- 在出现 版权问题 时，便于追溯。
- 让“担心的人可以追踪我们的机械霸主在做什么”。
一个悬而未决的问题是 披露的界限 在哪里。使用代码自动补全需要披露吗？使用编译器诊断发现问题呢？一个可能的标准是：“如果 AI 为你创建了任何算法，那么就必须披露”。
版权归属
LLM 生成代码的版权状态是一个巨大的法律雷区。如果这些代码最终被认定侵犯了他人版权，内核项目可能会面临法律风险。
目前的临时解决方案依赖于 Linux 基金会的指导方针，即开发者需要确保工具本身不对其生成的代码施加限制，并且代码不包含任何受版权保护的现有材料。
最终责任人
AI 不会自己发送补丁——是人类在做这件事。
这是整个讨论中反复出现的核心观点。无论代码来自何处，最终的责任都落在提交补丁的人类开发者身上。通过添加 Signed-off-by 标签，提交者即声明他们对补丁的合法性负责。
这意味着提交者必须：
- 理解代码 的工作原理。
- 能够回答关于代码的 技术问题。
- 能够修复其中可能出现的 任何错误。
尽管这个逻辑很清晰，但并不能完全打消维护者的顾虑。
我们不能一边抱怨维护者负担过重，一边又鼓励人们用更多这类东西来轰炸我们。
现实情况是，低质量补丁的涌入已经是一个问题，而 LLM 很可能使情况恶化一个数量级。
讨论仍在继续
如何将 LLM 工具融入内核开发流程，将是社区在未来很长一段时间内讨论的焦点。这些工具在带来潜在好处的同时，也带来了版权、错误和维护压力的风险。可以预见，这场关于 AI 在开源世界中角色的对话，才刚刚开始。