القائمة
查询与控制米家智能家居设备。查询能力包括设备开关状态、运行状态、电量、设定温度、当前温湿度、PM2.5 等环境与设备数据；控制能力包括开关灯、调节空调温度/模式/风速、控制窗帘开合、启动或停止扫地机器人、开关摄像头等设备操作；场景能力包括触发已有米家场景，如回家、离家、睡眠等智能场景；以及刷新设备列表缓存。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
感知范围控制 — 管理 miloco 感知哪些家庭、哪些摄像头，以及每台摄像头的声音（是否参与感知）。用户说「只用/不用某家庭」「让 miloco 感知/别感知 某家庭或摄像头」「屏蔽某摄像头/把某摄像头从感知里去掉」「把某摄像头声音关了/打开」「XX 老误报（声音类）」「哪些家庭在用」时激活。注意区分：开关摄像头设备本身（开机/关机/电源/录制）走 miloco-devices；感知引擎自身的开关/参数走 miloco-perception。
调用摄像头看画面、听现场声音，或回顾近期事件来判断——在干嘛、有什么动静、是否有人说话/吵闹、刚才/最近发生了什么；通过画面核实设备的开关状态（如开着/关着、亮着/灭着），尤其在拿不到设备上报状态时。读不出画面看不见的具体数值（温度、湿度、音量等）。
家庭档案管理 — 当用户提到自己或家人的喜好、兴趣、习惯、身体状况、作息规律、家庭规则时激活，无论用户是否明确要求"记录"。也在用户修正已有记录、要求删除、或查询家庭档案时激活。
家庭信息首次初始化 / onboarding —— 用户说"初始化家庭""配置家庭成员""首次设置""帮我建家庭档案""onboarding"时激活；收到后端推送的 `[系统事件]` onboarding 消息（全新安装检测）时主动发起；也在身份库成员为空 + 家庭档案为空时由 agent 提议。通过访谈把家庭成员与家庭档案一次性建起来。
miloco-perception-digest 定时任务的内部步骤，仅由该任务调用。
家庭成员身份注册主流程。**用户表达「想让系统认识/记住/录入某个人」的意图就触发本 SKILL,不要求出现"注册/登记"字面词**——包括上传图/视频指明某人是谁、回应 `[感知引擎]` 陌生人推送、说"建档案/录入家人/记下样子"、指认摄像头里某人身份、从近期陌生人记录里挑人建档、撤销注册、查看某人样本。覆盖"上传图/视频"与"从摄像头挑人"两条通路,所有路径需用户确认才入库。仅改 person 行(改名/删人,不涉及样本)走 miloco-miot-identity。
| name | miloco-devices |
| description | 查询与控制米家智能家居设备。查询能力包括设备开关状态、运行状态、电量、设定温度、当前温湿度、PM2.5 等环境与设备数据；控制能力包括开关灯、调节空调温度/模式/风速、控制窗帘开合、启动或停止扫地机器人、开关摄像头等设备操作；场景能力包括触发已有米家场景，如回家、离家、睡眠等智能场景；以及刷新设备列表缓存。 |
| metadata | {"author":"miloco","version":"1.7","date":"2026-06-14","openclaw":{"requires":{"bins":["miloco-cli"]}}} |
处理米家智能家居设备交互，通过 miloco-cli 查询、控制、米家设备；触发米家场景。
| 意图 | 用户说了类似… |
|---|---|
| control | "打开灯" "空调调到26度" "把窗帘拉上" "扫地" |
| query | "灯开着吗" "空调设定的温度" "客厅多少度" "湿度多少" |
| scene_trigger | "执行回家模式" "触发离家场景" |
| refresh | "刷新设备列表" "更新设备信息" "重新拉一遍" |
命令拆分 → 确定设备列表 → 确定 spec → 生成指令 → 安全分流 → 下发和回复 触发场景、刷新设备走文末「旁路操作」。
按用户自身的表述，拆成它点到的每一处设备指代，各成一条独立命令——各判各的，别把并列的几样揉成一团：
打开卧室空调、打开卧室灯关闭客厅的灯、关闭卧室的灯台灯开了么、落地灯开了么开空调设备目录注入：system context 注入了
## 设备目录段（行式记录的高频子集，≤50 台 + 生成时刻快照，每台 spec 块也只收高频属性）。字段含义、spec_name 形态看该段目录头部的注释。catalog 找不到 ≠ 不存在。
每个命令分别确定它落到哪几台设备。先判这条命令是单台还是复数（泛指、集合、多台、数量不定，如"空调全关了""灯都关""所有窗帘"）——靠语义理解判断，而非匹配字面措辞；拿不准就按复数处理。再据此定位 did：
device list | grep -E '<中文名>|<英文category>' 拉全量再找：grep 把中文名和英文 category 一起写进 alternation（灯|light），避免漏；device list 有时效性，会随时变动，每轮重查禁复用上一轮，绝不拿 catalog 子集当"全部"。注意事项
did= 是来源设备（摄像头/传感器），不是要控制的目标。miloco-cli device refresh 重试一次 → 回"没找到"，禁止编造 did。device list 很轻量、返回快，有需求直接调用；输出都是行式记录（每行一条完整记录、| 分隔），可以用 grep 过滤。每台设备都需要找到它自己的 spec 内容，依据 spec_name 和注释定位用户想控制/查询的那一项，读出 spec_name + access + format/range：
device spec <did1> <did2> … 一次拉全：把所有未确定 spec 的设备一并查（多 did 批量）。catalog 里有但语义不吻合 / 拿不准是不是最贴合的那一项时也拉完整 spec，挑最符合用户意图的调用，别将就模糊匹配。注意事项
on、另一个是只读传感器（无可写属性）；spec_name、枚举、范围都因设备而异。批量控制多台时尤其要每台核对，不能拿一台的 spec_name 发给全部。w 可写（控制）、r 可读（查询）、x 动作（一行可同时含多个，如 wr）。on/brightness/target-temperature/play-text/on@空调 等）；多键/多模块带 @ 后缀消歧（on@油烟机 / on@照明灯）。4.1 按 access 列生成命令
| access | 用途 | 命令 |
|---|---|---|
w | 控制属性 | 单属性 device control <did> <spec_name> <value>；多属性 device control <did> --set <spec_name> <v> --set <spec_name> <v> |
r | 查询属性 | device props <did> [spec_name ...] |
x | 执行动作 | device action <did> <spec_name> [<值1> <值2>…]（只传值，不传参数名） |
4.2 参数检查
Level1=1..Level3=3、也可能 Auto=0..Level8=8，不在 catalog spec 块就先 device spec 查真实枚举，别脑补"高=3"。[min,max;step] 校验（不越界、且符合 step 步进）。示例
| spec 行 | ✅ 正确 | ❌ 错误 |
|---|---|---|
start-charge|x（无参） | device action <did> start-charge | device control <did> start-charge |
play-text|x|text-content:string | device action <did> play-text "文本" | … play-text text-content:"文本" |
execute-text-directive|x|text-content:string,silent-execution:bool | … execute-text-directive "你好" false | … text-content:"你好" |
4.3 强制补 on（控制非 on 属性时）
控制非 on 属性时（temperature/brightness/mode/fan-level/volume…），把开关属性并入同一条 --set 一起开机——零成本且幂等，无需查 on 当前状态、无需分轮。但补的是 spec 里实际的开关 spec_name，不是字面 on（先确认存在、再选对 spec_name）：
@ 后缀（空调 on@空调、油烟机 on@油烟机）→ 补带 @ 的完整 spec_name，别补字面 on。on@油烟机 + on@灯；插座 on@开关 + on@指示灯）→ 只补与本次控制功能对应的主开关，别补到照明/指示灯那个。on：设 on 不会启动工作，须先设参数再调 start-cook 类 action，见文末「设备控制指导」。# "空调调到26度" → 属性 + 该设备实际开关 spec_name（空调是 on@空调，非字面 on）一条到位
miloco-cli device control 4962 --set target-temperature 26 --set on@空调 true
4.4 相对调节（"调高一点"）→ 先查后改
先 device props 取当前值 → 步进（亮度±10/色温±500/温度±1）→ 确保在 [min,max;step] 范围内。这是先查后改，必须单独一轮（要先拿到当前值，不能串进同一条）。
本步只分流、不下发：把步骤 4 生成的命令按是否安全分成普通批 / 危险批，交给步骤 6 的下发回合。
一个「回合」=下发（6.1）→ 回复（6.2）。按步骤 5 的分流结果，最多跑两轮：
"关客厅灯，顺便关摄像头" → 先把客厅灯关掉、回复"灯已关闭，确定要关闭摄像头吗？"（第 1 轮：普通批下发 + 危险确认）；用户确认后才
device control关摄像头（第 2 轮）。
6.1 下发
同一轮 ≥2 条互不依赖的命令（跨设备批量、多设备查询）→ 用 ; 串成一行一次下发：
miloco-cli device control 4912 --set brightness 30 --set on true ; miloco-cli device control 4945 --set brightness 30 --set on true
; 不用 &&：&& 短路（一台失败后面全不执行）；; 不短路、每条都跑、输出有序。❌ 也别发一条、等结果、再发下一条。control / props 返回体均含 data.did，多条按顺序输出、按 did 对号。; 串联；仅当环境不支持 ;（沙箱限制等）→ 退化为在同一条消息里一次性发出全部工具调用。6.2 回复
设备专属控制知识库：部分设备的正确控制方式与通用流程不同，命中下列设备时以此处为准。
play-text vs execute-text-directive两个 action 语义完全不同，按用户意图选对：
| 命令 | 语义 |
|---|---|
play-text | TTS 文字转语音，音箱逐字念出传入的文字 |
execute-text-directive | 小爱同学指令，等同于对音箱说"嘿小爱，xxx"，小爱理解语义后自己执行 |
play-text。execute-text-directive。start-cook 启动这类设备不能只设温度、也不能 set on true 就开始工作：必须先设好温度、时间等参数，再调用启动类 action（如 start-cook）才会真正运转。启动 action 的确切 spec_name 以该设备 device spec 为准。
scene list 拿 名称→scene_id 映射 → scene trigger <id>；名称匹配到多个 → 列出追问。miloco-cli device refresh，无需走命令拆分 → spec → 下发；返回最新设备数后回复"已刷新，共 N 个设备"。| 异常 | 处理 | 回复 |
|---|---|---|
| 设备不在目录 | device list | grep 拉全量再搜（别省） | （静默） |
| 设备未找到 | device refresh → 重试一次 | "没找到，正在刷新…" |
| 设备离线 | 照常下命令，CLI 返回体 results[]/result 的 code_msg 会标"设备离线" | "{设备名}离线了" |
| 设备侧执行失败 | 看返回体 results[]/result 的 code_msg 中文原因（属性不可写 / 属性不存在 / 属性值不正确等）→ 据此回复或改对重发 | "{设备名}该属性不可写" |
| 参数越界 | CLI 报 out of range [min,max;step] <unit> → 按范围改对 | "亮度范围1-100" |
| 枚举值非法 | CLI 报 not a valid enum; allowed: … → 从列出的可选值里挑对的重发 | "风速可选 自动/1-8 档" |
| 多设备同名 | 列候选追问 | "找到2个，哪个？" |
| spec_name 多匹配 | CLI 报 "matches N iids" → 按建议重发 | （自动处理） |
| 用 control 调 action | CLI 报 "is an action… 请改用 device action" → 切 device action | （自动处理） |
| CLI 超时 | 3 秒后重试一次 | "超时，重试中…" |
spec_name / action iid 不硬编码——以 catalog / device spec 为准（@ 后缀、play-text 等因设备而异）。--set，可能 on@空调，非字面 on）——不查不分轮（步骤4）。scene trigger 触发已有场景、device refresh 刷新缓存| 用户说 | 命令 |
|---|---|
| "空调调到26度"（控制非 on 属性 → 补该设备实际开关 spec_name） | device control 4962 --set target-temperature 26 --set on@空调 true |
"关客厅灯"（设 on 本身，灯的开关就是 on） | device control 4912 on false |
| "空调设定的温度"（查询） | device props 4962 target-temperature → 26 |
| "客厅多少度"（环境数据，同样走 props） | device props ht01 temperature → 24.5 |
| "家里有几盏灯"（集合 → grep 每轮重查） | device list | grep -E '灯|light' |
| "扫地机回去充电"（access=x → action 只传值） | device action 4981 start-charge |
多设备顺序下发 — "卧室灯都调到30%"：grep 筛出 4912/4945/4653，每盏补 on，; 串成一行：
miloco-cli device control 4912 --set brightness 30 --set on true ; miloco-cli device control 4945 --set brightness 30 --set on true ; miloco-cli device control 4653 --set brightness 30 --set on true
catalog 找不到 → list 兜底 — "打开阳台灯"：catalog 无 → device list | grep -E '灯|light' 命中 5001 阳台灯带 → device control 5001 on true。
多候选必追问 — "把灯调暗一点"：全屋多盏灯分散在各房间，用户没指明哪台、也没说"全部" → grep 枚举后反问"哪个房间的灯？"，既不默认挑一台、也不擅自全做（对照上面"灯都调30%"是明确全体 → 才全做）。
安全设备 — "关客厅灯，顺便关摄像头"：🔒 先关灯下发（普通）；回复"灯已关闭，确定要关闭摄像头吗？"（普通结果 + 危险确认）；用户确认后才 device control cam_001 on false。