如今围绕LLM是否应被允许参与内核开发、如何披露其使用、责任归属与版权风险等核心问题，一场深刻而复杂的讨论正在展开，这不仅关乎代码本身，更触及开源协作精神的本质。
这场争论的导火索是Sasha Levin在北美开源峰会（Open Source Summit North America）上展示的一次实践：他使用LLM生成了一个内核补丁，并成功提交合并。令人意外的是，连接受该补丁的维护者都未意识到其来源。
这一事件迅速引发社区震动，促使David Alan Gilbert提出一项正式补丁，建议引入新的补丁标签“Generated-by”，用于标识由AI或其他自动化工具生成的代码。
这一提议看似技术细节，实则触及信任机制的根基——我们如何知道一段代码是人类深思熟虑的结果，还是机器“凭空幻觉”的产物？
- Gilbert强调，这种透明化不应仅限于LLM，也应涵盖Coccinelle等长期使用的代码生成工具，从而建立统一的可追溯体系。
- 与此同时，Levin则提出另一条路径：沿用现有的“Co-developed-by”标签来记录AI的参与，但他明确指出，AI不应、也不能签署“Signed-off-by”这一关键法律与责任声明。
然而，部分开发者对此表示质疑：
- A观点：认为工具信息应仅出现在补丁系列的封面信中，而非嵌入每个补丁的元数据；
- B观点：将AI工具名写入变更日志无异于为商业产品免费打广告，有损社区中立性。
更深层次的争议在于：我们是否应该允许AI生成的代码进入Linux内核？
Vlastimil Babka直言Levin的配置提案“为时过早”，在他看来，社区必须先确立明确的人类行为准则，才能讨论如何规范AI的使用。否则，贸然接受这类补丁将传递一个危险信号——即开发者可以依赖AI配置文件自动合规，从而逃避自身的审查义务。
Lorenzo Stoakes进一步呼吁制定一份“官方内核AI政策文件”，并建议在2025年12月的维护者峰会上进行专题讨论。
他警告说，若在无政策框架下合并相关补丁，等同于公开宣布AI贡献已被默认接纳，这将带来不可预知的风险。
这些担忧并非空穴来风。多位资深开发者表达了对“黑箱补丁”的恐惧：提交者可能根本无法理解其所提交代码的逻辑，导致审查过程形同虚设。
- 有人担忧未来会面对一群只会将维护者提问转交给AI、再原样回复的“傀儡贡献者”。
- 有人一针见血地指出，LLM不过是放大了那些多年来提交机器生成代码却不知其意的开发者的影响力。
- QEMU项目已明令禁止AI生成代码，而Linux社区虽尚未采取同样立场，但压力已然显现。
- 有人悲观地认为，无论政策如何，总会有开发者私下使用AI工具，与其掩耳盗铃，不如鼓励公开披露，以便在审查时加以考量。
关于披露的具体标准，社区仍未达成共识。
有人提出一个实用主义标准：“如果AI为你创造了任何算法，就必须披露。”但这仍难以界定代码补全、智能编辑器提示与完整函数生成之间的界限；有的人则反对任何形式的禁令，认为既不现实也无法执行，但他也承认工具才刚刚变得“真正有趣”。
有人认为：开发者在用 AI 工具写代码的时候，要保证工具本身不会对生成的代码加上限制，也不能抄别人的版权代码。但这些要求太模糊了，维护者怎么能确认提交者真的遵守了？
在版权问题上，争议更为复杂：LLM生成的代码是否可能包含受版权保护的训练数据片段？一旦此类代码进入内核，是否会引发类似当年SCO诉讼那样的法律灾难？目前全球尚无定论，但内核维护者却必须在法律空白中做出判断。
社区里慢慢形成了一个共识：还是用传统的 “Signed-off-by” 来解决问题。也就是说，提交补丁的人自己在签名时就得担保，这段代码是合法的、自己能理解、也能维护的。无论代码是谁写的，背后必须有人能回答问题，AI 不会自己去提交补丁，人类才是最终责任人。
不过现实很残酷：如果提交者自己都不懂 AI 生成的代码，那签名的法律效力就大打折扣了。
社区不能一边抱怨维护者已经太累，一边又鼓励更多不懂代码的人提交低质量 AI 补丁，其实这种情况已经在发生。
总结来说，LLM 工具的引入不是单纯的技术选择，而是对开源协作模式的一次大考。它迫使社区重新思考：我们能信任谁？责任谁来承担？质量如何保证？短期内可能不会完全禁止 AI 补丁，但围绕披露、责任和审查的讨论肯定会越来越热。