文章摘要
Linux内核创始人Linus Torvalds对AI态度转变，从两年前称90%的AI叙事是炒作，到如今承认其为有效工具。这源于邮件列表上关于AI代码审查工具Sashiko的争论，他明确Linux非反AI项目。社区已形成AI贡献规范，虽允许AI参与开发，但责任由人类承担。其言论引广泛讨论，支持与质疑并存。

Linux内核创始人Linus Torvalds对人工智能的态度正在发生显著转变。从两年前直言90%的AI叙事都是营销炒作，到如今明确承认AI已经成为行之有效的工程工具，这位开源社区的标志性人物为Linux内核社区的AI应用划定了清晰边界。

这场态度的公开表态，源于Linux内核邮件列表上一场关于AI代码审查工具的争论。争议的核心是一款名为Sashiko的智能审查系统，它可以读取内核补丁并基于大语言模型生成分析意见，且支持切换不同的AI模型。开发者Laurent Pinchart提出，维护者在使用Sashiko的结果前，必须先自行验证筛选，再联系补丁作者，他同时援引了软件自由保护组织的相关建议。另一位开发者Roman Gushchin则对此提出反驳，认为强制要求完整验证会让Sashiko帮助维护者的初衷落空，真正的问题应该是Linux是否原则上反对AI工具。

正是在这样的讨论中，Linus给出了强硬且明确的回应。他直言Linux并非反AI项目，不认同这一方向的开发者可以按照开源规则分叉内核，或是直接离开社区。他强调，AI和编译器、静态分析工具一样，本质上都是开发辅助工具，虽然并不完美且会带来新问题，但如今AI是否有用已经不再是值得争论的话题。

需要说明的是，软件自由保护组织的建议并非简单的AI禁令。该组织提出，开源社区应当支持拒绝使用AI的开发者，项目也可以根据维护能力决定是否接收AI生成的贡献；但同时也强调，开源项目不应排斥使用AI的贡献者，提交AI辅助代码前必须充分审核、理解内容并披露AI使用细节，在能够加速软件改进的场景下，使用专有AI工具甚至可以被视为战略性妥协。因此这场争论的核心并非支持或反对AI，而是AI输出的验证责任该如何在工具开发者、提交者、维护者之间分配。

尽管态度鲜明，Linus并未主张内核无条件接受AI生成的代码。他明确表示，不会强迫任何人使用AI工具，但同样不会容忍试图阻止其他开发者使用AI的行为。对于AI容易出错的批评，他用一贯的讽刺口吻回应：AI并不完美，但批评者或许也该审视自身，因为“自然智能也并非总是出色”。他将讨论拉回Linux内核的核心原则：这个项目首先是一个技术共同体，开源协作带来的社区价值只是附加收益，而非存在的首要目的，因此AI相关的决策应当基于技术效果，而非对新工具的恐惧。

事实上，Linux内核社区已经形成了明确的AI贡献规范。根据官方文档，使用AI参与内核开发必须遵守常规的开发流程、编码规范和补丁提交要求，AI代理不能自行添加“Signed-off-by”标签——这一标签代表提交者对开发者原创证书的法律确认，只能由人类完成。提交者必须审核所有AI生成的代码，确认许可证兼容性并承担全部责任；如果使用了AI辅助开发，还建议使用“Assisted-by”标签标注工具名称、模型版本和相关分析工具。简言之，Linux允许AI参与开发，但最终责任必须由人类承担。

Linus此次的表态和两年前的公开评价形成了鲜明对比。2024年10月的维也纳开源峰会上，他曾承认AI有趣且可能改变世界，但同时痛斥行业围绕AI的炒作，认为当时90%的AI宣传都是营销，真正有价值的内容仅占10%。他当时选择暂时忽略AI，并认为需要五年时间才能看清AI在实际工作负载中的真实价值。而到了2026年，Linus已经明确表示，AI是否有用已经“毫无疑问”，怀疑这一点的人大概率没有真正使用过AI。如今AI已经能够在内核漏洞发现、补丁检查和代码审查中提供可验证的结果，Linus依然反感炒作、拒绝低质量的AI输出，但已经不再纠结AI是否有用这一命题。

和Linus一样态度转变的还有Linux稳定版维护者Greg Kroah-Hartman。他在今年3月的表态中提到，此前很长一段时间里AI生成的错误报告质量低劣，大多是浪费维护者时间的垃圾内容；但到2026年初，情况发生了变化，AI开始提交真实、可复现且质量较高的漏洞报告，这一变化不仅出现在Linux内核，也出现在多个开源项目的安全团队中。Greg曾测试相关工具，得到约60个问题和修复方案，其中三分之一的修复方向有误，但大多指向真实问题；另外三分之二的补丁基本正确，不过这些内容依然需要人类进行清理、验证并按照内核流程完成整合。

Linus并非没有看到AI给维护者带来的负担。就在此次表态前两个月，他就曾公开批评AI生成的重复报告和不必要的补丁。今年5月，他提到Linux内核的私密安全邮件列表正收到大量AI工具发现的问题，同一个漏洞可能被不同工具反复报告，导致原本用于处理敏感安全问题的列表几乎无法管理。他建议，通过AI发现问题的开发者不应直接抛出原始结果，而是应该阅读文档、理解问题、检查是否已有报告，最好还能尝试编写补丁，在AI结果的基础上增加人类价值，而非仅做“路过式报告”。在另一次内核候选版本发布中，他还批评了AI代码审查触发的琐碎修复，认为这类修改即便局部无误，也没必要在版本周期后期并入内核，简单的改动也可能引入回归风险，提交者需要思考的不是AI是否找到了可修改的代码，而是问题是否严重、是否会造成真实回归、是否值得在当前阶段修改。

这些表态勾勒出Linus相对完整的AI观：AI可以帮助寻找漏洞、检查代码和协助开发，但发现理论问题不等于生成了值得提交的漏洞报告，生成可编译的修改也不等于形成了值得合并的补丁。AI负责扩大搜索范围，人类依然需要判断问题是否真实、修复是否必要、修改是否安全，以及是否符合项目当前的开发节奏。

这也是整个开源行业正在面对的矛盾：AI降低了发现可疑代码、撰写报告和生成补丁的成本，却没有以同样的比例降低维护者验证、沟通和承担风险的成本。以curl项目为例，维护者Daniel Stenberg观察到，明显低质量的AI垃圾报告有所减少，但更可信、需要认真验证的AI报告正在增加，这类报告质量更高却更耗时，AI让报告生成更快，并不意味着维护者可以同样快速地完成复现、风险判断和修复。因此AI给开源社区带来的未必只是“垃圾内容泛滥”，还可能是更棘手的局面：大量报告并非完全错误，但每一份都需要人类花费时间判断其准确程度。

Linus的言论在社区中引发了广泛讨论，支持与质疑并存。有用户认为Linus的态度务实，即便个人不喜欢AI，也无法忽视其已经普及的事实；也有用户指出，当前很多开发者在反向使用AI：不是用AI帮助人类审查代码，而是让AI批量生成代码，再把审核压力甩给维护者。还有开发者采取更有条件的立场，支持AI用于漏洞检查、科学研究等高风险场景，但反对企业以牺牲普通人为代价追逐利润、滥用AI进行大规模监控，在代码开发上可以接受AI辅助找漏洞，但不愿让大语言模型直接生成最终补丁。

部分用户认为部分媒体标题夸大了Linus的敌意，认为他真正想表达的是AI在负责任开发者手中具有实际价值，但也有用户指出，他明确提出“可以分叉或离开”的表述，也让这类标题并非毫无依据。不少开发者将注意力放在AI带来的工作量膨胀上，有开发者提到，部分同事对AI工具的滥用让自己的工作更困难，AI大幅提高了代码产出速度，也让使用者对输出结果过度自信，最终由其他工程师负责修复和重构，面对快速增长的代码变更，审查者甚至不得不使用同类AI工具才能跟上提交速度。还有观点认为，“AI只是工具”的说法过于简化，普通编译器、编辑器不会涉及训练数据争议、算力消耗、基础设施控制权和就业替代等问题，即便AI在代码审查中有效，也不能就此认为围绕AI的其他社会经济问题已经得到解决。

以上内容不代表本平台立场，仅供读者参考