请想象一下你正在面试一位软件工程师。

你让他们解决一个编程问题。他们打开集成开发环境（IDE），编写一些代码，运行一些测试，使用调试器，并修复错误。

你对结果很满意。

现在想象一下，另一位工程师使用人工智能编程助手解决了同样的问题。代码运行正常，测试通过，实现也很简洁。

但这一次，你拒绝了这位候选人。

为什么？因为他们使用了人工智能。

显然，只要这台机器被称为编译器，用它编写代码就完全可以接受；但一旦它被称为 LLM，事情就变得复杂了。

Linux 的创始人 Linus Torvalds （林纳斯·托瓦兹）最近发表了一条颇具讽刺意味的关于人工智能辅助编程的消息，使这场辩论再次成为焦点。

说实话，这里存在一个比开发者是否应该使用人工智能更大的问题。

我们是在根据工程师解决问题的能力来评价他们，还是根据他们愿意做多少不必要的体力劳动来评价他们？

Linus Torvalds 对“不要将人工智能用于 X”的这种心态持反对意见。

2026 年 10 月 13 日，Torvalds 在 Linux 内核邮件列表中回应了关于 AI 辅助贡献的期望的讨论。

他的回答一如既往地直率。他质疑禁止将人工智能工具用于特定任务的想法，并讽刺地提出了另一种替代方案：为什么不禁止编译器用于内核开发呢？

他的论点很简单。如果你不能用汇编语言编写代码来证明你理解机器的运行机制，那么或许根本不应该允许你提交代码。

为什么就此止步呢？

为什么允许开发者使用文本编辑器编写提交信息？编辑器使得用退格键删除错误变得轻而易举。但一个真正理解自己工作的开发者，理应能够在没有这种辅助的情况下编写出完美的提交信息。

听起来很荒谬，对吧？

这正是他想表达的观点。

他认为，应该期望开发人员尽其所能，并且理解自己在做什么。他们是否使用某种特定工具本身，不应决定他们是否胜任。

他还观察到，他所尊重的人并不一定是那些回避新颖有趣工具的人。但在我们得出人工智能已正式赢得编程之争的结论之前，还有一些值得理解的事情。

numbers = [ 10 , 20 , 30 , 40 , 50 ]

average = sum（numbers）/ length（numbers）

print（average）

开发人员无需从头开始实现sum()函数来证明他们理解平均值。

人工智能编码助手就能做到这一点。

但是，生成代码和理解代码是两回事。

所以我认为真正的争论点不应该是人工智能是否是一种工具。它显然是一种工具。

更有价值的问题是，使用者能否分辨出好结果和坏结果。

想象一下，一位开发者请求人工智能助手为Web应用程序实现身份验证。助手会生成路由、令牌验证、中间件和数据库集成。

应用程序启动成功：登录节点返回预期响应，在快速演示中一切正常。

人工智能降低了代码编写成本，但并不会自动降低理解、测试和维护代码的成本。

事实上，当人工智能快速生成大量代码时，其他成本可能会变得更加重要。

为什么 Linux 内核让这场争论变得更加复杂

这场讨论之所以重要，不仅仅是因为开发者在个人项目中尝试使用人工智能。

Linux内核是一个庞大且长期存有的软件项目。它为服务器、云基础设施、嵌入式系统、安卓设备以及无数其他系统提供动力。

但这里有一个值得区分的地方。

拒绝全面禁止人工智能并不意味着接受所有人工智能生成的补丁。

这对初级开发人员意味着什么？

这或许是这场辩论中最令我担忧的部分。

人工智能在学习编程时非常有用。你可以让它解释不熟悉的函数，生成示例，找出错误，或者引导你理解复杂的概念。

但这其中暗藏陷阱。

即使不掌握维护所需的技能，你也能构建出功能极其强大的应用程序。假设一位初学者使用人工智能编码助手生成了一个完整的后端。应用程序运行正常，API 响应迅速，数据库也存储了记录。

从表面上看，这似乎是一个成功的项目。