如果“Skild S1”这样的机器人基础模型真能兑现“视频即提示词”这个说法那么机器人调试现场最枯燥的那部分工作可能要先被改掉。过去几年我在机械臂项目里最常见的场景是这样的任务本身不难——把零件放到料框、把螺丝拧到指定扭矩、把物料从一个托盘移到另一个托盘。但每换一个任务就要重新写感知模块、路径规划、末端姿态、碰撞检测参数。哪怕只是把零件换成另一个型号代码也要跟着调整。后来接触了机器人基础模型这个概念尤其是“视频即提示词”的玩法我才意识到真正需要重构的也许不是某个算法而是我们给机器人下指令的整套方式。这篇文章不打算把 Skild S1 讲成“未来机器人”的万能答案。我更想顺着“视频即提示词”这条线把它放在实际工程视角里拆开它到底改变了什么、为什么非要用视频、落地时会卡在什么地方以及一个普通开发者和研究团队可以从哪里开始。1. 先纠正一个直觉视频提示词不是“给它看一段录像”这么简单很多人第一次看到“视频即提示词”时第一反应是这不就是给机器人看一段示范视频让它照着做吗这个理解只说对了一半。给机器人看视频在模仿学习里早就存在。传统模仿学习的流程是先录制大量人类遥操作视频标注好关节角度或末端轨迹然后把视频当成监督信号去训练一个策略网络。这时候视频是“训练数据的一部分”模型从中提取的是统计规律。但“提示词”是另一种用法。它更接近大语言模型里的 prompt模型在推理阶段拿到一段视频不是要模仿这段视频里的动作本身而是把视频当成一段“任务描述”在它的通用能力基础上生成一条适合当前环境的动作序列。换句话说训练好的模型不会因为换了视频就重新训练你只是换了一个提示视频它就应该去干一件新的事。这个区别非常重要。我在不少项目讨论里发现团队把“预训练模型”和“基础模型”混为一谈。预训练模型只是先用大量数据初始化权重之后仍然需要针对每个下游任务微调基础模型的目标是零样本或小样本适配新任务。Skild S1 作为机器人基础模型真正吸引人的不是“它能看懂视频”而是“你用新视频提示它它大概率能直接执行一个之前没见过的新任务”。当然这是理想状态现实里还需要不少工程约束后面会展开。1.1 文本提示词依赖“共同知识”视频提示词依赖“物理状态”为什么机器人领域需要视频当提示词而不是像大模型那样用文字因为文本提示词能生效的前提是模型和用户共享大量常识。你说“把杯子放到托盘里”大模型能理解是因为语料里到处都是类似的句子杯子、托盘、放置这些概念都被反复对齐过。但机器人面对的是物理世界。同一个句子在真实环境里可能是无数种情况杯子是陶瓷还是塑料、托盘有没有边沿、桌面是否平整、机械臂从哪个角度靠近、末端夹爪应该张开多少。文字描述没有把这些信息传递出来模型只能猜测。而视频天然包含这些物理上下文物体形状、初始位置、相对关系、运动轨迹、速度节奏。这也是“视频即提示词”在表达效率上的优势。一段三秒的视频能传递的信息如果用自然语言描述可能需要几十行文本如果用路径点定义可能需要成百上千个坐标值如果用代码写规则可能需要覆盖各种 if-else 分支。视频本质上是一种高密度的任务表达方式。1.2 提示和监督信号的边界是理解这个项目的一把钥匙传统模仿学习里视频通常担任监督信号每个时刻的画面都对应一个标准动作模型要学着把输入映射到输出。但在“视频即提示词”的框架里视频更像是一个条件变量模型可以预测当前机器人处在什么状态、接下来应该做什么而不是简单复制视频里的轨迹。打个比方你给一位新厨师看一段颠勺的视频。如果这是监督信号新厨师要精确复现手腕的角度和力度如果这是提示词新厨师要做的是理解“这里需要让食材翻面”然后结合自己的技巧完成动作。前者关注像素级模仿后者关注任务意图。这个边界决定了模型的设计思路。如果只是监督信号模型学的是“视频画面到关节角度”的映射换个环境很容易失效。如果作为提示词模型需要把视频压缩成任务语义再结合当前观测生成动作。这也是为什么这类基础模型往往会借鉴视觉-语言-动作VLA的架构视觉编码器负责把视频和当前画面变成特征语言或者隐含语义负责任务意图动作头负责输出控制量。理解到这一层“视频即提示词”才真正有了基础模型的味道它不是在复读示范而是在理解任务之后做迁移。2. 为什么视频比自然语言更适合当机器人的任务指令如果你用过机械臂的示教器会发现“给机器人下指令”这件事其实一直很别扭。早期是坐标系、运动指令和点位列表后来有了一些拖拽示教和图形化编程但仍然是在用人类定义好的抽象语法去描述一个连续物理过程。语言、符号和坐标本质上都是对真实任务的压缩编码而编码过程一定会丢失信息。2.1 语言描述距离动作执行太远自然语言最大的问题是它擅长描述目标和约束不擅长描述运动细节。举个例子“轻轻地把鸡蛋从桌面拿起来放到纸盒里。”“轻轻”两个字人类能理解模型却很难把它转成力控参数是 2N 还是 5N移动速度是 0.1m/s 还是 0.3m/s接近角度有没有要求纸盒开口朝向哪里这些信息在语言里是缺失的。你当然可以继续追问或者写配置文件但每多一个字段任务描述的成本就高一分。而一段视频把这些细节全部包含进去了。模型看到的是一个连续的物理过程可以用视觉特征推断出接触方式、轨迹形态和速度曲线。语言要表达的东西视频已经替你表达完了。所以在实际操作中我通常建议团队把“用自然语言描述任务”这件事看作一种辅助手段而不是主要输入。自然语言适合描述目标比如“完成后把相机移到拍照位置”但具体怎么完成最好交给视频示范来传达。2.2 视频把“成功的样子”也带出来了机器人强化学习里最难的部分往往不是算法而是奖励函数设计。你希望机械臂把轴插入孔里到底该怎么定义奖励是距离越近越好还是姿态误差越小越好如果只看末端位置可能插歪了但奖励被认为完成任务如果惩罚太严厉学习过程又会非常脆弱。视频提示词绕开了这个痛苦示范视频本身就定义了“什么样算成功”。不需要显式写奖励公式模型可以参考视频中的状态转移去理解目标状态和路径偏好。这也是机器人基础模型在数据利用方式上的变化以前我们消耗的是人工标注的奖励现在消耗的是示教视频中包含的隐式语义。不过要提醒一句视频定义成功并不总是清晰。同一段视频可能是“把螺丝拧到底”也可能是“用手掌拧螺丝”具体哪一个才是任务意图模型不一定能区分。所以在落地时建议在视频之外补一个非常简短的任务标签或指令文本帮助模型把注意力放到关键语义上。多模态提示不是坏事反而能减少歧义。3. 这类模型最容易被高估的地方能看懂不等于能执行从宣传角度“视频即提示词”听起来很性感录一段视频机器人就会了。但真正到了工程现场“能看懂视频”和“能稳定完成操作”之间隔着相当远的距离。3.1 泛化能力不等于场景无关机器人基础模型要解决的核心问题是跨场景迁移。训练时它见过各种桌面、各种物体、各种光照理论上应该学会抓住共性。但实际部署时最常见的问题恰恰是“换一个场景就失灵”。光照变了、背景花了一点、物体换了颜色、相机角度低了五厘米模型输出的动作就可能偏移。这个问题的本质是视觉分布的漂移。视频提示词给出的是任务意图但模型仍然需要把意图映射到当前观测上。如果它没有真正理解“抓住杯子”是一个抽象任务而只是记住了训练数据里类似画面的统计特征那遇到分布外的场景就会翻车。所以一个负责任的验证流程应该包含“分布外测试”用训练的同一个任务但换环境、换物体、换视角去跑。如果模型只会在训练场景里绕圈那它更像是记住了数据而不是在理解之后完成推理。这也是判断“视频提示词”是不是真有效的快速方法。3.2 动作输出和视觉理解是两套系统机器人的控制回路对实时性要求很高。视觉基础模型通常跑得很慢一个视频序列或者多视角图像经过编码器可能需要几百毫秒到几秒。如果直接把这个延迟放进控制回路机械臂很难稳定跟踪物体。因此实用的机器人基础模型一般会把“做什么”和“怎么做”分层。视频提示词负责提供高层次的任务规划底层再由另一个更快的运动控制器去跟踪轨迹。这就像拿到一段示范视频后你并不会让神经网络直接输出每一个关节电机电流而是让它输出路径点或末端位姿序列再由运动学求解器平滑成关节运动。具体到模型训练常见的做法是让视觉语言模型生成动作 token然后解码成机器人动作序列。这里的“动作”可以是关节位置增量、末端笛卡尔速度也可以是夹爪开合指令。无论哪种都意味着模型不只是视觉模块还必须与机器人的运动学、动力学边界对齐。3.3 安全边界不在模型里要在执行层补视频提示词再强大也只是给模型指定了一个方向。它不会告诉机器人力矩上限是多少、哪些区域不能进入、碰到人必须立刻停止。这些安全属性不太可能从视频中学到也不应该让模型来负责。我的观点很明确视频提示词用于生成任务意图和参考轨迹但机器人本身的限位、力控、急停保护必须放在模型之外。不要让模型直接生成不受约束的电机指令也不要因为模型“看起来理解了任务”就跳过碰撞检测和安全冗余。注意在没有任何安全拦截层的情况下不要直接让视频提示词模型控制真实运动部件。先在仿真环境、虚拟测例或带限位保护的实验台上验证再考虑上真实设备。这不仅是工程问题也是责任边界问题。模型输出是一个建议系统执行必须有一个“最后一道闸”。真正的生产级方案应该是视频提示词负责生成提议安全层负责放行或纠正。4. 从一条样例视频到可控执行落地时通常卡在这几步如果你拿到一个类似 Skild S1 的模型想在自己的机械臂上跑通“视频即提示词”的流程我建议不要一开始就做几百条视频的数据集。先走一条最小路径一条样例视频一个固定相机一个简单的抓取任务。4.1 最小跑通流程先验证输入、输出和日志第一步是准备提示视频。视频要尽量符合“成功示范”的标准视角清晰、光照正常、动作完整、一次完成。不需要太长三到五秒一般够用。过长的视频反而容易引入冗余动作模型不知道你的核心意图是哪一段。第二步是对齐观测空间。机械臂部署地点的相机位置要和视频里的视角协调。如果提示视频是俯拍现场相机却装在侧面模型在理解空间关系时会遇到很大困难。尽可能保持“视频视角近似于推理时的观测视角”。第三步定义动作输出格式。实际抓取时你需要让模型输出什么是末端目标点的三维坐标、还是完整轨迹、还是关节角度序列不同输出决定后续不同的控制方式。建议从“末端位姿序列 夹爪状态”开始试因为它在运动学层面最容易检查。最后加一个日志记录。记录输入的提示视频、观测图像、模型输出的动作序列、实际执行结果。没有日志后续排查会非常痛苦。这里可以给一个通用的任务描述示例结构不代表某个模型的真实 APItask { prompt_video: demos/grasp_cup.mp4, observation_source: camera_front, output_mode: end_effector_pose_sequence, target_frequency_hz: 10, safety: { force_limit_n: 5.0, speed_limit_mps: 0.2, emergency_stop: True } }重点不是参数写法而是你要给模型一个明确的边界它输出到哪个抽象层、控制频率是多少、安全约束有哪些。4.2 常见问题排查顺序一旦跑不通不要急着调模型参数。按下面的顺序排查大多数问题能定位先看输入。提示视频是否可读、是否包含成功示范、视角是否与现场一致、物体是否相似。再看观测。相机画面是否清晰、物体是否有遮挡、光照是否变化过大、标定参数是否正确。再看输出。模型给出的动作序列是否合理末端轨迹有没有穿墙、抖动、突变。再看执行。机械臂有没有受到限位、速度限制、力控保护的影响。最后才是模型本身。确认前四层都没问题后再考虑模型版本、提示词格式、是否微调。这五层里前两层主要负责“能不能看见”中间一层负责“能不能想对”后两层负责“能不能做出来”。大多数刚接触这类模型的人都会先怀疑模型能力不行。实际上大多数故障都出在输入和观测的错位上。提醒不要用一个视频就跑十几个任务。先把一个任务跑通记录模型输出的规律再逐步增加任务样本。视频提示词的稳定性往往需要多次尝试才能看出边界。5. 什么项目适合引入“视频即提示词”什么场景可以先等等任何技术方案都有适用边界。我不主张一看到机器人基础模型就把原有代码全扔掉。你需要判断自己的任务画像和团队资源。5.1 适合视频提示词的任务画像从工程经验看符合以下特征的任务更容易受益任务目标可以被短视频清晰表达比如抓取、放置、装配、整理。物体状态变化不依赖隐藏信息主要靠视觉可以判断。任务需要频繁切换新变体但每个变体的底层物理逻辑相近。团队有一定数据采集能力能持续录制示范视频并评估失败反馈。环境相对受控相机、物体、工作台不会出现剧烈变化。这类任务里视频提示词的最大价值不是节省几分钟而是把“换任务”这件事变成改一条视频路径而不用改测试代码和状态机。打个比方以前你维护的是任务代码库每新增一种产品要新增一套视觉模板和轨迹策略。有了视频提示词之后你维护的是示范视频库和验证清单。代码量下降但数据管理复杂度上升。适合不适合取决于团队更怕改代码还是更怕录数据。5.2 不建议入场的情况反过来遇到这些情况我建议你先不要用视频提示词高频实时反应任务比如动态抓取移动物体对延迟极其敏感。任务需要精确力控像精密装配、打磨只靠视频无法表达受力边界。环境非常开放物体种类、背景、光照完全不可控。项目没有足够的安全验证条件不能容忍试错。团队没有数据管理意识视频命名混乱、版本不清。在这些场景里传统基于运动规划、力控、视觉伺服的方法仍然更可靠。视频提示词可以作为辅助或者预标注工具但不应作为唯一控制来源。维度适合视频提示词需要谨慎任务变化频繁换任务变体固定且高精度要求数据能力能录视频、能做版本管理无数据积累经验环境相对受控视觉可判断开放、动态、光照复杂安全允许试错或有硬限位保护不能有任何碰撞风险控制精度毫米到厘米级可接受需要力控、微米级精度这个表格不是绝对标准而是一个筛选思路。核心判断是“视频提示词”本质上是把任务理解交给模型但把物理正确性和安全边界留给你自己。如果你的任务需要极强的物理约束而模型不能接受这些约束那它就不适合。6. 长期来看真正值得沉淀的不是模型而是任务库和验证闭环聊到这里“视频即提示词”这种机器人基础模型到底会改变什么已经比较清楚了。它不会让工程师失业也不会让所有机器人立刻变成通用助手。它真正改变的是机器人项目的重心。6.1 工程师的角色从“写规则”变成“定义数据边界”以前做机器人项目核心工作集中在编写控制逻辑和策略规则。现在如果采用视频提示词核心工作会转移到三个地方一是视频数据采集和整理二是任务语义的定义和标注三是模型输出与安全层的接口。换句话说团队里最稀缺的能力从“能写复杂运动学代码”慢慢变成“能设计一套高质量数据采集流程”和“能判断模型失败时是数据问题还是任务表达问题”。这里有一个很实际的建议从现在开始就为你的机器人任务建立视频任务库。每一条视频都包含任务 ID、版本、场景描述、成功/失败标记、提示词说明、模型输出片段。这个任务库既是训练素材也是评估集更是你长期迭代的“可复用资产”。模型可以换任务库会一直沉淀。6.2 先做一个任务再搭一套闭环如果你还没有接触过这类模型我建议不要一上来就规划“全车间通用机器人”。挑一个最简单、最受控的任务跑通一次“视频提示词 → 动作执行 → 结果验证”。然后把这个闭环记录成一套标准流程录视频、补标签、跑模型、看输出、判断失败、调整提示。再往上一层你需要把这个闭环自动化。每次模型输出失败都要把失败样例加回评估集用于判断模型版本是否倒退。每次新增任务都要先跑现有模型再用记录下来的失败数据决定是否需要微调。这个过程很像大模型项目的 prompt 评测和回归测试。没有这套闭环“视频即提示词”就只是一次性演示不具备长期生产力。复盘时最值得问的三个问题模型是否真的理解了任务意图它在哪些分布外场景下会失败我们的提示视频和评估标准是否足够清晰这三个问题前一个决定模型能力边界后两个决定你能不能持续迭代。说到底Skild S1 这类机器人基础模型给出的是一条新路径你可以用视频这样丰富的信息去指认任务让机器人自己把“看到什么、该做什么、怎么做”连起来。它不是把控制问题消解掉而是把问题从“手写规则”推到了“数据、边界和验证”这一层。真正能在项目里跑出来的团队不是那些最快让机器人“看视频照做”的团队而是最早把提示视频、安全边界和失败反馈建设成闭环的团队。下次你再拿到一段提示视频可以先不急着让模型跑先想一想如果它失败了我能不能从日志里判断是模型的问题还是任务表达的问题。想清楚这一步视频提示词才真正成了你工作流里的一个可靠工具。