不是把?Linux 开始接受 AI 写的代码了 ...

点击上方蓝字关注我，加个🌟标不迷路。

今天看到很多人讨论 Linux 终于要接受 AI 提交的代码了，我的第一反应是，真的吗？作为喷 AI 最狠的祖师爷到底咋看这件事儿？

大家的反应好像都是：Linux 内核社区终于松口了，连 AI 写的内容也能进主线了。

链接在这里：https://github.com/torvalds/linux/blob/master/Documentation/process/coding-assistants.rst

我查了一部分资料发现真实的情况并不是这样。

Linux 社区真正接受的，不是“AI 写的东西天然可信”，而是另一套更现实的逻辑：

你可以用 AI，但你必须像对待自己写的代码和文档一样，对它负全责。

换句话说，被招安的不是 AI，本质上是“AI 作为生产力工具”这件事。社区从来没有把责任交给模型，责任依旧牢牢钉在人身上。

如果你把问题改成“Linux 能不能接受 AI 辅助生成的文档、补丁说明、甚至代码”，答案其实已经很明确了：

可以。

但前提只有一个，而且一点都不含糊：

提交的人必须亲自审过、亲自理解过、亲自签字担责。

这套态度看上去保守，其实很先进。因为它没有陷入两种常见误区：

1. 把 AI 当洪水猛兽，试图彻底封杀。

2. 把 AI 当免责工具，仿佛“不是我写的，是模型生成的”就能把锅甩出去。

   Linux 社区两边都没选。它选的是第三条路：允许使用，但责任你的承担。

为什么“文档也能接受”并不意味着门槛降低

很多人会误会，觉得文档风险比代码小，所以 AI 写文档这件事更容易放行。

这话当然没错，但别忘了，文档进入一个高门槛工程社区，也不只是“语句通顺”这么简单。

在 Linux 这种项目里，文档至少承担三层作用：

• 它解释设计意图。

• 它约束后续维护者的理解边界。

• 它会反过来影响代码审查和社区协作。

  也就是说，一份低质量文档未必会像坏代码那样直接把系统搞崩，但它完全可能把讨论方向带偏，把维护成本慢慢抬高。

  所以从治理逻辑上看，AI 写文档和 AI 写代码并不是两套完全不同的问题。它们共享同一条底线：

只要内容会进入正式协作链路，就必须有人类责任主体。

这才是 Linux 这次态度转变里最值得关注的地方。

社区真正关心的，从来不是“是不是 AI 写的”

如果只看表面，你会以为社区争论的是“要不要标注 AI 生成”。

但更深层的矛盾，其实根本不在标注本身。

Linus 的态度已经说得很直白了：靠文档规定，并不能拦住那些原本就不守规矩的人。

这句话背后的意思其实很重。

因为一个社区真正害怕的，从来不是“有人用了 AI”。社区怕的是下面这几件事：

• 提交者自己都没看懂内容就交上来。

• AI 把旧 bug、错误模式、许可证风险重新包装了一遍。

• 维护者要额外消耗更多精力，去分辨哪些补丁和说明只是“看起来像那么回事”。

  所以别把这个问题理解成“AI 文档能不能进”。更准确的说法是：

  Linux 正在接受 AI 参与贡献流程，但拒绝接受无人负责的 AI 产出。

2021 年那次恶意提交，为什么到今天还在影响社区判断

这件事绕不开明尼苏达大学当年的事故。

当时最让社区愤怒的，并不是“补丁有 bug”，而是有人故意把带漏洞的提交伪装成正常修复，然后还想把这种做法包装成研究成果。

这件事留下的后遗症非常深：

• 它让社区意识到，审查机制本身也会被利用。

• 它证明“表面上说得过去”的提交，不代表真的安全。

• 它让维护者对“你说你是善意的”这类解释天然失去耐心。

  这也是为什么今天讨论 AI 时，Linux 社区几乎本能地把责任重新拉回到人身上。

  因为历史已经证明过了：

  真正危险的，不是工具本身，而是提交者借工具逃避责任。

Linux 给出的治理答案，其实很现代

在很多组织里，面对 AI 的第一反应通常是两种：

• 要么全面禁用。

• 要么全面放开，最后把问题留给一线团队收拾。

  Linux 没这么做。

  它的做法更像一套成熟工程组织的治理模型：

  

1. 接受 AI 已经进入现实工作流。

2. 不把“是否使用 AI”当成唯一判断标准。

3. 把责任、签字、审查、追溯机制继续压实在人类开发者身上。

   这套机制为什么重要？

   因为它把问题从“工具伦理争论”拉回到了“工程责任分配”。

   这才是一个大型开源项目真正该关心的东西。

真正有意思的变化：AI 不只在写，也开始在审

如果事情只停留在“AI 帮人写补丁、写说明、写文档”，那还不算真正的拐点。

更关键的是，AI 现在已经开始进入另一个角色：

它不只是内容生成器，也开始成为审查层。

Google 工程师开源的 Sashiko 就很典型。它做的不是自动提交代码，而是帮 Linux 内核补丁做多阶段审查，把架构、安全、并发这些风险拆开看。

这件事释放出的信号很重要：

未来真正可持续的工作流，大概率不是“AI 写，人类被动兜底”，而是：

AI 写一层，AI 审一层，人类做最终判断。

这才像一个能规模化运行的生产体系。

对开发者来说，最现实的启示是什么

如果你是普通开发者，这件事其实给了一个很清晰的判断标准。

以后你在团队里用 AI 写代码、写注释、写文档，真正重要的不是“有没有用 AI”，而是这三件事：

• 你有没有亲自审过。

• 你能不能解释清楚它为什么这样写。

• 出问题时，这份内容是不是你愿意署名负责。

  只要这三关过不了，AI 参与越多，风险反而越大。

  反过来想，如果这三关你都能过，那 AI 写的到底是代码、提交说明，还是设计文档，其实已经没那么重要了。

  因为这时候它的身份就是工具，而不是作者。

写在最后

所以，“Linux 可以接受 AI 写的文档了吗”这个问题，最准确的回答应该是：

Linux 可以接受 AI 参与写出来的内容，但不会接受没有责任人的内容。

这句话听起来不激进，却很有分量。

它意味着一个成熟社区终于不再纠结“AI 到底该不该来”，而是开始认真设计“AI 来了之后，责任怎么分、风险怎么控、质量怎么守”。

这比单纯的支持或反对都更重要。

所以，AI 进入开源社区，已经不是趋势判断题了，而是治理能力题。

真正的分水岭，不是谁先用上 AI，而是谁先建立起一套人能负责、流程能追溯、风险能被拦住的协作方式。

Linux 现在给出的，就是这样一个答案。

如果觉得这篇文章有意思，欢迎：

点赞 | 在看 | 分享

你的支持是我更新的动力。