主题
型号库
型号库是指令库、产品共同依赖的底层资源:所有 AIoT 硬件必须先在这里登记一个「型号」,后续才能创建 指令集 与 产品。
型号 ↔ 应用是 1 : N 关系:一个型号可以被多个应用绑定复用;一个应用只能绑定一个型号。
1. 什么是型号
型号(Model) 是「一款具体的产品硬件」在平台内的数字化描述,承载三类元信息:
- 物理属性:品类、部件清单;
- 平台属性:IoT 平台归属(小家 / 集贤);
- 能力描述:主要功能、场景说明——供 LLM 在识别时作为背景上下文。
举例:同一款「智能台灯 097」若既接入小家平台又接入集贤平台,需登记为两个型号(平台归属不同);若只是外观颜色不同但控制协议相同,可视为一个型号。
2. 新建型号
进入【资源管理 > 型号库】,点击【新建型号】,弹窗中填写以下字段:
2.1 必填字段
| 字段 | 说明 | 举例 |
|---|---|---|
| 产品型号名称 | 内部识别用,建议「品类 + 序号 / 版本」 | 智能台灯 097 |
| 产品品类 | 一类产品的统称;不确定时选「通用」 | 台灯 / 洗衣机 / 空气净化器 |
| 指令描述 | 描述该型号的主要能力和属性,会作为 LLM 识别的上下文背景 | 「本设备为可调光台灯,支持亮度 0-100 无级调节和 5 档色温切换」 |
2.2 选填字段
| 字段 | 说明 | 举例 |
|---|---|---|
| 产品部件 | 一个型号内部可独立控制的子结构;若无独立部件可不填 | 主灯 / 氛围灯 / 上桶 / 下桶 |
| IoT 平台 | 若该设备的指令需经 IoT 平台转发,则选择对应平台;若指令直达设备,可不选 | 小家 / 集贤 |
IoT 平台两个选项:
- 小家:接入京东小家 IoT 平台,走小家的设备协议;支持真实设备通过
device_id + token直连调试。 - 集贤:接入集贤 IoT 平台;支持真实设备通过
device_id + token直连调试。
两选项与「设备管理」页联动:虚拟设备可在任意 IoT 平台下调试;真实设备两个平台均支持通过
device_id + token直连调试。详见「设备管理」。
3. 字段深度说明
3.1 产品品类的作用
品类不仅是分类标签,还会影响:
- LLM 识别时的上下文提示(告诉模型「这是一台台灯」有助于选择相关指令);
- 应用创建时的默认模板推荐;
- 后续跨型号统计分析。
如果找不到贴切的品类,选「通用」即可,不要强行归到某个不相关品类。
3.2 产品部件的作用
部件是可独立控制的最小单元:
- 双筒洗衣机 → 上桶 / 下桶(可独立启动、独立选模式);
- 双头台灯 → 主灯 / 氛围灯(可独立开关、独立调亮度);
- 单头台灯 → 不需要部件字段(整机就是一个控制单元)。
在 自定义指令集 中创建指令时,可以为每条指令勾选「作用部件」,平台会据此在下发时携带 partId,由设备端识别执行对象。
3.3 IoT 平台的作用
选择 IoT 平台后:
- 指令的【指令下发方式】可选择「IoT 平台」(平台将 action 转发到对应 IoT 平台);
- 若选择「端侧下发」,则 IoT 平台字段仅作为背景信息使用,不影响实际链路。
⚠️ IoT 平台一旦选定,后续修改会影响该型号已绑定应用的下发行为,请谨慎调整。
3.4 指令描述的写法建议
指令描述会被拼接到 LLM 的 System Prompt 中,直接影响识别质量。写法建议:
- ✅ 写清产品类型 + 核心能力 + 使用场景;
- 例:「本设备为家用空气净化器,支持开关机、5 档风量调节、滤芯寿命查询、定时开关;通常放置于卧室或客厅。」
- ❌ 不要写营销话术、参数堆砌;
- 长度建议控制在 100 字以内,避免占用过多 token。
4. 型号 ↔ 应用 关系
一个型号
├─ 被应用 A 绑定 (音箱形态)
├─ 被应用 B 绑定 (车机形态)
└─ 被应用 C 绑定 (小程序模拟形态)同一硬件在不同应用形态下复用同一型号,可以确保指令集只维护一份,大幅降低配置成本。
5. 注意事项
- 不可轻易删除:型号被指令集或应用引用后不能直接删除,需先解绑;
- 改名有影响:型号名称仅供后台识别,可以修改;但指令描述修改后需重新做 批量测试,因为它会影响 LLM 识别;
- 部件后加:若上线后新增部件,记得回到已有 指令集 中补勾「作用部件」;
- IoT 平台改动:更换 IoT 平台等同于换设备协议,必须与设备开发拉通并做端到端回归。