Linus Torvalds 谈 AI 编码：如果 AI 算作弊，编译器为何不算作弊？

请想象一下你正在面试一位软件工程师。你让对方解决一个编程问题。他们打开集成开发环境（IDE），编写代码，运行测试，借助调试器修复错误。你对结果很满意。

现在再想象一下，另一位工程师借助 AI 编程助手解决了同样的问题。代码跑通了，测试也通过了，实现干净利落。但这一次，你拒绝了这位候选人。为什么？仅仅因为他用了 AI。

显然，只要这台机器叫"编译器"，用它写代码就没什么问题；可一旦它被称为 LLM，事情就变得微妙起来。

Linux 的创始人 Linus Torvalds（林纳斯·托瓦兹）最近发表了一段颇具讽刺意味的评论，把这场关于 AI 辅助编程的争论重新推到了台前。

说实话，这里藏着的问题比"开发者该不该用 AI"大得多。我们到底是在根据工程师解决问题的能力来评价他们，还是根据他们愿意做多少不必要的体力劳动来评价他们？

Linus Torvalds 反对"禁止 AI 用于 X"的思维定式

2026 年 10 月 13 日，Torvalds 在 Linux 内核邮件列表里，回应了关于 AI 辅助贡献的讨论。他的回答一如既往地直来直去。他质疑那种动不动就"禁止把 AI 用在某某地方"的想法，还讽刺地抛出一个反问：既然觉得 AI 不行，那为什么不干脆禁止在内核开发里使用编译器呢？

他的逻辑很简单：如果你不能用汇编语言写代码来证明自己理解机器是怎么运行的，那也许你压根就不该提交代码。可为什么就此打住呢？为什么允许开发者用文本编辑器写提交信息？编辑器让退格删错变得毫不费力，但一个真正理解自己工作的开发者，按理说应该能在没有这些辅助的情况下写出完美的提交信息。

听起来很荒谬，对吧？这正是他想说的。在他看来，应该要求开发者尽力而为，并且明白自己在做什么。用不用某个特定工具，本身不该成为"是否胜任"的标准。

他还观察到，他尊重的人未必是那些躲着新工具走的人。不过，在急着宣布"AI 已经赢了编程之争"之前，还有一些事值得捋清楚。

从汇编到编译器，再到 AI 助手

几十年来，我们一直在用工具写软件。不妨稍微回顾一下。

计算机发展的早期，程序员需要跟硬件直接打交道。汇编语言让他们能直接操控机器指令，编程过程充满繁琐的底层工作。随后，高级编程语言发展起来。开发者不用再手写机器指令，可以用 C、Java、Python 这些语言表达逻辑，交给编译器把代码翻译成机器可执行的程序。

集成开发环境（IDE）的出现，让浏览大型代码库、发现错误、重构实现都轻松了不少。调试器帮开发者看清代码运行时到底发生了什么。库则让人能复用别人已经做过的工作。

没有人会要求现代软件工程师在证明自己胜任之前，必须自己实现一门编程语言、自己写编译器、同时用汇编写所有应用程序。我们评判他们的标准是：能做出什么，以及是否理解最终结果。

就拿一段简单的 Python 代码来说：

numbers = [10, 20, 30, 40, 50]
average = sum(numbers) / len(numbers)
print(average)

开发者不需要从头实现 sum() 函数来证明自己懂求平均值。他们需要理解的，是这个函数在做什么、为什么它能解决这个问题，以及在别的情况下可能出什么问题。比如：列表为空会怎样？值是字符串而不是数字呢？如果应用要处理数百万条记录、内存装不下呢？

编程的乐趣往往不在写语法，而在于理解问题、选对方案，并预判这个方案可能存在的缺陷。AI 编码助手改变了部分工作的完成方式，但取代不了对编码本身的理解。至少，不应该取代。

等一等——AI 真的只是另一种工具吗？这恰恰是争论开始有趣的地方。把 AI 比作编译器听上去有点道理，但这个类比并不完美。编译器按照语言规则翻译程序，它可能出错，但通常不会根据你对需求的模糊描述凭空生成一个全新实现。

AI 编码助手恰恰能做到这一点。你可以让它构建缓存层、实现 API 节点，或优化数据库查询。它能生成几百行代码，而你甚至不用逐条指定实现细节。有时候，结果确实漂亮。但有时候，它会引入一些不易察觉的错误，误用某个库，或者顺带"解决"了你根本没遇到的问题。还有些时候，它生成的代码看起来足够完善，直到很久以后才有人注意到埋下的雷。

这个差别很关键。编译器通常基于现有程序运行，而 AI 编码助手可以自行生成程序。这意味着使用 AI 的人不仅要评估最终输出，还要评估过程中做的那些决策。

还有一层：AI 大幅压低了代码生成的成本，省时又省力。当开发者清楚自己要构建什么时，这非常有用；但如果开发者根本不知道正确方案长什么样，那就很危险了。过去苦于写复杂代码的人，现在可能几秒钟就能生成一个版本。问题是，生成代码和理解代码，完全是两码事。

所以真正的焦点不该是"AI 算不算工具"——它当然是。更有价值的问题是：使用者能不能分辨出好结果和坏结果？

真正的问题：代码能跑，可没人看得懂

设想一下，一位开发者让 AI 助手给 Web 应用实现身份验证。助手生成了路由、令牌校验、中间件和数据库集成。应用启动成功，登录接口返回预期响应，快速演示一切正常。

几周后，有人发现过期令牌处理得不对。另一位开发者想修复，却发现自己面对的是多个互相纠缠的生成代码片段。原开发者说不清中间件为什么要那么实现，也解释不了背后的安全假设。他们不知道改哪些地方不会牵连出新的破坏——到了这一步，麻烦已经来了。

这其实跟用没用 AI 关系不大。真正的问题在于：有人发布了自己都无法正确解释和维护的软件。哪怕没有 AI，人也一样能写出烂代码。区别只是，不用 AI 可能要花三天，用了 AI 只要三分钟，但结果都可能是一团糟。AI 不过是让大量代码的生成变得更容易，而且几乎没人在发布前认真检查这些代码合不合理。这就是需要权衡的地方。

AI 降低了写代码的成本，却不会自动降低理解、测试和维护的成本。事实上，当 AI 快速产出大量代码时，这些"后续成本"反而可能变得更加突出。

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

这场讨论之所以重要，不只是因为开发者在个人项目里试验 AI。Linux 内核是一个庞大且长期演进的软件项目，支撑着服务器、云基础设施、嵌入式系统、安卓设备以及无数其他系统。

内核贡献的评判标准，并不是"演示程序在开发者自己机器上能跑"这么简单。一次改动可能以意想不到的方式影响内存管理、并发、设备驱动以及系统的其他部分。单独看起来合理的补丁，可能引入竞态条件，破坏内核其他位置的假设，或者只在特定负载下才暴露出问题。审查者需要理解一项改动到底做了什么、为什么有必要。这让 AI 辅助开发的问题显得格外尖锐。

在这种环境里，如果开发者提交的是生成代码却讲不清原理，会给代码审查和维护者制造巨大麻烦，而审查者的时间本来就很紧。Linux 内核社区一直在讨论如何处理 AI 辅助贡献，以及贡献者是否应该说明 AI 工具在何时帮忙生成了补丁。Torvalds 回应时坚决反驳了那种"广泛限制工具使用就能判断能力"的思路。

不过，这里有个值得区分的点：拒绝全面禁止 AI，不等于照单全收所有 AI 生成的补丁。一个项目完全可以允许开发者使用 AI，同时拒绝错误、测试不足、不安全或作者讲不清楚的代码。这两种立场并不冲突，甚至应该同时成立。

那是否该允许开发者把 AI 用在所有地方？答案是可以，但有一个重要前提：预期必须取决于任务、风险和后果。用 AI 生成简单的 Python 脚本，和用 AI 修改支付系统、实现加密功能、改动 Linux 内核里的内存管理例程，完全不是一回事。出错的后果天差地别。

同样的原则也适用于怎么评价工作。低风险任务中，开发者可以合理使用 AI 生成大部分初始实现，再检查是否可行。涉及安全问题的改动，则需要开发者深入理解实现方式，做充分测试，仔细推敲各种极端情况。

AI 辅助编程应有的标准

重点不是逼人们证明每一行代码都是亲手写的，而是验证最终成果是否达到既定标准。以下是一些合理的底线：

• 你应该能解释代码。如果有人问你某个函数为什么存在，或者为什么选这种实现方式，你应当能给出像样的回答。
• 你应该测试的不只是正常路径。程序在一个例子上跑通，不代表它就是对的。AI 生成的测试用例能帮上忙，但同样需要审核。
• 你应该清楚风险。如果代码涉及身份验证、支付、个人数据或基础设施，就要考虑简单演示发现不了的故障模式。
• 你应该为最终结果负责。提交的代码出了问题，说"是 AI 写的"不能成为借口。
• 你应该对工作内容保持诚实。项目、雇主或任务对 AI 辅助有具体规定的，依然要遵守。工具自由不等于其他义务都可以免了。

这些要求并不是让开发者远离 AI，而是要求开发者像工程师一样行事。

初级开发者的两难

这对刚入行的人来说意味着什么？这大概是整场辩论里最让人揪心的部分。AI 在学习编程时确实很有帮助。你可以让它解释不熟悉的函数、生成示例、找错误，或者引导你理解复杂概念。

但陷阱也在暗处。你可能还没掌握维护所需的技能，就能做出功能看起来很强大的应用。假设一个初学者用 AI 编码助手生成了完整的后端。应用跑得挺顺，API 响应迅速，数据库也有条不紊地存着记录。表面上看，这似乎是一个成功的项目。

可真要问他应用程序如何处理并发请求、数据库连接失败时会发生什么、为什么数据集变大之后某个查询会变慢，他可能答不上来。如果答不上来，这个应用展示的其实是"AI 能生成什么"，而不是"开发者理解了些什么"。

但这不意味着初学者必须等到成为专家之后才去碰 AI。这就像告诉别人在完全掌握所有数学运算之前别用计算器一样。更好的做法是利用 AI 加速学习，而不是拿它逃避学习。AI 生成代码之后，去读它、跑它，改一改再看结果，追问为什么选这种方案，主动找实现里的漏洞。遇到不懂的概念，在继续叠加新一层之前，先把概念弄清楚。

目标是能够自信地使用 AI 生成的代码，而不是盲目依赖。这一点对经验丰富的开发者同样成立，多年经验并不能保证不犯错。

更值得关心的是：如何衡量工程能力

多年以来，不少编程面试都在人为设限的条件下考察候选人。你可能被要求实现一个排序算法，但不能用内置的排序函数；也可能要在没有 IDE、调试器和文档的情况下，在白板上解题。

这些练习有它们的价值，能看出一个人怎么思考算法，是否理解基本概念。但用受限环境来测试某项技能，和把这种环境当作软件工程的唯一正经形式，是两码事。大多数开发者把时间花在阅读现有代码、排查生产问题、理解需求、审查拉取请求、验证假设、跟人协作上。如果 AI 成为软件开发的常规组成部分，我们显然需要更好的方式来评估这些能力。

开发者能不能识别出 AI 生成的实现里的缺陷？能不能发现安全漏洞？能不能解释设计决策并用技术论证支撑？当 AI 的解释是错的时候，能不能追查到一个 bug？能不能判断什么时候用 AI 合适，什么时候不如手动解决？

这些问题，比"有没有人用 AI 助手来写函数"要有意义得多。能回答好这些问题的开发者，无论手里拿的是什么工具，都是真正有价值的。

一些感想

AI 编码之争里，总有两种极端声音。一种认为用 AI 会让你变成更差的程序员，因为你不再亲手写所有代码；另一种认为 AI 能写所有代码，所以开发者不需要再懂编程。我对这两种说法都不买账。

用工具并不必然说明你能力不足，但用工具同样不必然说明你能力强。Linus Torvalds 的论点恰好提醒我们：工具和使用工具的人，是两码事。另一方面，对 AI 辅助开发的批评也点出了一个真实的问题：代码生成越来越容易，而生成"看起来正确"的代码，和生成"正确"的软件，并不是一回事。这两者不该被混为一谈。

我并不关心开发者是手写函数、用 AI 生成函数，还是从现有库里拿代码。我关心的是这个函数有没有解决正确的问题，行为对不对，开发者能不能承担责任。这就是我对 AI 生成代码的标准。说句实在话，这本该是我们一直用在人类自己写的代码上的标准。

编程的未来，不在于证明你离开 AI 也能干活，而在于证明即使 AI 承担了大部分工作，你依然清楚自己在做什么。

这个话题在云栈社区也颇有讨论度，不少开发者对 AI 辅助编程的态度差异很大：有人视其为效率利器，也有人担心它削弱基础能力。你怎么看？