机器人基础模型与视频即提示词：从传统控制到策略生成-平芜编程栈

如果你做过工业机器人或者机械臂的落地项目，大概率经历过下面这种场景：现场来了一种新的工件，没有现成的抓取策略，工程师只能先把机器人停下来，重新标定位置、调试姿态、写路径点，再反复试跑几十次，才敢让它上线。整个过程少则一两天，多则一两周。真正卡住进度的，往往不是机器人本体贵不贵，而是“让机器人学会一个新操作”这件事本身太重了。

Skild S1 这类“机器人基础模型”想改变的，正是这一环。它带来的一个关键口号是“视频即提示词”：不再需要工程师把任务拆成一行行动作指令，而是直接给模型看一段示范视频，模型理解任务目标后，输出机器人可以执行的控制策略。这个转变一旦成立，机器人开发的瓶颈就会从“写控制代码”转向“定义任务和准备数据”。

这篇文章会先拆解传统机器人控制为什么难，再讲清楚“视频即提示词”到底是什么、与文本提示词有什么本质区别，然后沿着“视频输入到动作输出”的完整链路，给出开发者可以上手的示例代码、验证方式和排查思路。无论你是做机器人算法、自动化集成，还是正在评估机器人基础模型是否适合自己的项目，这篇文章都能帮你建立一个完整的判断框架。

1. 机器人开发的老问题：控制策略为什么这么难写

先明确一个概念：机器人开发中最贵的部分，不是机械本体，而是“控制策略”。所谓控制策略，是指机器人面对一个具体任务时，该按照什么顺序、以什么轨迹、施加多大力度去完成操作。

传统机器人项目里，控制策略通常是这样构建的：工程师先拆解任务流程，把“抓取—搬运—放置”分解成多个状态，再为每个状态编写感知判断和运动指令。以抓取为例，你需要知道工件放在哪里、以什么角度接近、夹爪闭合多少、转移过程中会不会碰撞。这些逻辑在代码里往往体现为状态机和大量写死的位置点。

这带来两个典型问题。

第一，长尾场景处理成本极高。产线只要换一种产品、换一种摆放方式，原有策略就可能失效，必须重新调试。仓库里有上千种SKU，每一种都要单独适配，从工作量上看几乎不可能做到精细优化。很多团队最终的妥协方案是只针对高频商品做精细抓取，其他商品仍然依赖人工。

第二，异常处理逻辑难以穷举。真机环境里总有意外：工件反光导致识别不稳定、托盘位置偏了几毫米、物体表面材质变化。传统策略面对这些情况，要么靠工程师预先写规则，要么靠现场人工干预。规则写得越多，系统越复杂，维护成本指数上升。

所以，机器人行业一直缺的不是更好的电机或更精密的减速器，而是一种能够从少量演示中快速生成控制策略的方法。过去几年，研究者尝试用强化学习从仿真环境训练策略，效果不错，但仿真到真机的迁移仍不成熟；也有人尝试直接从人类操作视频中学习，但早期模型只能解决单一任务，换个场景就失效。

Skild S1 这类“机器人基础模型”的价值就在这里：它试图把“学会一个任务”的成本，从传统的按周计、按人计的工程投入，压缩到“给一段视频”的交互成本。这个变化如果成立，对整个自动化项目交付模式的影响会非常直接。

2. “视频即提示词”是什么：一次对机器人交互方式的重定义

“视频即提示词”这个说法，很多人第一反应是：机器人把视频里的动作照做一遍？这是最容易误解的地方。

用大语言模型来类比会更清楚。当你给 ChatGPT 一段文本提示词时，模型不是去“背”这段文字，而是理解文字背后的意图，再根据训练学到的知识生成一段新的回答。同理，“视频即提示词”也不是让机器人逐帧复刻视频里的轨迹，而是让模型从视频中理解任务目标、物体关系、动作顺序和约束条件，然后生成适用于当前机器人本体的控制策略。

为了把这个概念讲清楚，可以把几种提示词方式放在一起对比：

提示词类型	输入内容	模型输出	特点	局限
文本提示词	自然语言描述	文本/代码/计划	表达高效，易于理解	缺乏空间与物理细节
图像提示词	静态图片	目标检测/场景描述	提供空间信息	无法表达时序与动态
视频提示词	人类/机器人演示视频	动作序列/控制指令	包含时序、物理交互、物体变化	解析难度高，对数据质量敏感

从表格能看出，视频提示词的信息密度远高于文本和静态图像。一段 30 秒的演示视频，不仅包含“拿起杯子”这个目标，还包含了手怎么接近杯子、杯子在桌面上的位置关系、移动路径中如何避开障碍等信息。这些细节如果全部用文本描述，会非常冗长且依然不精确；但视频天然携带这些信息。

这也正是“视频即提示词”的精髓：它把传统机器人开发中“隐性知识显性化”的难题，绕了过去。过去工程师需要把经验变成规则和代码，现在只需要把经验变成一段视频。模型负责从视频中提取那种“只可意会”的操作要领。

不过要特别强调，视频提示词并不等于“视频回放”。如果模型只是把视频中的末端轨迹直接映射到机器人上，那本质上还是离线示教，遇到不同尺寸、不同位置、不同夹具的机器人就会失效。真正的基础模型需要做到的是“任务层面的理解”，而不是“轨迹层面的模仿”。

3. Skild S1 在机器人基础模型中的定位

“机器人基础模型”并不是一个新鲜概念。从最早的 RT-1，到后来的 RT-2、PaLM-E，再到各类基于扩散策略的机器人模型，研究者一直在尝试把大规模预训练的能力迁移到机器人控制领域。这些模型的共同思路是：先用大量跨任务、跨场景的数据训练一个通用模型，再在具体任务上做少量微调或直接零样本推理。

Skild S1 从公开资料看，属于这条技术路线上的新一代产品化尝试。它把“视频即提示词”作为核心交互方式，意味着开发者的使用方式发生了明显变化：

传统方式：定义状态机、写路径点、设计异常分支。
使用 Skild S1 的方式：准备一段示范视频，附上自然语言任务描述，模型输出动作策略。

这种变化真正的意义，不是“少写几行代码”，而是把机器人开发的重心从“实现动作”上移到了“定义任务”上。开发者不再需要深入了解每一个运动学细节，但需要更擅长拆解任务边界、准备高质量演示数据、设计约束条件。

从行业视角看，Skild S1 这类模型的定位是“机器人操作系统之上的策略层”。它处于感知硬件和运动控制之间的中间层：上层接收任务描述和视频输入，下层输出动作指令给执行器。这种分层有一个好处：机器人的硬件本体仍然由传统控制器精确控制，基础模型负责的是“决策”部分，也就是状态机里最难的“下一步做什么、怎么做”的问题。

但这不意味着 Skild S1 是万能的。从目前机器人基础模型的普遍能力边界来看，这类模型更适合处理短时长的操作任务，例如抓取、放置、插拔、按压等；对于需要数小时连续作业、包含大量时序依赖的复杂长任务，仍然需要上层任务规划系统来分解。更稳妥的判断是：Skild S1 先解决的是“单步操作策略”的生成问题，而不是整个生产流程的自动化。

对开发者来说，Skild S1 的出现意味着一个新的岗位能力要求——不是会调参就会用机器人基础模型，而是要懂得如何把真实任务转化为模型能理解的“视频+文本”输入。这有点像大语言模型时代的提示词工程，但难度更高，因为视频数据的采集和质量控制比写一段文字复杂得多。

4. 核心链路拆解：从视频到动作指令

理解了概念之后，我们需要知道“视频即提示词”在实际系统中是如何工作的。整个链路可以拆成五个环节，每个环节都有明确的输入输出和隐藏难点。

4.1 视频采集与任务定义

第一步是获取演示视频。这里有两个关键选择：一是视频来源，可以是人类手持摄像头操作，也可以是已有的机器人演示录像；二是任务定义，通常需要搭配一段简短的自然语言描述，比如“将红色方块从桌面左侧移到右侧托盘”。

这个环节最容易犯的错误是视频内容与任务描述不一致。比如视频里同时出现了多个物体，任务描述只提到其中一个，模型就可能产生歧义。从实践角度，采集视频时应该保证画面主体清晰、动作完整、光照稳定，最好一次只呈现一个主要操作动作。

4.2 视频预处理与对齐

原始视频不能直接输入模型，需要经过抽帧、裁剪、缩放、速度归一化等操作。这一步的目标是把视频转换成模型可以接受的张量序列。

一个容易被忽视的细节是“速度对齐”。人类演示视频中手的动作速度，和机器人的执行速度往往不同。如果模型直接从人类视频中学习时序规律，可能会生成过于激进或过于缓慢的动作。因此不少系统会在预处理阶段对视频做时间维度上的重采样，或者让模型在推理阶段输出带速度参数的动作指令，由下层控制器执行。

4.3 任务理解与策略生成

这是模型的核心环节。模型观看视频帧序列后，需要完成两层理解：第一层是场景理解，识别出有哪些物体、分别在哪里、处于什么状态；第二层是任务理解，推断出操作的目标是什么、动作的顺序是什么、哪些约束必须满足。

在机器人基础模型中，这两层理解通常不是分开的，而是由一个统一的网络联合完成。模型输出的形式也不是简单的文字描述，而是动作序列，可能是每个时间步的末端位置、速度、夹爪状态，也可能是更高层的动作原语编号。

4.4 动作映射与执行

模型输出的动作序列不能直接驱动真实的电机。机器人的执行器有自己的运动学结构，同样的末端位置坐标，在不同机械臂上对应的关节角度完全不同。因此，中间还需要一个动作映射层，把模型输出的任务空间指令转换成具体机械臂的关节空间指令。

这也是“基础模型跨本体迁移”的关键节点。做得好的系统，在训练时会加入大量不同机械臂的数据，使模型输出的动作具有本体无关性；做不好的系统，换一个机械臂型号，效果就明显下降。

4.5 闭环反馈与重试

真实环境充满不确定性，模型输出的开环动作很难一次成功。成熟的系统会在执行过程中加入视觉反馈：做完一步后，用相机确认当前状态，如果与预期不符，则重新调用模型生成修正动作。

这个环节对开发者来说是一个重要提醒：不要指望模型一次输出完美的开环轨迹。基础模型的正确使用方式，是把它当作“策略建议器”，每次都根据当前观测重新生成下一步动作，而不是执行一份固定脚本。

5. 开发者如何接入：环境准备与最小示例

注意：Skild S1 的官方 API 和开源工具链目前仍在快速迭代中，本文给出的代码是“概念验证”级别的示意代码，用于演示“视频即提示词”的开发范式。实际接入时，请以官方文档为准，重点关注接口的输入输出格式。

5.1 环境准备

推荐在本机或带 GPU 的服务器上进行实验。基础环境如下：

Python 3.9 及以上版本
PyTorch 2.0 及以上版本
OpenCV（用于视频抽帧）
机器人仿真环境，如 MuJoCo 或 Isaac Sim（用于策略验证）

如果 GPU 显存不足，可以先在仿真环境里用低分辨率视频做验证。视频建议控制在 10 到 30 秒，分辨率 640×480 即可，帧率 15 到 30 FPS。

# 创建虚拟环境 python -m venv skild_env source skild_env/bin/activate # 安装核心依赖 pip install torch torchvision opencv-python numpy

5.2 视频预处理：抽帧与归一化

以下代码演示如何将一段示范视频转换为模型输入所需的帧序列。代码实现了抽帧、缩放和归一化三个基本操作。

# 文件路径：preprocess_video.py import cv2 import numpy as np def extract_frames(video_path, num_frames=16, target_size=(224, 224)): """ 从视频中均匀抽取 num_frames 帧，并缩放到目标尺寸。 返回 shape 为 (num_frames, H, W, 3) 的 numpy 数组。 """ cap = cv2.VideoCapture(video_path) total_frames = int(cap.get(cv2.CAP_PROP_FRAME_COUNT)) if total_frames <= 0: raise ValueError(f"无法读取视频: {video_path}") # 计算均匀抽帧的间隔 indices = np.linspace(0, total_frames - 1, num_frames, dtype=int) frames = [] for idx in indices: cap.set(cv2.CAP_PROP_POS_FRAMES, idx) ret, frame = cap.read() if not ret: continue frame = cv2.resize(frame, target_size) frame = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) frames.append(frame) cap.release() if len(frames) < num_frames: raise ValueError("抽取帧数不足，请检查视频长度") # 转换为 float32 并归一化到 [0, 1] frames = np.stack(frames, axis=0).astype(np.float32) / 255.0 return frames if __name__ == "__main__": frames = extract_frames("demo.mp4") print(f"帧序列形状: {frames.shape}")

这段代码的关键在于“均匀抽帧”。视频中动作快慢不均时，均匀抽帧能保留完整的语义信息，避免动作被截断。

5.3 调用模型：视频提示词输入与动作输出

下面是一个示意性的模型调用代码。你需要将MODEL_API_URL替换为实际部署的服务地址，输入为视频帧序列和任务描述，输出为动作指令数组。

# 文件路径：generate_action.py import numpy as np import requests def generate_action(video_frames, task_description, model_api_url): """ 调用机器人基础模型，输入视频帧和任务描述，返回动作序列。 注意：此代码为示意代码，实际接口格式以官方文档为准。 """ # 将帧序列转为列表，便于 JSON 序列化 video_data = video_frames.tolist() payload = { "video": video_data, "task": task_description, "output_format": "action_sequence", "max_steps": 50 } try: response = requests.post( model_api_url, json=payload, timeout=30 ) response.raise_for_status() result = response.json() actions = np.array(result["actions"]) return actions except requests.exceptions.Timeout: raise RuntimeError("模型推理超时，请检查服务状态或减少视频长度") except Exception as e: raise RuntimeError(f"模型调用失败: {e}") if __name__ == "__main__": # 假设 frames 来自 preprocess_video.py task = "将红色方块从桌面左侧移到右侧托盘" actions = generate_action(frames, task, "http://localhost:8080/predict") print(f"动作序列形状: {actions.shape}")

在实际项目中，请求体里通常还需要加上机器人型号、末端初始位置、工作空间约束等信息。这些信息能显著提升模型输出动作的可行性。

5.4 仿真环境执行动作序列

拿到动作序列后，建议先在仿真环境里验证，不要直接上真机。下面是一个在 MuJoCo 中执行动作序列的示意框架。

# 文件路径：simulate_action.py import mujoco import numpy as np def execute_action_sequence(model_path, actions): """ 在 MuJoCo 仿真环境中顺序执行动作序列。 actions: shape 为 (num_steps, action_dim) 的数组。 """ model = mujoco.MjModel.from_xml_path(model_path) data = mujoco.MjData(model) for step, action in enumerate(actions): data.ctrl[:] = action[:data.nu] mujoco.mj_step(model, data) # 每 10 步打印一次当前执行状态 if step % 10 == 0: print(f"Step {step}, 末端位置: {data.qpos[:3]}") print("动作序列执行完成")

仿真验证的价值是能够在零成本条件下发现明显的轨迹问题，比如物体被撞飞、动作超出机械臂工作空间等。只有在仿真结果可接受的情况下，才建议进入真机测试阶段。

6. 运行结果与效果验证

跑通上面的示例后，你需要判断模型生成的策略到底好不好。单看“动作序列输出了”远远不够，需要用可量化的指标来评估。

6.1 成功率的定义

最基本的验证方法是多次重复同一任务，计算成功率。例如让模型基于同一段视频，在仿真环境的不同初始位置下执行 20 次，记录成功次数。成功率低于某个阈值时，需要回到数据或任务描述层面找问题。

# 运行 20 次仿真验证 for i in $(seq 1 20); do python simulate_action.py --model robot.xml --actions actions.npy --seed $i done

6.2 观察指标

除了成功率，建议同时观察以下指标：

指标	说明	理想表现
任务完成率	最终状态是否达到目标	越高越好
碰撞次数	执行过程中是否发生非预期碰撞	尽量为 0
轨迹平滑度	相邻动作指令的差分是否过大	无明显跳变
执行稳定性	不同初始条件下成功率方差	方差越小越好
单步推理耗时	模型生成一步动作所需时间	根据实时性要求评估

6.3 失败时先看哪里

如果仿真验证失败频发，不要第一时间怀疑模型能力。按照下面的顺序排查：

视频预处理是否正确：抽帧后的画面是否清晰、目标物体是否可见。
任务描述是否明确：是否有歧义、是否与视频内容一致。
动作映射是否正确：模型输出的动作维度是否与仿真机器人的控制维度匹配。
仿真环境物理参数是否合理：摩擦力、重力方向、物体质量是否正常。

大多数失败，根源都在前两个环节：视频数据质量不够，或者任务定义含糊。

7. 常见问题与排查思路

为了让你在实际接入时少走弯路，这里整理了一份高频问题排查表：

问题现象	可能原因	排查方式	解决方案
视频无法解析	编码格式不受支持	用 OpenCV 测试读取视频	统一转码为 MP4/H.264
模型输出动作剧烈抖动	视频帧率过密，模型学习到高频噪声	降低输入帧率或增加时间平滑	对动作序列做低通滤波
任务执行时物体被撞飞	视频中未体现避让路径	检查演示视频角度和路径	重新录制更合规的演示
模型输出与机器人动作空间不匹配	缺少机器人本体信息	确认请求中是否包含型号和约束	在入参中加入工作空间和自由度
长任务执行到一半停止	任务超出模型单次推理能力	观察日志中的结束标记	将任务拆分为多个子任务，逐个推理
同一模型换场景效果明显下降	场景光照、背景变化过大	对比新旧场景的视频特征	在目标场景补充少量视频作为示例
推理延迟过高	输入帧数过多或 GPU 资源不足	统计单次推理耗时	减少帧数或用更小的输入分辨率

这组问题的核心规律是：大部分问题出在“输入侧”而不是“模型侧”。视频提示词的质量，直接决定了策略生成的天花板。

8. 最佳实践与工程建议

8.1 视频数据采集规范

既然视频是提示词，那么视频质量就是提示词质量。建议在团队内部建立统一的采集规范：

固定相机视角，保持画面稳定。
确保目标物体在画面中占比适中，不要过小或出画。
一次演示只包含一个完整任务，避免多个任务混杂。
录制时保持动作速度适中、平稳，避免剧烈抖动。
每个任务至少录制 5 段不同方位、不同初始位置的演示视频。

8.2 任务描述的编写模板

虽然视频携带大量信息，但自然语言任务描述仍然非常重要。建议采用以下模板：

操作对象 + 动作类型 + 目标位置 + 约束条件

示例：“将（操作对象）红色方块用（动作类型）夹抓方式移到（目标位置）右侧托盘，全程（约束）保持方块水平。”

任务描述越明确，模型越不容易产生歧义。如果模型总是理解偏差，优先检查任务描述是否缺少关键约束。

8.3 安全边界与真机验证

模型输出的动作指令在真机执行前，必须在控制层面加装安全护栏：

限制最大速度与最大力矩。
限制关节角度范围与工作空间范围。
设置碰撞检测与紧急停止。
真机测试时安排专职安全员，并由一名工程师全程监视日志。

这里强调一个原则：基础模型是“建议生成器”，不是“安全保证器”。模型的泛化能力再强，也无法为真实环境中的意外负责。任何涉及生产环境的变更，都要先在仿真环境验证，必要时走灰度发布流程，并保留回滚能力。

8.4 日志与可回溯性

每次推理请求都应记录完整的输入输出上下文，包括视频路径、任务描述、模型版本、输出动作序列、执行结果。这既是为了调试，也是为了将来做数据集迭代。没有日志的模型系统，遇到问题基本只能靠猜。

建议每条日志至少包含以下字段：

{ "request_id": "20240516_001", "video_md5": "3f2a...", "task": "将红色方块移到右侧托盘", "model_version": "skild-s1-20240515", "actions_file": "actions_001.npy", "result": "success", "execution_time_ms": 1250 }

这种结构化的日志，能在模型迭代后快速对比新旧版本的效果差异。

8.5 从仿真到真机的迁移节奏

不要一步跨到真机。推荐的节奏是：

在仿真环境中验证成功率，达到验收标准。
在真机上用低速、低力矩模式空跑动作序列，观察轨迹是否平滑。
加入目标物体，执行真实任务，确保安全员在场。
逐步提高速度与力矩，并持续记录成功率。

每一步都保留数据，用于判断问题出在策略生成还是底层执行。

9. 总结与后续学习方向

这篇文章的核心，是帮你建立一套理解“视频即提示词”的方法论。Skild S1 这类机器人基础模型的意义，不在于它哪一层的网络结构更先进，而在于它把机器人开发中最昂贵的“策略生成”环节，从工程问题变成了数据与交互问题。开发者不再需要把每一个动作拆成代码，而是需要学会定义任务、采集视频、验证策略、控制边界。

如果你想在这个方向上继续深入，有四个建议：

第一，亲手跑通一个仿真抓取任务，哪怕用的是最简单的两指夹爪。仿真环境的失败成本低，最适合建立对“动作序列输入输出”的直觉。

第二，练习“任务拆解”。长任务分解成短视频提示词的能力，和写大语言模型提示词一样，需要刻意训练。你拆得越细，模型执行得越稳。

第三，关注跨本体迁移。真正的工程价值在于，同一个基础模型是否能适配多种机械臂和移动底盘。这是机器人基础模型走向落地必须解决的问题。

第四，重视数据积累。每做一次实验，都保留原始视频、任务描述、模型输出和执行结果。这些数据未来会成为你评测新模型、优化提示词最宝贵的资产。

Skild S1 不会是机器人基础模型的终点，但“视频即提示词”这个方向，值得每个做机器人开发的工程师认真理解。它改变的也许不是机器人的硬件，而是我们与机器人“沟通”的方式。早点掌握这套思路，等你的项目需要引入这类能力时，就能比其他人更快判断“什么任务适合、什么任务不适合、数据怎么准备、边界怎么控制”。