科技媒体 How-To Geek 在 8 月 10 日刊出的分析文章指出，Linux 社区的紧张情绪始于 AI 生成的贡献大量涌入一套本就没为此设计的评审流程。

生成一分钟，评审两小时

问题的核心其实很朴素：用 AI 工具生成一份补丁或一份漏洞报告，成本几乎为零；而认真评审这些提交，仍然需要真人投入大量时间和精力。

这让一个原本就超载的系统进一步恶化。在内存管理这类繁忙的子系统里，早在 AI 工具普及之前就已经有大量补丁排不上评审队列。

内核的私有安全邮件列表把矛盾推到了临界点。这个渠道过去很安静，每周处理少量经过深思熟虑的报告；如今每天会收到五到十份。由于列表是私有的，提交者无从得知同样的问题是否已经有人报过，于是相同的议题被反复提交。负责相关领域的维护者可能花上几个小时逐条筛查，最后发现这些漏洞要么根本不存在，要么几个月前就已经修复。

Linux 之父 Linus Torvalds 对 AI 生成代码持保留态度已有一段时间。他不认为这类代码适合用于生产环境，并指出在不理解底层代码与系统架构的前提下盲目采信 AI 的输出，出问题几乎是必然的。

表面能编译，不代表它是对的

社区内部对如何处置 AI 代码远未达成一致，一部分开源项目已经明令禁止 AI 生成代码，而另一部分开发者则希望 AI 辅助开发继续发展，认为这类工具确实能帮人更快穿过复杂的工作。

批评者的理由并不在于「AI 永远写不好代码」，而在于当下的可信度：一份补丁可能表面看起来完全正常，编译不报任何错误，却因为某些只有在后期才会显现的原因而完全跑偏。AI 没有对一份代码库历史的直觉，也不清楚某些架构决策当初为什么那样做，于是它带进来的问题往往多于它修掉的问题。

更现实的成本落在时间账上。软件开发的实质并不是写代码，而是在交付前理解和审查代码。当 AI 让缺乏经验的开发者也能轻易生成大段补丁，仍然得有人把这些代码逐行读完并作出判断。维护者要花几个小时去揣摩 AI 为什么做出某个决定，或者反过来追着提交者提问——而提交者往往答不上来。这些时间是从真正推动项目前进的工作里直接扣掉的。

目前出现的应对手段大多是临时性的，比如给拉取请求设置数量上限、强制要求标注 AI 参与情况。这类措施有一定效果，但由于生态本身是开放且去中心化的，很难让所有人对任何一项对外规则达成共识。

讽刺之处：最适合跑本地 AI 的系统，用户却装不起来

维护者其实在两条战线上同时作战，而两者都源于这套系统的构建方式。

一边是维护者疲于应付涌入仓库的机器生成内容；另一边是普通桌面用户想在本地跑一个模型，却要在互相竞争的桌面环境里挑选，还要面对 Snap 与 Flatpak 这类彼此冲突的打包格式，以及未必兼容的图形服务器。把一个本地 AI 模型在 Linux 上跑起来，需要真实的技术功底，门槛高到连长期使用 Linux 的作者本人都表示暂时不想碰。

而按架构来说，Linux 本应是运行本地 AI 最合适的平台：它能提供直连硬件的 GPU 算力访问，没有 Windows 及其 WSL2 兼容层带来的虚拟化开销与内存预留。缺少一个能统一界面标准和硬件适配规则的中心权威，生态的碎片化就停不下来，一个干净、易用的本地 AI 前端也就始终建不起来。

于是形成了一个尴尬的局面：维护者忙着筑墙抵挡机器生成的提交，普通用户则被挡在本地 AI 的门外。Linux 在本地 AI 上能提供的能力，与它实际交付的体验之间，这条缝隙短期内不太可能收窄。

来源：How-To Geek（作者 Jorge A. Aguilar）