Linux 内核正式允许使用 AI 辅助编程，但责任全在开发者
近日，Linux 内核维护团队发布正式政策，明确允许开发者在内核开发中使用 GitHub Copilot、Amazon CodeWhisperer 等 AI 编程辅助工具。这一决定并非仓促出台，而是经过数月内部讨论、社区反馈和法律评估后的结果。与一些开源项目彻底封杀 AI 生成代码的做法不同，Linux 团队选择了一条务实路径：不禁止工具，但严控责任。
“AI 是工具，不是替罪羊。”这是 Linus Torvalds 在多次内部邮件中反复强调的观点。他指出，那些靠 AI 生成代码、不加审核就提交的开发者，从来就不会遵守任何“禁止使用 AI”的规则。与其花精力去堵，不如直接让提交者为每一行代码负责——无论这行代码是自己写的，还是 AI 给的。
这一立场与 NetBSD、Gentoo 等项目的禁令形成鲜明对比。后者认为，AI 模型训练所依赖的代码大多来自开源项目（包括大量 GPL 许可的代码），生成的内容可能隐含许可证冲突，甚至构成“代码污染”。而 Linux 团队的回应是：你提交了，你就得能说清楚它从哪来、合不合法。如果连这个都搞不定，那问题不在 AI，而在你。
必须标注：AI 生成的代码，必须被明确标识
新规最核心的一条要求是：开发者在提交补丁时，必须在提交信息（commit message）中明确标注“Generated by AI”或类似说明。这不是建议，而是强制规范。内核维护者将以此为依据，判断代码审查的优先级和责任归属。
“我们不关心你用什么写代码，”一位内核维护者在邮件列表中写道，“但我们必须知道，这段代码是不是你亲手改的。如果是 AI 生成的，那它就更需要被仔细检查——因为它的错误往往更隐蔽、更系统。”
这一要求也回应了开源社区长期的担忧：AI 生成的代码常有“合法外观下的非法结构”。比如，它可能复制了某个 GPL 函数的逻辑，却改了变量名，试图绕过许可证审查；或者在内核驱动中加入看似无害的内存操作，实则埋下安全漏洞。这些都不是人类开发者会犯的典型错误，但 AI 却容易“无意识”生成。
AI 代码泛滥，已让多个项目不堪重负
在 Linux 做出决定前，开源生态早已被 AI 生成的代码冲击。cURL 项目去年一度被数千条 AI 补丁淹没，其中 90% 以上是语法错误、逻辑混乱或重复提交，最终被迫暂停公开的漏洞奖励计划。Node.js 团队内部曾出现过单次提交超过 12,000 行 AI 生成代码的案例，审查团队花了三周才清理干净。
OCaml 社区甚至专门成立了一个“AI 审查小组”，专门识别和回退可疑提交。一位成员在论坛上写道：“我们不是反对技术进步，但我们不能让项目被垃圾代码拖垮。如果 AI 能写代码，那它也得能承担后果——但它不能。所以，人得上。”
这种现实压力，是 Linux 团队最终选择“透明+追责”模式的重要原因。与其让开发者偷偷用 AI，不如让他们公开用、认真审。
开发者该怎么做？别以为“AI 写的”就能免责
这条新规对普通开发者意味着什么？
- 别指望 AI 代劳审核：你提交的每行 AI 生成代码，都得自己理解、测试、验证。内核审查不会因为你写了“Generated by Copilot”就放行。
- 标注要具体：只写“AI 生成”不够。建议写明工具名称，如 “Generated by GitHub Copilot, reviewed and modified by [你的名字]”。
- 法律风险你自己扛：如果 AI 生成的代码侵犯了版权、违反了许可证（比如把 GPL 代码混入 MIT 项目），你就是那个被追责的人。项目不会替你背锅。
- 高质量提交才有机会：内核维护者已经明确表示，AI 生成的补丁若缺乏清晰说明、测试用例或合理修改痕迹，将直接被拒。
事实上，一些经验丰富的开发者已经开始用 AI 做“初稿助手”——比如让 AI 生成一个网络协议的结构体定义，再手动重构、加注释、补边界检查。这种方式既提升效率，又守住质量底线。
未来：AI 不是敌人，但也不是队友
Linux 的决定，不是对 AI 的全面拥抱，而是一次现实主义的划界。它承认了 AI 已成为开发流程的一部分，但拒绝把责任让渡给机器。在开源世界，代码的可信度高于一切。而信任，只能来自人。
正如一位资深内核开发者在邮件中所说：“我们不需要更聪明的 AI，我们需要更负责任的程序员。”
