Linus 给 Linux 的 AI 争论划线：工具可以进来，垃圾不能甩给维护者
林岚｜OC 开发者生态编辑
林岚｜OC 开发者生态编辑
据 Ars Technica 报道，Linux 内核邮件列表近日争论一个非常具体的问题：Sashiko 自动审查补丁并发现疑似缺陷后，应该由维护者先核实，再把可靠结论发给补丁作者；还是可以把机器意见直接交给作者判断？争论随后扩大到 Linux 是否允许开发者使用 LLM，Linus Torvalds 明确表示，Linux 不是一个“反 AI 项目”。
一句话结论： Linus 确认了 Linux 不会禁止 AI 工具，却没有消除最棘手的流程问题：Sashiko 的误报究竟应该先消耗维护者的时间，还是补丁作者的时间。
Sashiko 到底在做什么
Sashiko 不是让 AI 自己写一份 Linux 内核再提交。它监控内核邮件列表里的新补丁，把补丁、相关代码和提交历史交给大模型，然后分多轮检查：补丁目标是否合理、实现是否符合提交说明、错误路径有没有漏掉、资源是否释放、锁和并发是否正确，以及是否存在越界访问等安全问题。最后，它把疑点整理成类似代码审查意见的内容。
项目开发者用最近 1000 个带有 Fixes: 标签的上游修复提交做回测：先把代码恢复到缺陷尚未修复的状态，再看 Sashiko 能否从当时的补丁中发现后来确认的错误。使用 Gemini 3.1 Pro 时，系统找出了其中 53.6% 的问题。这个实验说明它确实能发现人类评审漏掉的东西，但不能证明它比人类更会审代码，因为测试使用的是已知后来发生修复的样本，公开数据也没有给出完整的精确率评估。
Sashiko 团队估计误报在 20% 以内，并承认其中许多属于难以明确判断的灰色地带。同一个补丁重复运行，模型也可能给出不同结果。因此争议从来不是“它有没有找出过真 Bug”，而是这些概率性意见进入真人协作流程前，谁负责过滤。
争论双方到底在争什么
Linux media 子系统维护者 Laurent Pinchart 提出的方案是：维护者如果想根据 Sashiko 的结果采取行动，就应该先自己分类、验证，确认意见站得住脚后，再去联系原补丁作者。他同时援引 Software Freedom Conservancy 的建议：开源社区应支持拒绝 LLM 的贡献者，也应尊重每个人是否使用这类工具的自主权。
这套方案保护了补丁作者。假如作者没有选择使用 AI，就不应该被一批未经验证的机器意见追着解释。但代价也很明显：维护者必须逐条读代码、判断 Sashiko 是否说对。原本号称帮助维护者的工具，反而先给维护者增加了一道审核任务。
Sashiko 的开发者之一 Roman Gushchin 因此反对。他认为，如果每条机器意见都必须由维护者完整核实后才能交给作者，Sashiko“帮助维护者”的目标就很难实现。与其给每个使用场景叠加程序，不如直接回答 Linux 是否总体反对 LLM。
Linus 就是在这里加入讨论。他说 Linux 不采取反 AI 立场，不强迫任何人使用 AI，但也不会允许一部分人阻止其他人使用。他那句最容易传播的“fork it，或者离开”，回答的是项目政策：Linux 不会因为道德或意识形态理由全面禁止 AI。
但 Linus 同一封邮件里还有一句不那么适合做标题的话：解决办法是让 LLM 工具帮助维护者，而不是只给维护者制造痛苦。这等于承认最初的流程难题仍然存在。他划清了“可以用”的边界，却没有替 media 子系统规定“未经验证的机器审查应该发给谁”。
这才是整场争论最有价值的部分：允许使用一种工具很容易，设计出不会转嫁成本的使用方式很难。
关键事实
- Sashiko 自动读取内核补丁和相关上下文，以多阶段流程生成代码审查意见；它不负责决定补丁是否合并。
- 开发者称其在 1000 个历史修复样本中找出 53.6% 的已知缺陷，同时估计误报低于 20%，但承认结果具有随机性，精确误报率也难以测量。
- Pinchart 主张维护者先验证机器意见再联系补丁作者；Gushchin 认为这会让帮助维护者的目标难以实现。
- Linus 明确反对 Linux 全面禁用 LLM，但没有规定各子系统必须怎样接收、筛选或转发 Sashiko 的结果。
OC 判断
Linus 的表态解决了政治问题，没有解决产品问题。Linux 可以不是“反 AI 项目”，某个维护者也完全可以拒绝接收未经筛选的 AI 评论。这两件事并不冲突。
OC 认为，比较合理的落点不是把全部审核责任塞给维护者或作者，而是让 Sashiko 自己提高进入协作流程的门槛：只主动发送高置信度、能指向具体执行路径、最好还能附带测试或复现证据的问题；低置信度结果留在仪表盘里，由愿意使用它的人查看。机器可以把报告生产成本压到接近零，但不应该因此获得无限占用真人时间的权利。
未来更成熟的项目可能不会纠结“这是不是 AI 发现的”，而会检查它有没有证据、是否经过复核、意见接收者能否选择退出，以及制造噪音的一方是否承担清理成本。工具来源不是质量标准，责任链才是。
为什么重要
- 对补丁作者： 未来可能同时面对人类和机器评审，但应当知道意见是否经过验证，并拥有不被低质量自动消息轰炸的权利。
- 对维护者： 是否启用、什么置信度才能发信、谁负责复核，都需要成为明确的子系统规则。
- 对 AI 工具： 真正的成功指标不是生成了多少评论，而是发现多少真实问题、消耗多少人工确认时间。
评论
围绕这篇文章补充信息、提出问题或分享观察。