- 从最初拒绝直接采用别人提交的补丁，到逐渐学会与社区协作，让 Linux 成为全球开源协作的典范；
- 从顶住压力引入 BitKeeper，到因授权纠纷失去使用权限、退出内核维护，再到在短短 11 天内创造 Git，最终让其成为全球主流的版本控制系统；
- 从曾经一年甚至两三年才能发布一个新版本，到建立起合并窗口与候选版本机制，将发布周期缩短至几周，如今每隔 9～10 周就能稳定推出一个新版本。
过去 35 年间，Linux 之父 Linus Torvalds 做过不少当时看来并不容易被理解的决定，而这些决定也一次次改变了软件开发的方式。如今，AI 正在给 Linux 内核开发带来又一次重大变化。
谈及过去，Linus 坦言，Git 从来都不是他的主业，它只是一个帮助自己完成真正工作的工具，而自己在 Git 上获得的赞誉实在太多了："我确实参与了 Git 的诞生，但已经有 20 多年没有积极参与这个项目了。"面对 AI，Linus 的态度同样发生了转变。起初他对 AI 不以为然，对"氛围编程"更是嗤之以鼻，如今他却直言："我真的很喜欢使用 AI。"
近日，在 Linux 内核维护者峰会期间，Linus 与开源老友 Dirk Hohndel 展开了一场对谈。从 Linux 和 Git 的诞生故事，到 AI 如何改变内核开发与个人编程，两人回顾了许多鲜为人知的技术往事，也聊到了这位开源世界标志性人物对 AI 时代的最新思考。
最初收到补丁，Linus 却选择自己重写
Dirk Hohndel： 早上好，很高兴来到这里。我是 Dirk Hohndel，最近加入了爱立信，担任爱立信软件技术部——也就是爱立信的开源部门——负责人。能与一支规模庞大、充满热情的上游开源开发者团队共事，我感到非常荣幸。现场有爱立信的同事吗？
我从事开源已经相当长一段时间了。很多人都在说，这据说已经是第 35 个年头了。我觉得这实在有些难以置信，但事实确实如此。那么，您是哪位？
Linus Torvalds： 显然，我就是 Linus。我们之所以采用这种奇怪的对谈形式，是因为我极其讨厌公开演讲，即使过了 35 年，依然会为此感到紧张。
我们发现，让我放松下来的办法就是确保自己什么都不用准备。Dirk 负责构思问题、挑选话题来问我，而我只需要毫无准备地走进来，往后一靠，然后尽可能享受这个过程。
Dirk Hohndel： 所以大家接下来听到的是一场对谈，我觉得这挺有意思的。
说到这 35 年，我想回顾一下 1991 年 Linux 刚开始的时候。当时有件事很有趣：人们给你发送补丁，但你其实并没有直接应用它们。能稍微聊聊这个吗？
Linus Torvalds： 我觉得这并不是我独有的情况。当你开始自己的项目，习惯了独立工作时，确实需要一段时间才能真正学会与他人合作。你会觉得："这是我的项目，我懂这些代码。"诚然，当时第一个版本的代码量大概只有 10000 行，所以我确实熟悉整个代码库。
当人们给我发送补丁时——而这些人往往比我更懂 Unix——我本可以直接应用，但当时我的思维不是这样的。我希望让代码开源，但那时的我还不算一个真正的"开源人"，仍在学习如何成为这样的人。
不过，我并没有花太长时间就意识到了这一点。毕竟我一点也不懒，既然有人已经把现成的补丁发给了我，我又何必再做额外的工作呢？直接应用就好了。
在最终改变想法之前的三四个月里，我其实一直在做额外的工作：收到补丁后，先仔细阅读，弄清楚贡献者想实现什么，理解他们的意图，然后自己从头到尾重新写一遍。后来我才意识到，既然有人已经提供了可以直接使用的代码，就应该好好利用。
我觉得这种情况并不少见。后来我在其他项目中也见过类似的现象。只要不是持久战，只要你没有一直拒绝外部帮助、让大家觉得自己被排斥在项目之外，就问题不大。毕竟，学会如何与社区合作本来就需要时间。
Dirk Hohndel： 当我开始参与 Linux 时，我做了大家似乎都会做的事：把整个源代码打印出来。今天再想这么做就有点难了。如果现在这么干，一个新内核大概要合入 1.4 万个补丁，那得花上相当长的时间。
Linus Torvalds： 现在这种方法不太适合大规模应用了。
从没有版本控制工具到采用 BitKeeper 引发的争议
Dirk Hohndel： 回头看的话，一旦你开始应用补丁，手里就只有源码树。当时并没有源代码版本控制系统。你是怎么管理的？如果某个改动破坏了代码，要怎么回退？你当时的源码管理流程是怎样的？
Linus Torvalds： 当时根本没有什么正式流程。我每天都在内部处理补丁，至少每周发布一次。对于一个小项目来说，这种方式的效果出奇地好。
后来我变得非常讨厌 CVS，而且有具体的理由不使用它。不过在早期我倒不是讨厌 CVS，只是因为我这辈子从来没用过任何源码管理系统。用补丁和压缩包来记录代码变更，对我来说就是最自然的方式。
还是那句话，当时的系统规模小，参与的人也少得多。1991 年和 1992 年我们只有少数几个贡献者，后来才逐渐增加到大约 50 人。那时的项目更容易管理，也不一定需要大量基础设施。
Dirk Hohndel： 补丁和压缩包似乎是处理代码显而易见的方式。这种方法——接收补丁、每周创建新的压缩包、发布压缩包和差异文件（diffs）——一直持续到了 2002 年。到那时这已经是一个大得多的项目，贡献者也多了很多。你中途有改变过流程吗，还是依然只有你和你的电脑？
Linus Torvalds： 当时真的只有我和我的电脑。不过一些子系统——主要是网络子系统——已经迁移到了 CVS 上，而那时我也已经学会了使用 CVS。
问题在于，很长一段时间里我们都没有好的分布式版本控制工具可用。我一直坚信，每个人都应该拥有自己的本地开发环境。通过压缩包和补丁，每个人都能确保自己使用的是完全相同的代码。
相比之下，搭建一个中心化的 CVS 仓库、维护仓库、管理提交权限以及处理分支——分支操作在 CVS 中简直就像黑魔法一样——整个过程既痛苦又充满挑战。
Dirk Hohndel： 我曾在 CVS 中管理 XFree86，在我的系统上给一个发布版本打标签就要花上两个半小时。
Linus Torvalds： 在 Larry McVoy 带着 BitKeeper 出现之前，我们一直缺乏像样的基础设施。有些人对 BitKeeper 的记忆充满了强烈的厌恶，但对我来说，它是第一个让我意识到源码控制原来可以以分布式方式运行的系统。
它真正实现了数据的分发，而不是把数据锁定在一个中央仓库中再向外分发功能受限的副本。我非常享受这种体验，尽管当时认同这种方式的人并不多。
Dirk Hohndel： 你后悔使用 BitKeeper 的决定吗？它当时争议很大，Alan Cox 和其他人坚决反对使用专有软件。
Linus Torvalds： 我们当时的分歧很大。即使到了今天，虽然已经有一套标准工作流程，但成为一名内核维护者也并不意味着你必须使用 Git。Andrew Morton 作为 Linux 核心维护者长达 15 年，他就完全不用 Git。
事实上，当时我们也有一套推荐的工作流程。到了 2000 年代初期，这套流程使用的是 BitKeeper，但很多人拒绝使用它，因为它不是开源软件。尽管如此，BitKeeper 的普及程度已经足够高，对我来说简直是一种解脱——我终于能够轻松得多地合并网络代码、ARM 架构代码以及许多其他子系统的代码。
在教会我们一套工作流程应该如何运转这件事上，BitKeeper 取得了巨大成功。它确实存在缺陷，但做对了足够多的事情，让我逐渐看清自己真正想要的版本控制系统究竟是什么样的。
退出内核维护，11 天造了一个 Git 出来
Dirk Hohndel： 接着就到了 2005 年，以及那场授权纠纷。
Linus Torvalds： 我们当时遇到了一场许可证争议。BitKeeper 的许可证规定："你可以将它用于开源项目，但不能对其进行逆向工程。"结果最终还是有人对它进行了逆向工程，这意味着我们失去了使用这款工具的许可。
这对我来说是一个巨大的打击。毕竟在我从事 Linux 工作的 13 到 14 年间，BitKeeper 是唯一一款让我觉得真正可以接受的工具。
这件事令人非常震惊。一旦你习惯了某种工作流程，突然失去它就会感到极其痛苦。即使一个流程并不完美，只要你已经熟悉它，就知道该如何应对其中的缺陷。而在体验过更好的工具之后，我已经完全无法退回到压缩包和补丁的时代。
于是，我暂时退出了内核维护工作，并表示只要找到替代方案，我就会回来。
Git 就这样诞生了。
如果说 BitKeeper 曾遭到社区中一些人的反感，那么 Git 从一开始招致的厌恶就更为强烈。它虽然是开源的，但还很粗糙，而且我故意让它的工作方式与传统工具有所不同。当时一些从未接触过 BitKeeper 的人听说终于有了开源的源码控制工具，便表示："好吧，那我愿意试试。"但这些人通常都有 CVS 的使用背景，他们发现自己根本无法理解 Git。
Git 的有向无环图和对象存储模型，对他们来说完全陌生。再加上我对 CVS 的命名约定深恶痛绝，于是把所有命令都重新命名了一遍，这让他们更加无所适从。
所以我不知道在座有多少人是从 2005 年、2006 年就开始使用 Git 的。那时候 Git 还很新，不够完善，也存在不少缺陷，整体体验与人们的预期相去甚远。
但我想说的是，大约五年时间里，Git 就从一个古怪、特立独行的项目，演变成了彻底改变源码管理格局的标准工具。这件事其实很奇怪。因为在 Git 出现之前，CVS 已经存在了几十年，期间也有人试图用 SVN 来取代它。我曾经觉得，这个领域的阻力实在太大，历史包袱太重，大家又太习惯传统的工作流程，所以我们可能永远都无法说服别人使用 Git。
但对我来说，只要能在内核项目中使用 Git 就已经足够了。这是我当时唯一关心的事情，直到今天也依然如此。
然而某种转变还是发生了。如今甚至已经没人认识 CVS 了。如果你是一个刚走出大学校园的年轻人，很可能从来没听说过 CVS，而 Git 却已经无处不在。直到今天这件事仍然让我感到惊讶。
每次聊到这个话题，我都想澄清一点：我创建了 Git，维护了半年，然后就说"我不管了"。对我来说 Git 从来都不是首要目标，它只是一个帮助我完成真正工作的工具——让内核能够顺利运转，让我可以重新回到维护工作中。
半年后 Git 对我来说已经足够好用了，于是我把它交给了 Junio Hamano。在 Git 早期的大部分时间里——那半年中差不多有五个月——我一直在和他一起工作。我很欣赏他的思维方式，所以最后对他说："抓到你了，接力棒交给你。你现在就是 Git 的新维护者了，自己看着办吧。"
此后他与成百上千名其他贡献者一起，在这个项目上持续耕耘了 20 多年。
有时候，我觉得自己在 Git 上获得了太多赞誉。我确实参与了 Git 的诞生，但已经有 20 多年没有积极参与这个项目了。
Dirk Hohndel： 关于这一点，我想稍微反驳一下。人们总是对我能清楚记得 Git 是什么时候诞生的感到惊讶：那是 2005 年 4 月。
我之所以记得这么清楚，是因为当时 Linus 的太太邀请我和我太太一起帮忙筹办他二女儿的生日派对。我们到了之后才发现，这活儿至少得四个人才能干得完。结果 Linus 却对我说："嘿 Dirk，我想跟你聊聊我最近在弄的一个玩意儿。"
于是我们俩就溜到了一家冰淇淋店，把组织派对的活儿留给了各自的太太。这件事后来可没少让我挨抱怨。正因为如此，我才对这一切究竟是从什么时候开始的记得如此清楚。
我想说的是，在座各位都是软件开发者。如果你在一家公司工作，试图针对一个复杂的领域开发一种突破性的全新解决方案，然后告诉老板你打算一个人在 11 天内搞定——因为这正是 Linus 从开始动手到做出第一个可用版本所花的时间——那么请大家好好体会一下这件事的分量。
发明一种全新的对象模型，编写代码，并在不到两周的时间里让它真正跑起来。千万别让你们的老板听到这段话，否则他们可能会觉得你们平时都在摸鱼。
Linus Torvalds： 或者他们会说："我用大语言模型（LLM）两个小时就能搞定。"
Dirk Hohndel： 你觉得半年后 Git 已经足够好了，然后 Junio 就接手了。那社区觉得半年后它够好吗？社区花了多久才接受它？在那一个半礼拜之后，他们显然是不买账的。
Linus Torvalds： 因人而异。有些人花的时间比别人长。我们有些核心的内核维护者在一个月后就接受了。还有些人，比如 Andrew Morton，他花了 15 年才开始用。什么情况都有。
值得一提的是，今天的 Git 显然比 2005 年那会儿要好得太多了。
每两年发布一次太痛苦，Linus 提议改成每五周一次
Dirk Hohndel： 还有一个关于开发模式的有趣变化，我想简单聊一下。
Git 于 2005 年诞生。到了 2005 年、2006 年大多数人开始使用 Git 时，Linux 的开发模式仍然是原来的样子。真正发生重大转变大约是在 2014 年。当时我们从过去那种"Linus 想什么时候发布就什么时候发布"的模式，转向了合并窗口和候选版本机制，整个开发流程也变得更加规范和有序。你能谈谈这次转变吗？
Linus Torvalds： 我想先问一个问题：在座有多少人是在 2006 年之前就开始参与 Linux 开发的？嗯，举手的人还真不少。
对于那些没有那么长时间参与其中的人来说，我们现在已经拥有了一套非常稳定的开发模式。整整 20 年来，我们基本上每 9 到 10 周就会发布一个新版本，而且这套模式运行得非常出色。有时候人们甚至意识不到它有多好，因为它就那么运转着，一切都很顺利。
但在我刚开始推行这套机制的时候，这种模式简直被认为是疯狂的。昨天我们刚刚举行了 Linux 内核维护者峰会，这让我想起了早年时期的另一次峰会，大概是 2006 年那次。
当时我提出了自己的想法：我希望摆脱那种所谓的年度发布模式。因为名义上每年发布一次，实际上却往往要拖到两三年。
问题在于，当你采用年度发布模式时，就会出现两棵代码树：一棵是大家实际使用的稳定版代码树，另一棵是开发版代码树，所有新鲜、有趣、令人兴奋的工作都在里面进行。
可等到一年过去，真正要发布这些新功能时，整个系统往往已经无法正常运行了。因为这一整年里我们一直在不断地破坏原有的东西。这就是过去的开发方式。
这种模式一直让人非常头疼。很多 Linux 发行版会采用那棵没有进行新功能开发的稳定版代码树，然后再把他们认为绝对需要的补丁回移进去。结果每个人手里都有一套混杂不堪的代码树。我们称它们为稳定版，但实际上并不稳定；与此同时还有另一套开发版代码树。没有人能够真正制定计划，因为所谓的年度发布最后往往变成两年甚至三年才发布一次。
所以当你身处这样一种开发环境时，我却跑到维护者峰会上说："我不喜欢现在的模式，我希望我们能把发布周期从每两年一次改成每五周一次。"
当时大家看我的眼神，就像我脑袋上长出了第三只眼睛。有人甚至会问："你最近是不是吃了什么奇怪的药？"
但我的态度是："我真的非常想试试，因为现在这种两年一次的发布节奏根本行不通。"
事实证明，我提出的五周发布周期确实很激进，而且这是我故意设定得这么激进的。我当时也不认为我们真的能做到每五周发布一次。
但如今这套模式已经运行了 20 年。我不仅惊讶于它竟然真的行得通，更惊讶的是它至今依然运行得如此出色。我们几乎在一瞬间就彻底改变了整个开发模式，摆脱了过去那套方式。
严格来说，过去的模式并不是完全行不通，只是此前 15 年的开发过程一直非常痛苦。所以我们决定彻底改变工作方式。在这期间我们经历过几次类似的转变：工具和工作流程发生了巨大的变化，而这些变化往往伴随着非常痛苦的过程。但到目前为止，每一次转变最终都取得了成功。
过去 20 年里，我们一直拥有一套非常稳定、运转良好的开发模式，就像钟表一样精准。这真的非常棒。我们都知道，Linux 7.3 一周后就会发布，对吧？
Dirk Hohndel： 是的，7.3 已经发布了。有什么有趣的变化吗？
Linus Torvalds： 我以前常说，内核应该是无聊的。现在我很高兴地说，它确实基本上很无聊。我们没有什么特别重大的新功能，而且我一直在主动避免让每次发布都加入令人兴奋的新功能。
我非常相信渐进式的小改动。随着时间推移，这些小改动最终会汇聚成重大功能，而你不会觉得它们是突然出现的巨大飞跃。你看到的只是一些细微的变化，开发者和 Linux 发行版会逐渐采用它们，用户程序也会慢慢开始使用这些功能，有时候甚至要等上几年。
只有当你回头去看一个五年前的 Linux 发行版，再看看它现在的样子时，才会突然意识到："天哪，原来这期间已经发生了这么多重大变化！"
但我认为，我们不应该采用软件行业特别喜欢的那种传统的重大版本发布模式——发布一个全新的 1.0、2.0 版本，然后打破所有东西，引入一堆令人兴奋的新功能。
AI 生成的补丁越来越多，Linux 维护者开始用 AI 审查 AI
Dirk Hohndel： 这方面的典型例子，我不确定 Thomas Gleixner 是否在现场。从最初提出 RT Linux 到它最终被完整合并进主线内核，整整花了 10 年时间。所以是的，有些事情确实需要相当长的时间。
好了，我们这场演讲已经进行了 25 分钟以上，居然还没聊到 AI。我对此感到非常自豪。
Linus Torvalds： 好了，停！这种情况马上就要改变了。
Dirk Hohndel： 是的，马上就要改变了。那么，Sashiko 似乎是一个非常有用的工具，它可以利用 AI 来审查拉取请求。你实际上会在合并窗口期间用它来审查收到的 PR 吗？
Linus Torvalds： 我不用 Sashiko。我也不能这么说……
对于不了解情况的人来说，我们有各种 AI 工具，会在公开的邮件列表上进行补丁审查。这些邮件列表与我们平时进行内核开发的邮件列表是同一套。Sashiko 是其中最主要的一个工具，由 Google 内部维护，但整个项目是开源、公开进行的。
实际上，它已经改变了人们的工作方式。很多子系统现在基本上不再接受补丁，除非这些补丁已经经过 Sashiko 的公开审查。
我不会说这些审查结果完全可靠，因为它并不完美。AI 在代码审查中有时会提出错误的意见，这也是现实的一部分。我甚至不会因此责怪 AI，因为人类审查者同样会给出错误的意见。
Sashiko 确实改变了许多子系统的工作方式。某种程度上，我们正在用自己的 AI 补丁审查浪潮来应对 AI 生成的补丁浪潮。
人们开玩笑说，现在是机器人在和机器人对话。实际上，这种情况确实已经发生了。
其实 AI 对内核开发的影响是颠覆性的。我们现在收到了大量各种各样的补丁，其中有些针对非常重要、真实存在的安全问题，也有些针对已经 20 年没人碰过的代码——毕竟那些代码早就没人关心了。
可当你让一个 AI 机器人去检查代码，问它"这里是不是存在内存泄漏"，它就会回答："我才不管这个驱动程序现在是不是已经没人用了，我会把能找到的所有错误报告都给你。"
所以我们收到的补丁中，既有很有价值的，也有没那么有价值的。
总体而言，我认为 AI 正在改善我们的代码库。不过它也给维护者带来了很大的压力，甚至已经到了令人担忧的程度。
Dirk Hohndel： 我认为这也是 AI 代码审查工具如此重要的原因之一。它们并不是要取代维护者，而是能够让维护者的工作变得更加轻松。如果有一个 AI 工具能够帮忙检查差一错误（off-by-one errors）、API 使用错误以及类似的问题，我会觉得非常有帮助。
Linus Torvalds： 昨天的维护者峰会上，我们大约四分之三的讨论都围绕一个问题展开：如何让 AI 工具——无论是代码生成还是代码审查——都能减少大家的压力，让整个过程更加顺利，也能真正为所有人提供帮助。
显然，AI 已经成为 Linux 内核开发中的一个重大议题，其他领域也一样。相信大家对此都已经非常熟悉，甚至听得有些厌烦了。
"AI 是进入编程世界的入门药"
Dirk Hohndel： 不过谈到 AI 代码审查，人们最想讨论的往往是这样的场景：一位高级管理人员坐在办公桌前，告诉聊天机器人要开发什么新功能，然后 AI 就能完美地把它实现出来。我们还远远没有达到那个阶段。
我想聊的是我们最近关于你一个业余爱好项目的一次对话。你在开发一个原声吉他效果器，并且为上面的均衡器做了一个 JavaScript 用户界面。让我特别感兴趣的是，你描述了整个过程：你是如何从明确自己想要什么开始，一步步引导 AI，最终让它真正写出你想要的东西的。
Linus Torvalds： 我对 AI 的看法经历过很多阶段。最初我觉得它根本不怎么样。后来我开始觉得它作为一种工具还挺有意思，也鼓励大家多尝试、多玩玩。而现在我已经到了一个阶段：我真的很喜欢使用 AI。
需要澄清的是，我现在已经不怎么写大量的内核代码了。我的角色更像是一个维护者、技术负责人。对我来说，内核项目里真正干活的是其他人，而我更像是一个汇集各方工作的协调点。
不过在我自己做的那些小项目里——毕竟我至今仍然非常享受编程——我确实认为，只要正确使用 AI 并把它当作一种工具，它就会非常出色。我发现 AI 让编程变得有趣得多。
我大概是 1981 年开始编程的。那时候计算机简单得多，你能够理解它们在做什么，拿来和自己程序比较的作品也简单得多。我记得自己十几岁时写过一些游戏，那些游戏简直糟透了，但当时的标准也没那么高，所以我并不会因为自己写出来的东西而感到羞愧。
后来几年，我开始觉得软件工程的门槛已经高得惊人。一个刚入行的年轻人很难觉得自己那些微不足道的尝试有什么价值，因为他们看到的都是经过打磨、非常专业的作品。你看看自己的手机，里面有漂亮的界面。对于一个刚刚开始学习编程的人来说，要达到这样的水准实在太难了。
而现在，我在那些小项目中使用 AI 后，反而觉得 AI 真是一件了不起的东西。至于大家讨厌的"氛围编程"——当然也不是所有人都讨厌，只是很多人喜欢拿它开玩笑——我认为它是重新找回编程乐趣的一种绝佳方式。因为它让你觉得自己正在做一些真正有用的东西，也让初学者能够完成一些原本很难做到的事情。
我认为无论你在学习什么，尤其是编程，入门门槛都应该足够低，让你能够先享受到其中的乐趣，然后真正开始学习——而学习需要花很长时间。
我以前确实不喜欢 AI，也一直对"氛围编程"嗤之以鼻。对于真正的项目，我现在依然如此。我认为在处理真实而重要的工作时，使用 AI 必须非常谨慎。
不过，我很喜欢把 AI 看作进入编程世界的"入门药"。
我当时在做自己的一个小项目，也就是那个吉他效果器。我知道自己在做什么：我已经用 C 写好了一个 UI，它运行在微控制器上，显示在一块小屏幕里。但我看着它就觉得："这也太蠢了吧，简直像是 80 年代的东西。"
我不是做 UI 的人。我想让它看起来更现代一些，像是这个世纪的产品。可我不会 Java，也不会那些花里胡哨的东西。我写内核，做的是硬核的事情——用 C 做底层编程。
所以我想，解决办法就是让 AI 帮我做那些我不擅长、而且我也知道自己不擅长的事情。有时候那些东西是我想学的；但有时候我甚至根本不想学。我仍然对底层编程感兴趣，只是也想拥有一个漂亮的 UI。
我看过你们都看过的那些 YouTube 视频：只要给 AI 一个提示，它就能帮你把东西做出来。于是我也给了它一个提示。结果它做出来的东西糟透了，真的很差。
但我知道自己想要什么，也知道自己在做什么。于是我继续给 AI 提示，告诉它："看，我已经用 C 把这些功能实现了。我做得是正确的，只是界面很丑。你就按照我已经完成的东西来做——这些代码我理解，也知道它们是正确的——然后给它一个漂亮的外观。"
最终的结果确实让我非常惊讶。
我觉得很多人喜欢讨厌 AI，也有一些人真心喜欢它。我认为 AI 是一种很有意思、也很有用的工具。它可以成为进入编程世界的入口，也可以帮助你写出非常优秀的代码。
不过，如果你想用 AI 写出真正优秀的代码，我认为你也必须理解代码本身，并且把 AI 当作一种工具来使用。它不应该只是一个玩具。
但通过把 AI 当作玩具来尝试、进而进入编程世界，也许正是一条很好的路径。
Dirk Hohndel： 没有比用"AI 是进入编程世界的敲门砖"这个观点来结束对谈更好的方式了。非常感谢大家。
完整采访内容：https://www.youtube.com/watch?v=0PSA2LFFlvk
对 Linux 内核开发与 Git 工作流感兴趣的读者，可以在云栈社区找到更多实战课程与资源。
发表于 20 分钟前
|
查看: 2|
回复: 0
/1 
