如果说过去两年，开源社区对AI的态度还停留在“要不要用”的争论上，那现在，这个问题已经被现实彻底改写了——在不可避免要使用AI的前提下，怎样把风险降到最低？
就在最近，围绕AI生成代码的长期争议，终于在Linux内核社区尘埃落定。Linus Torvalds与内核维护者们，正式制定了一套项目级别的AI代码使用规范。
一句话概括就是：AI可以用，但你必须为它的一切后果负责。
Linus的态度：AI只是工具，“禁止AI”毫无意义
过去几个月，Linux内核社区其实一直处于一种微妙的拉扯状态：
一边是越来越普及的AI编程工具，比如GitHub Copilot和Claude等大模型；另一边，则是维护者对代码质量、法律风险以及社区文化深深的焦虑。
争论的爆发点出现在今年年初。当时，来自Intel和Oracle的内核开发者围绕“是否应该严格限制AI代码”公开出现分歧，讨论一度升级为社区层面的激烈对抗。有人主张强监管甚至封禁，有人认为这不过是技术演进中绕不开的阶段。
最终，Linus Torvalds亲自下场，用一句话给这场争论画上了句号：“讨论AI垃圾代码这事儿，其实毫无意义，这纯粹是在犯蠢。”
在他看来，AI本质上和编辑器、编译器一样，只是工具，真正需要监管的是“人”，而不是他们用了什么工具。与其试图“禁止AI”，不如把责任牢牢绑定到提交代码的那个人身上。
不管用不用AI，反正谁提交的谁负责
此次新政策最核心的变化，看上去只是一个标签的调整：AI生成的代码不能使用Signed-off-by标签，而必须添加Assisted-by标签，以明确标注AI参与了生成过程。
简单介绍一下背景：在Linux的开发流程中，Signed-off-by一直是一个极具法律意义的标签，它意味着提交者承诺：代码来源合法，并且有权提交。现在，这个标签被明确禁止用于AI生成内容，取而代之的是一个新的标签——Assisted-by。
这个调整的目的，其实非常清晰：
AI参与必须被明确标注（透明性）；最终责任仍然完全归属于人类开发者（可追责）。
换言之，无论代码是你写的，还是AI帮你生成的，只要是你提交的——出了Bug、性能问题，甚至安全漏洞——责任都在你。Linux社区并没有试图去定义AI的“可信度”，而是直接绕开这个难题，把问题重新拉回到最传统的工程原则上：谁提交，谁负责。
为什么开源社区对AI如此焦虑？
如果只看表面，很容易把这场争论理解为“老派工程师 vs 现代新工具”的冲突。但实际上，这不是一个技术问题，而是一个法律问题。
开源世界长期依赖一个关键机制：DCO（Developer Certificate of Origin），即开发者在提交代码时，需要声明：这段代码是我有权提交的。但问题来了——像Copilot、ChatGPT这样的AI，是基于海量开源代码训练的，其中包含了GPL（GNU General Public License）等强限制许可证，以及各种版权来源不明的数据。
这就造成了一个尴尬局面：开发者其实无法完全证明AI生成代码的“来源合法性”。这一点，Red Hat在此前的分析中曾明确警告：使用AI生成代码，可能会在无意中导致开源许可证违规，甚至可能从根本上冲击DCO体系。
除了法律风险，还有一个更现实的问题：AI代码太多了，而且质量参差不齐。开源社区甚至给它起了个名字——“AI slop”（AI垃圾代码）。
这些代码往往看起来结构完整、语法正确，但在逻辑上漏洞百出，甚至夹杂大量“幻觉”。现实中，已经发生了不少真实案例：
cURL的维护者因被大量AI生成的错误报告淹没，不得不关闭了漏洞奖励机制；白板工具tldraw开始自动关闭外部PR，以减少无效提交；Node.js、OCaml等项目中，甚至出现过上万行的AI生成补丁，引发维护者争议。
说到底，社区真正无法接受的，并非AI本身，而是“隐瞒使用AI”的行为。
有一个典型事件发生在Linux内核内部：NVIDIA工程师、内核维护者Sasha Levin曾提交了一段完全由大模型生成的补丁，但没有任何AI标注。这段代码虽然能运行，却引入了性能回退问题，并在评审阶段误导了其他维护者。
事后，连Linus Torvalds也承认：因为没有标注AI，这段代码没有被充分审查。所以，问题的本质其实很清晰：开源社区不怕你用AI，但非常反感你“装作是自己写的”。
不只是Linux，整个开源圈都在“震荡”
类似的冲突并不只发生在Linux：在经典游戏Doom的Mod社区中，GZDoom项目也曾因为AI使用问题陷入分裂。
当时，项目负责人Christoph Oelckers被发现使用AI生成代码却未披露，面对社区质疑时，他直接“摆烂”：“不满意可以fork。”结果，社区真的这么做了——一个名为UZDoom的新分支迅速出现，大量核心开发者迁移过去，原项目元气大伤。
事实证明，在开源世界，透明性一旦被打破，分裂几乎是不可避免的结果。
对比来看，Linux内核社区给出的最终答案，其实非常“工程师思维”：代码好不好，比是不是AI写的更重要。你可以用AI生成代码，但如果代码有问题、如果它是“AI垃圾”、如果它把内核搞崩了——那么，点下“提交”的那个人，要亲自向Linus负责。
在Linux的开源世界里，这大概已经是最强的约束机制了。
