企业官网建设流程全解析

最近具身智能的讨论群里，刷屏最狠的不是谁的灵巧手又抓起了鸡蛋，而是Figure放出来的那个56%。乍一看这数字平平无奇，但凡是真正做过机器人落地、而不是只看demo视频的人，心里都会咯噔一下：这哪里是秀成绩，分明是把整个行业的底裤掀了。

先说我的理解。Figure这次对外强调的，不是在实验室里挑出来的高光片段，而是在真实家庭环境中、长时程任务上的端到端成功率，按圈内流传的测试口径，大约就是56%。这个数字放在过去两年的具身智能叙事里，实在不算好看——毕竟大家习惯了“一条视频完成八步操作”的剪辑魔法。可恰恰是这个不够漂亮的数字，第一次让“泛化验证”从论文里的一个章节，变成了行业必须正面回答的大考。

这篇文章想聊的，就是这场大考本身：56%到底在测什么、泛化验证拆开有哪些维度、我们自己怎么搭一套可复现的验证体系，以及跑测试时最容易踩的那些坑。无论你是做具身智能算法的工程师、带团队的负责人，还是正在入门这个方向的学生，这篇内容都值得你从头看到尾。

1. 56%这个数字，到底在考什么

1.1 从demo到benchmark：为什么一个数字能刷屏

过去两年具身智能领域最让人头疼的，不是模型能力不够，而是行业缺乏统一的“度量衡”。你今天放一个机器人叠衣服的视频，明天他放一个机器人整理桌面的demo，看起来很热闹，可这些结果是在什么环境里跑的、测试了多少次、有多少次失败被剪掉了，没人说得清楚。

Figure这次把56%抛出来，等于是在逼行业回答一个问题：你的模型，到底敢不敢在没见过的环境里、用没见过的物体、执行一连串长时程任务，然后公开统计所有尝试的成功率？

这个意义远大于数字本身。它意味着具身智能的比拼正在从“demo经济”切换到“验证经济”。一个被反复剪辑过的两分钟视频，说服力开始低于一份包含失败案例、运行次数和统计口径的测试报告。56%这个数字之所以刷屏，恰恰因为它不够完美，才显得可信。如果谁宣称自己真实场景成功率95%，我反而会怀疑他是不是在特定场景里过拟合了。

说到底，这就是一次行业校准。大家终于有了一个可以拿出来对标的“标尺”：你跑的测试难度和Figure差多少？你的评测方式是更严格还是更宽松？你的模型在这个口径下能拿到多少分？

1.2 泛化验证和传统测试的核心区别

很多人把泛化验证理解成“在测试集上跑一跑”，这其实是个误会。传统深度学习里，我们做ImageNet分类、COCO检测，训练集和测试集虽然图像不同，但整体分布是一致的：都是互联网图片、相似的拍摄风格、相似的物体类别。这种测试叫分布内测试，衡量的是模型“记没记住规律”。

而具身智能面对的是一个开放物理世界。你训练时用的是这张桌子、这盏灯、这个杯子、这只机械臂，测试时却可能遇到完全不同的户型、光照、物体材质、甚至人的动作习惯。这要求模型具备的是“分布外测试”能力，也就是在训练语义空间之外，依然能做出合理决策。

我常用一个类比：传统测试像驾校考试，场地固定、路线固定、考官指令固定，你练熟了就能过；泛化验证像真正的上路驾驶，你永远不知道下一个路口会窜出什么，也不知道今天会不会下雨、前车会不会急刹。驾校满分的人，上路未必开得好；实验室成功率100%的机器人，进了陌生厨房也可能手足无措。

泛化验证要考的，从来不是“背题能力”，而是“迁移能力”。

1.3 为什么偏偏是“长时程任务”

还有一个细节值得注意：Figure那个56%，不是指单个动作的成功率。如果只是“抓取一个没见过的小球”，现在很多模型都能做到80%、90%以上。但真实任务从来不是单步操作，而是“打开冰箱、取出饮料、关上冰箱门、把饮料放到桌上”这样的多步序列。

这里有个简单的数学问题：如果每一个步骤的成功率是90%，一个5步任务的端到端成功率理论上只有0.9的5次方，约59%。每一步都在累积误差，而且一旦某一步失败，后续动作会全部脱节。更麻烦的是，很多任务在失败后无法自动恢复，比如饮料瓶倒了，下一个“拿起来”的动作就完全失去意义。

所以长时程任务的难点不在单点，而在整条链路的鲁棒性。一个能稳定完成10步任务的系统，哪怕每步成功率只有95%，实际任务成功率也只有约60%左右。Figure的56%，恰好落在这样一个“多步累积又带点失败恢复”的区间，说明它不是在刻意挑简单任务刷分，而是真的把难啃的骨头摆了出来。

单步能力决定底线，长时程成功率决定上限。这也是为什么我把这场验证称为“大考”——它考的是一整套系统，而不只是某个模型组件。

2. 泛化验证考的是什么：四个维度拆解

2.1 环境泛化：光照、布局、材质全变了

第一个维度是环境。机器人训练时看到的是一个固定房间：白色的墙、固定的窗帘位置、某个角度的灯光。可真实世界里，同样的“把杯子放到水槽里”这个指令，可能在明亮的开放式厨房、昏暗的公寓、布满反光台面的咖啡厅里执行。这些变化会直接影响视觉感知，比如阴影让目标物边缘变模糊，高反光表面让深度相机产生空洞，不同色温的光照会让颜色判断出错。

我见过不少仿真环境里表现很好的模型，迁移到真实场景后成功率直接腰斩。问题往往不是策略本身，而是感知层已经被训练环境“驯化”了。解决思路之一是域随机化：在训练时故意随机化光照强度、色温、相机姿态、地板纹理、随机物体位置，让模型没法依赖某个特定的视觉线索。这么做看起来是“给训练加噪声”，实际上是在逼模型学更本质的特征，比如物品的轮廓、相对位置关系，而不是某个固定像素模式。

环境泛化还包含“布局泛化”。训练时水槽总在右手边，测试时水槽换到左手边，模型是否还能理解“把水杯放到水槽”的空间语义？这是很多导航+操作任务过不去的坎。

2.2 物体泛化：没见过的东西怎么抓

第二个维度是物体。具身智能面试的时候，我经常问候选人一个问题：“你的抓取模型，是把见过的物体抓起来，还是把没见过的物体也抓起来？”这俩难度天差地别。

物体泛化可以分成三个层次。第一层是类别内泛化，训练时见过红色马克杯，测试换一个蓝色马克杯，这个大多数系统能做到。第二层是跨类别泛化，训练时见过杯子、瓶子，测试时出现一个没见过的碗，模型能不能识别出“这也是一个可抓握的容器”？第三层是全新类别，比如训练时从没见过雨伞，测试时把它随机放在桌上，模型还能不能规划出合理的抓取点？

难点在于物体的形状、材质、刚度差异巨大。软体物体（毛巾、塑料袋）会形变，透明物体深度相机容易“穿透”，反光物体视觉特征不稳定，细小物体（螺丝钉、耳机）又需要更精准的末端控制。一个在标准物体集上训练出来的策略，遇到这些情况很容易崩溃。

要做物体泛化验证，测试集里必须包含大量训练阶段完全没有出现过的物体。更严格的做法是，把所有测试物体单独隔离，由一个不参与训练数据准备的同事去采购或3D打印，从源头上避免数据泄漏。

2.3 任务泛化：指令和动作组合的无限可能

第三个维度是任务。自然语言指令是开放的，人类可以说“把红色杯子放到水槽旁边”，也可以说“把桌上那个脏碗拿过来”，还可以说“帮我把茶几擦一下，注意别碰倒上面的遥控器”。这些任务不可能全部出现在训练集里，所以模型必须学会组合式理解：把“红色”、“杯子”、“水槽旁边”这些语义单元拆开，再映射到对应的物体识别、空间定位和动作生成上去。

任务泛化的难点在于“指令的组合爆炸”。单纯增加训练任务数量是永远追不上的，真正有效的是让模型理解任务的内在结构。现在很多VLA（Vision-Language-Action）模型走的就是这个路线：先用大规模互联网图文数据做预训练，让模型建立语言和视觉的通用对应关系，再在机器人数据上做微调。这样即使遇到没见过的指令组合，模型也能利用语言先验“猜”出该怎么做。

不过在验证时要注意，任务泛化和物体泛化经常纠缠在一起。为了单独测任务泛化，你得固定使用训练中见过的物体，只改变指令组合；反过来测物体泛化时，又得固定指令。很多团队拿到的56%这种成绩，恰恰是在两者同时变化的情况下测出来的，难度翻倍。

2.4 交互者泛化：每个人都不一样

第四个维度最容易被忽略，也最影响真实落地：交互者泛化。机器人要服务的不只是工程师自己，而是形形色色的人。不同的人有不同的身高、肤色、手部大小、动作速度，甚至说话的语调和口音都不一样。

比如一个倒水的任务，操作者可能是左手递杯子、右手递水壶，也可能是把杯子放得很靠边。人类手部对物体的遮挡方式、运动轨迹，都会影响视觉模型对物体状态的判断。更麻烦的是，机器人需要理解人的意图，而意图往往藏在非标准动作里：一个人用手指了一下地上的盒子，再指了一下桌面，这到底是想让机器人捡盒子，还是想表达“那个盒子别动”？

在泛化验证体系里，如果所有测试都由同一个研究员完成，那测出来的成绩基本是“自我安慰”。我建议至少安排3到5名不同性别、不同身高、不同操作习惯的人参与测试，并且要求他们不要刻意“迁就”机器人，按自己平时习惯的方式布置场景和下达指令。这样才能暴露模型在交互层面的短板。

3. 如何搭建一套泛化验证体系：从训练场到指标

3.1 agent+具身训练场：仿真环境的高保真设计

聊完考什么，再聊怎么考。现在行业里比较流行的说法是“agent+具身训练场”，意思是要把具身智能agent放进一个高保真的训练场里，先在环境里跑出大量经验，再迁移到真实世界。这个训练场可以是物理仿真，也可以是真实场地+自动重置系统的结合。

仿真环境的选择直接影响验证结果。现在社区里常用的是Isaac Sim、MuJoCo、SAPIEN这些。MuJoCo胜在速度快、适合强化学习早期训练；SAPIEN对物体操作和关节物体支持比较好；Isaac Sim的优势是渲染保真度高，加上Omniverse的物理引擎，更接近真实视觉信号。最近Genesis这类新仿真器也很火，特点是训练速度极快，适合大幅缩短迭代周期。

不管选哪个仿真器，都要做域随机化，否则仿真成绩没有参考价值。下面是我自己常用的随机化参数表：

关键是不要只跑一套固定环境。我见过不少团队在仿真里成绩看似很高，结果是因为所有测试都在同一个房间布局下完成，模型悄悄记住了物体出现的大概位置。要避免这一点，训练和测试环境的布局必须完全独立，最好由不同的人配置。

3.2 测试集怎么划：分布内、分布外、全新分布

搭建验证体系的核心，是设计测试集划分方案。我建议把测试分成三档，对应不同能力等级：

很多团队的评测只做了ID，所以看起来“效果很好”。实际上真正有价值的数字是后两档。Figure的56%如果按这个分层看，大概率是OOD和Novel的混合成绩，含金量远高于一个纯ID的95%。

在划分时要注意隔离。负责搭建测试场景的人，不能接触训练数据，防止无意识地把测试场景调得和训练相似。测试物体和训练物体要严格分开，不能有重合。我甚至建议给每个测试物体单独编号、拍照存档，方便后续复现失败案例。

3.3 指标设计与统计口径

评估指标这关，是最容易糊弄也最需要较真的地方。只报一个“平均成功率”远远不够。建议至少记录以下指标：

• 任务成功率：完整完成所有步骤的比例
• 步骤完成率：多步任务中完成步骤数的比例，用来定位瓶颈
• 平均干预次数：人类平均需要介入多少次才能保证任务完成
• 平均完成时间：和人类操作时间对比，衡量效率
• 严重失误次数：碰撞、掉落、损坏物体等需要特别标记

统计口径上，我强烈建议用“重复N次求通过率”而不是“跑一次看结果”。一个小样本下的一次成功可能是运气，但20次里成功12次就更有说服力。这里可以用二项分布的Wilson区间来估算置信区间。比如20次任务通过12次，点估计成功率60%，但95%置信区间大约在38.7%到78.0%之间，说明样本量并不足以支撑精确对比。这也是为什么公开结果时，必须同时给出尝试次数和统计区间，否则数字没有可比性。

所有测试应当设置统一的初始状态。比如桌面摆放的范围、物体姿态、机器人起始位置，都要有明确协议。如果每次初始状态都不一样，结果根本无法复现。

3.4 从56%到可复现：记录和回放机制

泛化验证体系里最容易被忽略的，是完整的记录和回放机制。很多团队测试完只留下一张结果表，失败时完全不知道模型在哪里开始崩的。我建议每个测试用例都记录：

• 第一视角视频和第三视角视频
• 深度图、点云、相机标定参数
• 每一步的机器人关节角度、末端位姿
• 模型输出的中间决策记录，比如语言理解结果、目标检测框、抓取点
• 人类干预的时间点和原因

有了这些数据，你才能做失败归因。失败可能发生在感知层、规划层、控制层，也可能是执行器本身打滑。没有回放数据，你连“模型看到的是什么”都不知道，只能靠猜。我在调试时最常用的方法，是把失败视频逐帧倒退，找到第一个偏离正常轨迹的帧，然后去查那一帧的传感器输入和模型输出，基本能定位问题。

这套机制本身也是团队的资产。一场大版本测试下来，哪怕成功率只有50%，只要回放数据完整，下一轮迭代就有明确方向。怕的是成功率说不清、失败原因更说不清，那才是真正的大考失败。

4. 实操中的坑与排查技巧实录

4.1 机器人“作弊”了：仿真与现实的捷径

做泛化测试多了，你会发现机器人经常“作弊”。最典型的是在仿真里通过碰撞来完成任务。因为仿真器对碰撞力度的惩罚不严格，机械臂可以“穿过”障碍物边缘，把物体蹭到目标位置。真实世界可没有这种好事，这种策略一旦部署到真机，轻则失败，重则损坏设备。

排查方法很简单：把所有测试轨迹逐条检查，看是否有机械臂穿过物体或环境边界的帧。更严格的做法是，在仿真里显式开启碰撞检测日志，任何碰撞都会记录成一个事件，而不是被当作正常动作放过去。我见过一个团队，仿真成功率从70%虚标到95%，查完才发现一半的成功案例都带着数不清的碰撞。

解决办法有两层。底层是提升物理引擎的真实感，把接触刚度和摩擦模型调到贴近真实；上层是在评测脚本里把碰撞事件计入“严重失误”，一旦发生就直接判失败。如果仿真里考出了带水分的成绩，那泛化验证本身就没有意义。

4.2 泛化失败的第一原因：数据偏差

很多团队做完第一轮泛化测试，发现成功率远低于预期，第一反应是模型不行。我看了太多案例，最后发现真正的问题出在数据采集上：训练数据里的场景太单一了。比如所有数据都在同一个房间、同一张桌子、同一个光照条件下采集，模型根本没有机会见过多样性，泛化自然无从谈起。

数据偏差的另一种表现是标注不一致。不同标注员对“抓取点”的定义不同，有人标物体中心，有人标物体重心，有人沿边缘标。模型学到的特征因此变得杂乱。要解决这个问题，得建立一份详细的标注规范，并且在采集数据时主动做场景变换：换桌子、换光照、换相机高度、换背景，每隔一段时间就大改一次。

另一个隐蔽的坑是数据泄漏。如果你的训练数据和测试数据来自同一段连续视频切片，或者同一个物体的不同角度照片，那测试成绩就不算数。做泛化验证前，务必先做一次数据查重，把训练和测试之间任何可能重叠的物体、场景、时间片段都剔除掉。

4.3 指标“变好”其实是错觉

还有一类坑是统计层面的“自我欺骗”。最常见的是随机种子不同导致的评估结果波动。强化学习模型本身带随机性，如果每次测试初始化时随机种子不同，同一个模型跑两次，成功率可能差10个百分点以上。正确的做法是固定测试时的随机种子，或者跑足够多次取平均，不能因为某一次跑得好就向老板汇报“性能提升”。

更隐蔽的问题是“平均掩盖长尾”。假设模型在80%的任务上成功率是90%，在20%的困难任务上成功率是10%，平均下来是74%。这个平均数字看上去不错，但实际上困难任务的能力离落地还很远。我建议把测试结果按任务难度分桶统计，至少分成简单、中等、困难三档，分别看成功率分布，而不是只报一个合计数。

最后一种错觉来自“复位条件”。有些团队在做物理测试时，每次失败后都由人类悄悄把物体摆回到初始状态，再让机器人重试。这等于给了模型额外的“重开”机会，成功率自然虚高。真实场景里，失败之后物体已经乱了，下一步行动必须应对乱局。如果能做到失败后不重置、继续往下执行，那才是真的泛化。

4.4 我的避坑清单：开跑前至少要做到的事

兜了这么多，我把自己这几年跑泛化测试积累的检查清单放在这里，照着做至少能少踩一半坑：

• 统一评估脚本，所有模型用同一套代码跑，不搞手动换参
• 固定随机种子和初始状态，确保结果可复现
• 每个任务最少重复20次，公开结果时附上置信区间
• 测试场景和训练场景由不同的人搭建，做物理隔离
• 测试物体和训练物体严格分离，不可能出现同一个物体
• 每次测试完整录制多视角视频，保留传感器日志和推理日志
• 安排多名操作员参与测试，禁止所有人刻意迁就机器人
• 失败后不偷偷复位，让任务继续或者如实记录为失败
• 碰撞和严重失误单独统计，不混进成功率里
• 测试结束后按任务难度分桶汇总，而不是只报一个平均分

这些条目看着简单，但每一条背后都是我踩过的坑。只要你按着这个清单走一轮，基本能拿到一份可以对外讲的泛化报告。

5. 这场大考之后的行业影响与个人路线

5.1 从demo经济到验证经济：行业要变天了

56%这个数字刷屏之后，我能明显感觉到行业氛围在变。以前大家拿着demo视频去找客户、找融资，现在越来越多的人开始追问：“你的泛化测试集是什么？一个任务跑多少次？失败模式是什么？”这套提问方式，本质上是从“你看起来能做什么”，切换到“你到底可靠地能做什么”。

这个转变会带来一系列连锁反应。首先是具身智能操作系统和评测工具链会越来越重要。之前看过的具身智能操作系统深度研究报告里，核心观点之一就是“操作系统级的能力，取决于能不能支撑大规模、可复现的验证闭环”。拿一套统一的接口去控制机械臂、采数据、跑评测、记录指标，这种基建属性的产品，会在未来两三年成为刚需。

其次是团队的组织方式也会变。以前算法团队写完模型，拍个视频就完事了；以后要求每个团队都有一个“评测工程师”角色，专门负责搭建测试场景、维护测试集、统计指标、分析失败原因。这不是可有可无的岗位，而是决定产品能不能落地的关键一环。

5.2 具身智能学习路线：从泛化验证反推该学什么

很多打算入行具身智能的朋友问我学习路线，我的建议恰恰是从这场“泛化验证大考”反推。既然行业考的是跨场景迁移和多步长时程任务能力，那你学习时就得打牢这几个基础。

入门阶段，先把《概率机器人学》吃透，卡尔曼滤波、粒子滤波、状态估计这些概念躲不开；同时把深度学习基础打牢，尤其是视觉Transformer、目标检测、分割这些感知方向；然后再接触强化学习，理解PPO、SAC这类基础算法，以及奖励设计的基本逻辑。这个阶段大概需要半年到一年，目标是能用仿真环境跑通一个简单的抓取任务。

进阶阶段，重点学习Sim2Real迁移、模仿学习（尤其是行为克隆和扩散策略）、以及VLA模型的训练和微调方法。这时候要动手搭建自己的小型实验环境，比如用一个桌面机械臂加上两个摄像头，做一个室内物品整理任务。关键不是模型多先进，而是你能不能建立一套评测流程：今天改一个权重，明天能不能立刻跑20次实验，量化出涨点没有。

社区也很重要，我经常在具身智能交流群里看到新人问“该学什么框架”“仿真器和真机对不上怎么办”，这种问题光看书解决不了，需要有人带。像七月具身（July）这类行业社区经常组织线上下交流，里面很多内容就是围绕泛化验证、Sim2Real、真机部署展开的，可以帮你少走不少弯路。

5.3 给面试准备提个醒：泛化验证是高频考点

顺带说一句，具身智能面试现在越来越爱问泛化验证相关的问题，这跟这次56%新标尺的讨论有直接关系。面试官已经不再满足于你背得出VLA模型结构，他们更想确认你有没有真正动手测过机器人。

常被问到的问题大概有这么几类：第一，如何设计一套泛化测试集？你可能会答“分ID和OOD”，但这还不够，要能讲清楚怎么隔离训练数据和测试数据、怎么安排测试人员、怎么统计置信区间。第二，Sim2Real gap具体体现在哪里，怎么解决？只答“域随机化”是及格线，能讲清楚渲染差异、物理差异、系统延迟差异，才是加分项。第三，成功率指标为什么往往虚高？这时候如果你能提到“长时程累积误差”“平均掩盖长尾”“复位条件的影响”，面试官基本能判断你是真跑过实验而不是只看论文。

所以我的建议是，不管你是求职还是招人，都把“能不能讲清楚56%这类数字是怎么测出来的”当作一道门槛题。能讲清楚的人，大概率有独立搭建评测体系的经验；讲不清楚的人，哪怕模型做得再花哨，落地能力也得打个问号。

我自己回头看，最早入行时也迷信demo，觉得只要视频拍得好看、效果惊艳，就说明技术领先。后来真正把测试跑开，才发现那些动辄95%以上的“成功率”大多经不起推敲。反而是56%这种数字，逼着我把每一个失败案例翻出来看，一点一点把感知、规划、控制全链路调顺。这个过程很磨人，但它才是具身智能往前走的真正路径。泛化验证不是宣传话术，它是一面镜子，照见的是整个系统离真实世界还有多远。