# 垂域专项复杂度判断

本文件是 [复杂度判断](复杂度判断.md) 的专项条件表，父维度是 `complex` / 复杂度判断。

它用于沉淀不同垂域里“看起来不是简单一步执行”的复杂样式。命中本文件的复杂样式时，可以给 `complex=true`；没有命中时，不要强行升级复杂度，回到通用复杂度策略判断。

## 使用原则

- 本文件只补充 `complex=true` 的垂域专项信号，不替代业务标签判断。
- 不要因为 query 属于某个垂域就直接给 `complex=true`，必须命中具体复杂样式。
- 如果 query 是明确的一步控制、一步查询、一步播放、一步打开应用，通常仍按 `complex=false` 判断。
- 如果 query 同时涉及多指令、自动任务或输出形态，仍需分别读取对应维度文件，不要把多个维度混成一个结论。

## 判断次序

1. **先判断垂域**：确认 query 属于车控、IoT 设备、生活服务、系统控制、应用控制、图片问答或媒体播放等场景。
2. **再看复杂样式**：是否需要场景编排、意向理解、设备推理、功能组合、风险判断、推荐筛选、跨应用操作、视觉推理或资源推断。
3. **确认是否必须推理落地**：如果用户只表达感受、场景或约束，系统需要推理出具体动作、候选对象或执行方案，通常是 `complex=true`。
4. **排除简单直达**：如果用户已经明确给出单一设备、单一动作、单一资源、单一 App 或单一查询目标，且不需要综合判断，回到通用 `complex=false`。
5. **未覆盖则回退**：本文件未覆盖的场景，继续使用 [复杂度判断](复杂度判断.md) 的通用策略。

## 复杂车控

针对车内空调、车窗、座椅、灯光、驾驶相关设置等车控能力，以下类型可以给 `complex=true`。

### 场景编排

用户描述一个车内场景或目标状态，系统需要组合多个车控动作来完成。

示例：

- 等下要开个会，帮我把车里状态调一下。
- 一会儿有人上车，帮我把车内环境整理舒服点。

判断要点：

- 用户没有直接列出具体动作，而是给出场景目标。
- 需要推理出空调、车窗、座椅、灯光、媒体、静音等可能的组合动作。

### 意向理解

用户用感受表达需求，系统必须落到具体车控意图。

示例：

- 车里有点闷，我想透透气。
- 后排坐着不太舒服，帮我调整一下。

判断要点：

- “闷、热、冷、刺眼、不舒服”等感受本身不是具体控制动作。
- 如果需要推断打开车窗、调空调、调座椅、调灯光等具体动作，给 `complex=true`。

### 设备推理

用户用相对位置、排除条件或隐含设备集合描述控制目标，系统需要推理出具体设备。

示例：

- 把除了我这边以外的车窗都关了。
- 除了副驾，其他座椅加热都关掉。

判断要点：

- 需要根据说话人位置、车内座位、设备集合或排除条件推理控制对象。
- 如果只是“关闭主驾车窗”这类明确单设备单动作，不命中本条。

## 复杂设备控制

针对空调、灯光、摄像头、扫地机、传感器等 IoT 设备，以下类型可以给 `complex=true`。

### 功能组合

用户描述家居状态或环境目标，系统需要组合多个设备能力。

示例：

- 南向房间又热又干，帮我调一下。
- 客厅有点暗还闷，帮我弄舒服点。

判断要点：

- 需要同时考虑空调、加湿器、窗帘、灯光、新风等多个设备或功能。
- 如果只是“打开客厅空调”这类单设备动作，回到通用判断。

### 状态查询

用户要求系统基于多个设备状态做风险、异常或整体状态判断。

示例：

- 我计划出差，家里有啥设备有安全风险吗。
- 睡觉前帮我看看家里有没有什么不该开着的设备。

判断要点：

- 不是查询单个设备状态，而是需要遍历、归纳或判断多个设备状态。
- 涉及安全风险、异常状态、整体巡检时，可以给 `complex=true`。

### 查询 + 控制混合

用户先要求查询环境或设备状态，再要求根据结果调整设备。

示例：

- 屋内空气怎么样，帮我调整下。
- 看看卧室温湿度，如果不舒服就处理一下。

判断要点：

- 需要先获取状态，再决定控制动作。
- 如果 query 明确拆成多个可独立动作，还需要另行判断多指令维度。

## 复杂生活服务

主要涉及餐饮、旅游、酒店、出行服务等生活垂域，以下类型可以给 `complex=true`。

### 条件筛选 / 推荐

用户不是简单查找一个对象，而是要求根据偏好、氛围、避坑、体验、约束做推荐。

示例：

- 想找个安静点、适合聊天的餐厅，别太吵。
- 想找一家适合带老人吃饭的店，环境好一点，别排太久。

判断要点：

- “安静、适合聊天、别太吵、别踩雷、适合老人/孩子”等通常需要评价和体验判断。
- 如果只是“附近餐厅”“附近最近的酒店”这类简单检索，回到通用判断。

### 生活垂域组合

用户把多个生活服务目标组合成一个整体计划。

示例：

- 想去海边待两天，住得安静点，周围吃的也别太差。
- 周末想带孩子出去玩一天，别太累，吃饭停车都方便点。

判断要点：

- 需要综合地点、住宿、餐饮、游玩、交通、时间等多个因素。
- 如果需要形成行程、候选比较或方案推荐，给 `complex=true`。

## 复杂系统控制

系统控制包括亮度、字体、省电、音量、通知、显示、网络、权限等系统级能力。以下类型可以给 `complex=true`。

### 场景 / 感受 / 约束驱动的系统操作

用户没有直接说具体设置项，而是描述问题或目标，系统需要推理出系统级操作。

示例：

- 手机字太小图标也小，总是点错，请整理一下。
- 手机快没电了但一直要导航，帮我把其他耗电的都处理掉。

判断要点：

- 需要把“点错、省电、看不清、太吵、打扰”等问题映射为字体、图标、亮度、省电、后台、通知、音量等设置。
- 如果只是“把亮度调到 50%”“打开省电模式”，通常是 `complex=false`。

## 复杂应用控制

应用控制中，以下类型可以给 `complex=true`。

### 跨应用操作

query 涉及 2 个及以上 App，需要在不同应用之间传递内容、截图、分享或继续操作。

示例：

- QQ音乐里最近单曲循环的这首歌帮我分享到微信朋友圈让朋友们也听听。
- 支付宝里基金涨了，帮我截图发到微信让我爸也看看收益。

判断要点：

- 需要从一个 App 获取内容，再到另一个 App 执行动作。
- 涉及内容选择、截图、分享对象、发布渠道等步骤时，给 `complex=true`。
- 单独“打开微信”“QQ音乐搜索刘德华”不命中本条。

## 复杂图片问答

图片问答中，以下类型可以给 `complex=true`。

### 视觉理解 + 后续推理 / 执行

用户要求先理解图片、屏幕或前方环境，再做知识问答、路线规划、控制执行或风险判断。

示例：

- 前面那辆白色的车挂的哪里的牌？是哪个城市的？那个城市有什么好玩的地方，下次放假想去转转，帮我做个两天的攻略。
- 帮我看下这个标牌上写的什么，是不是限速的？现在我开多少了，有没有超速？如果超了帮我把巡航速度调下来。

判断要点：

- 需要先从视觉信息中识别对象、文字、场景或状态。
- 识别后还要继续问答、规划、比较或执行控制时，给 `complex=true`。
- 单纯“这是什么”“描述一下这张图”可以按通用策略判断，不一定命中复杂。

## 复杂媒体资源播放

媒体资源包括音乐、视频、电台、有声内容等。以下类型可以给 `complex=true`。

### 模糊感受 / 情境 / 碎片记忆驱动的资源推断

用户没有给出明确资源名，而是用感受、场景、碎片歌词、模糊记忆描述内容需求，需要系统推断资源并播放。

示例：

- 我想听一首以前特别火的伤感中文歌，男声唱的，副歌我会唱但现在一下想不起名字了，你先放几首最可能的给我。
- 先来一个适合今天这种阴天听的歌单，不要太丧，也别太闹腾，如果后面推荐越来越伤感，就帮我切到轻一点的民谣。

判断要点：

- 需要根据模糊描述召回、筛选或动态调整资源。
- 用户要求“先放几首最可能的”“根据后续反馈调整”时，通常是多步骤推荐与播放，给 `complex=true`。
- 明确“播放周杰伦晴天”“下一首”“暂停播放”不命中本条。