企业官网建设流程全解析

这两年我写过不少关于 AI Agent 的东西，也看过很多机器人公司的发布会。发布会看多了，人会免疫：机器人在台上翻跟头、煎牛排、给你倒水，底下掌声雷动，然后呢？然后那台机器人就回到展柜里，等下一次通电。

判定一家机器人公司是不是认真做事，我一直有个自己的土办法：不看它跑得多稳，看它敢不敢把接口开放出来，开放之后有没有人真的往上面写东西。

所以当我发现启元机器人（PRIMEBOT）把自家的 SDK、工具链，还有一批"机器人技能"（Skills）完整开源在了 AtomGit 上，并且真的搭了一个技能商店的时候，我就决定把它拆开看个仔细——一个"机器人 App"到底长什么样？它是怎么被触发、怎么被约束、又是怎么安全地跑在一台真机器人上的？

先交代几个背景数据。启元 Q1 和 T1 在今年 9 月正式发售，定价19999 元起（来源：AtomGit 官方公告）。Q1 是人形，身高约 88 厘米、重约 15 公斤，官方媒体探店报道的说法是"可装进背包，说走就走"；T1 更有意思，它可以在轮足人形与四足形态之间自主切换——室内用轮式，高度刚好适配人类的生活设施，户外切四足，应对草地和坑洼。制造端的细节也有点意思：核心线束做了超 100 万次折叠测试，头部舵机超 10 万次、关节模组超 6 万次冲击测试，按手机 3C 认证标准来测——这是把机器人当耐用品做，而不是当展品做。

换句话说，两万块的、形态可变的个人机器人，加上一个完全开放的技能生态——这件事本身就是故事。

一、先看底层：SDK 是"操作系统"，技能是"App"

聊技能之前，得先花几分钟讲清楚地基，不然后面全是空中楼阁。

启元开源的 PrimeBot SDK 基于ROS2 Humble + FastDDS，采用去中心化架构：机器人全部能力统一暴露为 ROS2 的 topic / service 接口，你的程序跑在 PC、运控板还是大脑板上都无所谓，接口是透明的。

这套接口按层组织，各层的分工一目了然：

• 运控（mc）——动作状态机、预设动作、速度控制、输入源仲裁、自定义关节控制；
• 交互（interaction）——语音合成（TTS）、语音识别（ASR）、表情与视频播放；
• 硬件抽象（hal）——相机、音频设备、触摸传感、电源管理（BMS）、灯带控制；
• 智能体（agent）——AI Agent 层的识别结果订阅。

SDK 仓库里还附带了 C++ 和 Python 双语言的场景化例程，光 C++ 侧就有 18 个场景，光看文件名就是一部"机器人能力说明书"：get_jpg（抓一帧图像）、get_video_stream（开视频流）、get_asr_result（拿语音识别结果）、play_emotion（播表情）、play_lights（控灯带）、set_mc_action（切动作状态）、mc_locomotion_velocity（下发速度）、joint_control（关节控制）、upper_body_control（上半身控制）、get_bms_state（读电量）、get_touch_state（读触摸）、record_audio（录音）、play_audio_from_pc/play_audio_from_robot（两端放音频）、volume_control（调音量）、get_audio_device_list（列音频设备）、shutdown_task（停任务）、get_bms_state……

这个分层，熟悉 Android 的人一眼就能对上：ROS2 是内核，SDK 是系统框架，hal 是 HAL 层。那技能（Skill）是什么？

技能 = 一段能完成完整任务的业务逻辑 + 一份机器可读的声明式描述，打包成标准格式，可以安装、可以分发。

一句话：机器人世界的 App。

二、20 种运动模式：机器人是怎么"换姿势"的

写到这里，我想暂停拆包，先回答一个很多人好奇但从没机会问的问题：机器人的"站起来"“坐下”“走路”，在软件层面到底是个什么东西？

答案藏在 SDK 的接口文档里，而且比我想象的有意思得多。

机器人本体的每一种"姿势"，对应运动控制模块里的一个McAction（动作状态）。官方文档给出的 Q1 机型枚举表里，一共列了20 种，我把它按语义归归类：

• 基础姿态：被动模式（PASSIVE_DEFAULT）、阻尼模式（DAMPING_DEFAULT）、位控站立（BIPED_STAND_DEFAULT）、折叠收储（STORE_DEFAULT）、躺姿、躺下-俯卧、躺下-仰躺；
• 移动：走跑（BIPED_WALK_RUN）、轻柔步态（室内）、越障模式（室外）、超能模式/跑步模式；
• 生活场景：坐下、入座、离座、站起；
• 高级控制：全身动作控制（BIPED_WHOLE_BODY_CTRL）、上肢控制（BIPED_CUSTOM_UPPER）；
• 模仿动作家族：MIMIC、模仿动作-灵创（MIMIC_LINKCRAFT）、模仿动作-开源（MIMIC_OPENSOURCE）。
  

说白了，机器人的姿态不是一连串随意的关节角度，而是一张预先定义好的状态机。开发者做的每一次"让机器人坐下"，本质上都是向状态机发起一次切换请求。

而这张状态机最工程化的地方在于：切换不是瞬移，是一段有完整反馈闭环的异步过程。文档写得非常直白：下发切换请求后，开发者需要循环高频探测，只有当状态从200 (TRANSITION)变成100 (RUNNING)时，才能进入下一步业务逻辑。切换失败还有一整张业务错误码表——“未定义从当前 action 切换到目标 action 的规则”（-1001）、“机器人姿态不具备切换目标 action 的能力”（-1004）、“请求过于频繁（500ms 一次）”（-10001）……

看到这张错误码表的时候我是真乐了。这不就是我们后端天天打交道的异步状态机吗？机器人只是把"订单状态流转"换成了"腿部关节的物理转移"。做过分布式系统的人应该能秒懂为什么要这么设计：从"坐着"直接切"跑步"是物理上不允许的，状态机必须显式定义合法的转移路径，把硬件的安全边界编码成软件规则。

三、谁说了算：一套基于优先级的"交通指挥系统"

第二节留了一个尾巴：一台机器人身上，同时存在着遥控器、语音交互、手机 App、你写的技能好几个"控制大脑"，它们同时想动机器人怎么办？

SDK 给出的答案相当漂亮——官方文档管它叫"一套基于优先级的交通指挥系统"：通过对实时指令流的唯一锁定与超时脱锁监控，确保机器人在多端并发操作下的运动稳定与物理安全。优先级表是公开的：

内置输入源的优先级也都预设好了：遥控器rc、导航规划pnc、语音手势等交互指令interaction都是 80 级，VR 远程操控vr是 70 级，而且每个输入源都有超时自动脱锁时间（默认 1000ms）——你抢到控制权之后如果断了线，1 秒后控制权自动释放，机器人不会被一个死掉的进程"卡住"。

carry-clothes 技能的 manifest 里就声明了{"name": "carry_clothes_skill", "priority": 30, "timeout": 1000}——它给自己报了个 30 级，落在"SDK 二次开发"档位，比语音交互低、比调试源高。抢到控制权之前，它还会先调GetCurrentInputSource校验一下"控制权是否真的到手"，拿到手才敢迈腿。

这个设计值得每一个做机器人开发的人仔细品味：安全不是"大家自觉别同时发指令"，而是架构层面保证任何时刻只有一个大脑在开车，而且行车记录仪一直开着。说白了，这套机制其实是理解所有机器人二次开发的钥匙——你写的技能再花哨，也只是这张优先级表上的一个数字。

四、机器人的"肢体语言"：招手是 3001，碰拳是 3003

聊完宏观的状态机，说点轻松但同样有信息量的：机器人的预设动作和表情。

SDK 里有一张预设动作编号表，我第一次看到的时候忍不住从头读到尾——这就是一部机器人的"肢体语言字典"：

调用就是一次服务请求：SetMcPresetMotion，带上动作编号和控制区域，还能选"是否打断前一个动作"。“让机器人跟你碰个拳”，在代码层面就是一个数字 3003。

表情是另一套体系（PlayEmotion）：Q1 的脸是一块屏幕，表情是内置的表情动画，按索引触发播放，还支持联动视频。配合灯带控制服务——灯效同样是一张枚举表：彩虹流光（LED_RAINBOW）、绿色流水（LED_GREEN_FLOW）、白色呼吸（LED_WHITE_BREATH）、开机灯效、充电灯效、故障灯效……商店里那个"摸头开心"技能的"开心表情 + 天蓝呼吸灯"，拆开看就是PlayEmotion+ 灯带服务 + 头部触摸事件的三重奏。

这套编号表不是纸面文章——在官方桌面工具 PrimeConsole 的 Skill 验证页里，你能亲眼看到它被调用：导入技能后仿真播放"开心"动作（对应编号 3005），左侧面板把这个技能用到的原子能力列得清清楚楚——语音合成、预设动作、表情播放、LED 灯效，和本节的编号表一一对应：

还有一条值得单独划出来：前面提到的 Motion 接口（SetMcMotion），专门用于播放基于神经网络推理模型（.onnx）或外部特征文件记录的动作序列。这句话信息量很大——机器人的新动作可以是一段 ONNX 模型的推理输出，也就是说**"动作"可以是数据而不是代码**，可以像皮肤一样被制作、分发、安装。为技能生态里"动作商店"的可能性，接口层早就留好了口子。

五、拆包：我盯着一台机器人"宪法"看了很久

铺垫完底层，回到主菜。启元官方和社区在 AtomGit 上开源了 5 个技能，我拿最复杂的那个——“把衣服拿到洗衣机旁”（carry-clothes）——做了个解剖标本。

它的目录结构长这样：

carry-clothes/ ├── manifest.json # 技能的"身份证 + 使用条款" ├── SKILL.md # 给大模型看的说明书 ├── main.py # 入口 ├── src/ # 任务状态机、视觉、机器人接口封装 ├── tools/teach_record.py # 示教录制工具 ├── config/task_config.yaml └── assets/icon.png # 商店展示用图标

打包后是一个format: rpk的技能包（当前格式版本 1.0）——你可以把它理解成机器人世界的.apk。这个包在官方桌面工具 PrimeConsole 里导入后长这样，源码视图里能直接看到技能的元数据、入口文件和它声明的原子能力：

真正让我停下鼠标的是manifest.json。这不是一个随手写的配置文件，它更像这个技能的宪法——每一份权利、每一道约束，都白纸黑字写在那里。我挑几段原文感受一下。

它声明自己是谁、跑在哪。版本 2.1.0，标签"家务、取放、搬运、人形交互"，运行时要求 Python ≥ 3.10，依赖 rclpy 和 aimdk_msgs，启动前自动 source ROS2 和 SDK 环境。target区块写着适用机型["T1", "T1-Pro"]，forms里同时包含humanoid和quadruped——同一个技能包，设计上就是跨机型、跨形态的，这份野心写在格式里，不是发布会 PPT 里。网络拓扑也写得清清楚楚：ROS2 Humble 中间件、10.1.1.0/24开发网段、运控板10.1.1.100、大脑板10.1.1.101。

它声明"我响应哪句话"。这是触发系统的核心，原文长这样：

"triggers":{"intents":["carry_clothes_to_washer"],"utterances":["把衣服拿到洗衣机旁","帮我把衣服放洗衣机边上","把这件衣服拿去洗衣机","衣服送到洗衣机那儿","把衣服拿过去放洗衣机旁边"],"slots":{"object":{"default":"衣服","required":false},"destination":{"default":"洗衣机","required":false}}}

五条触发语句、一个意图、两个槽位。注意required: false——用户没说清楚物体或目的地时，技能会先追问，而不是瞎猜。

它声明要动用哪些"器官"。capabilities区块把技能要用到的 12 个机器人接口逐条列出，每个都标注权限级别（readonly只读 /normal可控）和调用参数。随便摘两条：

{"name":"/aima/mc/locomotion/velocity","level":"normal","reason":"轮足滚动速度控制（无导航接口，靠视觉伺服闭环）","params":{"minRateHz":50,"maxForward":0.35,"maxYaw":0.5}}{"name":"/aima/hal/camera/CaptureJpegImage","level":"readonly","reason":"取头部双目单帧用于检测","params":{"cameraId":"head_stereo_left"}}

我第一次看到这里的时候，脑子里浮现的就是 Android 的权限弹窗：App 要什么权限、拿来干什么、参数边界是多少，摊开来讲，用户看得见。连调用频率都管上了——TTS 播报声明了minIntervalMs: 500，运动指令声明了 50Hz 的下发频率。

它还诚实地声明自己缺什么。selfProvided区块明明白白写着——SDK 不提供目标检测，不提供 SLAM/导航，“走到目标前需自建视觉伺服闭环”，甚至写明了缺了会怎样：“无法定位用户与洗衣机，任务在第一步视觉伺服即中止”。这在其他平台的技能模板里几乎见不到，后面我会说为什么这段话让我对这个生态产生了好感。

最后，它声明安全底线。safety区块是一整段可执行的约束：前进速度 ≤ 0.35 m/s、转向 ≤ 0.5 rad/s、电量低于 20% 拒绝任务（抱持衣物时地板抬到 25%）、急停使能、执行前必须设备端二次确认、关节限位钳制、任何一步失败就平滑回到站姿，连注意事项都写了三条——“SDK 无夹爪接口：接物为双臂合拢托住，非夹持，勿假设能抓紧”。

作为一个写惯了 Agent 的代码农民工，我看到SKILL.md这个文件时的反应是会心一笑——一份带 frontmatter 的 Markdown，写清楚"什么情况下触发我、我会怎么做"。这不就是给机器人侧大模型看的 system prompt 吗？同一个技能，一份 manifest 给运行时读，一份 SKILL.md 给模型读，人和机器各拿一份说明书。这个双文件设计，比很多只顾着跑起来的机器人项目想得远。

六、感官清单：把接口文档翻译成人话

拆包中途再插一段"番外"，因为这些东西太好看了：SDK 的硬件抽象层（hal）完整定义了机器人的感官系统，我把接口文档翻译一下，大家感受一下一台 Q1 的"五感"都是什么规格。

听觉。语音链路相当完整：语音识别结果是话题（topic）形式持续上报的，你的程序订阅一下就能拿到"用户说了什么"；语音合成是服务（service）调用，一句话下去机器人开口说话；还有 TCP 直连的音频播放和录制通道、音频文件播放服务、音量与静音控制、音频设备列表查询——从"听见"到"说出"再到"调音量"，每个环节都是独立接口。

视觉。Q1 的头部有一颗交互相机（camera_id: head_monocular_centra），SDK 提供两种取流方式：CaptureJpegImage服务一次性抓取当前帧的 JPEG 图像（返回相机 ID、分辨率、帧率、曝光值等完整元数据），或者订阅视频流话题持续拿帧，视频流还支持 RTSP。顺带一提，从 T1 技能包的 manifest 看，T1 用的是头部双目相机（head_stereo_left/head_stereo_right）——不同机型的传感器配置不一样，这大概也是 manifest 要声明cameraId参数的原因。

触觉。头部有一路触摸传感器（Q 系列sensor_id: 1就是头部），检测单击等触摸事件，而且是触发式上报——只在状态变化时发消息，没被摸的时候安安静静。就是前面说的，carry-clothes 里用户"摸摸头表示确认"的物理基础。

体感。电源管理话题持续上报电池状态（BMS），技能可以据此做安全守卫——电量低于 20% 拒绝出发，抱着重物时地板抬高到 25%。

表达。加上前面说的屏幕表情和 20 种灯语，这台机器人的"输出系统"其实比很多同类丰富：它会说话、会做表情、会发光、会做 9 种以上的预设肢体动作。

把这份清单和 18 个官方例程对着看，你会发现一件事：SDK 把机器人的每一感每一觉都做成了平等的、可组合的接口。技能生态里那些看起来"有性格"的技能（摸头开心、人格皮肤、点歌台），本质上都是这份接口菜单的不同组合方式。菜单足够丰富，菜才能足够多。

七、语音即入口：机器人版的"语音唤醒 App"

传统机器人演示里的语音，多数只是个装饰。但 rpk 把语音做成了一等公民的触发机制——manifest 的triggers区块（上一节贴过原文）把意图、触发语句、槽位声明得一清二楚，触发逻辑从代码里抽出来，交给平台统一匹配，开发者只声明"我响应哪句话"。

再看另一个技能"滴滴打车"（didi_taxi_agent）的交互设计：说"元仔，帮我打车"启动，语音询问起点、终点并复述，只有听到"确认叫车"才提交真实订单；说"取消""不叫了"直接退出。README 里还专门写了一句工程细节：API 密钥不打入技能包内，只读机器人本机的密钥文件。

"高危动作需二次确认"在这套体系里不是道德呼吁，是 manifest 里的一个字段（requireOnDeviceConfirm: true，确认文案也要写明：“即将执行：走到您面前 → 抬臂接衣服 → 送到洗衣机旁放下。确认开始吗？”）。把安全从文档搬进 schema，这是工程师的浪漫。

八、10 步流水线：它到底怎么"跑"在真机上

回到 carry-clothes。它的 manifest 里定义了 10 个执行阶段，每一步绑定真实接口和独立超时：

① 响应指令（TTS 播报 + 查电量） 超时 5s ② 切换双足直立（SetMcAction） 超时 35s ③ 走到用户跟前（轮足滚动 + 视觉伺服） 超时 60s ④ 抬臂等待接衣服（6 关节插值控制） 超时 15s ⑤ 等待接衣服（waitForUser） 超时 60s ⑥ 合臂抱住衣物 超时 10s ⑦ 寻找洗衣机（转圈扫描 + 相机取帧） 超时 40s ⑧ 前往洗衣机（双臂维持环抱位） 超时 60s ⑨ 放下衣服 超时 20s ⑩ 任务完成（TTS 收尾） 超时 5s

这份流水线最打动我的，反而是它的"不装"。

carry-clothes 的 README 里有一段少见的坦白：v1.0 版本用的那些接口——导航、夹爪、语音识别、末端力传感——“是凭空假设的，SDK 里并不存在，已全部废弃”。v2.1 老老实实按真实接口重写：没有夹爪，就用双臂合拢"抱"；没有导航和语义地图，就用"转圈扫描 + 视觉搜索"；SDK 没有 ASR 接口，用户确认就改用头部触摸事件——摸摸头表示"可以了"。

安全设计同样落到了实处：移动默认用"轮足滚动"（双轮静音）而非步行步态，更稳也更安全；每个阶段独立超时，任何一步失败，任务中止，机器人平滑回到站姿。

我们看惯了机器人演示里"看起来什么都会"的剪辑艺术，也看惯了开源项目里"理论上支持"的 README 文学。一个新生态最珍贵的品质，是诚实。能力边界写在 manifest 里，做不到的事情不假装做得到——这种工程文化，比炫技更能让我相信这个生态能长起来。

九、逛店：17 个技能的众生相

光拆一个包还不够，我把技能商店整个逛了一遍。

PrimeHub 的 Skill 仓库目前显示"12 个已发布技能（共 17 个）"，下载量最高的"视频电话"有一百多次下载。数字不大——但请记住，这是个上线才一个多月的商店。

有意思的是逛店时发现的两种气质。

一半技能在让机器人"干活"：视频电话（机器人摄像头 ↔ 电脑摄像头的双向通话）、拿衣服、语音打车、天气预报（Open-Meteo 数据 + TTS 播报，免 API Key）。商店还给它们打上了规范的场景标签——客厅、卧室、陪伴、老人照护，以及能力标签——视觉、听力、动作、表情、规划、语言。看到"老人照护"这个标签的时候我停了一下：一个上市一个多月的机器人技能商店，货架上已经有人在做照护场景了。

另一半技能在让机器人"有性格"：“摸头开心”——摸摸 Q1 的头，它会开心，随机撒娇台词 + 开心表情 + 天蓝呼吸灯，偶尔挥挥手；“人格皮肤·节日模式 / 日常模式”——一份配置切换台词、动作、表情和灯效，等于给机器人换"性格皮肤"；“点歌台”——说出歌名，机器人联网搜歌下载，自动做节拍分析，卡点起自由随机舞。

还有几个技能暴露了社区开发者正在把机器人往深处玩：PrimeBuddy 是一个绕过原厂对话 Agent 的自定义对话框架，用户可以自己定制 ASR、LLM 和 TTS 模型，支持方言接入和自训练模型接入——这几乎是明牌邀请大家给机器人换"大脑"；还有基于 WorkBuddy 的 T1 连接器和机器人绘本创作（用机器人完成显示、朗读和动作）。

把这两类技能放在一起看，我发现了一个值得玩味的事实：工具型技能让机器人有用，性格型技能让机器人被喜欢。早期手机 App 生态也是这个分布——一半人在做手电筒和计算器，另一半人在做主题美化。哪个方向会跑出来，现在没人知道，但货架已经开始反映人的真实需求了。

而从开发者的角度看，这批技能全是开源的：AtomGit @primebot 组织目前 16 个项目、163 个 Star、800+ 次下载。想学怎么写技能，最好的方式就是把天气技能（最小的那个，核心就一个 Python 文件）克隆下来改一改。

顺带说一句，这套生态面向的不只是程序员。官方的《Q仔功能体验指南》（Q仔是 Q1 的昵称）把普通用户的体验流程拆成了 7 个模块：开箱体验、外观与手感、语音交互、运动控制、APP 体验、玩法与内容、安全感受——其中"玩法与内容"一节里列的东西相当超出预期：图形编程、手把手教动作、AI 拍照、互动游戏、甚至"独处行为"（机器人自己待着的时候会干点什么）。“手把手教动作"这一条尤其值得注意，它对应的就是 SDK 里那套示教录制接口——用户拖动机器人的手臂走一遍动作，机器人记下来，这本质上就是没有代码的动作创作。消费端"手把手教”，开发端"示教录制接口"，两边在底层是同一件事。

而开发者社区论坛的现状，也真实记录着生态"刚开机"的样子：论坛目前只有十几个帖子，有开发者分享"用官方文档先跑通仿真环境，做了一个挥手的 hello world"，也有开发者认真提问"T1 的麦克风通道分配和 SDK 文档对不上"“文档里说的两个端口连不通”。这些带着毛边的真实反馈，恰恰是生态活着的证据——文档和实机的差距被公开讨论，比文档完美无缺却无人问津，健康得多。

十、分发与工具链：从"写出来"到"装进去"

有了包，还得有货架和工具箱。启元的这套体系目前有三层：

• AtomGit @primebot 开源组织：所有技能源码的托管地，官方的说法是"技能看得到、下得来、装得上"，可以直接克隆改造；
• PrimeHub 技能中心：机器人技能的统一商店，注册后管理个人主页、仓库和机器人，技能按任务、兼容性、分类、标签检索，还能按机器人型号筛选；
• AtomCode 工具链：官方 README 写明，社区技能统一托管于 AtomGit，并可在 AtomCode 插件市场"一键安装"。

再配上打包命令（python3 pack/build.py生成 rpk）和官方桌面工具PrimeConsole——Windows / macOS（Apple 芯片、Intel 芯片）/ Linux 三端都有安装包，负责连接、控制、调试、日志、实时视频流监控、动作与表情测试，还有一个管理模型和算力的 AI 中心——从"写一个技能"到"装进机器人"的链路是完整的。

"装进去"这一步：PrimeConsole 的 Skill 验证页里，导入一个技能有三种渠道——本地 .rpk 包、PrimeHub 商店浏览安装、机器人侧已装技能同步，下图商店列表里的 17 个已发布技能都带真实下载量。分发渠道在工具层面是真实打通的，不是 PPT 功能：

值得一提的是调试体验的设计：SDK 文档里专门写了CLI 调试指南——不写一行代码，用ros2 service call命令行就能直接点对点调通任何接口，文档甚至细致到告诉你"字符串建议外层单引、内层双引"这种填空级别的规范。从命令行验证一个想法，再到 Python/C++ 里写成技能，这个渐进路径对新手非常友好。

十一、一个开发者的上手路线图（文档版）

拆完包、逛完店，我顺手把"如果我想发布一个自己的技能"的完整路径从官方文档里捋了出来。先声明：我没碰真机，这一节是纯文档整理，供想上手的同学参考，细节以官方文档为准。

第一步，克隆一个现成技能当模板。从 AtomGit 把 weather_forecast（最简）或 carry-clothes（最全）拉下来，读懂它的 manifest 和 main.py 的任务状态机。

第二步，改触发，写逻辑。换掉triggers.utterances，改写任务阶段（stages），在capabilities里如实声明你要用的接口——记住那个 12 项权限的先例，声明制不是形式，是技能和平台之间的契约。

第三步，无真机预演。carry-clothes 提供了两级"安全阀"：--dry-run只打印 10 步计划不动机器人，--sim跑仿真全流程（官方说约 7 秒跑完）。manifest 里甚至内置了仿真场景配置（home_laundry场景、MockPrimeBot 后端、可加速 4 倍回放）。没有机器人也能把任务逻辑调通，这个设计对个人开发者极其友好。

第四步，打包上架。python3 pack/build.py生成 rpk，发布到 PrimeHub，等待被某台 Q1/T1"一键安装"。

第五步（真机才需要），进开发者模式。carry-clothes 的 README 里记录了真机准备的全过程：SSH 进机器人切开发者模式、开发 PC 有线网卡配到10.1.1.99/24、调大内核缓冲区（否则高频 topic 丢帧）、colcon 编译 SDK……每一步都是标准的 ROS2 开发动作，如果你玩过 ROS2，这套流程不会有陌生感。

顺带交代这些资料从哪拿：开发者社区的"开发"页里，Q1/T1 的 ROS2 SDK（v1.0.0.0）、URDF 仿真描述包、交叉编译工具链、甚至 DIY 外壳的 STEP 模型文件，都是挂好版本号直达下载的——路线图上每一步要用的东西，官方都提前放好了：

这条路线图最让我在意的是第三步。“无真机开发"意味着参与门槛从"拥有一台两万块的机器人"降到了"有一台电脑”——这才是生态能不能滚起来的关键变量。

十二、放进坐标系：这到底是一件多大的事？

最后我想把这件事放进几个坐标系里量一量。

和手机生态比。App Store 2008 年上线时的三件套：声明式的应用清单（Info.plist）、审核与权限机制、统一分发渠道。对照本文拆开的东西：rpk manifest、安全约束与权限声明、PrimeHub/AtomCode 分发——范式是同一个。我做了个逐项对照：

最后一行是机器人独有的，也是最有意思的：手机 App 崩了顶多闪退，机器人技能出 bug 可能撞到人。安全在这个生态里不是"最佳实践"，而是格式本身的一部分——manifest 里没有 safety 区块的技能，理论上根本不该被上架。这既是复杂度，也是护城河。

和既有机器人生态比。ROS 生态搞了十几年，有成千上万个功能包，但它本质上是开发者互赠的礼物——你得会编译、会踩坑才能用。而"技能包 + 商店 + 一键安装"第一次把"普通用户给机器人装能力"变成了可能。从功能包到技能包，差的那一步就是消费级生态的入场券。

从经济学角度比。19999 元的定价放在人形机器人里已经杀到了"个人极客可承受"的区间，而开放生态的逻辑其实是明牌：硬件毛利换生态规模。机器人本体越便宜、越普及，技能生态的边际成本越低、网络效应越强——这笔账，手机厂商二十年前就算过了。

如果你读到这里，大概能对号入座三种角色之一：

• 想尝鲜的用户：去 PrimeHub 装个"视频电话"或"摸头开心"，十分钟感受一下"给机器人装软件"是什么体验；
• 想入场的开发者：克隆 weather_forecast，改触发语句和 TTS 文案，跑一遍--sim，一个下午就能拥有第一个上货架的技能；
• 想找机会的团队：盯着 manifest 的 selfProvided 区块做通用能力——视觉检测、导航伺服，这些平台明牌缺口就是第一批生态卡位。

当然，冷静地说，现在的 Skills 生态还非常早期，挑战也明摆着：技能数量还只有十几个；视觉检测、导航这些关键能力要开发者自建；安全责任在平台、技能作者、用户之间怎么划分，还需要真实的案例来打磨；manifest 里已经出现的minSdk、minFirmware字段提醒我们，跨版本兼容会很快成为生态必须解决的问题。

但方向我认为是对的。声明式的技能包格式、语音意图触发、权限声明制、内置安全约束、跨机型适配、商店化分发、配套的调试工具链——智能手机生态的成熟范式，正在机器人领域被系统性复刻。

对开发者来说，现在反而是最好的入场时机：平台的能力缺口就是生态红利。manifest 的 selfProvided 区块已经把缺口写得明明白白——视觉检测、导航伺服，谁先把这些做成通用能力，谁的技能就会被更多机器人装上。两万块的本体、开源的 SDK、刚刚起步的货架，剩下的就是人和时间了。

如果你也想给机器人"写个 App"，可以从 weather_forecast 开始克隆改造，或者直接去开发者社区翻文档：

👉 **启元机器人开发者社区：https://dev.primebot.com/**（开发文档、SDK 下载、PrimeHub 技能中心入口都在这里）