LEAP71创始人：大模型附加到CAD是死胡同！

为什么工程必须超越CAD以实现AI和增材制造的潜力

几十年来，我们看到了信息技术以摩尔定律的指数级进步，高速发展。随着生成式AI和大语言模型的兴起，这条曲线现在似乎正在变得更加陡峭——但工程领域并非如此。为什么设计一个热交换器仍然需要几个月的时间，而设计一个火箭发动机需要几年的时间？为什么有些工程师被困在反复设计同一个支架上，有时甚至是他们整个职业生涯？这与微芯片形成了鲜明对比，微芯片可以说是人类设计出的最复杂的“机器”之一，可以在几个月内开发出来。如果我让你使用一台四十年前的电脑，你会笑，但如果你乘坐20世纪80年代的汽车或电梯，你却不会犹豫——从这个角度来看，工程的进展是痛苦缓慢的。

这种差异长期以来一直困扰着我。这两个领域都根植于物理、逻辑和可制造性。两者最终都生产物理硬件。那么为什么工程没有跟上计算机硬件的步伐呢？我们都生活在物理世界中。为什么工程不能加速，以更有效地应对人类面临的巨大挑战和机遇呢？

在过去的十年里，我一直在试图弄清这个问题的根源。这个问题的核心在于一种根本不同的工程方法。在IT之外，我们仍然被困在一种视觉设计范式中，这种范式自古以来就没有发生过根本性的改变。一位古罗马工程师在一张纸上创建了渡槽的蓝图；今天，一位航空航天工程师在计算机辅助设计（CAD）工具中绘制航天器部件。

CAD只是做了它名字所暗示的事——它帮助工程师画草图。但它不保留意图，也不编码逻辑；这些都留在工程师的脑海中。我曾说过CAD是邪恶的——不是因为它有恶意，而是因为它创造了一种错觉，让你以为你在用计算机进行计算，而实际上你只是把它当成画板——尽管是一个强大的画板。真正的算法在工程师的大脑中运行，然后工程师的手以极其缓慢的效率将其转化为几何图形。

这种方法阻碍了创新，因为它使工程变得乏味。而且，当知识没有被保留下来——当设计视觉表现背后的意图没有被记录下来时——你就无法质疑它、改进它或严格测试其背后的逻辑。俗话说：“永远不要改变一个正在运行的系统。”而当你考虑到增材制造开启的广阔设计空间时，这种局限性就变得完全站不住脚了。增材制造消除了许多传统生产限制，能够创建高度集成、多功能和几何形状复杂的结构。但要充分利用这种自由，我们必须超越绘图。我们必须拥抱计算工程。

计算工程也是AI工程的必经之路，因为如果不了解设计决策背后的物理、逻辑和意图，就没有什么可以用来训练神经网络的。任何没有经过这一中间步骤的AI工程尝试都是障眼法。在LEAP 71，我和我的搭档约瑟芬·利斯纳一直在推进构建Noyron，这是一个大型计算工程模型（CEM），旨在将工程知识编码为计算逻辑。有人称它为“第一个制造机器的AI”。在某种程度上，它是的，这句朗朗上口的话肯定符合当前的炒作周期。

但在本文中，我想澄清我们实际构建了什么——以及为什么工程中的“AI”，至少在通常理解的意义上，往往是一条死胡同。我们将看看把工程带入计算时代真正需要什么，AI应该扮演什么角色，以及增材制造如何能以摩尔定律的速度解锁工程。最重要的是，我们将展示计算工程如何已经在生产现实世界的硬件——以及为什么下一代机器不会被画出来：它们将被计算出来。

（图源：LEAP71）

从命令到对话：与AI协作设计

设计机器的理想流程是什么？有些人想象一个黑盒AI，只需按下一个按钮就能神奇地产出一个完成的蓝图。只需输入新航天器的规格，就能输出一个完整、可直接构建的CAD模型。但工程不是这样运作的。工程是探索性的。你很少确切知道你想要什么，尤其是当你涉足已建立的设计之外时。发明新东西意味着测试大胆的想法、迭代并在过程中学习。当你实验时，你会有新的见解，完善你的目标，并重塑解决方案。它不是一份规格说明书，它是一场对话。

这就是为什么《钢铁侠》中虚构的AI助手J.A.R.V.I.S.实际上是对我们所需的一个更好的比喻。J.A.R.V.I.S.不只是输出一个完成的设计。它会倾听、建议并填补空白。随着新见解的发现，它会重新设计。它会标记什么是可行的，什么是不可行的。它支持一场开放式的对话，这场对话建立在第一性原理和严谨的工程基础之上，最终导向一台能够运行的机器。虽然J.A.R.V.I.S.是虚构的，但这种方法是现实的。在一个拥有ChatGPT和生成式代码工具的世界里，对话式的人机设计过程不再是遥不可及的。

在我们的版本中，输出不是CAD文件，而是一个计算工程模型：一个创造设计的算法。它可以被修改、迭代和测试——因为它不是一张蓝图，而是一个活的、逻辑的系统。就像自然界中DNA编码了动态产生生物体的算法一样，计算模型可以创建三维形状，以及直接驱动生产过程的数据——切片、G代码和热处理指令。这是因为该模型理解制造以及每个阶段带来的约束。

强调计算模型与传统CAD创建的“几何树”之间的区别很重要。计算模型是一组丰富的指令，其中对算法的微小调整就能产生截然不同的对象。计算模型可以在过程中的任何时刻运行物理模型、逻辑检查和制造验证，并直接改变结果。

在LEAP 71，我们已经构建了这样一个系统所需的许多逻辑构建块。我们手动编码来自教科书、现有设计、第一性原理思考和实践经验的工程知识。我们编码基础物理并嵌入通过多次生产运行丰富的制造约束。我们测试现实世界的部件（例如，热试车火箭发动机），收集数据，并将见解反馈到模型中。这个大型CEM——Noyron——不是一个在非结构化数据上训练的黑盒神经网络。它是面向对象的源代码（在我们的例子中，用C# 编写），明确编码了我们学到的所有东西。它是确定性的：给定相同的参数，它总是产生相同的结果。它是可追溯的、可解释的，并且不会产生幻觉。

每一个假设都有记录。即使是工程师经常使用的经验法则，一旦底层逻辑变得清晰，最终也会被公式所取代。从这个意义上说，计算工程可能是工程师第一次真正被迫变得科学化。传统的工程流程容忍了惊人数量的民间传说、试错和未记录的最佳实践——我们可以称之为“工程直觉”。在计算模型中，每一个假设都必须是明确的。每一步都必须是可验证的，每一个设计决策都必须是可解释的。其结果不仅是更好的机器，而且是工程本身更强大、更科学的基础。

计算工程模型需要为其创建的每个特征提供一个清晰的、算法的基础。它是基于逻辑的工程，而不是直觉。随着时间的推移，Noyron已经发展到涵盖了设计复杂机器所需的大部分知识。它仍然不完整——知识只在我们积极工作的领域中被添加——但许多领域共享相同的逻辑框架。例如，我们用于设计生物打印血管系统中的毛细血管分布的规则，结果发现直接适用于航空航天热交换器。指导歧管中流体布线的相同原则可以用于避免电动机中的电线交叉。Noyron已被应用于广泛的领域——从微机电系统和生物组织到火箭发动机、过滤系统、电极、热交换器和电动机。

在每一种情况下，设计都源于Noyron中编码的抽象工程DNA，而不是工程师头脑中的视觉概念。就像托尼·斯塔克在《钢铁侠》中从不接触触控笔一样，计算工程师从不在电脑屏幕上画几何图形。计算模型完成了所有的草图绘制。而且重新计算不需要很长时间，所以工程过程虽然还不是口头对话，但变得几乎是好玩的。你可以自由地测试想法，因为一个新设计只需要几分钟，而不是几周。创新需要迭代，而在这种范式中，迭代不再是昂贵的。

为什么工程的未来必须是计算型的

从根本上说，计算工程模型是一个算法，它从同一组输入中确定性地产生相同的结果。它如何得出这个输出取决于你想创建的对象类别。对于一个简单的歧管，你可能有一组空间中的连接点，这些点都需要连接到另一个点，并避免碰撞。一个简单的CEM可以在几秒钟内生成这样的输出，而一个人类工程师可能要在这个任务上花费几个小时。一旦你有了这样一个计算块，你基本上再也不用考虑这个问题了，除非你遇到算法失败或需要处理新挑战的情况。这意味着连接热交换器中所有复杂的管道不再是一项手动任务；一旦编码完成，逻辑会自动且一致地处理它。随着时间的推移，你可以添加制造约束、质量流量保持以及当前CAD设计范式下工程师觉得乏味的许多其他方面。

随着这些构建块的成熟，抽象级别也在提高。在某些时候，你只需说，“我这里需要一个热交换器，传热能力为X”，系统就会为你构建一个，完全可制造的，并且理想情况下已经使用了你确立的现实世界测试数据。你的热交换器需要适应复杂的边界形状？没问题，算法 会将管道布线或延伸到这个空间。如果这不可能，它会告诉你。

我们的太空推进系统计算模型Noyron RP，可以为完全不同的任务剖面自主生产功能齐全的火箭推进器。不涉及CAD；甚至连草图都没有。如果因为来自现场的反馈需要更改，算法就会得到改进，例如，通过调整只能在实践中发现的系数。该CEM生成的每一个未来设计都会自动受益于这一改进。这与人类CAD工程形成了对比，在后者中，任何见解都需要传达给碰巧设计该特征的那个人。很容易看出这种传统工作方式丢失了多少信息。

计算工程极大地加快了进展。例如，我们通过现实世界的测试和多次火箭发动机热试车验证了Noyron。在五个月的时间里，我们总共测试了八个独立的火箭发动机，包括气尖发动机，这是热试车中最难以捉摸和最复杂的发动机之一。气尖发动机看起来与传统钟形喷管发动机完全不同，但共享了它们90%的DNA。从规格到制造交接，没有一个火箭发动机花费超过几周的时间。每一次生成运行在普通的笔记本电脑上花费不到一个小时——并且每一个在第一次测试时都能工作，因为它是基于经过实践验证的物理模型。

Noyron输出一个视觉模型以供检查，但它也生成可制造的文件（例如，切片），提供性能预测，记录所有假设，甚至创建可以增材制造的夹具，以及可以加载到CAM系统中进行后加工的辅助几何形状，所有这些都是自动的，每次运行时都有。这远远超出了典型CAD工作流所提供的。计算工程模型是唯一的真理来源，每次运行时，它都会从视觉模型到制造文件和文档重新生成所有内容。

（图源：LEAP71）

为什么大多数工程中的AI会失败，该如何解决

与所有的炒作周期一样，现在出现了一种新趋势，即把一切都称为“AI”，即使它不是，并将AI应用于不适当的地方。让我们先澄清这一点：计算工程模型是一个算法，而不是神经网络。它在精神上更接近于专家系统。具有讽刺意味的是，在神经网络重新定义该术语之前，专家系统曾被称为“AI”。

在LEAP 71，我们确实使用大语言模型（LLM）来总结和从海量工程信息中提取信息。我们还将Noyron代码库连接到LLM，旨在构建一个系统，通过将经过验证的计算块与来自非结构化知识的新见解相结合来合成新机器。这种混合方法——将结构化逻辑与基于语言的合成相结合——使我们更接近J.A.R.V.I.S.的愿景。但毫无疑问，如果没有计算工程的算法、逻辑、科学基础，你将无法实现AI工程。

人们曾尝试将LLM附加到CAD工具上，使用神经网络生成3D文件，并将拓扑优化称为“AI”。这些方法可能看起来很有趣，但它们是死胡同。虽然与CAD系统对话很有趣，但你的通信效率甚至比使用鼠标或触控笔还要低。你必须费力地用语言解释你试图完成的事情，而不是指向某个地方。计算工程依赖于编程语言的清晰逻辑，编程语言正是为了以简洁和结构化的方式交流意图而设计的。自然语言是模棱两可的，不适合对几何形状进行低级描述。

为什么我们不能像用AI生成图像那样，从口述描述或餐巾纸上的草图，通过神经网络直接转化为功能性的3D设计呢？因为3D几何图形与图像不同，必须遵守物理定律。草图不携带关于设计如何运作的信息。即使你在数十亿个3D形状上训练神经网络，输出仍然是碰运气，因为3D网格不理解它是用来做什么的或它是如何工作的。

拓扑优化是CAD工具库中的一个有用工具。你可以画一些东西，然后使用底层物理对其进行优化，虽然这很有用，但它是反向工作的：从几何体开始并对其进行优化。在我们的范式中，我们从一张空白画布开始，从头生成对象。当然，拓扑优化与AI无关；它只是应用物理。

不过，有一个领域，AI工程和拓扑优化可能会握手言和。大多数人认为LEAP 71的技术栈涉及大量的计算流体力学（CFD）或其他模拟技术。事实并非如此。CFD需要巨大的计算资源，所以它非常慢。更令人不安的是，它基本上只对完成的对象运行。因此，它无法在设计过程中的某个特征生成时给你提供见解。

Noyron依赖于启发式方法，即对物理（例如，热传递）的直接评估，这在设计特征时适用。在我们的火箭发动机构建冷却通道的过程中，我们在创建通道本身的同时评估流体密度、推进剂的化学性质、压力、热载荷等，所有这些都直接影响横截面、曲率、壁厚等。我们不等待设计完成后再模拟这些东西，因为那很难产生可操作的见解。但是，如果你能瞬间评估复杂的CFD物理，我们就可以在设计阶段做出更明智的决定。物理信息神经网络（PINN）的出现相当有趣，因为它们基本上提供了即时结果。真正的AI工程将取决于计算系统（数学、物理、逻辑）和像PINN这样的新工具的结合。

一个类似J.A.R.V.I.S.的系统可以解释你的意图，并合成经过预验证的高层构建块来制造功能性的机器。这就是真正的AI工程将如何发展的方式。毕竟，你不仅想要一台能工作的机器，你还想了解它为什么能工作。即使是由J.A.R.V.I.S.对话生成的计算工程模型，也总是可追溯的和确定性的。

（图源：LEAP71）

工程的新基础

十年前，我带着一个简单的问题开始了这段旅程：为什么现实世界的工程不遵循IT的发展趋势？直接的答案是，我们没有像其他领域那样对底层方法论进行抽象。金融界的人如果想到要使用老式计算器手动处理公司的销售预测，会觉得好笑。当然，所有这些数据都是自动获取、重新计算并以高层格式呈现的。微芯片直到20世纪70年代都使用CAD进行设计。然后它们变得太复杂了，设计转向了根植于物理和逻辑的编码规则和算法。现代芯片设计不是由计算机辅助绘制的，而是从用Verilog等硬件设计语言编写的高级规范中计算出来的。列奥纳多·达·芬奇会对微芯片设计的过程感到困惑——但他会对CAD工程师的日常工作相当熟悉。计算工程改变了这一点。它将工程推向了那个抽象层面，推向了一个可以在几秒钟内重新运行的系统。但是，就像微芯片设计一样，它迫使工程师学习如何编写代码以表达他们的意图。

我们在未来几年将看到的是工程师之间的分化，一部分工程师将在更高的层面上工作，通过可访问的交流（也许是通过自然语言或高层视觉界面）创造性地与AI工程系统互动。另一部分工程师将生产经过验证和稳健的组件。

在过去的三年里，与我的搭档、Noyron系统的架构师约瑟芬·利斯纳一起工作让我大开眼界。我们能多快地构建和测试复杂系统？我们如何最终利用增材制造的惊人能力，我们如何将原本需要由数千个独立零件制造的机械进行功能集成？我毫不怀疑它将把工程带入摩尔定律的指数曲线之下，因为我已经在我们的日常工作中看到了这一点。