Linus Torvalds 对 AI 编程的支持遭遇 Linux 维护者难题

尽管机器生成的贡献在开源软件领域引发的冲突日益加剧，Linus Torvalds 如今谈起 AI 编程时却显得异常热情。在 10 月 9 日的一场主题演讲中，这位 Linux 创始人表示，自己如今“非常喜欢使用 AI”，而此前他曾认为 AI 编程并不令人印象深刻。

但这一认可并不意味着可以提交未经检查的代码。Torvalds 称，AI 是让编程变得愉快的有用方式，尤其适合初学者和个人项目；同时，他也警告开发者，在严肃工作中使用 AI 时必须“非常谨慎”。

这一区分之所以重要，是因为 Linux 内核已经遭遇了 AI 辅助开发的两面性。自动化工具能够发现真实缺陷，也能帮助开发者处理自己不擅长的编程语言；但它们同样可能让维护者淹没在重复报告、肤浅补丁以及需要人工验证的工作中。

因此，Linux 面临的问题比“AI 写出的代码是否合格”更棘手。它真正的挑战在于：谁来承担验证这些代码的成本。正在形成的答案，是允许使用工具，但同时要求披露、人工审查与个人问责。

Linus Torvalds 关于 AI 编程的评论划出明确界限

Torvalds 支持将 AI 作为编程工具，但这种支持止于未经验证的输出。

Torvalds 在布拉格举行的 Open Source Summit Europe 上，与 Dirk Hohndel 进行对谈时讨论了 AI。Linux Foundation 将这场活动安排在 10 月 9 日，作为该项目 35 周年纪念活动的一部分。会议议程显示，两人的对谈与 Linux、开放 AI、数字信任及安全关键软件等主题并列。

他的立场反映了个人体验的变化。Torvalds 表示，他曾认为 AI 编程“就是不太好”。如今，他已经开始享受使用 AI，并认为只要使用得当，它就是一项有价值的工具。

但这一转变并未使他成为无人值守式软件生成的拥护者。Torvalds 强调，他主要是内核的维护者和汇总协调者，而不是编写其中大部分代码的人。他自己的实验与接纳面向全球基础设施的代码变更，所处风险等级并不相同。

他认为，AI 对于超出自己既有专长范围的任务尤其有用。其中一个例子是个人吉他效果器项目。Torvalds 可以用 C 编写固件，但界面看起来过时；随后，他使用 AI 生成了 Java 实现，而这并非他通常使用的语言。

这一结果并未被描述为专业的 Java 工程实践。它展示了他熟悉的 C 实现如何映射到另一种语言，并为项目提供了可用的界面。这个实验说明了一种边界清晰的使用场景：开发者理解预期行为，也能够检查结果。

Torvalds 还将 AI 与学习编程的体验联系起来。他在 1981 年开始编程时，即使是简单程序也足以令人觉得有意义，因为当时商业软件的完成度较低。如今的新开发者，则会把自己的第一个项目与由大型团队打造的成熟应用相比较。

AI 可以降低这种心理门槛。它能帮助初学者在尚未掌握每个组成部分之前，就把一个小想法变成可见的成果。Torvalds 将这一过程描述为发现编程乐趣的方式，甚至称 AI 是进入这个领域的“入门毒品”。

对于严肃工作的警告，改变了这些话的含义。一个运行不佳的生成式业余界面只会带来不便；而一份有缺陷的内核补丁则可能引入崩溃、数据丢失、安全弱点，或难以察觉的维护问题。

因此，Torvalds 将责任放在工具操作者身上。开发者必须理解软件应当做什么，并确认生成的实现确实做到了这一点。仅靠提示词技巧无法取代技术判断。

这正是 Linus Torvalds 对 AI 编程支持的核心边界。AI 可以减少产出初步结果所需的工作量，但无法免除确认该结果是否适合进入关键代码库所需的工作。

他的立场既不是全面支持，也不是意识形态式拒绝。它将 AI 视为与其他开发工具类似的工具，同时认识到，其流畅的输出可能比传统工具更具迷惑性地掩盖错误。

这种务实的中间立场，与内核正在形成的贡献规则高度一致。该项目接受自动化系统的协助，但不允许 AI 代理承担贡献者应负的法律或技术责任。

Linux 内核允许协助，但不接受匿名自动化

内核规则聚焦于可问责的贡献者，因为生成的代码无法自行证明其来源、许可或正确性。

Linux 内核现已为贡献者发布专门的 AI 助手指南。该指南要求 AI 辅助工作遵循与人工编写补丁相同的开发流程、编码标准、许可要求和审查预期。

这种延续性很重要。Linux 长期以来一直接纳受编译器、静态分析器、代码生成器、自动化重构系统和脚本影响的代码。并非只有由人逐字输入的贡献才可能被接受。

反过来，一项贡献也不会仅仅因为工具生成了其中一部分而变得不可接受。审查者关心的是行为、可维护性、许可状况，以及提交者是否能够为这项变更负责。

生成式系统让既有模式变得更复杂，因为它们能通过同一界面生成代码、说明、提交信息和审查意见。即使推理有误或来源仍不确定，其输出也可能看起来完整无缺。

内核指南通过人类责任来处理这种不确定性。AI 代理不得添加 Signed-off-by 标签。该标签属于能够作出 Developer Certificate of Origin 所要求认证的个人，后者通常被称为 DCO。

根据内核的 DCO 流程，签署者确认该贡献具有可接受的来源，并可根据项目许可证进行分发。语言模型无法作出这种法律声明。

提交 AI 辅助工作的人必须审查生成的代码、确保符合许可要求、添加自己的签署，并承担全部责任。这意味着，当审查者发现问题时，“模型写的”不能成为辩解。

该指南还引入了 Assisted-by 标签，用于披露 LLM 的实质性参与。贡献者可以注明使用了 LLM 及其他专门的分析工具。该标签能为维护者提供有用背景，但不会假装该工具是法律意义上的贡献者。

单独的生成内容规则将这一原则扩展到源文件之外。当生成内容实质性进入提交时，这些规则还可覆盖提交信息、附函、文档和翻译。

这些规则鼓励贡献者说明自己使用了哪些工具，以及在有助于审查时说明哪些输入产生了相关工作。目的不是要求提供每一条自动补全建议的记录，而是揭示可能影响审查、来源或责任的实质性自动化参与。

随着 AI 协助变得愈发不可见，透明度也变得更加重要。生成的补丁可能经过手工重写；人工编写的补丁也可能配有 AI 生成的描述；模型可能发现了缺陷，而最终修复则由维护者完成。

内核的做法承认这些混合工作流。它避免了将每个字符归类为人类或机器生成这一不现实的任务，转而关注工具是否作出了实质性贡献，以及人类是否准备为最终提交负责。

这一模式为企业和其他开源项目提供了有用先例。团队无需在全面禁止所有 AI 工具与接受不透明的代理输出之间二选一；他们可以定义披露门槛、保留人类签署，并要求常规测试证据。

然而，关于署名的规则只解决了部分问题。它们是在有人创建提交后识别责任，却无法阻止 AI 增加维护者必须检查的报告和补丁数量。

而这个数量问题，正是 Linux 的宽容立场面临最严峻考验的地方。

AI 让贡献变得廉价，但审查依然昂贵

矛盾不在人类代码与机器代码之间，而在于海量生成输出与稀缺的维护者注意力之间。

Torvalds 承认，AI 辅助分析正在内核中发现有价值的问题；但他也提到，随机补丁不断涌入，涉及从重大安全漏洞到 20 年无人维护的驱动程序等各种内容。

自动化系统并不会天然理解，哪一种缺陷值得占用稀缺的人类注意力。如果要求它搜索内存泄漏，它可能会在分析发现可疑模式的任何地方生成报告。它并不在意受影响组件是否被广泛部署、已经过时，或是否正由他人修复。

这种缺乏优先级判断的情况，会将工作转移给维护者。必须有人确认报告是否有效、判断它是否重复了早先工作、找到正确的子系统负责人、检查拟议修复，并评估更广泛的影响。

一个看似合理但错误的报告，可能比明显低质量的报告消耗更多时间。维护者必须调查足够的上下文才能证明其不成立，而生成报告的人可能只花了几分钟向模型发出提示。

Torvalds 此前就曾警告，大量 AI 报告正使内核安全邮件列表难以管理。重复发现进一步加重了负担，因为不同用户可能会针对相同代码运行类似工具，并各自独立报告同一问题。

在布拉格活动上，他表示 AI 总体上正在改善代码库。但这一积极评价也伴随着同样直接的警告：它正在给维护者带来压力，“已经到了成为问题的程度”。

相关维护者聚会上的情况也显示了这种担忧的规模。据 Torvalds 所述，其中大约四分之三的讨论都围绕如何让用于代码生成和审查的 AI 工具压力更小、实用性更强。

这一细节表明，争论早已超越个人偏好。维护者并非只是在讨论生成代码是否显得“真实”，而是在围绕已经到来的生产环境变革重新设计工作流程。

AI 同时降低了多重门槛。它让经验较少的开发者能够起草补丁，帮助研究人员扫描陌生子系统，并将可疑问题转化为措辞完善的报告。这些能力可以扩大贡献者基础，并暴露原本可能长期未被发现的漏洞。

但同样的便利也鼓励了“一次性”参与。有人可以在不了解周边代码的情况下提交报告，然后在维护者要求提供复现步骤、测试或更完整的修复时消失。

传统的贡献摩擦曾能筛掉一部分这类行为。准备补丁、撰写连贯的说明并回应审查，需要投入足够精力，才能传达出投入承诺。生成式工具却能在用户尚未具备相应知识前，模仿这些信号。

披露无法完全恢复这种失去的信号。Assisted-by 标签会告诉审查者自动化工具参与其中，但它无法说明提交者是否理解该子系统，或是否会在首次回应后继续参与。

因此，内核除了署名机制外，还需要可操作的筛选机制。维护者需要能对重复发现进行归类、评估实际影响、自动验证声明，并识别持续提交可用成果的贡献者的方法。

他们还需要有权迅速拒绝低价值输出。若将每一份流畅的 AI 报告都视为完整贡献，就会把生成内容的规模转化为无偿或负担过重的审查者必须承担的义务。

这一问题对小型项目的影响更为尖锐。Linux 拥有庞大的贡献者网络，以及受大型科技公司雇佣的维护者。一个由一两名志愿者维护的库，几乎没有能力吸收自动化报告。

这种失衡解释了为何开源项目采取了不同的 LLM 规则。禁止使用可能是一项资源管理决策，而非声称所有生成代码都有缺陷。当项目具备测试基础设施，并有足够审查者来执行标准时，宽松政策可以奏效。

Linux 所处的位置很特殊。它可以从对庞大代码库的 AI 分析中受益，但每一项被接受的变更都会影响关键基础设施。其规模既构成了使用自动化的最强理由，也构成了约束自动化的最强理由。

真正的权衡在于开放性与问责制

AI 可以让更多人进入编程领域，但负责任的贡献仍需要专业知识、持续投入和主人翁意识。

Torvalds 论点中最吸引人的部分关乎开放性。当初学者能够描述一个想法、得到可运行的草稿，并通过对话不断修改时，编程会变得更容易探索。

这种反馈循环能够让学习者保持投入。与其在第一节课花时间解决安装问题或记忆语法，用户可以先看到结果，再逐步了解其运作方式。

对于经验丰富的开发者，同样的工具可以弥合较小的知识鸿沟。内核程序员可能需要用户界面、测试框架，或用陌生语言编写的脚本。AI 可以提供起点，而无需为不相关的专业领域投入数周时间。

这是一项正当的生产力提升。但它不同于将一项涉及安全的完整变更委托给模型。第一种情境中的开发者已经理解目标系统，并能够约束自己不熟悉的组件。

当用户无法评估输出时，这一区别就会弱化。初学者可能因为程序通过了一项可见测试，就相信它能正常工作。经验丰富的工程师也可能因为生成的解释听起来可信，而遗漏其专业范围外的错误。

这正是“人在回路中”可能沦为空洞保证的原因。有人批准输出，并不意味着存在有意义的监督。审查者必须拥有足够的背景、时间和权限，才能发现失败之处。

内核的人工签署规则界定了谁应负责，但无法凭空制造能力。提交者可以签署自己并不真正理解的补丁。维护者仍需要技术证据和积极响应的参与。

生成代码还带来了尚未解决的来源问题。模型可以复现常见模式，却无法为某一特定输出提供清晰的历史。即使模型无法解释每一种训练影响，贡献者也必须确保提交的工作符合内核仅限 GPL-2.0 的许可要求。

Linux 政策并未声称要解决有关训练数据或版权的更广泛争论。它设定了一条贡献边界：人类提交者必须能够作出现有的法律认证。

安全性带来了另一项不确定性。AI 系统可以在被遗忘的代码路径中发现漏洞，这对项目有益；但它们也能高效地大规模生成浅层漏洞声明，从而压垮私有报告渠道。

公开报告会带来不同的风险。即时披露可能在维护者准备并发布修复之前暴露用户。私有报告有助于协调，但如果渠道充斥重复或捏造的发现，其效力也会消失。

Torvalds 的评论表明，Linux 不会通过完全拒绝 AI 来解决这种紧张关系。2026 年早些时候，他曾表示 Linux 不是反 AI 项目，工具应该帮助维护者，而不是给他们带来痛苦。

这一标准给工具开发者带来了压力。成功不能只以发现的缺陷数量、生成的补丁数量或审查评论数量来衡量。一个有用的系统必须减少做出正确决策所需的人力总投入。

对于漏洞发现代理，这意味着需要提供复现步骤、影响评估、重复检测，以及与具体代码路径相关的证据。对于补丁生成器，这意味着变更必须聚焦，并附带能经受专家审查的测试和说明。

对于审查代理，有用意味着能识别后果严重的缺陷，而不会用推测性的警告淹没维护者。精准性和优先级排序比大量评论更重要。

同样的教训也适用于采用 AI 编程系统的公司内部。衡量生成代码行数或被接受的建议，可能会奖励数量，却无法反映维护成本。团队需要跟踪审查时间、回归问题、返工、事故率和长期所有权。

Torvalds 个人的热情并不会削弱这些担忧，反而会使其更加突出。如果一位理解内核风险的开发者仍认为 AI 有趣且实用，那么彻底拒绝将意味着放弃重要收益。

如果 Linux 在没有额外控制措施的情况下接受所有生成输出，它就会把这项技术的隐性成本转移给维护者。项目当前的方向试图在保留实验空间的同时，拒绝这种成本转移。

Linux 社区接下来必须证明什么

只有当生成式贡献比当今涌入的洪流更易于验证、排序和维护时，Linux 的 AI 政策才会成功。

第一个值得关注的信号，是内核如何在日常审查中执行披露规则。正式文档固然重要，但一致的实践将决定贡献者是否理解何时使用 Assisted-by，以及审查者期待哪些信息。

过于宽泛的披露可能产生大量价值有限的重复元数据。披露不足则可能隐藏重要的自动化参与，并剥夺审查者所需的背景。实用的平衡将通过真实提交、维护者反馈和指南修订逐渐形成。

第二个信号，是审查自动化能否减轻生成行为带来的负担。Torvalds 指出，项目已经在使用 AI 审查 AI 辅助的补丁，有时看起来像是机器人在与机器人对话。

这个循环未必荒谬。静态分析早已检查机器生成和人类编写的代码。如果发现结果精准、可复现，并且服从于承担责任的维护者，AI 审查者可以发挥类似作用。

危险出现在一个不确定系统验证另一个不确定系统，而人类将这种一致视为证据之时。多个模型可能重复同一个错误假设。审查流程必须依赖测试、构建结果、运行时行为和可追溯的代码分析，而非模型共识。

应关注那些为每项发现附加具体验证的工具。一份包含复现程序、受影响配置、测试结果和最小补丁的报告，比一段自信描述可能缺陷的文字更有价值。

第三个信号是维护者的工作负荷。如果重复的安全报告减少，低价值补丁能更快分流，而有用的贡献者能在审查中保持参与，那么 Linux 的受控接纳模式将显得可持续。

如果队列持续增长，经验丰富的维护者不断倦怠，项目就有更充分理由施加更严格的限制。关键结果并不是有多少 AI 生成代码进入代码树，而是社区能否在不耗尽负责人员的前提下保持审查质量。

工具供应商应将这一结果视为产品要求。一个生成十个补丁、却带来二十小时审查工作的代理，并没有交付十个单位的生产力。

开发者也应区分实验与贡献。Vibe coding，即通过自然语言提示进行迭代编程，可能非常适合一次性原型。向上游提交代码则要求理解其行为、历史、测试和维护后果。

Linus Torvalds 对 AI 编程的支持在这种转变中最能作为指导发挥作用。从一项边界明确的任务开始。在 AI 有帮助的地方使用它。检查它创建的内容。测试结果，用自己的话解释它，并在请他人审查前承担责任。

初学者不应将这种谨慎理解为避开 AI 的理由。Torvalds 的“入门毒品”比喻承认，易用的工具可以创造学习所需的动力。下一步是将一次生成的成功转化为真正的理解。

经验丰富的工程师也不应把专业知识视为免于犯错的保障。流畅性可能助长过度自信，特别是在模型于陌生领域生成看似合理的代码时。严肃系统需要独立验证，即使第一版结果看起来已经很完善。

与此同时，维护者需要有权定义何种辅助真正有利于自己的项目。Linux 可以支持 AI，而无需要求每位子系统负责人接受无限量的机器生成工作。

内核正在形成的模式要求严格，却具有连贯性。工具可以参与；人类必须披露实质性辅助，满足许可要求，理解自己的提交，并为后果持续负责。

这种方法不会终结围绕 LLM 生成内容的开源争论。不同项目面临不同风险，也拥有不同的审查能力。不过，它确实将讨论从身份立场转向了实际运作。

未来几个月将揭示 Linux 能否将这一原则转化为可管理的工作流程。开发者现在就能帮助回答这个问题：在提交 AI 辅助工作之前，先确认它节省的是维护者的时间，而不只是生成它的人的时间。