企业官网建设流程全解析

如果“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 最小跑通流程：先验证输入、输出和日志

第一步是准备提示视频。视频要尽量符合“成功示范”的标准：视角清晰、光照正常、动作完整、一次完成。不需要太长，三到五秒一般够用。过长的视频反而容易引入冗余动作，模型不知道你的核心意图是哪一段。

第二步是对齐观测空间。机械臂部署地点的相机位置，要和视频里的视角协调。如果提示视频是俯拍，现场相机却装在侧面，模型在理解空间关系时会遇到很大困难。尽可能保持“视频视角近似于推理时的观测视角”。

第三步，定义动作输出格式。实际抓取时，你需要让模型输出什么？是末端目标点的三维坐标、还是完整轨迹、还是关节角度序列？不同输出决定后续不同的控制方式。建议从“末端位姿序列 + 夹爪状态”开始试，因为它在运动学层面最容易检查。

最后，加一个日志记录。记录输入的提示视频、观测图像、模型输出的动作序列、实际执行结果。没有日志，后续排查会非常痛苦。

这里可以给一个通用的任务描述示例结构，不代表某个模型的真实 API：

task = { "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 这类机器人基础模型给出的是一条新路径：你可以用视频这样丰富的信息去指认任务，让机器人自己把“看到什么、该做什么、怎么做”连起来。它不是把控制问题消解掉，而是把问题从“手写规则”推到了“数据、边界和验证”这一层。真正能在项目里跑出来的团队，不是那些最快让机器人“看视频照做”的团队，而是最早把提示视频、安全边界和失败反馈建设成闭环的团队。下次你再拿到一段提示视频，可以先不急着让模型跑，先想一想：如果它失败了，我能不能从日志里判断是模型的问题，还是任务表达的问题。想清楚这一步，视频提示词才真正成了你工作流里的一个可靠工具。