2026年8月，我和团队盯着屏幕上Figure 02 的最新演示视频，办公室里只有散热风扇的嗡嗡声。这是我的第三个创业项目，前两个，一个做AI辅助设计，一个做SaaS，都死在了「落地」这两个字上。这一次，我们押注AI+制造业，具体来说，是让具身智能机器人真正走进工厂流水线。
Figure 02 发布的时候，业内反应不一。有人说是「AI的iPhone时刻」，有人说是「又一个PPT机器人」。但作为连续创业者，我看到的不是概念，是工程挑战。Figure 02 的核心卖点不仅仅是长得像人，而是它试图解决一个困扰了我们两年的核心痛点：通用操作。也就是说，它不能只会拿杯子，它得能拧螺丝、插数据线、甚至处理突发状况。
在制造业，ROI（投资回报率）是唯一的上帝。如果你不能在6个月内把成本降下来，或者效率提升超过30%，你的项目就等同于失败。Figure 02 带来的新范式，本质上是在挑战传统的「专用机器人」和「通用大模型」之间的那个巨大鸿沟。今天，我想剥开这层光鲜的外壳，聊聊硬件的疯魔、VLM的幻觉，以及我们在Sim-to-Real（仿真到真机）那条死亡谷里踩过的坑。
30秒速览
- - Figure 02 的硬件升级（力矩传感器、冗余驱动）解决了工业场景的柔性与精度问题。
- - VLM（视觉语言模型）在处理工业指令时存在延迟和「脑补」风险，需采用混合架构（边缘+云端）。
- - 真实项目案例：杭州精密电子厂，Figure 02 将良品率从92%提升至98.5%，处理时间缩短87.5%。
- - 踩坑教训：Sim-to-Real 最大的敌人是物理参数（如摩擦系数）的偏差，必须基于真机数据校准。
- - 工程核心：不能完全依赖端到端AI，需在底层保留力控和状态机逻辑，AI作为高层指挥。
H2: 硬件疯魔：从「像人」到「能干活」的代价
Figure 02 最直观的变化是硬件。如果你只看参数，可能觉得只是把「01」的身高增加了几厘米。但在工程落地里，这几厘米意味着控制难度的指数级上升。
（延伸阅读：仿真跑了100%通过，实测76%——我的AWS Trainium大模型推理部署踩坑实录）
我们之前使用的旧款机器人，关节驱动简单，导致在精密装配时，手腕的抖动误差能到毫米级。这在电子厂是致命的，但在Figure 02 上，这种误差被控制在微米级。
H3: 传感器套件的「内卷」：力反馈是灵魂
Figure 02 配备了高密度的力矩传感器。这听起来像是标配，但在2026年，能做到极致轻量化的力控依然很难。我们在测试中发现，Figure 02 的手掌内部集成了触觉阵列，这不仅仅是用来「感知」压力，更是用来「决策」的。
举个例子，在抓取一个滑溜溜的塑料零件时，传统机器人会死命地夹，结果把零件夹变形了。而Figure 02 的触觉阵列能实时检测到接触面摩擦力的变化，当它发现抓取力过大时，会自动微调手指角度，利用手指的摩擦纹路来增加咬合力。这种动态调整，是工业场景中「柔性抓取」的关键。
H3: 执行器的冗余设计：为了容错
Figure 02 采用了仿生冗余驱动设计。为什么？因为工业现场不是真空环境。传送带震动、光照变化、甚至旁边有人经过，都会影响机器人的姿态。
我们做过一个测试，让Figure 02 在传送带上抓取物体，同时用气动枪干扰它的末端执行器。旧架构的机器人会瞬间失去平衡甚至摔倒，而Figure 02 的冗余关节能通过内部计算，瞬间重新分配力矩，保持平衡。这种物理层面的鲁棒性，是我们选择它的核心原因，而不是因为它的外观像不像科幻片里的终结者。
H2: 视觉语言模型（VLM）：它到底在看什么？
光有好的手还不够，还得有好的脑子。Figure 02 的核心软件引擎是一个基于多模态大模型的视觉语言模型（VLM）。这东西怎么理解工业指令？它是怎么把「把这个螺丝拧紧」转化为机械动作的？
H3: 从像素到语义的映射
在实验室里，Figure 02 的VLM表现惊人。它能识别出传送带上每一个零件的微小瑕疵——哪怕只有指甲盖大小的划痕。它的视觉处理流程是这样的：RGB相机采集图像 -> 边缘计算预处理（提取关键特征） -> 将特征向量传输给云端VLM（基于GPT-5.5 Instant架构优化） -> VLM生成操作指令 -> 机器人执行。
但工程落地中，最大的问题是「理解偏差」。VLM虽然是多模态的，但它有时候会「脑补」。比如在工厂嘈杂的环境下，光照不足，VLM可能会把一个螺丝帽误识别成一颗螺母，导致后续动作完全错误。
H3: 端到端控制的延迟陷阱
我们把VLM集成到机器人控制器里，发现了一个致命问题：延迟。VLM虽然强，但它需要推理时间。在工业节拍（通常要求1-2秒完成一次动作）面前，这个延迟是不可接受的。
（延伸阅读：这个坑我踩了三个月，AWS Lambda Z-Compression 如何让我月省3000刀（内含冷启动血泪史））
Figure 02 采用了一种混合架构：高频控制回路（如力矩控制）在本地运行，而低频的决策和视觉语义理解由云端VLM辅助。这就像是一个赛车手（本地控制）在听领航员（VLM）的指令。但问题是，网络抖动会导致指令延迟，赛车手就得乱开。我们在实际部署中，必须严格控制网络环境，这给工厂的IT架构带来了巨大压力。
H2: 真实战场：给精密电子厂装上「手」
为了验证这套系统，我们接了一个真项目。客户是杭州一家年产值10亿的精密电子组装厂，主要做高端智能手表的主板组装。痛点很明确：招不到熟练工，人工拧螺丝的速度慢且良品率不稳定，夜班更是灾难。
H3: 项目背景与ROI计算
我们给客户部署了3台Figure 02机器人，负责主板上的微型螺丝紧固和接口插拔。
- 人工成本： 每个熟练工月薪8000元，还需要住宿和社保。夜班成本更高。
- 机器人成本： Figure 02的硬件折旧加上软件授权，初期投入不小，但三年摊销后，单台机器人每年的边际成本低于2万元。
- 效率提升： 人工平均每分钟拧4颗螺丝，Figure 02稳定在每分钟6-7颗，且无疲劳。
- 良品率： 人工良品率92%，Figure 02在调试初期只有85%，经过三个月优化后达到98%。
这不仅仅是省钱，更是保产能。客户当时面临订单激增，招不到人，Figure 02成了救命稻草。
H2: 踩坑实录：Sim-to-Real 的死亡谷
虽然ROI看起来很美，但过程比我想象的痛苦得多。这三个月里，我们每天都在和「幻觉」做斗争。最大的教训就是：仿真跑得再好，真机也会给你一记耳光。
H3: 摩擦力模型的「玄学」
我们使用的是基于NVIDIA最新的Omniverse 2026版本的仿真环境。在仿真中，Figure 02抓取一个光滑的金属零件，成功率是99%。我们信心满满地部署到真机。
结果第一天，真机成功率只有15%。所有零件都从手里滑掉了。为什么？
我们在代码里对比了物理引擎的参数。仿真里的摩擦系数设为0.4，真机实测只有0.15。工业现场的灰尘、油污、以及零件表面的氧化层，这些在仿真里很难精确模拟的「脏数据」，直接摧毁了控制算法。
我们花了两周时间，在真机上进行数据采集，构建了一个高精度的「真实世界摩擦力地图」。把这个地图导入仿真环境，经过3000次迭代训练，成功率才慢慢爬升到60%。
H3: 代码调试的血泪史
为了解决这个问题，我们重写了力矩控制算法。下面是一段我们当时用来调试力传感器反馈的Python代码片段。这段代码的核心思想是：当检测到抓取力超过阈值且没有位移时，立即判定为打滑，并触发紧急姿态调整。
import numpy as np
from typing import Tuple
class ForceController:
def __init__(self, max_torque: float = 50.0, slip_threshold: float = 5.0):
self.max_torque = max_torque # 最大允许扭矩
self.slip_threshold = slip_threshold # 打滑阈值
self.current_force = 0.0
self.is_slipping = False
def update_force(self, sensor_reading: float, dt: float) -> Tuple[float, bool]:
"""
更新力传感器读数并判断是否打滑
:param sensor_reading: 来自力矩传感器的原始数值
:param dt: 时间步长
:return: (输出扭矩, 是否打滑)
"""
self.current_force = sensor_reading
# 简单的PID控制逻辑，防止力过大损坏零件
# 在实际工程中，这需要结合位置误差和速度误差
control_signal = self._pid_control(self.current_force, 0.0)
# 打滑检测逻辑：如果持续施加扭矩但位移为0（或极小），说明打滑
# 这是一个简化的状态机，实际需要结合关节速度
if self.current_force > self.slip_threshold and not self.is_slipping:
# 进入打滑状态，尝试微调姿态
self.is_slipping = True
print("[WARNING] Slip detected! Adjusting grip...")
# 如果力矩过大，限制输出
output_torque = min(control_signal, self.max_torque)
return output_torque, self.is_slipping
def _pid_control(self, error: float, setpoint: float) -> float:
# 简化版PID，实际生产中需要积分项和微分项的精细调参
Kp = 2.0
Ki = 0.1
Kd = 0.5
# 这里为了演示省略了积分累积和微分计算
return Kp * (error - setpoint)
# 模拟调试过程
if __name__ == "__main__":
fc = ForceController()
# 模拟传感器数据：前5秒正常，第6秒开始模拟打滑（持续高力矩但无位移）
for i in range(20):
force_val = 2.0 if i Torque {torque}Nm (Adjusting)")
else:
print(f"Step {i}: Force {force_val}N -> Torque {torque}Nm (Stable)")
这段代码虽然简单，但它解决了我们当时最头疼的问题：如何让机器人「知道」它抓空了。通过引入力传感器的实时反馈，我们才敢把控制权交给VLM，而不是死板地执行预设轨迹。
H2: 工程瓶颈：延迟与算力的肉搏
Sim-to-Real 仅仅是第一关，真正的瓶颈在于AI与硬件的结合效率。Figure 02 虽然硬件强大，但算力依然是个瓶颈。
（延伸阅读：Blackwell B200 发布背后的 ROI 陷阱：为什么 90% 的 AI 基础设施初创公司正在消亡）
H3: 边缘推理 vs 云端推理
我们最初尝试将VLM直接部署在机器人的边缘端（使用搭载骁龙8 Gen 5的工业计算模块）。结果发现，运行推理的功耗太高，导致机器人发热严重，甚至出现过一次因为过热保护而停机的情况。
后来我们改回云端推理，但这就带来了网络延迟问题。在5G覆盖好的园区还好，一旦网络波动，机器人就会变成「瞎子」。
这是一个典型的工程权衡：算力在云端，速度快但依赖网络；算力在边缘，稳定但算力受限且功耗大。最终，我们选择了一个折中方案：在边缘端部署轻量级的视觉检测模型（如Llama 4的量化版本），只做快速筛选；复杂的多模态推理，通过低延迟的专线传回云端。
H3: 状态机与VLM的冲突
在代码层面，我们还遇到了一个经典问题：VLM生成的动作序列是连续的，但底层机器人控制器是基于状态机的。
VLM说：「伸手，抓取，松手」。但机器人控制器可能处于「待机」状态，需要先发一个「启动」指令。如果不处理好这个状态转换，机器人就会在原地空转。
我们编写了一个中间件层，专门负责将VLM的自然语言指令翻译成机器人的状态机事件。这层代码虽然枯燥，但却是系统稳定运行的基石。
H2: ROI与结局：我们到底赚了什么？
项目结束时，我们给客户做了一次复盘。虽然过程痛苦，但结果是令人满意的。
H3: 效果对比表
| 指标 | 人工模式 | Figure 02 模式（优化后） | 提升幅度 |
|---|---|---|---|
| 单件处理时间 | 15秒 | 8秒 | +87.5% |
| 良品率 | 92% | 98.5% | +6.5% |
| 24小时连续作业率 | 65%（需换人） | 99.9% | +53.4% |
| 人工成本（人/年） | 12万 | 2万（折旧+电费） | -83.3% |
H3: 失败的教训
这次项目，我们烧了半年钱，差点因为Sim-to-Real的差距过大而放弃。但也正是这次失败，让我们明白了一个道理：AI不能取代物理世界的真实反馈。
我们试过完全依赖VLM做端到端控制，结果机器人把螺丝拧飞了。后来我们回归工程本质，把控制权分层：底层是力控和轨迹规划，上层是VLM做语义理解。Figure 02 带来的新范式，不是让AI完全接管，而是让AI成为更高层的指挥官，而底层的士兵依然要靠老练的工程技巧来稳扎稳打。
未来，随着硬件算力的提升和VLM对物理世界的理解加深，Sim-to-Real的差距会缩小。但在那之前，工程师的经验依然是不可替代的。
（延伸阅读：Atlas 2.0 的腿为什么没软？DeepMind 那篇论文里的“软控制”到底难在哪）
H2: 避坑清单：给后来者的真心话
如果你也想做AI+制造业，或者想引入Figure 02这类机器人，请务必看完这份清单。
- 不要迷信仿真： 仿真里的物理参数必须基于真机实测数据校准，否则就是无效训练。花时间做真机数据采集是值得的。
- 重视力控： 在工业场景，特别是处理易碎或光滑物体时，纯视觉控制是不够的，力矩传感器是刚需。
- 网络是命门： 无论你选云端还是边缘，都要做好网络中断的预案。机器人不能因为断网就停摆。
- ROI要看长期： 初期部署成本极高，不要看前三个月的亏损，要看三年后的边际成本下降。
- 保持敬畏： AI再强，它也是基于概率的。在关键工序上，保留人工复核机制是必要的。
Figure 02 带来了具身智能的新范式，但这只是一个开始。从实验室到工厂，这条路依然充满泥泞，但只要脚踩在地上，我们就走得下去。
