物理AI、世界模型与空间智能：术语混战背后的技术同源与路线之争

上周内部技术评审A组汇报的标题是《基于世界模型的端到端具身操作框架》投影刚切出来B组的同事就小声嘀咕“这不就是我们上季度做的物理AI平台吗”仔细比了一下技术方案两边确实高度同源输入多模态观测、预测未来状态、输出控制指令。但两个团队对同一个东西叫了两个名字然后评审的前二十分钟全耗在“世界模型和物理AI到底是不是同一个东西”上没有一个人聊模型结构和数据质量。这不是个案。过去半年物理AI、世界模型、空间智能、具身智能底座这些词在技术社区、行业会议、融资BP里高频出现但不同语境下指的东西经常互相打架。有些团队把世界模型等同于视频生成模型有些团队坚持必须是强化学习里那种可参与规划的内部模型有些公司对外讲物理AI实际做的却是空间重建。术语没有收敛既说明这个方向真的处在爆发前夜也说明整个行业对“我们到底在做什么”还没有形成统一共识。这篇文章想聊的就是这场名字之争背后的技术路线、商业叙事和研发管理问题。我会把几个热词各自的来历和指向拆开来看说说不同叫法背后隐含的技术选择再聊聊术语不收敛对实际工作到底有哪些真实影响最后给出我在日常协作里应对这种混乱的一些方法。1. 这是一场怎样的“术语混战”物理AI、世界模型与空间智能的三角关系先看现状物理AI、世界模型、空间智能、具身智能这四个词几乎是当前AI圈最拥挤的赛道标签。随便打开一个招聘网站输入“世界模型”能搜出一堆要求“熟悉生成式模型、有视频理解经验”的职位再搜“物理AI”出来的岗位描述八九不离十也是类似的东西——理解物理规律、预测环境变化、支撑机器人决策。岗位名称不同JD却高度重叠。这背后的原因很简单大家确实在做一个相似的东西但祖师爷不同、出发点不同、场景侧重不同于是每个人都在用自己的母语给同一个新生儿起名。1.1 物理AI从机器人叙事出圈的“热词”物理AI这个概念严格来说不是学术界先喊出来的而是产业界推出来的。某芯片巨头的创始人在年初的行业大会上把“物理AI”作为战略方向抛出时台下大部分研发人员的第一反应是这不就是我们做了好多年的机器人感知、仿真和决策吗但包装成物理AI之后它有了新的商业张力。按照这套叙事的定义物理AI指的是能够理解并遵守物理世界规律的AI系统包括但不限于对重力、惯性、弹性、摩擦、因果关系的建模。它强调的是“AI不再只活在文本和图片里而是要和真实的物理环境打交道”。这个定义天然贴合机器人、自动驾驶、工业仿真、数字孪生这类需要闭环控制的应用场景。从纯技术角度看物理AI这个词指向的能力非常具体模型需要在物理规律约束下做预测而不是仅仅在统计意义上生成一个合理的结果。比如说一个轮式机器人要从斜坡上下来物理AI得在内部表征里“知道”坡度、摩擦系数和速度之间的关系不能把轮子悬浮在空中。这种能力不能靠堆语言模型数据获得必须有物理交互数据的支撑。也正因为它的产业属性很强物理AI这个术语在融资、战略合作和对外宣传里出现频率很高。很多机器人创业公司在BP里写“具身智能”在对外采访里说“物理AI”技术文档里又写“多模态世界模型”——三个词指同一个核心系统但每个词的读者群不一样。1.2 世界模型一个跨越几十年的经典概念被重新激活世界模型的资历比物理AI老得多。学术界对“模型需要对外部世界建立内部表征”这件事的讨论最早可以追溯到上世纪八九十年代的认知科学和机器人学。后来强化学习社区把“基于模型的学习”发扬光大在一个智能体内部显式学习一个环境动态函数从当前状态和动作预测下一状态。这个“环境动态函数”其实就是一个朴素的世界模型。2024年到2025年这个世界模型概念被多模态大模型浪潮重新激活但指向发生了漂移。现在很多团队说的世界模型更接近一个“视频生成器”——给定一张静态图和一段动作文本让模型生成接下来的视频帧序列用来表示环境对动作的响应。这样做的好处很多视频是通用接口既不需要精确标注物理参数也不需要显式建三维环境直接从海量视频数据里学动态规律。于是“世界模型”这个朴素老词如今在不同论文里承载着完全不同的含义。有的是agent内部的状态预测器有的是基于扩散模型的视频生成网络有的是机器人领域用来做数据增强的仿真器。名字没变内涵四分五裂。1.3 空间智能具身智能的另一个坐标空间智能是第三股势力由某位知名华人学者在创业时大力强调。空间智能的核心命题是AI要能在三维空间中理解、推理、行动不仅知道“画面里有什么”还要知道“这些东西在三维世界中处于什么位置、什么姿态、如何被操控”。相比物理AI强调的“物理规律”空间智能更加关注“几何与拓扑”。一个系统如果能把RGB图像转成稠密的三维几何表征能在新视角下渲染出正确景象能识别出一个抽屉的打开方向和把手的抓取位姿那它就具备了对空间的基本理解。从应用落地看空间智能和具身智能的重合度相当高但它并不一定要求有机械臂或机器人本体纯数字的3D重建、场景编辑、自动驾驶占用网格预测等也属于这个范畴。这样一来局面就很清晰了物理AI强调“物理规律”世界模型强调“内部动态预测表征”空间智能强调“三维空间理解”。三个词各有侧重确实不完全等价但落到具体系统上它们经常出现在同一个系统里。如果一个具身机器人要完成“把桌上的杯子端起来递给你”这个任务它需要空间智能搞清楚杯子的三维位置和杯把朝向需要世界模型预测手伸过去时杯子的状态变化更需要物理AI确保移动轨迹符合重力约束、不把杯子碰倒——同一个系统三个词的粉丝都能指出自己关心的那部分。术语强调的核心典型能力最常出现的场景物理AI物理规律、因果重力/摩擦/惯性建模动态预测机器人控制、自动驾驶、工业仿真世界模型环境内部表征、动态预测预测下一时刻状态规划支持强化学习、视频生成、具身决策空间智能三维空间理解与操作深度估计、位姿识别、3D重建空间计算、机器人操作、自动驾驶具身智能身体与环境交互感知-决策-执行闭环人形机器人、移动操作、家庭服务2. 名字背后的技术路线之争为什么同一个东西会有这么多名字术语之所以难以收敛最表层的原因是学科背景不同。但往深处挖真正让几个名字吵得不可开交的是技术实现路线的分叉。同样的“预测环境未来状态”这个目标从生成式模型、强化学习、图形学三个方向出发做出来的东西在数据、模型结构、训练范式上差异很大团队自然要用不同的词来区分自己。2.1 生成式路线世界模型等于一个视频生成器先看最火的路径用扩散模型或自回归模型从视频数据里学世界动态。这套路线的核心假设是物理规律已经隐式编码在海量视频像素里模型不需要显式推出Fma这类公式只要见过足够多“物体掉落”“液体流动”“布料变形”的画面就能在给定输入帧和动作指令时生成符合物理直觉的未来帧序列。这条路线最大的特点是数据易得。互联网上有天文数字级别的视频配合文本和廉价标注模型可以以无监督或弱监督方式大规模训练。业界有不少团队把这个思路用到了机器人数据生成上——先学会一个视频生成模型再为机器人合成训练数据弥补真实物理交互数据不足的短板。但它的问题也很明显像素级生成成本高、推理慢且学出来的规律是统计学意义上的“像物理”而不是解析意义上的“是物理”。对于高速高精度控制场景比如机械臂插拔连接器、无人机穿越狭窄空间统计生成的结果可能看着顺滑但毫厘偏差就会导致物理失败。从业者心里清楚这类模型更像“视觉先验”离真正可闭环的物理模拟还有距离。2.2 智能体路线世界模型是规划器内部的环境动力学第二条路线的血统来自强化学习。model-based RL的核心思想是智能体除了学“给定状态选动作”的策略还要学一个“给定状态和动作预测下一状态”的动力学模型然后用这个模型进行想象和规划也就是在脑子里预演多种行为路径挑选最有利于长期回报的那条。这个动力学模型长期以来就被直接称为“世界模型”。一路发展下来代表性工作包括用一个紧凑潜空间作为环境的向量表征、用小规模循环网络或Transformer捕捉长程时空依赖在几百到几千步的想象轨迹中训练策略。这条路线的落地场景以机器人控制、游戏AI、自动驾驶决策为主尤其在样本效率上相比纯粹的model-free方法有明显优势。但这套世界模型与生成式路线最大的区别在于它通常不需要输出像素级未来画面而是输出压缩后的潜状态。好处是效率高——在潜空间里做预测和规划需要的算力远低于逐像素生成代价是潜表征的可解释性差人类很难直观看出模型内部“想象”的到底是什么。在技术评审时这种“隐式世界模型”常常被质疑你怎么证明它真的学到了物理规则而不是过拟合了训练环境的统计分布2.3 仿真与图形学路线世界模型作为可微物理引擎第三条路线来自机器人学和图形学传统用可微物理引擎、神经辐射场、高斯溅射这些东西构造一个能被神经网络驱动的模拟器。团队把物理引擎本身变成可微的这样梯度可以从任务损失直接反传到环境参数上或者用一个神经隐式场来表示静态场景再叠加刚体动态模拟器来做可交互的虚拟环境。这套路线的目的跟前两条不太一样它追求的不是在模型中“隐式学会物理”而是显式构造一个物理正确的数字孪生。机器人可以在里面练千万次动作再把策略迁移到真机上。某种意义上它更像是工程工具链而不是一个端到端的大模型。不过今天很多项目正在把三条路线融合起来。用生成式大模型当视觉先验用RL潜空间做决策规划用可微仿真做验证和打磨一个系统里同时出现三种“世界模型”并不稀奇。这就导致标题里说的“术语还没收敛”更加显著——同一个项目组的三个子团队可能各自用“世界模型”这个词但分别指向三种完全不同的模块。2.4 三足鼎立的路线的简要对照路线核心建模对象训练方式强项弱项生成式像素级未来帧大规模视频自监督泛化好、数据易得物理精度不足、推理成本高RL智能体式潜空间动态函数试错交互、想象训练决策闭环、样本效率高可解释性差、泛化受限物理仿真式实体几何动力学参数显式建模、数值求解精度高、可介入式修改数据/场景构建成本高这三条路线之间不存在谁是“正统”的答案它们解决的是同一个大问题的不同侧面。真正的共识性技术栈要等这三条路线在某些关键Benchmark上分出高下或者被迫互相借鉴之后才能稳定下来。到时候用什么词或许才会跟着技术范式一起收敛。3. 术语不收敛带来的真实影响研发沟通、论文检索与产品叙事如果只是学术圈内部的百家争鸣术语不收敛其实没那么要命。但它发生在产业落地最热、人才争夺最狠、资本关注度最高的窗口期就会产生一系列连锁反应。这些反应不会直接体现在模型精度上但会实打实地影响一个团队的工作效率和决策质量。3.1 跨团队协作中的“定义对齐税”先说我感受最深的一点跨团队协作时花在术语对齐上的时间成本高得惊人。一个项目可能需要感知团队、控制团队、仿真团队、数据团队、大模型团队多方配合而每个团队都有自己的话语体系。感知团队说“空间理解”控制团队说“动力学建模”仿真团队谈“数字孪生”大模型团队讲“视频预测”——所有人都以为自己在聊同一件事但一旦要联合设计接口问题就来了。最典型的场景是评审会。本来要评估技术方案的可落地性结果前二十分钟全在澄清名词你说的“世界模型”是视频生成的那个还是RL里做规划的那个你说的“物理AI”是从感知入口做还是从控制入口做这种对话连续发生几次后团队的应对方式通常是在项目立项文档里专门加一节“术语定义”明确本文档里的“世界模型”指什么、不指什么。这节文档浪费不了多少篇幅但能省掉大量无效讨论。领导层更容易被术语不一致带偏。某个管理层听到“世界模型”就以为团队在研究AGI听到“物理AI”又觉得公司在做机器人一周换一个战略印象。技术负责人如果不想办法把术语锚定到具体能力上长期下来团队的技术边界会在老板脑子里越来越糊融资和预算决策也会跟着摇摆。3.2 论文检索与学术积累的关键词漂移在学术层面术语不收敛直接污染了检索体系。过去研究环境预测你搜“world models”能找到经典RL文献也能找到视频预测的论文还能搜到自动驾驶场景预测的工作。但现在再搜结果里混着大量时空扩散模型、视觉Transformer、具身操作基座模型相关性显著下降。反过来搜“物理AI”学术数据库里返回的结果又非常稀疏——很多做类似研究的人根本不把这个词用在论文标题里。我自己的习惯是每季度做一次领域调研这两年明显感觉检索效率在下滑。以前围绕一个关键词可以把领域全貌扫出来现在得同时盯着“world model”“world simulators”“physical reasoning”“spatial intelligence”“embodied AI”至少五组关键词筛重处理的时间翻了一倍。更麻烦的是有些高质量工作因为命名冷门长期被索引遗漏直到被受关注的工作引用之后才进入主流视野。学术界对术语不收敛的反应往往是设立专门的Workshop。如果某个方向连续两年在同一顶会上有专门的讨论论坛那个名字大概率就会成为未来的主流术语“物理AI”和“世界模型”目前都还没有走到这一步还需要时间沉淀。3.3 产品叙事如何悄悄影响技术路线很多人没注意到的是术语选择会反向塑造技术路线。当一个团队决定对外统一使用“物理AI”这个词时他们内部的OKR就会不自觉地向“物理规律理解”倾斜——多采集带接触力的训练数据、强化物理一致性损失、把Benchmark侧重点放在动态预测上。这就是叙事锁定的效果。我见过一个项目原本做的是面向机械臂的视频预测模型性能不错。后来公司层面决定把对外口径改成“物理AI平台”产品团队为了配合叙事硬生生加了大量力学特征模块反而把原来的端到端流程弄复杂了。这就是被品牌叙事绑架的技术路线本质上不划算。做技术选型时不要让对外宣传的词反向定义内部技术栈产品和研发要各说各话但各话之间必须能对得上。3.4 招聘市场的用词混乱最后是招聘。团队想招一个能构建环境内部预测模型的工程师在JD里写了“世界模型方向”的职位名收到的简历里一半是做多模态生成的一半是做3D重建的还有一小撮做游戏引擎的。候选人觉得“世界模型是个筐什么都能往里装”投递意愿虽然高但匹配精度差。招人时如果只写热点词很难筛到对的人。我比较推荐的做法是在JD里同时写清楚能力层描述需要熟练的RNN/Transformer架构经验、有自监督学习/对比学习实战、熟悉强化学习或多模态对齐。术语词留在职位名里吸引流量能力词写在细节里做筛选效果比纯用术语词好得多。4. 如何在不稳定的术语环境里工作一线研发与管理的应对心得术语一时半会儿收敛不了工作还得继续。我在项目里摸爬滚打一段时间后总结了一套在不稳定的术语环境中谋生存的方法分享出来希望对同行有点用。4.1 把术语当“索引”不当“定义”第一件事调整对术语的心理预期。不要指望某个词能给出严谨边界把术语当成检索索引使用就够了。评审会上听到“世界模型”时第一步不是扑上去澄清或者纠正而是先识别对方在这个词下面对应的具体能力模块。索引相同、定义不同的人很多不值得浪费情绪。实际操作层面我会给常用术语加限定前缀来缩小范围比如“像素级世界模型”“潜空间世界模型”“策略内置动力学模型”。虽然说起来拗口但能保证对话双方对齐粒度。没有限定词的术语讨论尽量不要超过五分钟超过就立刻切换到具体模块和接口层面聊。4.2 用任务指标对齐不用名词对齐跨团队对齐时最有用的操作是立刻把讨论对象换成具体的任务描述和评估指标。如果A组说自己的世界模型“模拟效果好”B组说自己的物理AI“预测准确”那这场讨论永远不会有结果因为两个词完全不在同一个评估维度上。这时候要做的是直接追问“你的预测任务是什么输入输出格式是什么在哪个测试集上评估误差指标是多少”我参与过的比较顺利的项目评审都有一个共同特征PPT里的架构图全是模块框和数据流而不是大段概念定义。负责人在开场花30秒说明每个框的输入输出接口剩下的时间全部用于讨论数据量、网络结构、收敛曲线、消融实验。名词只出现在页脚说明“本模块在本文档里称为X”。4.3 内部文档先定义再使用写内部设计文档时我之前直接用大标题写“世界模型模块设计”组员读文档的过程中会默认代入自己的理解结果文档里的技术方案和阅读者脑内的期望不匹配返工率很高。现在我会在任何涉及歧义术语的技术文档开头强制增加一个简短的定义区三到五句话说明本项目中该术语的含义。这样有三个好处一是写作者被迫思考自己到底在说什么二是阅读者不会带着错误预期看文档三是后续项目成员交接时有明确的约定可查。下一条建议我特别推荐给技术负责人定义区不要用抽象语言写尽量与具体模块绑定。例如“本文档所称的世界模型指输入当前观测图像和历史动作序列、输出未来N步潜状态序列的Transformer网络”这种写法任何人都不会产生歧义。4.4 对外叙事与内部技术体系解耦品牌传播需要热词产品叙事需要卖点这是市场逻辑。但技术团队内部的一切文档、评审、实验记录不要为了配合市场而强行替换术语。我认为比较好的做法是“内部以能力命名对外以叙事命名”两者之间维护一张映射表。比如内部叫“预测模块”对外叫“物理AI引擎”内部叫“动作生成器”对外叫“具身决策大脑”。翻译工作应该由产品经理完成而不是让研发改自己的文档。5. 哪些名字大概率会留下来我的几点判断既然聊到术语收敛那不妨再往前看一步未来两三年哪个名字会在这场混战中胜出我自己没有水晶球但基于历史规律和行业动态有一些倾向性判断可以分享。5.1 “世界模型”这个经典词最可能沉淀“世界模型”这个词最大的优势在于它有深厚的历史根基且在学术界已经积累了大量引用。从一个通用的“环境内部动态表征”概念出发它天然能兼容RL范式、生成式范式和仿真范式。即便目前各家做的形态很不一致大家也都在用它作为公约数沟通。历史上很多术语的收敛路径都是相似的先是各说各话然后某一两个影响力大的工作把大家拉到一个标题下之后逐步形成共识。世界模型目前最有机会走通这条路。物理AI则更可能作为产业和商业叙事的固定表达被沉淀下来它的价值不在于精确的学术定义而在于对外部世界解释“AI进入物理世界”这个新的叙事锚点。空间智能大概率会收窄为一个子方向专名专指三维感知、几何理解、场景表征这一类任务。它会长期存在但可能不再作为一个大一统的平台概念使用。5.2 术语收敛的触发条件是什么结合历史经验我认为术语收敛通常会发生在三个条件成熟时。第一某类固定的Benchmark或者比赛被行业广泛接受参与方被迫使用同一套评估语言术语就会被Benchmark定义统一。第二顶会连续几年出现专门的方向讨论论文标题里的关键词分布会自然引导社区收敛。第三当某一两个头部团队的巨大成功案例被反复引用时他们偏好的命名会通过跟随效应快速扩散。眼下这三个条件都处于萌芽阶段所以我的判断是术语混战至少还要持续两三年但这个时期恰恰是技术迭代最快的窗口。名字不重要的时候往往就是范式最稳定的时候名字吵得不可开交的时候说明大家还在探索真正有效的路径。5.3 如果只记住一件事能力层、命名层、叙事层要分开看最后说一个核心方法论。面对任何热点术语我建议把三层拆开看能力层是模型真正具备的技术功能命名层是我们给某个模块起的代号叙事层是对外讲述这个故事的话术。混乱的根源就是这三层没有对上。深入讨论技术时反复回到能力层跨团队对齐时互相交换命名层映射表对外沟通时再用叙事层包装。用这个框架去看物理AI、世界模型、空间智能的争论很多烦恼都会消散。6. 写在最后我自己的一点体会这些年见过了太多术语起高楼、术语楼塌了的案例。我的切身体会是热词能吸引注意力但解决不了技术问题一个团队真正能依靠的仍然是把物理规律建模清楚、把预测做准、把决策闭环跑通的能力。物理AI也好世界模型也好空间智能也好名字只是我们在这个充满不确定性的技术窗口期给未来画像打下的草稿。我自己踩过几次坑之后最大的收获是养成了一个习惯每次听到一个新热词先不急着去找定义而是去找这个热词背后锚定的那个具体问题和被验证过的技术组件。很多时候名字之争在会议室里打了半天最后发现大家想要的下一帧预测、下一状态估计、下一个决策指令本质上指向的是同一个模块。争论会继续Demo也在继续迭代这种并行本身就是技术加速的常态。如果你现在也被这些名字搅得有些混乱我建议你放下工具去翻一下自己项目里最核心的那个模块到底在解决什么问题用自己的话说清楚它是什么、输入什么、输出什么。想清楚这三件事比记住任何热词都管用。