要么Fork要么走人！Linus怒怼AI反对派：Linux不搞反AI
2026 年 7 月 14 日，Linux 内核邮件列表爆发了一场围绕 AI 代码审查工具的争论。面对部分开发者对大语言模型的抵触，Linus Torvalds 以最高层维护者的身份划下边界：Linux 不是"反 AI 项目"，不认同的人可以按开源方式 fork，或者干脆离开。
核心判断很直接：AI 和编译器、静态分析器、代码搜索工具一样，首先是一种工具。它不完美，会制造新问题，但"它是否有用"已经不再是一个值得争论的问题。Linus 同时强调——不会强迫任何人使用，但也不会理会试图阻止其他开发者使用 AI 的人。
争议起点：Sashiko 智能体审查系统
争论围绕一个名为 Sashiko 的项目展开。这是一套面向 Linux 内核代码变更的智能体审查系统，能从邮件列表或 Git 仓库读取补丁，结合内核特定的提示词、协议和工具生成审查意见，且不绑定单一模型提供商。
开发者 Laurent Pinchart 提出：维护者若要根据 Sashiko 结果采取行动，应先自行筛选验证，再联系补丁作者，并引用了 Software Freedom Conservancy（SFC）针对 LLM 辅助开源贡献的建议。Roman Gushchin 则反驳——如果要求维护者完整验证 AI 每条意见，"帮助维护者"的目标就难以实现，问题应直接聚焦于：Linux 是否原则上反对 LLM？
Linus 的回应是：不是。
SFC 建议不是"AI 禁令"
值得注意的是，被卷入争论的 SFC 建议本身是平衡的：
- 支持完全拒绝使用 LLM 的开发者，无人应在雇主或项目压力下被迫使用 AI
- 但开源项目不应排斥使用 AI 的贡献者
- 提交 AI 辅助代码前，提交者必须充分审核、理解代码，并披露模型名称、版本及 AI 参与方式
- 对能显著加速开源改进的场景，SFC 甚至将使用专有 AI 工具视为可接受的"战略性妥协"
真正的分歧不是"支持还是反对 AI"，而是验证责任在工具开发者、提交者、维护者和原作者之间如何分配。
Linux 内核已有的 AI 贡献规则
Linus 没有给 AI 完全开绿灯。Linux 内核文档已经形成一套明确规则：
- AI 参与开发仍须遵守正常的开发流程、编码规范和补丁提交要求
- AI 代理不能自行添加
Signed-off-by标签（该标签代表对《开发者原创证书》的法律确认，只能由人类完成） - 提交者必须审核所有 AI 生成代码，确认许可证兼容性，承担全部责任
- 涉及 AI 辅助时建议使用
Assisted-by标签，标明工具名称、模型版本
用一句话概括：Linux 允许 AI 参与开发，但最终责任不能交给 AI。
从"90% 是炒作"到承认价值
Linus 此次的态度与其 2024 年的公开评价形成鲜明对比。2024 年 10 月维也纳开源峰会期间，他判断市场上约 90% 的 AI 叙事是营销，真正有价值的可能只有 10%，并将 AI 热潮与加密货币浪潮类比，选择暂时忽略 AI。
不到两年后，他表示 AI 是否有用已经"毫无疑问"，怀疑这一点的人可能根本没真正使用过 AI。到 2026 年，AI 已开始在内核漏洞发现、补丁检查和代码审查中提供可验证的结果。
Linux 稳定版维护者 Greg Kroah-Hartman 今年 3 月也表达了类似改观：AI 生成的错误报告此前质量很差，多为"垃圾"；但到 2026 年初，AI 开始提交真实、可复现且质量较高的漏洞报告。Greg 测试相关工具得到约 60 个问题和修复方案，约三分之一修复方向不正确但通常指向真实问题，约三分之二补丁基本正确——但仍需人类清理验证。
AI 发现漏洞的速度 > 维护者处理速度
Linus 并非没有看到负担。今年 5 月他公开批评：Linux 内核私密安全邮件列表正收到大量 AI 工具发现的问题，同一漏洞被不同人、不同工具反复报告，导致邮件列表几乎无法管理。
他的建议很明确：通过 AI 发现问题的人，不应只把原始输出扔给维护者。报告者应阅读文档、理解问题、检查是否已有人报告，最好尝试编写补丁。提交者必须在 AI 结果基础上增加人类价值，而非进行"路过式报告"。
这勾勒出 Linus 相对完整的 AI 观：
- AI 可以寻找漏洞、检查代码、协助开发
- 但发现一个理论问题 ≠ 产生值得提交的漏洞报告
- 生成一段能编译的修改 ≠ 形成值得合并的补丁
- AI 负责扩大搜索范围，人类仍须判断问题是否真实、修复是否必要、修改是否安全、是否符合项目开发节奏
开源行业的结构性矛盾
这是整个开源行业面临的矛盾：AI 降低了发现可疑代码、撰写报告和生成补丁的成本，却没有以同等比例降低维护者验证、沟通和承担风险的成本。
curl 维护者 Daniel Stenberg 观察到：明显低质量的 AI 垃圾报告有所减少，但更可信、需要认真验证的 AI 报告正在增加——后者质量更高，却更消耗时间。AI 让报告产生得更快，并不意味着维护者能同样快速地完成复现、风险判断和修复。
社区反应：务实支持与条件性质疑并存
在 GamingOnLinux 和 Reddit 等社区，Linus 言论获得大量支持，也引发质疑：
- minus9（GamingOnLinux）：Linus 务实一如既往，"精灵已从瓶子里跑出来"，无法假装 AI 不存在
- pb：让代码审查变更容易是最合理的 AI 用途，但许多人正反过来用——让 AI 批量生产代码，把审核压力甩给别人
- wytrabbit：支持 AI 用于科研、高风险工作和漏洞检查，但反对企业以牺牲普通人为代价追逐利润，不愿让 LLM 直接生成最终补丁
- PlacidTurbulence（Reddit）：部分媒体用"Linus 让 AI 反对者滚去分叉"的标题夸大了敌意，Linus 真正表达的是 AI 在负责任开发者手中具有实际价值
更多开发者关注 AI 造成的工作量膨胀：AI 提高代码产出速度，也让一些使用者过度自信，最终由其他工程师负责修复重构。审查者甚至不得不使用同类 AI 工具才能跟上提交速度。也有人指出，"AI 只是工具"是过度简化——普通编译器不会涉及训练数据争议、算力消耗、基础设施控制权和就业替代压力。
工程视角的启示
对关注 AI 落地和团队效率的工程团队而言，Linux 内核社区的处理方式提供了可借鉴的框架：
- 工具中立，责任归属清晰——不禁止工具使用，但将验证和责任锚定在人类提交者
- 流程先行——通过标签机制（
Assisted-by）和审核要求，让 AI 参与可追溯 - 分层处理 AI 输出——AI 扩大搜索范围，人类做判断、风险评估和节奏控制
- 拒绝"路过式贡献"——要求提交者在 AI 结果上增加人类价值，而非简单转发
Linus 的立场本质上是一种工程实用主义：技术决策应依据技术效果而非对新工具的恐惧，同时拒绝让宏观争议自动转化为对工具的全面否定。
参考链接：