zk-data-agent/skills/label-master/knowledge/边界/高频混淆/系统控制-设备控制-车载控制.md

系统控制-设备控制-车载控制

适用场景

当 query 是“打开、关闭、调节、设置、查询状态”等控制类表达时，容易在 系统控制、设备控制、车载控制、应用控制、相机、声纹、设备查找、自动任务 之间混淆。

候选集合

• 系统控制：当前设备或通用系统层能力，如音量、亮度、关机、护眼、截图、朗读屏幕、系统开关。
• 设备控制：IoT 设备控制，如灯、空调、电视、扫地机、洗衣机等，通常涉及家庭/房间/米家设备。
• 车载控制：车载设备和车辆特有能力，如车窗、座椅、雨刮、前备箱、智驾、泊车、哨兵、驾驶模式。
• 应用控制：打开/关闭 App、进入 App 页面、App 内操作。
• 相机 / 声纹 / 设备查找：白名单型专项控制标签，优先级高于系统控制兜底。
• 自动任务：存在条件触发结构时，优先进入自动任务维度。

决策顺序

1. 先判断是否是条件触发：
   • “当/如果/时候/之后/到达/每/一...就”：先读 自动任务判断.md，不要直接给普通控制标签。
2. 再判断控制对象：
   • 当前设备系统属性：优先 系统控制。
   • 家庭 IoT / 米家设备：优先 设备控制。
   • 车辆部件或车载特有功能：优先 车载控制。
   • App 或页面：优先 应用控制。
   • 声纹、相机、查找设备等专项能力：优先专项标签。
3. 再看发起端和上下文：
   • 车载端中“空调、座椅、车窗、方向盘”等优先 车载控制。
   • 家庭音箱/手机控制家中设备，优先 设备控制。
   • 控制当前设备自身音量/亮度，优先 系统控制。
4. 最后处理歧义：
   • 如果设备词既可能是当前设备又可能是 IoT 设备，例如“电视音量大一点”，需要看发起端和用户意图。
   • 如果上下文缺失且影响标签，向用户确认或在结果中标注不确定点。

正例

query	推荐	原因
音量大一点	系统控制	当前设备系统属性
屏幕亮度调到 50	系统控制	当前设备系统设置
打开主卧空调	设备控制	家庭 IoT + 房间
扫地机扫一下客厅	设备控制	IoT 设备控制
打开车窗	车载控制	车辆部件
副驾座椅加热打开	车载控制	车载座椅能力
打开微信	应用控制	App 打开
找一下我的手机	设备查找	专项能力

反例

query	不应给	推荐
上车时打开空调	车载控制	自动任务维度 + subquery 车载控制
电视音量大一点	固定系统控制	需要看发起端：电视自身可能系统控制，音箱控电视可能设备控制
打开相机倒计时	系统控制	相机
录入声纹	系统控制	声纹
打开智能驾驶	应用控制	车载控制

输出建议

• 结构上命中自动任务时，最终输出通常是带 condition 的 group，而不是单个控制标签。
• 控制类标签经常有端侧依赖，输出时应说明“依据当前设备/上下文判断”。
• 如果当前任务要求 function program，但控制类 function 未共识，不要编造函数；先用 intent 或 Agent 包装，并标记待确认。

仍需确认

• 当前设备端是什么。
• query 中的设备是当前设备、IoT 被控设备，还是车载部件。
• 控制类 function 是否已经有正式函数化定义。