“物理AI界独角兽”：硅谷自动驾驶都在忙着做两件事：提效和评估！创始人爆料：真正瓶颈不在模型，是物理约束！机器人已进入高阶工程阶段

物理AI正处在“安卓前夜”！量产车不需要激光雷达！

今天，大洋彼岸，硅谷自动驾驶领域的秘密，终于有大佬站出来分享了。

如果你对自动驾驶、人形机器人中炙手可热的 VLA、世界模型还有疑惑，全球“物理 AI” 领域头部的基础设施平台 Applied Intuition 两位创始人：CEOQasar Younis、CTO Peter Ludwig的分享可真的是太对口了。

只要是物理 AI 领域，不管是近些年大火的 Robotaxi、人形机器人、世界模型，还是此前的新能源车、智能采矿机器、智能配送卡车，这家公司都已经深深扎入了它们的底层。

自动驾驶车辆量产时，为什么可以不需要激光雷达？

还不明白世界模型到底是做什么的？

物理 AI 的数据策略跟 LLM 有多大区别？Sim-to-real 究竟是怎样的过程？

美国的自动驾驶处于什么水平？

人形机器人真的不是泡沫吗？

可以说，所有这些疑惑的答案，都在这期长达 74 分钟的 Latent Space 的对谈中了。

最大的感受有五点。

首先就是，如今的物理 AI 产业所处的一个位置。Qasar 用一个精妙的类比点明了现状：“这非常像 Android 和 iOS 出现之前的手机市场。”

就如同当年谷歌决定做安卓的逻辑一样，如见物理机器设备买回来发现，市面上的操作系统五花八门，几乎不可能让现代 AI 应用运行在这些车辆和机器上。

“与其适配所有系统，不如做一个更好的操作系统，并让所有手机厂商愿意采用它。”因此，第一步必须是统一底层操作系统。Applied Intuition 正在做的，就是这一层整合。

第二点，在大模型时代，人们出于惯性地认为“更聪明的模型”就能解决一切。但 CTO Peter 指出了物理 AI 领域的根本差异：

“在物理 AI 领域，我们现在其实并不主要被‘模型有多聪明’限制。真正限制系统的是：如何把模型可靠地部署到硬件上。”

物理 AI 与 AI Lab 最大的不同是，本身会有各种不同的物理约束限制。比如：车端算力限制、安全关键约束、实时性要求（毫秒级响应），此外还有诸如震动、温度变化等极端环境条件。

相比之下，基础模型公司更多受限于算力、资金或者研究进展。物理 AI 面对的是一组完全不同的“物理世界导向”的约束。

另一个洞察，即现在 VLA 目前的主流范式是：云端训练大模型，车端部署蒸馏版本，已经成为标准范式。但难点就在于仅仅是高性能的“子版本”还不够，关键问题得是必须足够快（延迟足够低），同时保持性能。

第三，一个非常反直觉的爆料。激光雷达其实只是“教具”。

在自动驾驶领域，激光雷达的去留问题一直充满争议。Qasar 给出了一个行业内部的清醒判断：“激光雷达在研发阶段确实有用，但在量产阶段完全可以被去掉。”

它的核心价值在于提供“逐像素深度信息”。通过激光雷达和摄像头的组合，系统可以知道每个像素点距离车辆有多远，这些数据被用于训练模型，让模型“学习”深度信息。

所以最终结果是：研发阶段的车辆配置很“重”，传感器很多；但量产车辆会被大幅降本，仅依靠摄像头也能推断深度。

可以说这种瘦身操作是工程化的必然选择——低成本、高可靠性才是量产的核心目标。

第四，sim to real 是一个业内非常热门的话题。但具体业界都是怎么做的呢？似乎还没人具体爆料过。“仿真表现很好，一到真实世界就失效”这是行业常见困境。Peter 给出了破解之道：对齐。

“没有任何仿真系统可以一开始就完全等同现实世界。真实的流程是‘仿真—现实对齐’。”

你必须不断用真实世界数据去反向校准仿真系统参数，这个过程要反复很多轮，才能逐渐获得可信度。

Peter 还举一个非常具体的例子：人形机器人。一个真实问题是，执行器会过热。大家看到很多机器人做后空翻、跳跃，非常炫酷，但现实问题是这些动作是有热负载的。

如果仿真里加入“温度”这个变量，比如电机的发热情况，那么在强化学习过程中，机器人就会学会“避免过热的动作策略”。但如果仿真里没有这个参数，模型就不会考虑热约束，结果部署到真实机器人上，它会过热，然后失败。

总之，仿真只是一个软件系统，它比硬件更容易调整，但也更复杂——你必须决定“哪些现实因素要建模”。

第五，关于 Coding Agent 的话题。AI 编程工具的普及正在改变硅谷的招聘标准。Peter 透露，他们内部几乎什么都在用——前一阵最火的是 Cursor，最近基本已经被 Claude Code 接棒，甚至还有使用排行榜来推动团队采用。

但有一个重要的边界：“在安全关键系统里，人类验证依然是绝对核心。你不可能把生命安全交给未经严格验证的 AI 生成代码。”

真正的挑战变成了：在人类验证与 AI 自动化之间，找到一个合理的平衡点。

除此之外，还有一些有关业内特别关心的判断。

比如对于近期人形机器人赛道，Peter 和 Qasar 都认为，这条赛道经过了长期的发展，已经从概念真正进入了可用的阶段，所以会毫不动摇的参与下去，并表示：现在的人形机器人随时可以进入跑全程马拉松的阶段。而且，他们还对近日中国的人形机器人半程马拉松大赛表示关注，并称这是一种倒逼系统验证系统可靠性的直观范式，也是社会层面推动该赛道发展的“奖赏机制”。

此外还有物理AI方面招聘标准，俩位都特别提到跟 AI Lab 有着明显的不同，他们要求必须真实参与过生产环境的人，真正理解硬件与软件边界的人。

对于创业者的建议，有着 YC 背景的 Qasar 表示，认同 Sam Altman 之前的说法，即十几年前 YC 的建议已经不再适用如今的时代了。他建议不要再套路大厂或其他初创公司的模式，因为早期的苹果和如今的苹果，根本不是同一家公司。

同时 Qasar 还是建议如果背景不够硬，建议还是要尽早建立商业约束，不要铺开太多，聚焦在“复利型技术上”。

篇幅关系，不再一一展开。

以下是小编为大家精心整理的“物理AI世界的硅谷核心区域公司的大尺度内部爆料”，enjoy！

没有屏幕的世界：物理机器

日本已经跑通了L4级无人驾驶卡车

主持人：欢迎来到 Latent Space podcast。今天很荣幸邀请到 Applied Intuition 的两位创始人：Peter 和 Qasar，欢迎你们。

接下来请两位简单自我介绍一下。

Peter：我是 Peter Ludwig，Applied Intuition 的联合创始人兼 CTO

Qasar：我是 Qasar Younis，联合创始人兼CEO。

主持人：能否简单介绍一下 Applied Intuition 现在做什么？我看到一些材料提到：全球非中国前 20 大车企中，有 18 家是你们客户，同时你们也服务农业、国防、建筑等行业。很多人可能最早是在 YC 阶段知道你们，之后有一段时间比较低调。能不能用一个高层视角讲一下现在的业务？

Qasar：我们的使命是为更安全、更繁荣的世界构建“物理 AI”。我们做的是面向各种移动系统的物理 AI，包括汽车、卡车、工程机械、矿业设备，以及国防相关系统。

我们本质上是一家技术公司：研发并销售技术，客户是制造这些机器的公司，也包括政府机构。任何希望让机器变“更智能”的组织，都是我们的服务对象。

在整个 AI 版图里，过去三年大家的注意力主要集中在大语言模型上，也就是屏幕内的智能，比如代码、应用等。但我们的方向不同，我们是在把智能部署到“没有屏幕的世界”里——物理机器中。

这些机器有时会有驾驶舱屏幕，但核心价值并不在那里，而是在安全关键环境中的智能能力。这里“安全关键”非常重要，因为学习型系统可能会出错，但在某些场景中不能容错。

举个例子，我们现在在日本运行无人驾驶卡车（L4级别）。在这种系统里，你不能允许错误发生。

跟Scale AI的区别：做物理AI界的英伟达

主持人：这个方向一开始就是这样设定的吗？很多人会把你们和 Scale AI 放在一起看，早期都和数据基础设施有关。公司是怎么演进的？

Peter：从一开始，我们就希望成为一家技术公司，推动工业领域整体进步。最初我们从自动驾驶切入，客户是 robo taxi 公司，主要做仿真和数据基础设施。

后来逐步扩展，现在已经有 30 多个产品，整体覆盖非常广，是“物理 AI”领域的综合技术平台。

Qasar：之所以有人会把我们和 Scale AI 放在一起，更多是因为 YC 的背景。但实际上差别很大。Scale 更偏服务和数据标注公司，而我们从一开始就是工具链和技术平台。

当时（2016-2017）开发者工具并不流行，VC 普遍认为工具只是工作流，而工作流不值得投资。但现在行业又回到这个方向。

但我们从早期就明确一点：我们想把软件部署到物理机器上，比如汽车、卡车等。

当时我们并不知道 Transformer 会爆发，也不知道自动驾驶会走向端到端模型。但后来这些变化反而验证了一点：模型可以跨形态泛化。

所以工具链仍然是一个很好的切入点，一方面支持客户自己构建系统，另一方面也可以提供完整解决方案。

可以把我们理解成一个技术提供商，有点像 Nvidia 或 AMD，只不过我们不做芯片，我们做的是物理 AI 的软件基础设施。

我们甚至开玩笑说过，我们不是做 Instagram 那种消费产品的人，这从本质上就不一样。

招人更偏大厂工程师

Peter：是的，这种方向更偏工程体系。比如我们早期也做过地图等产品，但消费产品有完全不同的复杂性。我们更偏传统工程体系的人群，有点像来自工程文化链条的团队。

Peter：10年前就已经很清楚的一点是，软件和 AI 在车辆上的可能性远比当时实现出来的要大得多。我们当时进入这个领域，本质上就是看到了这一点。

过去这10年，我们的路径并不是一条直线，而是持续根据市场价值去调整方向。技术本身变化非常快，我们自己的技术栈基本上每两年就会经历一次完整迭代，到现在已经完成了大约四轮完整的技术栈升级。

这种节奏也影响了我们对工程的理解方式，我们几乎是按“两年周期”来规划研发投入，一方面保持足够的长期投入，另一方面也必须保持高度灵活，随时跟随最新研究进展和团队的技术突破进行调整。

一个比较稳定的点，是我们招人的类型一直没有变。

我们主要招聘的是工程师，这些人可能来自比较传统的大厂体系，比如 Google 这种，但他们和普通互联网公司的工程师有明显不同——他们必须理解硬件和软件的交叉系统，同时也要懂系统工程，以及把机器学习系统真正落地到生产环境的人。

目前公司大约 83% 是工程师，总体规模大约 1000 名工程师，这个数据是最新的。

同时我们还有一个有意思的现象：公司里有 40 多位前创业者。

这部分更多是“自然发生”的结果，而不是刻意设计的策略。我们吸引了很多 YC 和非 YC 背景的创始人加入。某种程度上，这里更像一个让工程能力和产品能力同时被释放的环境。

我们也确实吸引了很多来自 Google 的人，他们在这里可以同时发挥技术能力和产品能力。

从组织结构来看，我们既有做基础研究的团队，也有做工程落地的团队。我们会发布研究成果，但最终核心目标始终是：把智能系统真正部署到现实世界。

这家硅谷核心区的公司都在做什么

主持人：Peter，你刚提到技术栈，我想进一步问一个问题——Applied Intuition 这个公司能力的边界在哪里？你们不做什么？以及在不同垂直行业里，哪些能力是共通的？

Peter：我们可以拆成几个主要模块来看。

第一部分，是我们最早起步的方向：仿真（Simulation）和相关基础设施。

如果你要构建一个涉及复杂移动机器的软件系统，你必须先测试它。而测试的最佳方式，是虚拟环境 + 真实世界测试结合。

这里面关键是一个问题：仿真结果必须和真实世界高度一致，这种“对齐”本身就是一个非常深的技术问题。我们在这块有完整产品体系。

其中强化学习（Reinforcement Learning）也是这个体系的重要组成部分。现在很多 AI 系统的进步，本质上都和强化学习密切相关，在算力足够的情况下，它能做非常多事情。

第二部分，是操作系统技术（Operating Systems）。这里不是传统意义上的应用系统，而是真正的系统层能力，包括调度器、内存管理、中间件、消息传递、高可靠网络通信、数据链路等等。

现实情况是，如果要把 AI 部署到车辆和机器上，你需要一个非常强的操作系统。

我们在深入这个领域之后发现：市场上现有方案并不令人满意。所以我们决定自己做。这也直接催生了我们现在的操作系统业务。

核心逻辑很简单：要运行好的 AI，就必须有好的操作系统。

第三部分，是基础 AI 技术本身，包括模型层。我们做大量基础研究，同时也在构建所谓“世界模型”和自动驾驶模型，这些模型运行在真实的物理机器上。

应用范围包括汽车、卡车、矿山设备、建筑机械、农业设备，以及国防系统，覆盖陆、空、海多个领域。

Qasar：第三部分还有一个子方向，是人机交互。过去这些机器主要依赖按钮、机械控制，或者简单触控屏。但趋势正在变化：未来更自然的方式是通过语音与机器协作。

机器会理解环境，也会理解驾驶员或操作员的状态。比如最基础的安全场景：驾驶员是否疲劳。这种能力会被放大到更复杂的工业场景中。

更进一步，可以把“人 + 多个机器 + AI agent”的协作类比到农业或工业系统中：农民只需要在关键节点做决策，其余时间由系统代理执行任务。

这类似于在物理世界中运行 agent，而人在关键时刻介入。

这也不完全是纯自动驾驶，而是人机协同系统，在汽车行业里通常可以理解为 L2++ 或带人类在环的系统。

研发阶段车配置激光雷达，

量产阶段却可以去掉，为什么？

主持人：你刚才完全没有提到硬件，比如传感器、芯片这些。在自动驾驶领域，大家经常讨论摄像头、激光雷达之类的选择。你们在这些设计上影响力有多大？有没有参与联合设计？

Peter：我们不做硬件，也不生产传感器。但在我们的系统中，会使用大量传感器。我们会提供一套“推荐支持的传感器组合”，客户可以在这个范围内选择。

如果客户有非常强的需求，我们也会把新的传感器集成进平台。

至于激光雷达的问题，在这个行业里其实已经是一个长期讨论的经典话题了。

关于自动驾驶这个领域，目前行业的一个现实情况是：激光雷达毫无疑问是一种有价值的传感器，尤其是在数据采集和自动驾驶研发阶段。

比如你现在在湾区，还能看到一些测试车——包括 Model Y 或 Cybertruck，上面依然装着激光雷达在跑路测。这说明它在研发阶段确实是有用的。

它的核心价值在于提供“逐像素深度信息”。如果把激光雷达和摄像头组合起来，一个看前方，一个提供距离信息，就可以知道每个像素点距离车辆有多远。这些数据可以用于模型训练，让模型“学习”深度信息。

最终结果是：在生产阶段，你可以去掉激光雷达，仅依靠摄像头也能推断深度。

所以你会看到一个很典型的结构：研发阶段的车辆配置很“重”，传感器很多；但量产车辆会被大幅降本。

我们整个产品体系都是基于这个逻辑设计的。最终目标很明确：低成本、高可靠性。

在某些特殊场景，比如国防应用，会有完全不同的取舍。例如夜间作业时，会更依赖红外传感器，而不是激光雷达或雷达，因为有些情况下你不能主动发射能量，但仍然需要“看见”环境。

所以本质上，我们是在覆盖整个传感器技术谱系，根据场景做取舍。

未来车辆的OS长什么样

主持人：那在操作系统这一层呢？用户的直观体验往往是车里的屏幕很差，比如一些车的系统卡顿、像廉价 Android 平板一样。未来车辆的操作系统会是什么样？

Peter：很多人提到“车载操作系统”，第一反应是人机交互界面（HMI），也就是屏幕和交互体验。

这确实是其中一层，但只是很薄的一层。真正的车载 AI 操作系统，会深入到安全关键系统和嵌入式系统的底层。比如：电机控制、发动机控制、执行器控制、转向冗余系统等，这些都需要操作系统直接参与调度。

同时，自动驾驶系统还有一个核心特点：实时传感器数据流。这些数据的延迟极其关键。如果用类似 Windows 这样的通用操作系统来处理，会完全无法满足实时性要求，延迟会高到不可接受。

所以我们做的事情，本质是系统级设计。我们关注的是整个系统的性能特征，并且可以对每一层进行精细调优。比如：控制延迟、内存管理、安全回退机制、故障保护，甚至包括一些极端情况，比如宇宙射线导致比特翻转，进而引发系统异常——这种情况也必须有安全机制兜底。

还有一个经常被低估但非常重要的问题：软件更新的可靠性。比如我自己的 Tesla，大概每个月都会收到一次 OTA 更新。

但在传统汽车行业，大多数厂商几乎不做系统级更新，即使有，也通常只更新某个模块，比如 HMI，而不是安全关键系统。很多情况下，甚至需要进店升级。

而通过我们的操作系统，可以实现整车系统级的高可靠 OTA 更新。

但这件事技术难度非常高。核心挑战是：不能“变砖”。如果更新失败导致车辆无法使用，成本极高，影响也非常严重。

某种程度上，我们对行业最大的改变之一，就是让“整车软件更新”成为可规模化的能力。

车载OS，目前处于“前安卓和iOS”时代

主持人：这些技术的客户是谁？很多硬件厂商本身就有自己的固件系统，有的甚至会自己开发软件。你们是卖给谁？谁来买单？是制造商还是终端用户？

Peter：可以用一个类比来理解。今天的物理机器行业，其实非常像 Android 和 iOS 出现之前的手机市场。

我自己很多年前在 Google 做过 Android。

当时 Larry 在 Google 推 Android，有一个核心动机：他们希望 Google 的产品可以运行在尽可能多的手机上。

但现实是，他们发现市面上手机大概有 50 种不同操作系统，Google 的应用几乎不可能在所有设备上保持一致体验。

于是逻辑变成了：与其适配所有系统，不如构建一个优秀的操作系统，让设备厂商主动采用。

这就是 Android 的起点。

现在的物理世界行业也是类似状态：虽然每家公司都有自己的固件，但系统极度碎片化。要让现代 AI 应用真正跑在这些机器上，第一步就是统一操作系统层。

这就是我们做的事情。

至于客户，主要是制造这些机器的公司，我们向他们提供技术，用来简化整体架构，并让 AI 应用可以运行在这些设备上。

通用车载AIOS的难点

主持人：这些系统的可复用性怎么样？是一个通用 OS，还是每个行业都要做定制？

Peter：整体是高度可复用的。核心技术是通用的，但有一些需要适配的地方，比如芯片支持。

如果你在做 LLM，通常会假设运行在 CUDA + NVIDIA 生态里，那你基本不需要考虑硬件差异。

但在物理世界里情况完全不同，尤其是安全关键系统，硬件非常多样化，所以必须做更广泛的适配，这是完全不同的复杂度问题。

不是只有一两家厂商，而是有很多不同的芯片组需要我们支持。所以我们的操作系统不仅能在类似 x86 的架构上运行，还必须能运行在多家公司、多种不同架构的芯片上。

但话说回来，我们在这方面已经耕耘了很久。所以我们支持所有这些芯片组。然后，当你需要运行应用程序时，我们现在可以跨多个供应商可靠地完成这项工作。

Qasar：这套思路其实非常受 Android 启发。Android 有一整套极其庞大的测试体系，它之所以强大，是因为它能作为一个稳定可靠的操作系统运行在成千上万台设备上。

我们认为，同样的事情也可以发生在各种物理移动机器上——只不过区别在于，我们所处的是安全关键领域，而 Android 不是。

主持人：那它的生态是开放的吗？比如在 Android 上，我不一定非得用 Gmail，也可以用 Superhuman。放到你们的机器系统里，客户能不能接入别家的自动化系统？还是说必须使用你们的全套方案？

Qasar：完全开放。

Peter：我们的理念一直很明确：我们是一家技术公司，我们把技术授权给客户，由客户按照自己的需要去使用。

如果客户希望同时采购我们的自动驾驶技术和操作系统，那当然没问题；如果客户只想采购操作系统，再搭配其他自动驾驶方案，也完全可以。

我们提供了非常完整的文档和开发工具，方便客户自己接入和开发。

主持人：所以属于“协同更好，但不强绑定”。

Peter：对，就是 better together，但不是封闭体系。

底层主要还是C++，不少场景用Rust

主持人：底层主要是 C++ 吗？毕竟要面对不同编译目标。

Peter：我们大量使用 C++。当然，Rust 现在也是很热门的新工具，在不少场景里也在用。

但只要你一路往底层走，尤其进入实时约束系统，最终一定会碰到 C++，有些极端性能需求甚至还得直接写汇编。

ClaudeCode正在反向影响物理AI平台

主持人：这就够硬核了。我很好奇你们内部对 coding agent 的采用情况。既然你们涉及这么多底层和偏冷门语言，AI 编程工具到底用得怎么样？有什么经验？

Peter：我们几乎什么都在用。前一段时间公司里最火的是 Cursor，最近基本已经被 Claude Code 接棒了。

我们内部甚至搞了一个使用排行榜，专门推动团队 adoption。而且说实话，这些工具真的非常有用。

不仅仅是用它们写代码，我们还从这些工具身上获得很多启发：既然在纯屏幕软件世界里，构建一个应用已经变得这么容易，那我们能不能把同样的思路搬到物理世界？让配置一台机器像写一段文本一样简单。

也就是说：如果你想让一台物理机器完成某个任务，我们能不能通过自己的工具链，把这件事也做得足够简单？

这其实已经在反向影响我们整套平台设计。

GUI 已经不重要了，纯文本就可以

主持人：这会不会改变你们 OS 的架构？比如接口层是否会变得更“AI 友好”？

Peter：会，而且变化很明显。早期我们的工具偏向工程专家使用，很多操作是数学化、系统化的，GUI 非常重要。

比如我们有一个产品叫 Sensor Studio，用来设计自动驾驶系统的传感器配置。你可以在里面拖拽、布置传感器，系统会帮你分析不同设计的权衡。

这种工具非常依赖 GUI，本质上更像 CAD 软件。但现在情况在变化。我们开始把所有能力开放成 API，然后再叠加 AI Agent。

现在你甚至可以通过纯文本描述来配置传感器系统，而且效果往往比传统 GUI 更好。

这种思路正在逐步扩展到整个产品线。

整个硅谷都在调整招聘标准，因为AI

主持人：AI 的普及有没有影响你们的招聘方式？

Peter：有，而且影响非常大。整个硅谷都在调整招聘标准，因为“能力模型”变化太快了。

过去我们主要考察的是代码实现能力——你能不能把东西写出来。

但现在更重要的是：你是否知道该问什么问题、如何组合不同 AI 工具，以及如何把这些工具变成工作流。所以现在的面试比以前更难，但允许候选人使用 AI 工具。

结果也很明显：工程师之间开始出现非常明显的能力分层。一类人已经深度使用这些工具，效率非常高；另一类人还没有适应，差距非常明显。我们现在更倾向于选择前者。

主持人：我记得你三年前写过“AI engineer”的观点，当时你提到不是所有人都适合成为 AI engineer，比如嵌入式系统、数据库、操作系统这些领域可能不适合。但现在情况好像变了？

Peter：是的，这其实就是经典的“苦涩教训（Bitter Lesson）”。六个月前我可能还会说，有些领域不太适合 AI。但现在情况变了。

比如半年到一年以前，用最新模型去写 GPU shader（着色器代码），效果其实一般。

但现在用同样的模型，你会发现它已经可以做得非常好，甚至会让人觉得“居然真的能用”。

AI 的能力扩展正在覆盖几乎所有工程领域。我们在嵌入式领域也看到同样趋势。

但有一点不会改变：在安全关键系统里，人类验证依然是绝对核心。你不可能把生命安全交给未经严格验证的 AI 生成代码。

所以真正的挑战变成了：在人类验证与 AI 自动化之间，找到一个合理的平衡点。

端到端方案：如果仿真速度不够快，成本不够低

就没有意义

主持人：再回到仿真和强化学习。现在“可验证奖励（verifiable reward）”和强化学习是很热门的话题。你们内部是怎么做这块的？

Peter：关键问题在于，随着模型越来越强，“评测（eval）”去发现系统缺陷这件事，反而变得越来越难，但它的重要性从来没有下降过。

因为即便系统整体变得更好，edge cases 依然存在，而且永远不会被完全消除。所以这块对我们来说是持续重点投入的方向。

再说强化学习。在新一代物理 AI 和自动驾驶系统中，有一个非常关键的变化：端到端模型正在成为主流。也就是说，模型可以直接从传感器数据输入，输出控制信号，并且效果越来越好。

但问题在于，这类模型的训练方式，和上一代系统完全不同。如果你要对端到端模型做强化学习，就必须能够“模拟完整的传感器数据”。这也就是我们所说的“神经仿真”。

可以把它理解为一种混合系统：结合了 Gaussian Splatting 和 diffusion 方法，同时对性能极其敏感。

因为性能在这里是决定性的。如果你的仿真速度不够快、成本不够低，你就无法训练出有意义的结果。

Qasar：这也和我们在嵌入式系统里的工作高度相关，本质上都是性能驱动的工程。这种“性能优先”的理念，也延伸到了模型训练中，因为只有足够快，训练才变得可行。

验证测试标准转向可靠性评估方面

Peter：有一个值得单独讨论的点，是我们对“验证与测试”的理解正在发生变化。

传统仿真，比如基于车辆动力学方程、教材公式构建的系统，是一种非常确定性的黑白判断。

例如在欧洲，有一个叫 Euro NCAP（欧洲新车评估计划）的体系。它会规定一系列测试标准，比如：

·自动紧急制动是否能识别冲出来的小孩

·是否能在特定场景下完成刹车

·这些测试是明确的“通过 / 不通过”。

也就是说，过去行业本质上是基于一组固定测试用例来做验证。但在过去十年发生了变化。

现在的 AI 系统是统计性的，而不是确定性的。问题不再是“是否通过测试”，而是：

·系统能达到多少个“9”的可靠性（99.999…%）

·平均无故障时间（MTBF）是多少

·整个验证体系变成了概率问题。

而物理 AI 行业的关键突破之一，就是这些系统的可靠性已经提升到“足够可用”的水平。

也就是说，“可靠性数量级”达到了可以商业化部署的程度。

所以现在的 V&V（备注：verification and validation，验证与测试）体系，从“是否满足要求”，变成了“统计可靠性评估”。

主持人：这些评估是给谁看的？是监管机构，还是客户？

Peter：我们同时与多个政府机构合作，包括美国、欧洲、日本等。但政府本身并不是 AI 实验室，他们关注的只是结果。所以很多时候，我们实际上是在做“方法论教育”——告诉他们：

我们如何定义安全、如何评估无人驾驶系统是否可以上路、如何理解统计意义上的安全性。

但严格来说，并不是监管机构在推动我们，而是我们在向他们解释这个体系。同时，这也是我们自己内部的标准，因为我们要构建真正安全的系统。

客户也非常重视这一点，我们也在持续教育客户如何理解这些指标。

Qasar：我们的第一个核心价值观就是“安全优先”。所以从内部来看，我们对系统安全性的验证，和监管要求一样重要，甚至更重要。

Peter：在全球范围内，监管往往是“最低共同标准”，但真正要做出好的产品，必须远远超过这个标准。

Cruise的终结并不是单点技术原因

人类驾驶的统计风险远高于机器

主持人：我经常会想到 Cruise 的案例，他们的一次事故几乎导致公司终结。你们怎么看这种“单点事故”的影响？是不是行业有点过度反应？

Qasar：Cruise 的问题，并不仅仅是技术问题。更大的问题在于公司如何与监管沟通，以及整体行为方式。

从技术角度看，它确实是一个事故，但真正放大影响的是后续处理方式。

如果换一种方式，Cruise 甚至可能仍然存在。但现实是，这是多次事件叠加后的结果。

更重要的一点是：统计系统里，事故是不可避免的。问题在于社会如何解读这些事故。

比如 Waymo 在这个领域做得很好的一点，是它在设定更高的行业标准，同时以更负责任的方式处理安全问题。

未来一定还会有更多类似事件，只是严重程度不同。但长期来看，有一个核心问题必须面对：人类驾驶的统计风险，其实远高于机器。这点没有争议。

所以最终社会需要回答的是：是否可以接受“极少数但可解释的事故”，来换取整体安全性的大幅提升？

主持人：有点像飞机。

Qasar：对。飞机是目前最安全的交通方式之一。甚至比起飞行本身，更危险的是你去机场的那段路。所以如果你担心坐飞机，可以换个角度想——先想想你是怎么去机场的。

Peter：现实中不会出现“比人类驾驶更严重事故的系统灾难”，至少在可预见范围内是这样。

人类本身就会犯非常严重的错误，比如疲劳驾驶、分心驾驶，甚至酒驾。我自己也经历过非常困倦的驾驶状态。

但在AI系统里，你有冗余机制、备份机制、失败保护机制。要出现灾难级事故，必须有很多层同时失效才会发生，这在设计上是被极力避免的。

仿真数据如何跟真实世界对齐

主持人：你们的仿真系统覆盖了大量场景，但有没有一种情况是：在仿真里表现很好，到了真实世界完全失效？

Peter：这里有一个常见误解：没有任何仿真系统可以一开始就完全等同现实世界。真实的流程是“仿真—现实对齐（sim-to-real）”。

也就是说，你必须不断用真实世界数据去反向校准仿真系统参数。这个过程要反复很多轮，才能逐渐获得可信度，让你相信“这个仿真结果和现实是接近的”。

如果你在完成这个验证之前就假设它是准确的，那确实会出现偏差场景。

但关键点是：验证流程不能跳过。必须确保仿真和现实之间的 gap 足够小，才能依赖仿真结果。

举个比较有意思的例子：人形机器人。一个真实问题是，执行器会过热。大家看到很多机器人做后空翻、跳跃，非常炫酷，但现实问题是：这些动作是有热负载的。

如果你在仿真里加入“温度”这个变量，比如电机的发热情况，那么在强化学习过程中，机器人就会学会“避免过热的动作策略”。

但如果仿真里没有这个参数，模型就不会考虑热约束。结果就是：部署到真实机器人上，它会过热，然后失败。

世界模型改变了以往的仿真：基于真实世界的数据扩展

主持人：问题在于现实环境变化太多，比如温度。那怎么保证仿真覆盖所有变量？比如在冰冻环境里，机器人其实不需要担心过热。

Peter：这正是仿真最难的地方。本质上你是在做一个优化问题：如何更快、更便宜、更好地构建系统。

而仿真只是一个软件系统，它比硬件更容易调整，但也更复杂，因为你必须决定“哪些现实因素要建模”。

而世界模型的出现改变了一件事：仿真不再只是基于公式，而是可以基于真实世界数据进行扩展。这让整个仿真系统可以随着数据增长而扩展能力。

但这里有一个关键边界，我们内部称为“临界线”。有些情况下，真实世界测试仍然更有价值。因为你可以用极高成本在仿真中逼近现实，但永远无法做到完全替代真实环境。

所以最终是一个平衡问题：一部分用仿真（便宜、可扩展），一部分用真实测试（不可替代）

在传统软件开发里也类似：大约 95% 测试可以在 CI/CD 流程中完成；剩下的一部分在硬件测试架构（rig）中完成。只有极少部分必须在真实车辆上验证，物理 AI 也是同样结构。

只依靠世界模型，不现实

目前更多还是一个辅助仿真工具

主持人：世界模型一直是一个很难理解的概念。比如它可能会“误以为太阳绕地球转”。如果只看视觉数据，模型可能会形成错误物理直觉。你们如何解决这种问题？比如“水面打滑”这种复杂现象？

Peter：这是一个非常好的问题。如果你完全依赖 world model，并希望它单独完成现实部署，那基本不现实，至少在工业可行性上不成立。

world model 很强，但它不是唯一工具。它的核心能力是理解“因果关系”：做了什么动作、会导致什么结果。比如在工程机械场景里：

如果你把土从 A 位置移到 B 位置，系统必须理解：A 的质量减少，B 的体积增加，这就是因果变化。

所以在实际系统中，我们不会只依赖 world model。它更多是：一个生成工具、一个辅助仿真工具、一个帮助工程师构建场景的能力。

但真正的系统落地，还需要其他工程体系一起工作。从工程角度看，如果完全依赖 world model 去做真实系统部署，很可能在商业上走不通。

所以现实策略是：world model 是工具，不是唯一答案。

世界模型如何理解车“打水滑”的？

Peter：数据本身当然是一个很大的问题。像“水滑（hydroplaning）”这种情况其实就很有代表性，而且很多时候它并不直观。

比如说下雨天，一条路因为有一定坡度，水会被排走，所以车辆可以更快行驶。

但当你进入一段非常平的路面时，水开始积聚，车辆就必须减速，因为速度一高就会失去抓地力。这里面有很多非常细微的视觉线索，是高度复杂的环境信号。

在 world model 的框架下，一个合理的情况是：模型其实可以学到一个更简单的策略——当它识别到这些视觉特征时，就自动降低速度。

这也是这类模型的优势：它不需要显式知道“水滑”这个物理概念，也可以学到“在类似环境下应该减速”。

云端训练大模型，车端部署蒸馏版本

主持人：我想问一下部署的问题。你们在训练阶段大量使用模型和仿真，但到了生产环境，这些模型是如何部署的？是在设备端运行 GPU 吗？或者说正确的术语是什么？

Peter：我们一般会分成两类：onboard（车端）和 offboard（云端）。

云端系统的优势是：不需要考虑时间约束。你可以运行非常大的模型，哪怕需要 1 秒甚至 10 秒出结果都没问题，因为是在数据中心环境。可以使用大规模 GPU，也可以做分布式计算。但 onboard（车端）完全不同。

车端系统有严格的实时约束，你必须在毫秒级时间内给出结果。所以核心问题变成：效率。

每一毫秒都非常重要，因为系统不能等待。

因此你会看到一个典型流程：先用大型模型在云端训练和运行，然后通过“蒸馏”得到一个更小、更高效的模型，部署到车端。

这个车端模型本质上是大模型的一个高性能“子版本”，但必须足够小、足够快，同时保持性能。

自动驾驶真正的瓶颈：不是模型本身，而是物理约束

Qasar：更宏观一点说，在物理 AI 领域，我们现在其实并不主要被“模型有多聪明”限制。

真正限制系统的是：如何把模型可靠地部署到硬件上。包括：车端算力限制、安全关键约束、实时性要求。这些才是瓶颈，而不是模型本身的能力。

相比之下，基础模型公司更多受限于算力、资金或者研究进展。所以我们面对的是一组非常“物理世界导向”的约束，这也会逼着你做出不同的设计选择。

 技术演进路线

主持人：

这就带来一个问题：你们的技术栈在过去几年是怎么演进的？

Peter：

如果回看 Transformer，其实最早论文是在 2017 年发布的。在论文的后半部分甚至提到，这种方法可能也适用于图像和视频。

但当时这个方向并没有立即爆发，而是过了几年才真正开始产生影响。现在你会看到 Transformer 已经无处不在。

与此同时，算力也在持续提升。但始终存在一个基本权衡：功耗、成本、性能。

在嵌入式系统里，你必须在这些约束之间找到平衡，同时还要考虑现实环境，比如震动、温度变化等极端条件。

我们也会基于这种趋势来规划技术路线，预测这些系统的进化速度。

车载系统能跑谷歌小模型，

但本质问题两个字：延迟

主持人：比如 Google 最近发布的 Gemma 2B 模型，这类模型对你们有用吗？还是太大了？

Peter：2B 参数模型在嵌入式系统里是可以运行的。但关键问题不是“能不能跑”，而是“怎么用”。你需要对模型进行大量定制，才能真正适配具体系统。

在一些场景下，比如语音交互，这类通用模型确实是有价值的。但在自动驾驶核心系统里，大部分能力还是完全自研的，包括数据、仿真、模型等。

Qasar：同时也存在一个结构性问题：有多少计算必须在本地完成，有多少可以依赖云端？本质上这是一个延迟问题。

Peter：对，核心还是 latency（延迟）。

VLA的大问题：依赖基础设施，离不开信号覆盖

Qasar：在一些环境下，比如美国，你确实可以依赖网络调用云端。但我们的大部分应用环境仍然必须是本地运行。原因很简单：覆盖条件不稳定。

如果回到更早期的自动化行业，比如矿业自动化，在 Transformer 出现之前，系统基本都是手工规则。比如：GPS 定位、预设路径、机械执行，这些系统已经能运行 20 年，而且在特定环境下非常可靠。但问题是，它们只能“执行路径”，无法理解环境变化。

而现代系统的关键变化是：机器开始具备感知能力，能够在动态环境中做决策。

早期 RTK（实时动态定位）可以做到 1–2 厘米级精度，这在很多离线场景非常有效。

但问题是，它依赖基础设施，比如信号覆盖。在很多偏远地区，比如矿区或无网络环境，这种系统就会受到限制。

Peter：同样的情况也出现在传统采矿和农业自动化系统里。比如一台联合收割机在田间作业时，精度可以做到一两厘米级别，他们使用的就是 RTK 这类系统。成本不低，而且虽然具备自动化能力，但这种“自动化”还远谈不上我们在 2026 年讨论的那种“智能”。

多技术路线策略

主持人：你在博客里提到过关于大规模 Transformer 的研究，它们和现代生成式 AI 使用的结构很相似。除了这一点之外，还有哪些关键差异？

Peter：我们内部采用的是一种多路径的策略。这么做的原因是我们同时在多个行业、多个地区运行，每一种技术路线的风险结构都不同，所以不会把所有资源押在单一方案上。因为某一条路径未必会成功。

不同方法在实践中会带来不同的优势，也会暴露不同的问题。研究团队的工作，就是不断针对这些薄弱点进行迭代，最终收敛到一个更稳定的系统方案。

物理系统也有规划模式，跟用CC一样

主持人：在物理系统里，是否存在“规划模式”？比如先规划再执行？

Peter：答案是肯定的。和你用 Claude Code 处理复杂任务一样，系统也可以先生成一个类似“规格说明”的计划，再逐步执行。这个模式在机器人出租车中很明显，但在矿山、国防等场景中会更重要，因为任务往往包含大量前置决策步骤。

驾驶这件事本身，很像“下一步 token 预测”。路径是连续的，可以随时修正。但在挖掘或采矿场景中，你一铲子下去，状态空间就发生变化，这种环境更“不可逆”。

不过从更抽象的角度看，很多问题都可以被统一成“下一步预测”的形式。无论是动作序列还是轨迹序列，本质上都是状态演化。模型在理解“当前状态变化”之后，会调整后续预测。

从这个意义上说，这套方法的通用性非常强。

机器人跑马拉松，随时都会发生

主持人：

你们在物理 AI 上，外界可能低估了什么？很多人看到的是演示效果很好，但现实中无法购买产品，这中间差距非常大。

Peter：

真正难的部分在于“生产化”。一旦进入真实世界，问题数量会急剧增加。比如人形机器人行业，目前普遍存在的问题就是系统脆弱性。

不只是中国，几乎所有国家都会用一种方式来引导产业发展，叫做“Prize Policy（竞赛激励政策）”。美国当年的典型案例就是 DARPA Grand Challenge，它对整个自动驾驶产业的启动作用非常大。

推动产业通常有几种手段：一种是监管引导，另一种就是通过竞赛机制去刺激技术突破。

我看到中国正在做一个人形机器人马拉松，这其实是一种“奖赏机制”。

这种方式本质上是在倒逼系统解决可靠性问题。人形机器人的核心难点之一就是可靠性。那还有什么比让机器人直接跑完 26 英里更直观的验证方式？

物理AI已经进入了“高阶工程阶段”

主持人：所以我们已经到了机器人能跑马拉松的阶段了吗？

Qasar：差不多随时都会发生。其实汽车行业也有类似机制，比如勒芒 24 小时耐力赛。Porsche 在赛场验证的很多技术，最后都会进入量产。

但我想把这个过程拆成三层：研究（research）、高阶工程（advanced engineering）、量产（production）。

很多人只看研究和量产，但中间其实有一层最关键的“高阶工程”。

它不是纯理论创新，不是在发明全新原理，而是围绕量产做工程化突破：找出哪些子系统会成为量产瓶颈，然后逐个攻克。

等真正进入量产之后，你又会遇到另一类问题：部署、维护、长期运行。所以至少在我们这个行业，大部分公司现在其实都处在“高阶工程”阶段。

机器人条件已经初步具备，会长期参与

主持人：听起来每一步都很难。

Peter：确实，每一步都难。

主持人（笑）：所以你们才值 150 亿美元，每一层都在流血。

Qasar：但这也挺有意思的，我个人其实很享受。更有意思的是，我们已经在这个行业快10年了，见过太多失败案例。

现在随便看一家这个领域的新公司，只要看一个 demo，我大概就能写出它接下来会遇到的20个问题，甚至能猜到它会怎么解决，以及哪几个方案大概率能成。

这不是说我们多天才，而是我们踩过太多坑了。我们自己的世界模型，就是在无数成功和失败里迭代出来的。

今天我们在节目里讲的是成功经验，但背后其实有大量失败尝试。这些失败最后都会沉淀成你判断世界的方式。

Peter：总的来说，我们对机器人领域是非常兴奋的，这里面的机会巨大。

但行业里有一点很关键：这些概念本身都不新，真正变化的是——现在它们开始真的“能用了”。

过去很多人一直想用神经网络做机器人，但一直缺少数据、缺少仿真能力，系统也跑不起来。现在这些条件开始逐步具备，模型也真的开始在现实任务中表现出效果。

所以我们肯定会参与，而且会长期参与这个方向。

创业建议一：尽早建立商业约束，在盒子里做事

主持人：你们会对创业公司提建议吗？或者说，有没有哪些创业方向你们会明确不建议做？

Qasar：最大的建议是：尽早建立商业约束。我们前面聊了很多硬件约束、技术约束，但其实商业约束同样重要。

也就是，你必须明确：我们只在这个盒子里做事。

很多创始人不愿意给自己加这个约束，因为一方面融资机会很多，另一方面技术问题本身已经足够难了，大家会觉得“我先把技术攻克再说”。

而且 VC 往往也不会特别在意商业边界。你只要告诉他，如果这个技术做成会赚很多钱，很多投资人就买单了。但那只是对融资有效，不代表对经营一家可持续公司有效。

主持人：也就是说，不能只用融资逻辑来替代商业逻辑。

“要做复利型技术”

Qasar：对。其实我们公司有个外界不太容易看到的特点：我们做的是“复利型技术”。

很多技术工作不会被丢掉，而是会不断累积增值。操作系统会持续变强，开发工具会持续变强，模型也会持续变强。

这是一种非常强的技术复利。你看 Waymo 就很典型。Waymo 很多年都只是“看起来很有意思”，但很难让人情绪上理解它为什么后来会值上千亿美元。

因为人的大脑天然不擅长理解复利效应。而这种复利，会在我们的行业里不断发生。

所以如果你是创业者，刚开始走这条很长的路时，最好在商业上给自己加一点约束，让自己更有概率活着走到复利兑现的那一端。

因为真正的大回报出现在后半程，但很多人根本撑不到那里。

所以总结一句：一定要非常谨慎地计算钱该怎么花，有限的工程师资源该怎么投。

创业建议二：别套巨头的策略

“早期和现在的苹果，根本不是一家公司”

Qasar：很多创始人还有一个常见误区：喜欢把成熟巨头的策略直接套到自己身上。

比如有人会说，Steve Jobs 说要做完全垂直整合。但问题是，2007年的 Apple 和1978年、1982年的 Apple 根本不是一家公司。

早期的 Apple 也不是一上来就全栈垂直，它也是大量采购外部电子元件，然后自己整合封装。所以创业公司在商业策略上要更细腻一点，这件事会直接影响你的技术路线。

YC早期经典路径：创业要聚焦，不要上来就铺太大

主持人：你现在的感受和早期创业时还一样吗？比如现在你在 X 平台也更公开了，很多创始人会选择融资很多钱来“展示实力”，但还没真正进入执行阶段。你怎么看“保持很窄的方向，但慢慢成长”的模式？

Qasar：这个问题其实可以换个说法：能不能从一个很小的产品空间出发，然后让这个空间逐渐扩展？

答案是可以的，而且这其实就是 YC 早期很经典的路径——先做小而深的东西，而不是一开始就铺很大。尤其在硬科技领域，问题是在太多了，如果一开始范围太大，最后每个方向都只能做到一般。最终产品反而会变得平庸。

所以我仍然支持从小问题出发。至于“是否要保密、是否要在早期沉默做产品”，这取决于你的背景。

如果你是我们这种背景，可以。因为我和 Peter 之前都在 Google 共事很多年，我们有很长的合作历史。这换句话说就是：我们有很大的行业人脉网络。

我们前 400 名员工里，大部分都是 Googler。公司早期人才来源和普通创业公司完全不是一个难度。

如果你是没有这种背景的创始人，那你就必须主动出来做这些事——发声、建立品牌、建立招聘吸引力、建立客户信任。

所以不要照搬我的版本，也不要照搬别的明星创始人的版本。大家所处的时间、环境、公司阶段都完全不同。

但你如果再去照抄别的年轻创业公司，也一样不靠谱，因为其中绝大多数都会死掉。

真正唯一有用的方法还是第一性原理：基于你自己的能力、联合创始人的能力、早期团队的能力，以及客户真实反馈，这些共同决定你应该进入哪个产品空间。

认同 Sam 的说法：10年前的创业建议已经不适用了 

主持人：这确实说得通。Sam Altman 也说过，他后来会反思自己当年在 YC 给出的很多建议，所以我也总喜欢问你们这些已经走出来的创始人。

Qasar：我大体认同这个方向，但这不完全是 YC 的问题，更大的变化来自市场环境。今天的 AI 创业环境和 2014 年完全不是一个世界。

AI 公司和传统 YC 创业公司的融资关系、资本密度、种子基金数量，全都发生了根本变化。

我们早期投资人之一是 Floodgate。他们曾做过一个统计：2000 年代末，市场上像 Floodgate 这种专门写 100 万美元以下第一张支票的基金，个位数都不到。但三四年前他们再做这个分析时，数到 350 家左右就已经懒得继续数了。

所以今天的创业环境和当年已经彻底不同。2014 年的 YC 建议，放到 2026 年很多都不适用了。

只是 Sam Altman 比我更擅长把这些话讲得简洁又有煽动力。我属于那种，如果你问我汽车的用途，我会直接翻开说明书告诉你：第一，这里是方向盘；而 Sam 会告诉你，汽车将改变人生。

主持人（笑）：确实，一个是用户手册，一个是愿景演讲。

物理AI值得关注的两大方向：

模型效率、模型评估

主持人：那 Peter 这边我也想问：有没有哪些你们特别希望行业有人能解决、但现在仍未解决的技术研究问题？如果有人在做，你们希望他们来联系你们？

Peter：有两个方向我觉得非常关键。

第一，是模型效率。因为我们的模型不是跑在数据中心，而是要跑在真实车辆和真实机器上。

物理 AI 本质上是在做一件事：把非常大的 AI，压缩成非常小、非常快、非常高效、可以在边缘设备上运行的 AI。

所以我们一直卡在这个边界上——模型能力很好，但还不够小、不够快。

如何在保持能力的同时继续缩小、继续提速，这是一个长期核心问题。

第二，是模型评估。尤其在安全关键系统里，评估是极其困难的课题。模型越强，错误越隐蔽；但你又不能允许错误进入现实世界。

所以我们在这块投入非常大。

简单说，我们非常欢迎两类人：一类是对模型性能优化痴迷的人，另一类是对模型评估和验证痴迷的人。这里的性能不仅是能力，也包括实际运行延迟。

物理AI工程师跟AI Lab招人要求：大不同

主持人：你们现在在招什么样的工程师？哪些人更容易在你们公司成功？

Qasar：可以直接看 fly.co/careers，现在大概有几百个岗位，覆盖从开发工具、物理 AI、操作系统，到自动驾驶和机器人系统的各个方向。

但其实“岗位”不是重点，更重要的是人。

我们是一家 Sunnyvale（硅谷核心区）风格很重的公司，这意味着我们偏爱非常硬核、非常严肃的工程师。

我们需要的是对底层系统有真实理解的人，不是停留在技术表面的那种。

当然我们既招通才，也招很多专家型人才，但有一个共同点：他们最好见过真实生产环境。因为只有真正做过生产系统的人，才知道技术该怎么搭。

Peter：对，我们很看重那些真正理解硬件与软件边界的人。

现在在 vibe coding 时代，出现了一批工程师，他们几乎完全不考虑硬件约束。但我们没有这个奢侈条件。我们的工作对象是真实机器，所以必须更往底层钻。

Qasar：如果拿我们和纯 AI Lab 做对比，最大差别就在这里：他们更多在处理抽象智能，我们处理的是现实世界。现实世界不会因为 prompt 写得漂亮就自动工作。

当然，老生常谈的品质也重要：愿意拼、真的热爱技术。说得直接一点，如果你能听这个播客听到现在，你大概率就属于我们想找的人。

教育体系脱节了

主持人：顺着你提到的硬件和软件边界这个话题，我其实一直在想美国，甚至更广义上的整个教育体系。我感觉大家正在逐渐远离那种传统的计算机科学教育、工程教育。

是不是到了某个阶段，你们得自己来培养这类人？毕竟现在你们已经算是这个领域的世界级专家了，没必要等着大学体系慢慢给你们输送，对吧？

Qasar：你是说内部教育和技能升级这件事？

主持人：对，直接自己抓起来培养。像通用汽车当年不就干过吗？搞了个自己的 GMI 大学。

Qasar：对，我本科就是在通用汽车学院读的。

主持人：等等，我刚才完全没听出来。我之前只注意到 HBS。

Qasar：对，大家都会先看到HBS，哈佛那个牌子毕竟太响了。

主持人：通用汽车学院是个什么样的地方？

Qasar：它100年前创办出来，目的就是回答你刚才这个问题。真的是一模一样的问题：密歇根工程师不够用了。那时候正是现代企业制度刚起步，通用汽车在快速扩张。这里我很推荐一本书：My Years with General Motors，作者是 Alfred P. Sloan，里面讲的就是现代公司是怎么成型的。通用当时意识到自己最大的瓶颈就是工程师储备不足，于是干脆自己办了一所学校。甚至谷歌在大概十年前内部也认真讨论过要不要自己搞一所大学。所以答案是肯定的，我们现在也在做大量内部培养。说实话，我们公司内部培训的规模之大，很多人都会觉得意外。

Peter：对，但这也是公司做到我们这个体量之后才有的奢侈条件。你如果只有 25 个工程师，先活下来再说。

Qasar：所以还是那句话，创业者要听适合自己阶段的建议，而不是一上来就想着“我要不要直接从高中生开始培养工程师”。

主持人：我还真上过你教的一门课，听起来你确实很会教。

工程思维的本质：极致的好奇心

Peter：说实话，我觉得现在这些大模型最惊人的一个应用场景其实就是教育。我亲自带过一个工程师，他原本是航空航天背景，本身就很优秀。结果在相对很短的时间里，借助这些模型，他已经能非常自信地做前端，也能非常自信地做后端。大模型不只是帮你写代码，它还能帮你学习。你可以不停问问题，而且不会尴尬，因为模型不会嘲笑你问得蠢。

Qasar：对。但我觉得相比工程学位，更关键的是工程思维。当然，工程学位依然很重要，我也不觉得像流体力学、热传导这种基础知识能有什么捷径可走。这些底层原理你还是得啃。尤其机械系统这一侧，最重要的是你得具备工程师那种思考方式，而这件事并不是每个人天生都有。有些人天生更偏向艺术或者别的方向，这完全没问题，也没有价值判断。只是工程思维的本质，其实是一种不断往更底层追问的冲动：我想知道更深一层，再深一层，还能不能更深一层。比如光子到底是怎么运动的？

主持人：极致的好奇心。

Qasar：对，极致的好奇心。光到底是什么？无线电波是什么？这种最基础的问题。如果你对软件足够好奇，最后一定会一路追到硬件层。就是Alan Kay那套思路。

备注：Alan Kay，2003年图灵奖得主，是计算机科学领域一位举足轻重的人物，被誉为“面向对象编程之父”，同时也是图形用户界面（GUI）的先驱。

卡车和汽车完全是两个优化目标

主持人：对，完全是那个意思。我其实一直在试图给你们找个类比，方便大家理解。你们有点像“新一代通用汽车”加上“Tesla自动驾驶部门”的混合体，对其他人来说是这么个感觉。

Qasar：嗯，我们其实横跨了很多别的领域。比如你如果去问我们的卡车客户，他们甚至不会把我们理解成一家“做汽车的公司”。他们会觉得：你们是真正在帮我们解决卡车问题的。汽车和卡车完全是两回事。

Qasar：对，是分开的。里面是不同的问题集。你大概可以先粗分成两大类：公路场景和非公路场景。但哪怕在公路场景里，也还有大量不同的机器子类别。

尤其像配送机器人这种里面根本没有人的设备，它和载人的自动驾驶系统就完全不同。因为这时候你不用考虑乘坐体验，不用考虑人坐在自动驾驶系统里会不会紧张、会不会晕、不舒服。你甚至可以急刹，完全不在乎车辆的 jerk（加加速度）这些指标。整个优化目标都会变掉。

Peter：更准确的理解方式其实是：任何一台需要人类经过专门训练才能操作的机器，你都该把它视为一套独立的问题体系。开卡车需要的驾照和开汽车不一样，开飞机的执照又完全不一样。

主持人：太棒了，感谢两位今天花时间来聊。

Peter：感谢邀请。

Qasar：谢谢。

参考链接：

https://www.youtube.com/watch?v=rv23_KcHt4s

文章来自于微信公众号 "51CTO技术栈"，作者 "51CTO技术栈"