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

你让他们解决一个编程问题。他们打开集成开发环境（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()函数来证明他们理解平均值。

他们需要了解该函数的作用、为什么它能解决这个问题，以及在其他情况下可能会出现什么问题。

例如，如果列表为空会发生什么情况？

如果这些值是字符串而不是数字呢？

如果应用程序要处理数百万条记录，而内存无法全部容纳，该怎么办？

编程的乐趣往往不在于编写语法，而在于理解问题，选择正确的解决方案，并预判该方案可能存在的缺陷。

人工智能编码助手改变了部分工作的完成方式，但并不能取代对编码的理解。

至少，他们不应该这样做。

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

你可以让它构建缓存层、实现 API 节点或优化数据库查询。它可以生成数百行代码，而无需你指定每个实现细节。有时，它实现的结果的确出色。

有时候，它会引入一些不易察觉的错误，错误地使用某个库，或者解决你从未遇到过的问题。而有时候，它生成的代码看起来足够完善，以至于很久以后才有人注意到问题。这种差别至关重要。

编译器通常基于现有程序运行。而人工智能编码助手则可以自行生成程序。

这意味着使用人工智能的人不仅需要评估最终输出结果，还需要评估过程中做出的决策。

还有一个问题：人工智能大大降低了代码生成的成本，节省了时间和精力。当开发者知道需要构建什么时，这非常有用。但如果开发者不知道正确的解决方案应该是什么样子，那就非常危险了。

以前苦于编写复杂代码的开发者，现在可能只需几秒钟就能生成一个。

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

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

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

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

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

几周后，有人发现过期令牌的处理方式不正确。另一位开发人员试图修复这个问题，但发现身份验证流程包含多个相互交互的生成代码片段。

原开发者无法解释中间件为何采用那种实现方式，也无法说明这种实现方式背后的安全假设。

他们不知道更换哪些部件不会造成其他损坏——现在我们遇到麻烦了。

这与是否使用了人工智能关系不大。

问题在于有人发布了他们自己都无法正确解释或维护的软件。即使没有人工智能，人类也能写出同样糟糕的代码。他们可能需要三天而不是三分钟，但结果仍然可能是一团糟。

人工智能只是让大量代码的生成变得更加容易，而无需任何人来检查这些代码是否合理。

这就是权衡取舍。

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

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

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

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

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

内核贡献的评判标准并非仅仅在于演示程序能否在一位开发者的机器上运行。

变更可能会以意想不到的方式影响内存管理、并发性、设备驱动程序以及系统的其他部分。单独来看似乎正确的补丁可能会引入竞争条件、破坏内核其他部分的假设，或者产生仅在特殊工作负载下才会出现的问题。

审阅者需要理解一项更改的具体作用及其必要性。这使得人工智能辅助开发的问题显得尤为重要。

在这种环境下，如果开发者提交的是生成的代码却无法解释其原理，就会给代码审查和维护人员带来问题。而审查人员的时间本来就有限。

Linux 内核社区一直在讨论如何处理 AI 辅助的贡献，以及贡献者是否应该说明 AI 工具何时帮助生成了补丁。

托瓦兹的回应反驳了这样一种观点：对工具使用进行广泛限制是判断能力的正确方法。

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

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

一个项目可以允许开发者使用人工智能，同时拒绝那些错误、测试不足、不安全或作者无法解释的代码。这两种立场完全兼容。事实上，我认为它们应该齐头并进。

那么，是否应该允许开发者将人工智能应用于所有领域？

我的答案是肯定的，但有一个重要的前提：预期应该取决于任务、风险和结果。

使用人工智能生成简单的 Python 脚本与使用人工智能修改支付系统、实现加密功能或更改 Linux 内核中的内存管理例程是不同的。

犯错的后果各不相同。

同样的原则也适用于我们如何评价工作。

• 对于低风险任务，开发人员可以合理地使用人工智能来生成大部分初始实现，然后检查其是否有效。
• 对于涉及安全问题的变更，开发人员可能需要更深入地了解实现方式、进行广泛的测试并仔细审查各种极端情况。

重点不在于让人们证明每一行代码都是他们自己写的，而在于验证最终成果是否符合既定标准。以下是我认为人工智能辅助编程应达到的一些合理标准：

• 你应该能够解释代码。如果有人问你为什么存在某个特定的函数，或者为什么选择某种实现方式，你应该能够给出合理的解释。
• 你应该测试的不仅仅是正常运行的路径。一个程序在一个例子中运行良好，并不一定意味着它就是正确的程序。人工智能生成的测试用例可以提供帮助，但它们也需要经过审核。
• 你应该了解其中的风险。如果代码涉及身份验证、支付、个人数据或基础设施，则需要考虑一些简单的演示可能无法揭示的故障模式。
• 你应该为最终结果负责。当你提交的代码导致问题时，说“是人工智能写的”并不能成为辩解。
• 你应该对工作内容保持诚实。如果项目、雇主或任务对人工智能辅助有具体规定，这些规定仍然适用。工具自由并不意味着可以免除其他所有义务。

这些要求并非要求开发者回避人工智能，而是要求开发者像工程师一样行事。

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

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

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

但这其中暗藏陷阱。

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

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

但请开发者解释应用程序如何处理并发请求，数据库连接失败时会发生什么，或者为什么随着数据集的增长，某个特定查询会变慢。

如果他们无法回答这些问题，那么该应用程序展示的是人工智能能够生成的内容，而不是开发者所理解的内容。但这并不意味着初学者应该等到成为专家后再去接触人工智能。

这就像告诉人们，在完全掌握所有数学运算之前，不要使用计算器一样。相反，应该利用人工智能来加速学习，而不是逃避学习。

当人工智能生成代码时，请阅读并运行它。修改一些代码并观察结果。询问为什么选择特定的方法。尝试找出代码实现中的漏洞。如果代码中包含你不理解的概念，请在构建新层之前先进行研究。

目标应该是达到能够自信地使用人工智能生成的代码，而不是盲目依赖它。

这一点也适用于经验丰富的开发人员。

即使有多年的经验并不能使人免于犯错。

开发者能否识别出人工智能生成的存在缺陷的实现方式？

他们能否识别安全漏洞？

他们能否解释设计决策并用技术论证来支持它？

当人工智能的解释是错误的，他们能否调查出一个漏洞？

他们能否判断人工智能何时有用，何时最好手动解决问题？

这些问题比“是否有人使用人工智能助手编写函数”更有意义。

能够回答这些问题的开发人员是有价值的，无论他们使用什么工具。