wuyang6
14 KiB
垂域专项复杂度判断
本文件是 复杂度判断 的专项条件表，父维度是 complex / 复杂度判断。
它用于沉淀不同垂域里“看起来不是简单一步执行”的复杂样式。命中本文件的复杂样式时，可以给 complex=true；没有命中时，不要强行升级复杂度，回到通用复杂度策略判断。
使用原则
- 本文件只补充
complex=true的垂域专项信号，不替代业务标签判断。 - 不要因为 query 属于某个垂域就直接给
complex=true，必须命中具体复杂样式。 - 如果 query 是明确的一步控制、一步查询、一步播放、一步打开应用，通常仍按
complex=false判断。 - 如果 query 同时涉及多指令、自动任务或输出形态，仍需分别读取对应维度文件，不要把多个维度混成一个结论。
判断次序
- 先判断垂域：确认 query 属于车控、IoT 设备、生活服务、系统控制、应用控制、图片问答或媒体播放等场景。
- 再看复杂样式：是否需要场景编排、意向理解、设备推理、功能组合、风险判断、推荐筛选、跨应用操作、视觉推理或资源推断。
- 确认是否必须推理落地：如果用户只表达感受、场景或约束，系统需要推理出具体动作、候选对象或执行方案，通常是
complex=true。 - 排除简单直达：如果用户已经明确给出单一设备、单一动作、单一资源、单一 App 或单一查询目标，且不需要综合判断，回到通用
complex=false。 - 未覆盖则回退：本文件未覆盖的场景，继续使用 复杂度判断 的通用策略。
复杂车控
针对车内空调、车窗、座椅、灯光、驾驶相关设置等车控能力，以下类型可以给 complex=true。
车控意向表达的基础分流
先判断 query 是否包含车内设备、车内空间、车载功能或明确车载上下文。
- 如果 query 包含车内设备/空间/功能线索，并表达主观感受、状态不满、舒适度诉求或潜在操作意向，业务标签优先判断为
车载控制，复杂度给complex=true。 - 如果 query 不包含车内设备/空间/功能线索，只是单纯表达身体感受或闲聊式状态，不要强行映射到车控；通常按
闲聊/QA等非车控标签判断，复杂度不因车控规则升级。 - “车内设备/空间/功能线索”包括但不限于：车里/车内/后排/副驾/脚底下/头顶/车窗/空调/风/座椅/阅读灯/后视镜/车耳朵/引擎盖/雨雪模式/压线提示音等。
示例：
| query | 业务标签倾向 | complex | 原因 |
|---|---|---|---|
| 车里空调好热 | 车载控制 | true | 包含车内设备“空调” + 主观感受，需要推断降温/调空调 |
| 脚底下好冷，腿快冻麻了 | 车载控制 | true | 包含车内空间“脚底下” + 冷感，需要推断脚部出风/空调/座椅等 |
| 风一直吹我脸，有点难受 | 车载控制 | true | 包含车内风向线索 + 舒适度诉求，需要推断调整风向/风量 |
| 我好热啊 | 闲聊/QA | false | 未出现车内设备/空间/功能线索，只是身体感受 |
| 我有点晕车 | 闲聊/QA | false | 未指定车控设备或可执行车控意向，默认不落车控 |
注意：如果上文已经明确处于车控慢系统确认链路，当前轮可按“多轮策略”继承；没有上文时，不要脑补车载上下文。
慢系统车控类型
以下车控类型进入慢系统，复杂度给 complex=true。其他未命中这些类型、且是明确单设备单动作的车控 query，默认走快系统，给 complex=false。
意向性表达
用户可能无法说出功能准确名称，但表达了舒适度、主观感受、状态不满或潜在需求意向；没有明确指令“要做什么操作”，需要系统主动推断对应车控动作。
示例：
- 我感觉好冷快冻死了，帮我调一下。
- 脚底下好冷，腿快冻麻了。
- 风一直吹我脸，有点难受。
判断要点：
- 必须有车内设备、车内空间、车载功能或上下文线索。
- 需要从“冷、热、闷、刺眼、难受、挤、不舒服”等感受推断空调、风向、座椅、车窗、灯光等动作。
模糊场景表达
用户只有场景诉求，不知道车上有哪些模式或功能可以达到目标，需要系统把场景拆成车控动作或模式组合。
示例：
- 等下要开个会，帮我把车里状态调一下。
- 后排宝宝睡着了，把车里调成适合睡觉的状态。
- 今天情人节，帮我把车内营造一点节日氛围。
判断要点：
- 需要推理出空调、灯光、座椅、车窗、媒体、静音、氛围灯等可能组合。
- 如果用户已经明确“打开氛围灯”“关闭阅读灯”这类单动作，不命中本条。
模糊功能指代
用户不知道功能名或忘了名称，只能描述功能效果、触发场景或俗称，需要系统识别具体车载功能。
示例：
- 停车时自动把车耳朵收起来的功能叫什么，你帮我开一下。
- 后视镜反光看不清，有个防反光的功能你帮我调一下。
- 那个压线噔噔的声音把它关掉。
判断要点：
- 需要把“车耳朵收起来”“防反光”“压线噔噔”等模糊描述映射到后视镜折叠、防眩目、车道偏离提示等功能。
- 如果功能名明确且动作明确，例如“打开后视镜防眩目”，通常是
complex=false。
复杂多位置设备推理
用户表达了设备选择逻辑，需要根据位置、说话人、排除条件或设备集合推理具体控制对象。
示例：
- 把我头顶灯以外的灯都关了。
- 把除了我这边以外的车窗都关了。
判断要点：
- “我这边、头顶、除了、副驾以外、其他”等需要结合车内位置和设备集合推理。
- 明确单位置单动作如“关闭主驾车窗”不命中本条。
口语化纠正和重复表达
用户表达中出现口吃、重复、临时改口或前后纠正，需要系统消解最终设备和动作。
示例：
- 你帮我打开那个那个什么引擎盖。
- 你帮我把那个前排阅读灯哦不后排阅读灯打开。
判断要点：
- 需要从口语冗余、纠正和模糊指代中恢复最终控制目标。
- 简单重复但不影响理解的单动作，可结合实际难度判断；明显需要纠错消解时给
complex=true。
多轮确认继承
首轮进入慢系统并且系统主动询问用户确认时，次轮用户说确认、取消或继续类意图，默认仍进入慢系统并继承首轮车控任务。
示例：
- 首轮：“帮我打开那个适合雨雪天气防路面打滑的模式。”系统询问是否确认开启湿滑模式；次轮：“帮我开启。”次轮给
complex=true。 - 首轮：“我觉得后排好挤呀帮我调一下。”系统询问是否确认调节座椅位置；次轮：“调一下吧。”次轮给
complex=true。
判断要点：
- 必须有明确上一轮慢系统车控确认上下文。
- 单独看到“帮我开启”“调一下吧”且没有上一轮时，不要凭空判断为车控慢系统。
控制兜底逻辑
研发口径待补充。当前只在 query 明确命中上述慢系统类型时给 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。 - 明确“播放周杰伦晴天”“下一首”“暂停播放”不命中本条。