如果你最近在关注机器人学习和具身智能应该会注意到 “Skild S1” 这类机器人基础模型。它最值得琢磨的点不是又增加了一个更大的神经网络而是把视频当成了提示词——过去给机器人下达任务靠代码、按钮或者文本指令现在一段示范视频本身就能成为描述任务和引导行为的输入。这个思路把“机器人学习”拉近到大模型时代不用再为每个新技能手工设计奖励函数也不需要写一整套状态机视频即提示词相当于把人类的动作示范直接变成了可被模型读取的任务描述。这篇内容主要面向三类人想评估机器人基础模型是否值得接入的研究者、已经跑过模仿学习或强化学习但觉得数据成本太高的开发者以及想搞清楚“视频提示词”和普通提示词工程有什么区别的技术负责人。我会按实际落地顺序拆解概念、环境、流程、参数、边界、排查。先说结论Skild S1 这类方案的核心价值在于降低任务指定的成本但它不是万能遥控器对视频样本质量、运行环境和资源占用都有要求。1. 先搞清楚 Skild S1 这类模型真正改变了什么1.1 从“写代码控制机器人”到“用视频描述任务”传统机器人控制链路大致是这样的先定义任务再写状态机、运动规划、轨迹生成或者设计一个强化学习的奖励函数。开发者要处理“任务描述”和“动作实现”之间的巨大鸿沟。比如让机械臂把方块从左侧推到右侧常规做法是定义坐标点、规划路径、设置碰撞检测、判断结束条件。机器人基础模型的做法不一样。它把“任务描述”这件事交给模型开发者只需要提供一段视频或者一段视频加一句文本指令。模型自己在视频里提取目标、动作顺序、交互对象和成功条件然后输出机器人可执行的动作。Skild S1 被关注核心就在这里它把视频当作一个可被模型理解的任务提示词。这个改变的实际价值是什么最直接的是降低新任务的上手成本。以前每个新技能都要重新写逻辑、调参数、设计奖励现在只要有一份合格的示范视频就能让模型具备执行同类任务的基础能力。尤其是面对“拿左边杯子放到右边托盘”“把红色积木叠到蓝色积木上”这类变化多、规则繁、又很难用一句话讲清楚的任务视频比文本描述准确得多。1.2 为什么“视频即提示词”也是一种提示词工程做 AI 应用的人都熟悉提示词工程。文本提示词是给大模型描述意图画质和风格类模型靠提示词控制生成内容。现在 Skild S1 这类机器人基础模型把视频也变成提示词本质上是把“多模态提示词”的范围扩大了。视频提示词和文本提示词有一点本质区别文本提示词是“抽象描述”视频提示词是“具象示范”。文本写“把杯子放到托盘里”会出现无数种理解比如杯子怎么拿、托盘在哪里、放哪个位置。视频示范则把这些细节都包含在画面里模型需要做的不是理解抽象概念而是对齐示范中的视觉特征、操作顺序和时机。所以视频即提示词不是在传统提示词工程旁边加了一个新文件而是把提示词从“语义描述”升级成“过程示范”。对使用者来说最大的变化是判断输入好坏的标准变了。文本提示词看语义是否清晰视频提示词看画面是否稳定、动作是否完整、场景是否一致、视角是否可读。当然文本仍然有不可替代的作用。实际使用中视频负责示范动作文本负责补充约束条件比如“不要碰到旁边的杯子”“完成后要在原地停两秒”。这更接近提示词工程里的“多模态提示词组合”视频给出主体文本给出限定。后面我讲实操流程时会专门聊怎么把视频和文本绑定。1.3 这件事适合谁不适合谁我的判断是Skild S1 这类机器人基础模型最适合两类场景。第一类是任务变体多、但单任务示范成本可控的机器人应用。比如服务机器人、实验室机械臂、物流分拣设备任务经常在物体类别、摆放位置、目标容器上发生变化。用视频提示词可以快速换任务不用每次都改代码。第二类是科研验证和 Demo。特别是做具身智能、机器人学习、多模态模型结合研究的团队需要快速验证一个新任务能不能被模型理解视频提示词比重新训练模型快得多。不适合的场景也有。高精度工业生产、需要严格力控和安全认证的制造环节目前不建议依赖一个大模型的视频推理结果作为唯一控制来源。模型可能有不错的泛化能力但工业级控制更看重确定性、可审计性和重复精度这些恰恰不是这类方案目前最强的点。如果只是尝鲜学习那没有太多限制默认理念、最小样例跑通即可。2. 落地前要备好的环境仿真器、算力、视频样本和依赖检查2.1 典型软硬件组合Skild S1 这类模型的具体运行要求应当以官方仓库和文档为准。我这里给的不是官方数字而是从“机器人基础模型项目”常见实践里整理出来的通用参考适合你在准备环境时提前排坑。级别硬件方向软件方向建议用途入门验证10GB 以上显存的 GPUCPU 内存 16GB 以上使用仿真环境不接真实机械臂跑通单条视频提示词、看输出动作进阶实验24GB 以上显存内存 32GB 以上仿真环境 视觉模型依赖库微调、批量数据、多任务验证生产评估按实际任务配置多卡或服务器仿真环境 真机接口 日志服务长时间运行、真实环境测试如果本地显存不够可以考虑云 GPU 实例。我的经验是第一次跑不要直接上最大规格先用小视频、小上下文长度确认流程能通再逐步增加资源。很多项目卡住的点不是模型跑不动而是视频解码依赖、仿真器版本、Python 环境冲突。2.2 视频样本怎么准备才算合格视频即提示词视频就是输入质量的天花板。视频越乱后面的所有环节越难排查。准备视频样本时我一般按这几个标准来检查画面稳定拍摄视角不要频繁切换最好固定机位或者缓慢移动。动作完整示范要从任务开始前拍到任务结束不能只拍了中段。目标可见被操作物体、目标位置、机械臂末端都要清晰可见。环境单一背景、光照尽量保持一致避免模型把背景特征当成任务特征。时长适度不是越长越好长视频意味着更多计算资源和上下文限制。分辨率合适不是越高越好过高的分辨率可能对模型没有帮助反而拖慢速度。这里要特别强调动作完整比画质高清更重要。一段 480p 但动作完整的视频往往比一段 4K 只拍到一半动作的视频更有用。模型要先理解“任务从哪里开始、到哪里结束”才能正确生成动作序列。画面好看不是重点语义完整才是重点。2.3 依赖和版本检查顺序机器人基础模型项目通常涉及 Python、PyTorch 或类似深度学习框架、仿真器接口、视频处理库还有可能依赖多模态编码模型。第一次启动前我建议按这个顺序检查环境Python 版本和依赖管理方式确认是 conda、venv 还是其他环境避免和系统 Python 混在一起。深度学习框架版本确认 GPU 版本的 CUDA 是否匹配不匹配的常见表现是运行时报找不到算力设备。仿真器安装和许可证不同仿真器的安装方式差异很大有的是纯 Python 包有的需要单独图形界面。视频编解码库确保能正常读取 mp4、mov、avi 等常见格式推荐先用官方样例视频测试。模型权重路径和下载完整性权重文件如果没下完加载时可能不报错但推理结果异常。注意不要一上来就开最大并发先跑通一条视频提示词。确认输入、输出、日志都正常再考虑批量。3. 实操流程从一段示范视频到机器人执行动作3.1 第一步准备最小可用的视频提示词我建议不要一开始就去拍真实机械臂环境先用仿真环境里的一段标准任务视频做最小验证。比如一个机械臂把方块从左侧推到右侧视频时长控制在 5 到 15 秒固定视角画面里只有机械臂、方块、目标区域。准备好视频之后先单独测试视频读取。有些项目对视频编码格式敏感可能读 mp4 没问题读 mov 就报错。先用官方示例跑通再换自己的视频。3.2 第二步把视频和文本指令绑定起来视频提示词不等于完全抛弃文本。实际工程里最好的做法是“视频示范动作 文本补充约束”。文本里可以写清楚目标物体是左边那个红色方块不是右边那个蓝色方块。任务边界推到托盘中心即可不需要继续按压。禁止项不要碰倒旁边的杯子。结束条件机械臂完成任务后回到起始位置。这样写是因为视频本身虽然包含了视觉细节但缺少“意图层”的信息。一段视频可以有很多种理解方式加上文本约束之后模型更容易知道你要的是哪一个层面的任务。很多人在这一步会忽略以为视频把一切都拍清楚了结果输出动作和预期不一致问题往往就出在约束条件没有说清楚。3.3 第三步跑单条推理任务在完成环境检查后可以用类似下面的伪代码流程来做第一次推理。注意这不是官方 API只是帮助你理解整个流程中需要控制哪些环节。# 伪代码示例视频提示词推理流程 video_path demo_push_block.mp4 task_text 将红色方块推到右侧目标区完成后机械臂回到原点 # 加载视频提示词和文本指令 video_prompt load_video(video_path, frame_rate10) instruction build_instruction(task_text) # 模型推理输出动作序列 actions skill_model.infer( video_promptvideo_prompt, instructioninstruction, context_frames8, # 模型每次参考的前序帧数 max_action_len64, # 最大输出动作帧数 ) # 在仿真环境执行并记录结果 simulator.execute(actions, record_videoTrue)第一次跑通后马上看两个东西日志是否正常、仿真输出视频是否接近示范视频。不要急着调参。3.4 第四步用仿真指标验证输出机器人任务不能只看“能不能动”要看“有没有按要求完成任务”。仿真环境里我一般关注这几个指标任务成功率连续跑 20 次以上看目标是否达成。动作平稳度关节速度是否突变、末端轨迹是否抖动。碰撞和越界次数机械臂是否碰到非目标物体。任务耗时是否明显低于或高于示范视频时长。重复一致性同一视频提示词连续跑多次结果是否稳定。单次成功没有说服力同一个模型、同一个视频提示词至少要重复跑 10 到 20 次。如果成功率在 80% 以上说明这个任务基本被模型学会了如果只有 30%优先怀疑视频提示词的信息不完整而不是模型能力不够。3.5 批量跑起来命名、失败重试和日志单条任务跑通后如果想做几十条视频的批量测试不能简单写个 for 循环就结束。实际过程中最容易被忽略的是三点。第一输出文件命名。每条视频对应一组动作数据和一段仿真记录命名里必须带上任务 ID 和视频文件名否则后面根本分不清结果对应哪条输入。第二失败重试。有些任务失败不是因为模型不会做而是仿真环境初始化随机、视频解码偶尔卡顿。批量任务里最好设计一个重试机制比如每一条最多重试 3 次重试之间间隔 2 秒并记录失败原因。第三日志分级。建议每条视频都输出单独日志文件记录视频路径、文本指令、关键参数、运行时间、最终结果。这样后面调参数时可以快速对比不同配置的效果。{ task_id: task_001, video: demo_push_block.mp4, instruction: 将红色方块推到右侧目标区, result: success, retry_count: 1, duration_ms: 3420, error_log: }4. 核心参数怎么看帧率、上下文长度、批大小和动作频率4.1 参数速查表模型推理涉及的可调参数不少但真正影响任务质量和资源占用的通常集中在下面几个。以下参数名是通用命名实际项目里可能叫 context_frames、action_horizon、batch_size、fps含义类似。参数作用优先调整方向注意事项视频采样帧率决定模型每秒看到多少帧画面先 10 fps再按需提高帧率过高会显著增加计算量不一定提升效果输入分辨率决定画面细节在能识别目标前提下尽量低高分辨率不等于高准确率上下文帧数模型做决策时参考的历史帧数从 4 到 8 帧开始太短会丢失动作连续性太长会拖慢推理最大动作长度模型单次输出的动作序列长度按示范视频时长设置太短会导致任务中途停止批大小同时处理的视频任务数量先 1再逐步增大批大小越大显存占用越高随机种子控制结果可复现性固定 seed 后记录排查问题时先固定 seed4.2 参数调优顺序不要同时乱改多个参数。我建议按下面的顺序来先固定视频采样帧率和分辨率保证输入一致性。再调上下文帧数。任务动作简单就小一点动作复杂就大一点。然后看最大动作长度。如果机器人任务做到一半就停了多半是长度不够。最后才考虑批大小。批大小只影响吞吐不影响单任务质量只是用来压资源占用和速度。随机种子从一开始就固定方便对比实验。这种顺序的核心原因是输入参数决定“模型能不能看明白任务”动作长度决定“任务能不能做完”批大小只决定“能跑多快”。很多人一上来就把批大小拉满结果显存爆了反而不知道是模型问题还是资源问题。4.3 怎么判断“跑得动”和“跑得稳”跑得动是模型能启动、能输出动作、不再报错。跑得稳是连续多次执行的成功率、资源占用、耗时都维持在一个可接受范围。我常用这样的观察方式启动阶段看显存和内存是否在运行开始后快速攀升。单任务阶段看推理耗时和视频输出是否正常。多任务阶段看批大小变化后是否出现显存溢出或速度急剧下降。稳定性观察看连续跑 20 条任务是否出现前几轮正常、后几轮变慢或者失败率上升。如果前面几条正常后面突然变慢优先检查是不是输出视频、日志文件写得太频繁导致磁盘瓶颈。机器人模型任务常常伴随大量可视化记录磁盘 IO 被忽略的话很容易让整个流程越跑越慢。5. 最容易翻车的四个地方以及我的排查顺序5.1 视频输入问题格式、视角、遮挡、动作幅度视频即提示词第一类坑几乎都出在视频上。最常见的现象是模型输出完全不动或者动作明显和示范视频无关。我的排查顺序是先确认视频能被正常解码、帧数不为零再确认画面里是否存在遮挡、反光或目标物体太小最后检查动作幅度示范视频里如果动作太快模型可能只学到了“开始动作”和“结束动作”中间过程是混乱的。处理方法是把视频动作放慢增加中间状态。比如示范推方块不要一下推过去而是“移动到位—接触方块—持续推动—到目标位置—松开—返回”每一步都留出几帧稳定画面。5.2 仿真和真实环境的鸿沟仿真环境里表现很好一换真机就失败这种问题非常典型。原因通常是视觉差异和物理差异叠加。仿真里的光照、材质、摩擦力都更干净真实环境里物体表面反光、遮挡、零件公差都会影响模型判断。降低这个鸿沟的现实做法是仿真环境里增加随机光照和物体位置变化让模型见过更多变体。真机测试前先用真机采集 10 到 20 条短视频做少量微调或作为参考输入。不要指望一个纯仿真训练出来的视频提示词模型直接完美迁移到真机。5.3 资源占用突然暴涨任务跑到一半显存爆掉或者内存一直不释放常见原因有三个视频帧全部被加载进内存没有释放模型推理时的批大小和上下文帧数过大视频解码返回了异常尺寸或极大帧序列。遇到这类问题不要立刻怀疑是模型线程泄漏。先检查输入视频的帧率、分辨率和时长再看推理循环里是不是每一轮都在重新累积历史帧最后看批大小设置是否合理。5.4 动作不连贯、任务失败动作不连贯通常表现为机械臂停顿、突然抖动、只输出了前半段动作。排查顺序是看动作序列长度是否足够完成整个任务。看上下文帧数是否太少导致模型每走一步都像重新看任务。看视频提示词里示范动作是否中断比如后半段机械臂被遮挡。看文本指令里是否缺少明确的结束条件。这些排查并不复杂但很多人会直接进入调模型、加数据的路线结果浪费大量时间。事实上视频示范中的一个小中断就足以让模型误以为一个完整动作应该在那里停止。5.5 按这个顺序排查基本不跑偏我的推荐排查顺序是现象 → 输入 → 环境 → 参数 → 模型边界。先记录完整现象是报错、卡住、无输出还是输出不对再检查视频和文本输入这是最容易被绕过的一层然后检查依赖、仿真器、GPU 驱动接着检查上下文长度、动作长度、批大小等参数最后再讨论这个任务是不是模型本身不擅长。把顺序反过来很容易在模型层面找半天最后发现只是视频文件读不出来。6. 什么时候该用视频即提示词什么时候别急着上6.1 更适合用视频提示词的场景我建议优先在下面这类任务上尝试视频提示词。任务描述难以文本化比如“像这样摆放餐具”“模仿这种分拣节奏”。任务变化多、重复训练不划算比如不同物体、不同位置组合。已经有大量人工示范视频但不想为每个视频重新标注复杂状态机。需要快速验证一个任务能不能被机器人学习再做后续投入。这类场景的共同点是示范数据多任务规则复杂但允许一定程度的随机性和泛化误差。这正好是视频提示词的强项。6.2 不适合或需要谨慎的场景以下情形我建议谨慎。高精度装配、焊接、点胶等需要次毫米级精度的制造场景。对安全性有严格认证要求的场景比如涉及重型设备、医疗操作、公共空间移动。只有一段低质量视频没有其他数据支撑的任务。任务本身非常简单用传统控制就能稳定完成没必要引入大模型。另外要留意即使模型输出动作看起来很合理也不能把它当成安全验证通过。机器人运行在真实环境中仍然需要单独的急停、限位、碰撞检测和安全逻辑。视频提示词模型负责“任务理解”安全保护是另一套系统不能混在一起。6.3 和传统提示词工程如何配合最后把视频提示词和现在大家熟悉的提示词工程放在一起看。提示词工程的价值在“定义输入”机器人基础模型的价值在“理解输入并输出动作”。你仍然需要思考提示词怎么写视频该拍多长、动作要不要拆分、文本怎么补充约束、失败样例要不要也录几段。这些经验本质上还是提示词设计的经验只是对象从文本变成了视频。我建议团队在正式接入前先建一份内部“视频提示词规范”包含视频时长、分辨率、视角、动作节奏、文本模板。规范先不用追求完美能保证同一个任务由不同人录制时模型结果差异可控就够了。实际测试中这份规范会慢慢变成最有价值的资产比单纯堆算力更有用。Skild S1 和“视频即提示词”给机器人学习带来的变化不是让每个开发者都去训自己的模型而是让更多人能把“示范”直接变成“指令”。这个思路对数据利用方式的影响可能比某一个模型本身更值得长期关注。如果你正在考虑接入这类模型我个人的建议是先用小任务、小样本、固定视角跑通闭环再逐步扩大视频覆盖范围。先让单条视频提示词稳定成功再考虑批量任务和真实环境迁移。很多问题看起来像模型能力不行实际上只是视频提示词没说清楚。