企业官网建设流程全解析

最近这个行业里有一个特别明显的动向：做机器人的公司和做大模型的公司，开始朝对方的方向走了。四足机器人厂商的发布会，PPT首页不再只强调负载和续航，开始大讲“具身智能”“多模态理解”；而大模型团队的技术分享里，也越来越多地出现机械臂、关节电机、仿真环境这些词。两边像是约好了一样，从各自熟悉的地盘出发，在物理世界和数字世界的交界处相遇。

这篇文章想把这些变化拆开讲清楚：双方各自的优势在哪里、短板在哪里，真正融合起来的技术栈长什么样，落地过程中有哪些我反复踩过的坑，以及最后我自己对这个方向的判断。适合正在做机器人或AI应用的人看，也适合准备往具身智能方向转型、投资的朋友参考。某种意义上，这是一次“硬件派”和“模型派”之间漫长的双向奔赴。

1. 两条技术路线，突然开始朝对方走

1.1 机器人公司开口闭口都是“模型”

先看机器人这一侧的变化。过去做四足机器人的团队，核心技术栈是运动控制、执行器、轻量化结构，发布会参数比的是关节扭矩、行走速度和单次充电续航。但对终端客户来说，这些指标解决不了一个最本质的问题：一台机器人买回去，到底能替我干什么。客户开始问“它能听懂我说话吗”“能不能自己规划路线”“遇到没见过的门能不能自己想办法”——这些问题靠传统脚本一个都答不上来。

于是硬件厂商开始给机器人的“大脑”做升级。比较务实的做法，是接一个云端多模态大模型做任务理解，本地保留运动控制；激进一点的团队，已经开始训练自己的视觉-语言-动作模型，把感知和动作直接连起来。本质上，他们在补齐自己最缺的那块拼图：通用性。以前一个任务写一套代码，现在只需要一句自然语言指令，剩下的交给模型去拆解和规划。

1.2 大模型团队开始研究机械臂和关节电机

再看模型这一侧。大模型的智能在文字、图片、视频这些数字载体上已经有目共睹，但数字世界有一个天然天花板：模型没有办法验证自己对物理世界的理解。它知道“杯子”是什么，却不知道拿起来的时候要用多大的力；它会规划“从A走到B”，却不知道走向B的路上那堵墙是不能穿过的。所以一批模型团队开始往具身智能延伸，把机器人的真机采集、仿真环境、遥操作数据引入训练闭环。

一个很直观的变化是，不少做预训练模型的团队，最新的技术报告里开始讨论“动作token”“末端执行器”“仿真到现实的迁移”。这些词汇放在三年前，绝对不可能出现在大模型团队的文档里。他们的目标也不再只是让模型“更会对话”，而是让模型真正具备对三维空间、物理交互、动态环境的理解能力。

1.3 “相向而行”不是巧合，而是路径依赖的必然

这种靠拢不是偶然。我自己的判断是至少有三个推力同时在起作用。第一，机器人硬件越来越便宜、可靠，本体的稀缺性在下降，运动控制已经变成“基本功”，不再构成竞争壁垒。第二，大模型的能力溢出到了可以理解连续任务的程度，从“单轮问答”进化到“拆解一个多步骤任务并逐步执行”不是质变，而是量变积累后的自然结果。第三，需求端在倒逼——客户不满足于一个能表演的机器人，他们要的是能替自己干活的机器人。三条线同时推进，两边自然就往中间走了。

2. 各自的底牌与死角：为什么要借对方的力

2.1 硬件派手里的王牌

硬件派手里的牌其实很硬。运动控制、机械结构、本体设计、供应链管理、现场工程部署，这些能力是模型派短期内补不上的。一台能在碎石路上稳定行走的四足机器人，背后是电机选型、减速器匹配、力矩控制、振动抑制、电池热管理等一系列实打实的工程问题。没有这些，模型再聪明也没处落脚。

但硬件派的死角同样明显：泛化能力太弱。传统机器人执行任务依赖预定义脚本，碰到场景里的任何意外变化——门牌位置变了、光照条件变了、物体的形状没见过的——就可能卡住。打个不恰当的比方，硬件派像一个体能极好但只会照剧本演戏的演员，剧本一换，立刻手足无措。

2.2 模型派手里的王牌

模型派手里的牌是另一个维度的。自然语言理解、多模态感知、开放性强、知识面宽、迭代速度快。用户说“帮我去客厅把茶几上的白色杯子拿过来”，模型能准确拆出目标物体、位置、动作类型，甚至能结合上下文判断“茶几”大概是什么样的家具。这种语义能力，传统规则系统完全做不到。

但模型派的死角更致命：没有物理载体，没有动作闭环。模型输出一段文字是一回事，这段文字能不能变成真实的位移和抓取力是另一回事。对模型来说，“抓取”这个词只是一个token，它不知道指尖接触物体表面时的触感反馈，不知道玻璃杯和塑料杯需要不同的夹持力。这种身体性的知识，靠互联网文本预训练是学不到的。

2.3 一加一大于二的前提是分工明确

把两边放在一起看，互补关系非常清晰：

拿“让机器人去会议室拿杯子”这个任务举例。硬件派自己做，能做到导航到会议室，但不知道“杯子”在当前场景里对应哪个视觉特征，更没法理解“拿”这个动作在不同杯型上的差异。模型派自己做，能完美回答“杯子是什么、会议室在哪里”，但没有手和轮子，一切停留在文本层面。只有两者组合，才能完成一个开放式任务——这也解释了为什么“相向而行”不是某个公司的战略选择，而是整个行业走向落地的必然路径。

3. 融合系统的技术栈：从自然语言到关节电流

3.1 大脑、小脑、脊梁：三层架构

真正能把两边揉在一起的系统，通常不是“一个端到端模型解决所有事”，而是分三层的架构。

最上层是大脑，部署云端或边缘端的大语言/多模态模型，负责用户意图理解、任务分解、异常处理和自然语言对话。中间层是决策规划层，通常由任务状态机、动作规划器、行为树构成，负责把大脑给出的高层任务转成可执行的动作序列。最底层是小脑，也就是机器人本地的运动控制与感知模块，负责关节电流、轨迹跟踪、里程计、避障这些实时性要求极高的事情。

这个分层的关键理由只有一个：实时性。大模型推理一次动辄几百毫秒甚至几秒，但机器人走路、避障、保持平衡的控制频率是几十到几百赫兹。让高层模型直接参与每一个控制周期，从响应时间上就不可行。所以实际系统里，大脑是“低频决策者”，小脑是“高频执行者”，决策规划层在中间做翻译和缓冲。

3.2 视觉-语言-动作模型和它的问题

现在业界讨论比较多的一条路线，是视觉-语言-动作一体化模型，大家通常简称VLA。核心思路是把摄像头画面和语言指令作为输入，直接输出机器人的动作信息，跳过传统意义上“感知-规划-控制”的显式拆分。

这个方向听起来很诱人，但我实际接触下来发现，它目前最大的问题是数据量和实时性的双重约束。VLA训练需要海量的真机交互数据，而机器人数据采集成本远比文本和图像高得多；同时端到端模型推理延迟通常很难压到实时控制可接受的范围。所以现实中的多数落地方案，其实是“预训练多模态模型 + 规则规划器”的组合，而不是纯粹的端到端。VLA更适合先在小范围任务集上跑通验证，再逐步扩大规模。

3.3 数据闭环：遥操作、仿真、再训练

不管选哪条路线，绕不开的一个环节是数据闭环。要让模型理解“物理世界里的杯子”和“语言世界里的杯子”是同一种东西，必须靠交互数据来拉通。

具体流程一般是这样：工程师在真机上做遥操作，同时记录视频流、关节角度、力矩信息、力传感器读数这类多模态时序数据；然后按时间戳对齐并清洗，构建成“指令-状态-动作”配对的数据集；再拿去训练模型；训练完的模型先放进仿真环境做大规模验证，挑出失败案例，再回补到数据集里。这个循环跑得越快，模型对物理世界的理解就越准。

一个容易被低估的事实是：语言模型在互联网文本里学到了“杯子”的概念，但机器人在现实里看到的是杯子的点云、材质、光照反射和位置关系。两者的语义鸿沟，只有靠真实交互数据这一种方式填平。这也是为什么那些早期就开始积累遥操作数据的团队，后面会越来越有优势。

3.4 云端与边缘端的分工

部署层面的一个关键设计，是云端和边缘端的分工。大多数成熟项目的做法是：云端大模型负责复杂推理和全局规划，边缘端小模型负责低延迟的感知和执行，中间用结构化接口通信。

举个例子，用户说“帮我去客厅拿茶几上的水杯”。云端大模型把它拆解成任务清单，返回一个结构化任务图；边缘端的状态机按任务图一步步执行，遇到走廊被椅子挡住了，再回调云端请求重新规划路径。这样既享受了大模型的理解能力，又不会让每次避障都去等云端响应。通信格式一般用JSON或更紧凑的二进制协议，重点是字段要固定、可校验，不能让模型自由发挥。

4. 真实部署中反复踩到的四个坑

4.1 网络抖动会把机器人卡在电梯门口

第一个坑是网络依赖带来的任务中断。我们之前调试一台园区巡检样机，任务规划放在云端，机器人本身只做执行。结果连续几次测试都卡在同一个环节：机器人到了电梯门口，需要呼叫电梯，可它在电梯口傻站着不动，直到任务超时。

排查链路是这样的：先看机器人本地日志，发现“大脑”没有下发下一个动作指令；再看云端日志，请求发出去了，但迟迟没有返回；反复测试后确认是网络环境抖动导致推理请求超时，而本地又没有重试机制，于是机器人就永远陷在“等待指令”的状态里。最后修复办法有三件事：把“在电梯口等待电梯并响应”这类关键行为改成本地原子动作，云端只负责决定“要不要坐电梯”；给云端请求加超时重试和失败降级；第三，如果连续重试失败，机器人主动上报并原地待命，等待人工介入。修完之后连跑五十次，再没出现卡死。

4.2 端侧模型尺寸、算力和电池之间的拉锯

第二个坑是端侧算力和功耗的拉锯。我们在一台小型四足样机上试过塞一个7B参数的量化模型，后果很直接：电池续航掉了近三分之一，机身温度逼近报警阈值。这不是说模型上机器人这个思路不对，而是要在尺寸和功耗之间找平衡。

最后采用的方案是，端侧只放一个1B出头、经过INT8量化的轻量模型，负责目标检测和局部避障这类低延迟任务；复杂推理全部给云端。这样响应时间恢复了，续航也拉回到可接受范围。经验是：给机器人选型算力平台时，别只盯着TOPS指标，要把“功耗预算”和“散热条件”放进同一张评估表里，尤其是小型机器人，电池既要喂电机又要喂算力，矛盾非常现实。

4.3 大模型幻觉在物理世界的代价

第三个坑是大模型幻觉在物理世界的代价。大模型生成的内容在文本场景里出点错，最多是尴尬；在机器人场景里出错，可能是撞墙、夹手、损坏设备。

我们遇到过模型输出一条语义正确但物理上不可行的指令：让机械臂用超出关节限位的方式去抓一个低矮物体。机器人的执行器照做，结果关节直接触发了过载保护报警。事后分析，问题不出在运动控制层，而是出在模型输出没有经过物理校验。从那以后，所有模型输出都必须经过三道检查：动作白名单——只允许 navigate、grasp、release 这类预定义动作；参数校验——目标坐标必须在地图范围内，末端执行器位姿必须通过运动学逆解验证；执行前感知复检——比如按下电梯按钮前，先确认面前确实有电梯面板。三道检查全过，指令才会下达到运动控制层。

4.4 评测指标盯住了成功率就够了吗

第四个坑和评测方式有关。早期我们评估系统好坏，只盯一个指标：任务成功率。后来发现这个指标会骗人。

一个系统成功率很高，但每次任务耗时是正常值的两倍，或者隔三差五要人工介入一次，那它在实际场景里根本没法用。更值得关注的是失败模式——任务失败时机器人是安全停住，还是做出危险动作；以及长期运行的稳定性——连续干一百个任务，第80个开始是否出现漂移。所以现在我们看一个具身智能系统，至少同时关注四个维度：任务成功率、平均耗时、人工干预次数、安全事件数。任何单一指标都不要轻信。

5. 参与这类项目后，我总结的几条实操经验

5.1 先学会划分“哪些该交给大模型”

做这类项目最忌讳的事，是把所有任务一股脑丢给大模型。我给同事的建议永远是先画一张“任务归属表”，按实时性和风险等级决定每个模块的归属：

分清楚“哪些事非大模型不可，哪些事交给大模型反而是累赘”，项目至少能少踩一半的坑。

5.2 别急着自研VLA，先搭一条伪智能链路

如果你所在团队刚起步，我的建议是先别碰自研VLA。先用现成的开源多模态模型，搭一条“伪智能”链路验证需求：用户说自然语言，模型把这句话解析成结构化JSON指令，再由规则引擎映射到已有的导航和机械臂SDK执行。

举个例子，模型层返回的指令可以规范成这样：

{ "task_id": "fetch_cup_from_living_room", "steps": [ {"action": "navigate", "target": "living_room", "condition": "avoid_obstacles"}, {"action": "locate", "object": "cup", "visual_feature": "white_ceramic"}, {"action": "grasp", "method": "top_down_grip", "force_limit": "2N"}, {"action": "navigate", "target": "user_position", "final_drop": true} ], "fallback": "report_to_user_if_step_fails" }

这套链路一两周就能跑通Demo，它能非常直观地检验一件事：用户真正需要的是什么。模型跑不出来的bad case，恰恰是你下一步数据采集要优先补充的方向。等这条链路验证清楚了，再决定要不要投入资源自研更复杂的模型。

5.3 遥操作数据越早采集越划算

数据不是等训练模型时才需要的。我见过很多项目组，模型训练阶段才开始慌慌张张搭采集环境，结果发现一小时遥操作产生的有效数据，可能连几分钟都凑不满，进度一拖再拖。

正确的做法是项目启动第一天就搭好采集流程：全流程日志、多视角视频、关节角度、力矩读数都要同步记录；每天采集完立刻做bad case标注，别让数据堆成山后再处理。数据标注的颗粒度也很重要，除了“成功/失败”这种粗标签，最好记录具体的失败原因，比如“抓取滑落”“路径规划撞到障碍”“目标识别错误”。这些细标签，是后面训练模型时最值钱的信息。

5.4 给大模型输出套一道物理安全锁

最后一条实操经验，也是我认为最重要的一条：大模型的输出，永远不能直接进执行层。前面提到过三道检查，这里再展开说一下动作白名单怎么落地。

白名单不是一个模糊概念，而是要硬编码在控制层里的。无论模型输出什么，控制层只接受名单内的动作类型，并且每个动作都要通过参数校验和感知复检。碰撞检测和急停按钮的优先级永远高于AI指令——也就是说，即使大模型输出“继续前进”，但碰撞传感器触发了，机器人必须无条件停下。这个原则没有任何商量余地。安全不是AI能力的一部分，安全是独立于AI并行的一层物理兜底。

6. 交汇点之后：硬件走模型的路，模型走硬件的路

6.1 硬件公司的下一站：把传感器变成“身体感”

硬件公司往模型方向走，真正的增量不在“会说话”，而在“身体感”。传统机器人的传感器大多是离散的：摄像头管看、激光雷达管测距、IMU管姿态。但人要操作物体，靠的是多模态信息的融合——手里传回的力觉、指尖的触觉、关节角度变化带来的本体感觉。

我判断下一阶段硬件公司的竞争点，会在力控、触觉传感和全身运动协调这些方向。这些能力让机器人采集到的数据质量更高，让模型真正有机会学到“像人一样操作”的物理直觉。没有这些底层感知能力的升级，所谓具身智能就是空中楼阁。

6.2 模型团队的下一站：让模型懂物理常识

模型团队往硬件方向走，核心课题是让模型建立物理常识。互联网文本教不会模型“玻璃杯碰硬地面会碎”“湿地面摩擦力会突然变小”“推门要先感知门的旋转方向”，这些常识必须通过与物理环境的交互来学习。

目前比较可行的路径有两个：一是在高保真仿真环境里让模型大规模试错，通过强化学习隐式学会物理约束；二是从遥操作数据里提炼那些“默认不写进文档”的实操知识。哪个路径先跑通，哪个团队就能在下一轮竞争中拉开身位。

6.3 终局不一定是哪边赢，而是共同定义新物种

很多人喜欢问“最终是机器人公司吞掉模型能力，还是模型公司造出机器人”，我觉得这个问题本身可能问错了。更可能的终局是，两边在接口处握手：硬件公司继续做执行器和传感器，但会在本体里预埋推理芯片，并开放标准化控制接口；模型公司继续做预训练和强化学习，但会把输出格式标准化成下游运动控制可以直接消费的结构化指令。真正定义新产品形态的，不是某一边的独撑，而是两边在交界处碰撞出来的“翻译层”。

最后说点个人的感觉。我前年参与过一个四足机器人和大模型结合的验证Demo，项目里既有做关节运动控制的硬件工程师，也有整天调temperature的算法工程师。第一次联调，机器人完美理解了指令，却在场地里绕了三圈才找到目标——路径规划模块没有正确解析大模型输出的目标坐标。那个瞬间大家都笑了，也没人再争论谁的模块更重要。要让机器人在现实里干活，光有聪明的大脑不够，光有强壮的身体也不够，真正难的是把它们之间的翻译层做对。而这个翻译层，恰好不是硬件派单独能做的，也不是模型派单独能做的。这可能就是“相向而行”最实在的含义。