内核对 AI 编程工具的回应

经过数月争论，Linux 内核项目正式确立了其首个针对 AI 辅助代码贡献的明确政策。正如 ZDNET 所总结的，这项新指导方针更像是一种务实折中，而不是全面禁止，也不是无条件认可。核心信息很简单：开发者可以使用 AI 工具，但不能把责任转移给它们。在 Linux 世界里，代码质量、许可证纪律和审查规范都异常严格，这一区别正是关键所在。

该政策确立了三项原则。第一，AI 代理不能添加 Signed-off-by 标记，因为只有人类贡献者才能确认符合内核的 Developer Certificate of Origin。第二，AI 辅助提交必须包含 Assisted-by 标记，注明所使用的模型、代理和辅助工具。第三，提交代码的人类必须对代码审查、许可证合规以及由此产生的任何漏洞或安全问题承担全部责任。这些规则把 AI 的使用从一个隐藏变量，变成了贡献流程中必须披露的一部分。

其结果与其说是关于人工智能的魅力，不如说是为了维护内核的责任链。Linux 内核不只是一个软件项目，它还是一个具有明确来源、审查和所有权规范的法律与运营体系。如果生成代码在缺乏透明归属的情况下进入这个体系，维护者就会失去对风险的可见性。新的 Assisted-by 要求通过向审查者清晰提示补丁是如何生成的、以及哪里可能需要额外关注，来解决这一问题。

透明，而不是表演

ZDNET 将这种做法描述为务实，这正是正确的理解框架。该政策并不假装 AI 工具在现代开发中不存在，也不把它们当作值得信赖的同伴。相反，它把它们归类为输出必须披露、后果仍由人承担的工具。这大概是内核唯一能够站得住脚的立场。当法律认证和技术审查在变更接受流程中如此核心时，项目不能允许一种含糊的署名模式。

这项政策也受到争议推动。原文提到，Nvidia 工程师兼内核开发者 Sasha Levin 向 Linux 6.15 提交了一个完全由 AI 生成的补丁，包括 changelog 和 tests，尽管他在提交前审查并测试了结果，这一事件加剧了争论。那次事件把许多软件社区如今都在面对的问题具体化了：如果 AI 帮助生成了补丁，需要披露什么，又是谁为这份工作负责？

内核的回答之所以值得注意，是因为它拒绝了两种极端。它既不要求开发者彻底避免使用 AI，也不允许他们躲在自动化后面。这种组合可能会影响 Linux 之外的领域。许多开源和企业项目仍在为生成代码自行摸索规范。内核现在提供了一个模型，其中披露是强制性的，而责任不能转移。

这对软件治理意味着什么

更广泛的意义在于，AI 辅助编程正从单纯的效率问题，变成治理问题。一个能编译的补丁，并不一定就是值得信任的补丁。项目需要知道代码从哪里来、谁审查过，以及以后由谁负责。在高风险代码库中，这些问题与安全性、可维护性和法律合规密不可分。

这也是为什么 Assisted-by 标记很重要，哪怕它看起来只是一个小小的流程细节。它给维护者提供了上下文，可能影响补丁审查的严格程度，也可能因为披露不可避免，而抑制对 AI 工具的草率使用。如果贡献者知道生成内容会被额外审查，他们就更有动力在提交前认真复核。

内核社区的新规则并没有解决 AI 生成代码周围的所有问题。ZDNET 指出，这项政策可能没有触及最大的挑战。但它至少明确了一条核心原则：机器可以协助，人类必须负责。在一个依靠流程建立信任的软件生态中，这条规则最重要。

为什么这条新闻重要

  • Linux 内核现在已经把 AI 辅助贡献正式纳入政策。
  • 提交代码的人类贡献者仍需对法律和技术结果负责。
  • 强制性的 Assisted-by 标注可能会影响其他开源治理模式。

本文基于 ZDNET 的报道。阅读原文.

Originally published on zdnet.com