Build to Last

杰里米留言：我们将于11月3日开始一门课程，教授如何在有效利用人工智能的同时，朝着软件精通和工艺的方向发展。如果你感兴趣，请访问 solve.it.com。

我花了数十年时间教人们编程，开发帮助开发者更高效工作的工具，并倡导编程应该对每个人都是可及的。通过 fast.ai，我帮助数百万人不仅学会使用人工智能，而且深入理解它，从而构建出真正有意义的东西。

但最近，我深感担忧。人工智能代理革命承诺让每个人都更高效，然而我看到的却是另一种景象：开发者正在抛弃那些能带来理解、精通和持久软件的实践方法。当首席执行官们吹嘘他们的团队每天生成一万行由AI编写的代码时，当初级工程师告诉我他们“凭感觉编码”来解决问题，却并不理解解决方案时，我们是否正奔向一个无人理解任何事物运作方式、能力急剧下降的未来？

我需要与一位体现相反理念的人交谈：一位他的代码在他创建几十年后依然在运行世界的人。这就是为什么我联系了克里斯·拉特纳（Chris Lattner）。

克里斯和我在2025年10月5日进行了交谈，他很友善地允许我记录这次对话。我很高兴这么做了，因为这是一次富有思考性和启发性的交流。请观看视频以获取完整采访，或继续阅读我总结的所学内容。

视频 3

与克里斯·拉特纳对话[](https://www.fast.ai/posts/2025-10-30-build-to-last.html#talking-with-chris-lattner)

克里斯·拉特纳构建的基础设施因其无处不在而变得隐形。

二十五年前，作为一名博士生，他创造了LLVM：将人类编写的代码转换为计算机可执行指令的最基础系统。到2025年，LLVM已成为大多数主要编程语言的基础：驱动Firefox的Rust、在你的iPhone上运行的Swift，甚至是由克里斯创建的C++编译器Clang，如今谷歌和苹果都用它来构建其最关键软件。他形容自己创造的Swift编程语言是“LLVM的语法糖”。今天，它支撑着整个iPhone/iPad生态系统。

当你需要某样东西不仅持续几年，而是几十年，足够灵活以至于你从未见过的人可以在其基础上构建你从未想象过的事物时，你就应该像克里斯建造LLVM、Clang和Swift那样去构建它。

我第一次见到克里斯是在2017年，当时他来到谷歌帮助他们处理TensorFlow。他没有只是对其进行微调，而是做了一直以来都会做的事：从第一性原理重新构建。他创建了MLIR（可以将其视为现代硬件和人工智能的LLVM），然后离开谷歌，创立了Mojo：一种旨在最终为人工智能开发者提供持久基础的编程语言。

克里斯设计的系统成为他人几十年来赖以构建的基础，因为他是一位真正的工匠。他非常重视软件开发的工艺。

我向克里斯表达了我的担忧以及作为程序员和CEO所感受到的压力：

“全世界其他人都在这么做，‘通用人工智能就在拐角处。如果你不全用人工智能做事，那你就是个傻瓜。’说实话，克里斯，这确实让我感到困扰。我质疑自己……我正感受到这种压力，想说，‘该死的工艺，该死的关心。’我们听到风险投资家说，‘我的创始人告诉我他们每天产出一万行代码。’我们疯了吗，克里斯？我们是不是老男人对着天空大喊，‘在我那个年代，我们关心工艺’？还是发生了什么？”

克里斯告诉我，他也分享我的担忧：

“很多人说，‘天哪，明天所有程序员都会被通用人工智能取代，所以我们干脆放弃回家算了。我们为什么还要做这些事？如果你在学习编程或为自己的作品感到自豪，那你就是做错了。’这是我相当担心的事情……

但今天的问题是：你如何构建一个能够真正持续超过六个月的系统？”

他向我展示了这个问题的答案是永恒的，实际上与人工智能关系不大。

从第一性原理设计[](https://www.fast.ai/posts/2025-10-30-build-to-last.html#design-from-first-principles)

克里斯的方法始终是提出根本性问题。“对我来说，我的旅程一直致力于理解是什么让某件事运作的根本。”他告诉我。“当你这样做的时候，你会开始意识到，许多现有系统实际上并不那么好。”

当克里斯在2000年圣诞节假期开始LLVM时，他在问：编译器基础设施从根本上需要具备什么，才能支持尚未存在的语言？当他进入人工智能领域时，他渴望了解我所看到的TensorFlow和其他系统中的问题。然后他深入探讨了从底层看人工智能基础设施应该是什么样子。克里斯解释道：

“这些系统之所以根本、可扩展、成功且不会因自身重量而崩溃，是因为这些系统的架构实际上运作良好。它们设计得非常好，具有可扩展性。那些参与其中的人拥有一个工程文化，他们团结在一起，因为他们希望使它们在技术上卓越。

以LLVM为例，它从来不是为了支持Rust编程语言、Julia甚至Swift而设计的。但因为它为此设计和架构，你可以构建编程语言，Snowflake可以构建数据库优化器——这真的很酷——并且从这种架构中衍生出了大量其他技术应用。”

克里斯指出，他和我有一个共同的兴趣：“我们喜欢从基础开始构建事物。我们喜欢理解它们，喜欢提问。” 他发现（正如我也发现的那样），如果你想让自己的工作有意义并持久，这一点至关重要。

当然，从基础开始构建并不总是奏效。但正如克里斯所说：“如果我们一定要犯错，那就犯一个全新的错误。” 如果你以与其他人相同的方式做同样的事情，那么你的工作不太可能产生重大影响。

工匠精神与架构[](https://www.fast.ai/posts/2025-10-30-build-to-last.html#craftsmanship-and-architecture)

克里斯指出，软件工程不仅仅是个人不断编写代码：“产品演进的很大一部分不仅仅是获得结果；它还涉及团队对代码架构的理解。” 实际上，这甚至不仅仅是理解，而是他追求更多。“让人们真正关心，让他们对自己的工作感到自豪。”

我见过那些用心、深思熟虑地构建的团队能够实现非凡的成就。我向他指出：“软件工程一直致力于打造越来越好的产品，同时你处理该产品的能力也在不断提升。因为你在构建越来越好的抽象和越来越深入的理解，所以事情变得更容易、更快。”

克里斯同意这一观点。他再次强调了长期思维的重要性：

“从根本上说，大多数软件项目，其软件寿命都超过六个月或一年。我所从事的项目以及你喜欢构建的系统，都是需要持续演进的。看看Linux内核。Linux内核已经存在了几十年，有成千上万的人参与其中。这种持久性得益于一位架构师林纳斯（Linus）的推动，他致力于保持一致性、抽象化，并在多个方向上进行改进。这种持久性正是由这种架构专注所实现的。”

这种深度工作不仅有利于组织，也对每个个体有益。克里斯说：

“我认为问题本质上是关于进步。它是关于你作为一名工程师。你学到了什么？你如何变得更好？你发展了多少掌握程度？为什么你能解决别人无法解决的问题？……我看到在职业生涯、生活和发展中表现得非常出色的人，都是那些不断进取的人。他们不会满足于现状，不会仅仅按照别人告诉他们的去做。他们实际上是在提出难题，并希望变得更好。因此，投资于自己，投资于你的工具和技术，并真正努力深入理解事物——我认为这才是让人们成长并实现几年前可能认为不可能的事情的关键。”

这也是我对我团队所说的。我最关心的是，他们是否始终在提升解决这些问题的能力。

注意：尽管心存疑虑，依然坚持建造

要建造一个能持续25年的项目，比如LLVM，需要的不仅仅是架构思维。它还需要在他人尚未看到愿景时，仍愿意追求自己愿景的勇气。

当我问克里斯关于Mojo的旅程时，他的热情和奉献精神再明显不过了：

“这是我毕生的工作。这就是我来到这个世界的目的：Mojo和MAX，解决人工智能计算，让人们可以为所有芯片编程并拥有选择权。这就是我的目标，我对此毫不避讳。但另一方面，这并不意味着每个人都相信。这对我来说没问题。很多人出于各种原因没有相信，无论是Hacker News上那个愤怒的人挥舞拳头质问‘为什么我不直接用Julia？’，还是某个员工说‘嗯，实际上，我不相信X、Y和Z。’ 这就像说‘好吧，酷，这里不是合适的地方。’…

试图让每个人都满意，只会导致平庸、委员会驱动的事物，如果你这样做，你就无法做出大胆而雄心勃勃的赌注。你必须有一个假设，一个核心信念。它可能是方向性的，可能没有完全精确的细节，但你必须坚持它，否则你无法到达那里。”

自我测试[](https://www.fast.ai/posts/2025-10-30-build-to-last.html#dogfooding)

但是，即使你非常投入并具有架构思维，如果你在真空环境中构建，这些仍然不够。

我不确定，如果你不亲自使用自己的产品，或者不与用户紧密合作，是否真的能创造出优秀的软件。当克里斯和他的团队开发Swift语言时，他们不得不在一个苹果保密的环境中进行。他分享道：

“使用自己的产品这一点非常重要。Swift在IDE功能和其他许多方面出现问题的一个主要原因是我们根本没有真正的用户。我们在开发它，但在发布之前，我们只有一个测试应用，可以说是‘自我测试’，但并不是真正的自我测试。我们根本没有在生产环境中使用它。等到发布时，你可以看出来。工具无法正常工作，编译速度慢，经常崩溃，缺少很多功能。”

他的新项目Mojo采取了完全不同的方向：

“在Mojo中，我们认为自己是第一个客户。我们有数十万行Mojo代码，而且全部是开源的……这种做法截然不同。这是经验的产物，但也是因为我们构建Mojo来解决我们自己的问题。我们从过去的经验中学习，采用最佳原则。”

结果显而易见。在早期阶段，基于Mojo构建的模型已经取得了最先进的成果。Mojo的大部分代码都是用Mojo编写的。因此，如果某些东西运行不佳，他们将是第一批注意到的人。

我们在 fast.ai 的 Solveit 平台也有类似的目标：我们希望达到一个点，即我们的大多数员工选择在 Solveit 中完成大部分工作，因为他们更喜欢它。（事实上，我现在正在 Solveit 中撰写这篇文章！）在达到这一点之前，我经常不得不强迫自己使用早期版本的 Solveit，以便亲身体验这些版本的不足之处，从而深入理解其中的问题。经历过这一切之后，我现在更加欣赏它如今的流畅运作！

但正是这种深刻的、基于体验的理解，正是我们在过度依赖人工智能时所面临的风险。

人工智能、工艺与学习[](https://www.fast.ai/posts/2025-10-30-build-to-last.html#ai-craftsmanship-and-learning)

克里斯使用人工智能：“我认为这是一个非常重要的工具。我觉得我能获得 10% 到 20% 的提升——一些非常酷的代码补全和自动完成功能。”但鉴于克里斯对工艺、持续学习和不断改进的重视，我开始怀疑，过度使用人工智能（尤其是代理工具）（“氛围编码”）是否可能对组织和个人产生负面影响。

克里斯：当你进行“氛围编码”时，突然……我看到的另一件事是，人们会说，“好吧，也许它会起作用。”这几乎就像一种测试。你离开去说，“也许这个代理工具会生成一些代码”，然后你花大量时间等待并指导它。然后，它并没有起作用。

杰里米：这就像一台赌博机，对吧？再拉一次杠杆，再试一次，只是再试一次。

克里斯：没错。再次强调，我不是说这些工具无用或不好，但当你退后一步，看看它在哪里增加价值以及如何增加价值时，我认为人们对“当通用人工智能出现时，它将解决这个问题”的热情有点过高了。我只是在等待和观察……另一个方面是焦虑问题。我看到很多刚毕业的初级工程师，他们非常担心自己是否能找到工作。很多事情都在变化，我真的不知道会发生什么。但正如你早先提到的，很多人说，“好吧，我就把所有事情都‘氛围编码’好了”，因为这是“生产力”（带引号）。我认为这也是一个严重的问题。

杰里米：在我看来，这简直是在毁掉职业生涯。

克里斯：……如果你陷入“好吧，我需要弄清楚如何让这个东西让我成为一个 10 倍效率的程序员”的境地，这可能是一条根本不会让你真正开发任何东西的道路。实际上，这意味着你在浪费自己的时间，因为我们在这个地球上只有有限的时间。最终可能会阻碍你的发展，阻止你成长，并且无法真正完成任务。

从根本上讲，克里斯的担忧是，高度依赖人工智能的编码与工艺并不兼容：

“软件工艺正是人工智能代码所威胁的东西。并不是因为它无法正确使用——再次强调，我确实使用它，并且我觉得我做得很好，因为我非常关心代码的质量。而是因为它鼓励人们不认真对待工艺、设计和架构。相反，你只会退化到让错误队列变浅，并消除症状。我认为这才是我感到担忧的地方。”

“你想要达到的，尤其是在你的职业生涯不断发展时，是精通。这就是你摆脱人人都能做到的事情并获得更多差异化的方式……我的担忧是这种文化：‘好吧，我甚至不想尝试理解发生了什么。我只是花一些代币，也许它会很棒。’”

我问他是否有一些具体的例子，说明他见过事情出错的情况。

“我见过一位高级工程师，在收到一个 bug 报告后，让代理循环运行，花费一些代币，也许它会生成一个修复程序并创建一个 PR。然而，这个 PR 完全错了。它让症状消失了，所以它‘修复’了这个 bug（带引号），但它太错了，如果合并了，会让产品变得更糟。你用一堆其他更难理解的 bug 替换了原来的 bug，还有一大堆代码放在错误的地方做着错误的事情。这非常令人担忧。真正的担忧不是这位特定的工程师，因为幸运的是，他们是高级工程师，足够聪明，不会简单地说‘好吧，通过这个测试，合并’。我们也有代码审查，这是一件非常重要的事情。但我担心的是这种文化：‘好吧，我甚至不想尝试理解发生了什么。我只是花一些代币，也许它会很棒。现在我不必再思考了。’ 这是一个巨大的担忧，因为产品的演进不仅仅是关于获得结果；它关乎团队对代码架构的理解。如果你将知识委托给人工智能，而你只是在不思考你想要实现的目标的情况下审查代码，我认为这非常非常令人担忧。”

有些人告诉我，他们认为单元测试是更广泛使用人工智能的一个特别好的领域。然而，克里斯对此提出了警告：

“人工智能在编写单元测试方面非常出色。这是人们最不喜欢做的事情之一。说‘只需生成一大堆测试’感觉超级高效，看，我有这么多代码，太棒了。但有一个问题，因为单元测试本身也可能是技术债务。测试可能没有测试正确的东西，或者它们可能测试的是某个事物的细节，而不是该事物的真实理念……而且如果你使用模拟，现在你的测试中就会包含所有这些紧密绑定的实现细节，这使得随着事物的发展，很难改变产品的架构。测试就像你主应用程序中的代码一样——你应该认真思考它们。此外，很多测试需要很长时间才能运行，因此会影响你未来开发的速度。”

克里斯指出，问题的一部分在于，许多人使用“代码行数”这一统计数据来支持人工智能正在产生积极影响的观点。

“对我来说，问题不在于如何获得最多的代码。我并不是一个吹嘘AI编写了多少行代码的CEO；我认为这是一个完全无用的指标。我不以编写的代码行数来衡量进展。事实上，我认为冗长、重复且缺乏良好设计的代码是一个巨大的负担……真正重要的是：人们在完成任务和改进产品方面的生产力如何？这才是我关心的。”

所有这些担忧背后都有一种信念：通用人工智能（AGI）即将到来，因此传统的软件开发方法已经过时。克里斯对此并不陌生。“2017年，我在特斯拉工作，负责自动驾驶汽车项目，领导着Autopilot软件团队。我当时坚信，到2020年，自动驾驶汽车将无处不在，并且问题会被解决。那是一场急切的竞赛，试图去解决自动驾驶……但当时没有人真正知道这有多难。然而当时空气中弥漫着一种氛围：数千亿美元的利益、工作岗位被取代、交通方式的变革……我认为今天正发生着完全相同的事情。现在不是关于自动驾驶，尽管它确实在进步，只是没有人们想象中那么辉煌和迅速。但现在焦点是编程。”

克里斯认为，就像所有之前的技术一样，人工智能的进步实际上并不是指数级的。“我相信进步看起来像S曲线。预训练曾是一个大事件。它似乎呈指数增长，但实际上随着事情的发展逐渐趋于平稳。我认为我们有多个叠加的S曲线，它们都在推动令人惊叹的进步，但至少我没有看到那种突破性的火花。”

危险不仅在于人们对AGI时间表的判断可能出错——更在于他们在等待期间自己的职业生涯和代码库会发生什么变化。“技术浪潮会导致巨大的 hype 循环、过度戏剧化和夸大宣传，”克里斯指出，“无论是80年代的面向对象编程，其中一切都是对象，还是2000年代的互联网浪潮，要求一切必须在线，否则你就无法购买衬衫或狗粮。技术本身确实有其真实的一面，但最终结果是事物会趋于稳定，远不如最初承诺的那样激动人心。问题是，当事情趋于稳定时，你作为一名程序员处于什么位置？因为你走错了方向，是否已经浪费了自己几年的开发时间？”

克里斯谨慎地澄清，他并非反对人工智能——恰恰相反。“我是一个极客。我希望人工智能融入我们生活的方方面面，”他告诉我。“然而我不喜欢那些做出决策的人，仿佛AGI或超级智能（ASI）明天就会到来……变得多疑、焦虑、害怕生活以及建设更美好的世界，这看起来非常愚蠢，也不现实。”

与AI共存的软件工艺[](https://www.fast.ai/posts/2025-10-30-build-to-last.html#software-craftsmanship-with-ai)

克里斯认为关键在于理解将AI当作拐杖与将其作为增强你工艺的工具之间的区别。他认为AI在探索和学习方面特别有价值：

“它对于学习你不熟悉的代码库非常出色，因此非常适合发现新内容。AI的自动化功能非常重要。让我们摆脱编写样板代码、记忆API、查找Stack Overflow上的答案等繁琐任务；我认为这真的意义重大。让我担心的是，如果你走得太远，以至于不再关心你在Stack Overflow上查找的内容以及为什么它能这样工作，也不从中学习。”

克里斯和我共享的一个原则是紧密迭代循环的重要性。对于克里斯来说，从事系统编程意味着“编辑代码，编译，运行，得到一个失败的测试，然后调试并在这个循环中迭代……运行测试的时间应少于一分钟，理想情况下少于30秒。”他告诉我，在开发Mojo时，首要任务之一就是“尽早建立VS Code支持，因为如果没有能够让你快速迭代的工具，你的所有工作都会变得更慢、更烦人、更容易出错。”

我的背景有所不同——我是Smalltalk、Lisp和APL传统的粉丝，这种传统中你有一个实时的工作区，每一行代码都在该环境中操作对象。当克里斯和我最初一起合作Swift for TensorFlow时，我告诉他的第一件事是：“我需要一个笔记本。”不到一周，他就为我构建了完整的Jupyter Swift支持。我可以输入一些内容，立即看到结果，并观察数据在过程中逐步变换。这就是布雷特·维克托（Brett Victor）所说的“基于原则的发明”风格，即贴近你所创造的事物。

如果你想在使用AI的同时保持工艺水平，你需要紧密的迭代循环，以便你能看到发生了什么。你需要一个实时的工作区，你（和AI）都在操作实际状态，而不仅仅是编写文本文件。

在fast.ai，我们一直在努力将这种哲学付诸实践，通过我们的Solveit平台。我们发现了一个关键原则：AI应该能够看到人类所看到的一切，而人类也应该始终能够看到AI所看到的一切。没有单独的指令文件，也没有与你实际工作区不匹配的上下文窗口——AI就在你身边，支持你工作。

这创造了一种我认为是“对话中的第三位参与者”——之前，我通过 REPL 与计算机进行对话，输入命令并查看结果。现在，AI 也加入了这场对话，能够看到我的代码、数据、输出以及我在解决问题时的思考过程。当我问“这是否符合我们之前讨论的内容？”或“我们是否处理了这个边界情况？”时，AI 不需要我复制粘贴上下文——它已经在那里了。

我们团队的一名成员 Nate 构建了一个名为 ShellSage 的工具，完美地展示了这一点。他意识到 tmux 已经显示了你在 shell 会话中发生的所有事情，于是他只是添加了一个与大语言模型（LLM）交互的命令。仅此而已——大约 100 行代码。LLM 可以看到你之前的所有命令、问题和输出。到了第二天，我们所有人都在持续使用它。另一位团队成员 Eric 使用相同的方法构建了我们的 Discord Buddy 机器人——他没有在编辑器中编写代码然后部署，而是在一个实时符号表中逐条输入命令，直接操作状态。当它工作后，他将这些步骤封装成函数。无需部署，无需构建流程——只有对运行系统的迭代优化。

Eric Ries 正在用 Solveit 写他的新书，AI 能够精确地看到他写下的内容。他会问诸如“这段文字是否符合我们之前陈述的使命？”、“我们之前讨论过这个案例研究吗？”或“你能检查一下我的编辑笔记中关于这个部分的评论吗？”这样的问题。AI 不需要特殊指令或上下文管理——它就在前线，看着工作一步步展开。（我现在正在用 Solveit 写这篇文章，原因也是一样。）

我向 Chris 询问了他对我们在 Solveit 中所采取方法的看法：“与其引入一个只会快速编写代码的初级工程师，你实际上是引入了一位资深专家、一位高级工程师、一位顾问——一个能真正帮助你写出更好的代码并教你东西的人。”

我们如何做有意义的事情？[](https://www.fast.ai/posts/2025-10-30-build-to-last.html#how-do-we-do-something-meaningful)

Chris 和我都看到了一种分化的趋势即将出现。“我觉得我们会迎来技能的分化，”我告诉他，“因为那些错误使用 AI 的人会变得越来越差。而那些利用 AI 更深入、更快学习的人，将会超越 AI 能力的增长速度，因为他们是人类，并且拥有这种优势……会出现一群习得性无助的人，还有一小群人，大家都会说：‘这个人怎么知道这么多？他们太厉害了。’”

让 LLVM 持续 25 年的原则——架构；理解；工艺——并没有改变。“问题是，当一切稳定下来时，你作为程序员站在哪里？” Chris 问道。“因为你用错了方式浪费了多年的发展时间，现在突然间，其他人都比你在为世界创造生产力方面走得更远了。”

他的建议非常明确，尤其是对那些刚刚起步的人：“如果我刚从学校毕业，我的建议是不要走那条路。特别是当大家都在走一条路时，正是该走另一条路的时候。你想要达到的，尤其是在职业生涯发展过程中，是精通。这样你才能成为高级工程师。这样你才能真正深入理解事物，而其他人无法做到。这就是你如何摆脱人人都能做的事情，获得更多的差异化。”

hype 会平息。工具会改进。但 Chris 提出的问题依然存在：“我们如何真正为世界增加价值？我们如何做有意义的事情？我们如何推动世界前进？” 对我们两人来说，答案都涉及对我们技艺的深切关注，理解我们正在构建的东西，并将 AI 视为一种提升思维效率的工具，而不是替代思考的手段。如果目标是建造持久的事物，你就无法将这一任务外包给 AI。你必须深入投资于自己。