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

## 适用场景

当 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 是否已经有正式函数化定义。