Add label master skill

skills/label-master/knowledge/边界/高频混淆/内容播放-播放器控制-播放状态.md

@@ -0,0 +1,68 @@
+# 内容播放-播放器控制-播放状态
+
+## 适用场景
+
+当 query 涉及播放音乐、视频、电台、有声内容、播放器控制、当前播放内容查询、听歌识曲或指定 App 播放时，容易在内容类标签之间混淆。
+
+## 候选集合
+
+- `音乐播放`：播放歌曲、歌手、专辑、音乐风格，或听歌识曲之外的音乐播放需求。
+- `视频播放`：播放电影、电视剧、综艺、动画、短视频等视频内容。
+- `电台播放`：播放播客、有声书、相声、评书、电台、故事等有声内容。
+- `媒体应用播放`：明确指定第三方影音 App 并要求播放内容。
+- `播放器控制`：暂停、继续、上一首、下一首、快进、跳到指定位置、循环播放等不需要重新搜索的播放器按钮操作。
+- `媒体资源切换`：换一个版本、换一首歌曲等需要重新推荐或搜索的资源切换。
+- `播放状态查询`：对当前正在播放内容进行查询。
+- `听歌识曲`：识别外部环境或非本机播放歌曲。
+- `QA()`：静态内容知识问答，不依赖当前播放状态。
+
+## 决策顺序
+
+1. 先判断是否是播放动作：
+   - “播放/放/听/看 + 内容名”：按内容类型进入音乐、视频、电台。
+   - “用某 App 播放”：优先 `媒体应用播放`。
+2. 再判断是否是播放器控制：
+   - “暂停、继续、下一首、上一集、快进、跳到十分钟、单曲循环”：优先 `播放器控制`。
+3. 再判断是否需要重新搜索/推荐：
+   - “换一首歌曲、换个版本、来个别的”：偏 `媒体资源切换`。
+4. 再判断是否是状态查询：
+   - “这首歌是谁唱的、现在放的是什么歌、这个演员是谁”：如果依赖当前播放内容，优先 `播放状态查询`。
+5. 再判断是否是听歌识曲：
+   - “识别一下这首歌、听歌识曲”且不是本机播放内容，优先 `听歌识曲`。
+6. 如果只是知识问答：
+   - “周杰伦是谁、甄嬛传滴血认亲是哪一集”：按具体内容问答或 `QA()`。
+
+## 正例
+
+| query | 推荐 | 原因 |
+| --- | --- | --- |
+| 播放周杰伦的晴天 | 音乐播放 | 明确播放歌曲 |
+| 看一段猫咪搞笑视频 | 视频播放 | 明确播放视频 |
+| 我要听斗破苍穹 | 电台播放 | 有声内容 |
+| 用 Bilibili 播放三体动画 | 媒体应用播放 | 指定 App 播放 |
+| 下一首 | 播放器控制 | 按钮级控制，不重新搜索 |
+| 换一首歌曲 | 媒体资源切换 | 需要重新换资源 |
+| 现在放的是什么歌 | 播放状态查询 | 查询当前播放内容 |
+| 识别一下这首歌 | 听歌识曲 | 识别环境音乐 |
+
+## 反例
+
+| query | 不应给 | 推荐 |
+| --- | --- | --- |
+| 下一首我的大学 | 播放器控制 | 音乐播放，带资源名称 |
+| 甄嬛传滴血认亲是哪一集 | 视频播放 | 媒体资源问答或 QA |
+| 周杰伦是谁 | 音乐播放 | QA 或音乐问答 |
+| 打开热歌榜 | 音乐播放 | 应用控制或内容入口，需看端侧能力 |
+| 播放热歌榜 | 应用控制 | 音乐播放 |
+
+## 输出建议
+
+- 播放动作和控制动作必须分开判断。
+- “换一首”这类短句需要看上下文：如果是播放器按钮行为，偏 `播放器控制`；如果是资源推荐，偏 `媒体资源切换`。
+- 当前播放状态查询依赖上下文，不要把静态百科问答误判为播放状态查询。
+
+## 仍需确认
+
+- 当前是否有本机播放内容。
+- 用户是否指定了 App。
+- “换一首/下一个”是按钮操作还是重新推荐。

skills/label-master/knowledge/边界/高频混淆/地图导航-餐饮服务.md

@@ -0,0 +1,56 @@
+# 地图导航-餐饮服务
+
+这个边界用于判断“找附近 POI / 美食 / 奶茶 / 餐厅”和“导航去某地”之间的标签归属。
+
+## 核心判断
+
+- 明确要求导航、带路、路线规划、去某个地点：优先 `地图导航`。
+- 查找、推荐、比较附近或某地的餐饮 POI，但没有明确导航动作：优先 `餐饮服务`。
+- 单实体 POI 只说名字或问知识时，需要结合上下文；没有动作诉求时不要只因为是地点就强行给地图导航。
+
+## 地图导航
+
+适合：
+
+- 导航去附近的奶茶店。
+- 带我去最近的海底捞。
+- 怎么去评分最高的鄂菜馆。
+- 去公司附近的充电站。
+
+判断依据：
+
+- query 中出现“导航去”“带我去”“怎么去”“去 xxx”“路线”“途经点”等动作。
+- 用户目标是到达某地点，而不是了解、推荐或比较餐饮信息。
+
+## 餐饮服务
+
+适合：
+
+- 附近有什么好吃的。
+- 附近的奶茶店推荐一下。
+- 北京有什么好吃的。
+- 附近的海底捞评分怎么样。
+
+判断依据：
+
+- query 的核心是餐饮 POI 查询、推荐、问答或比较。
+- 没有明确要求开始导航或规划路线。
+
+## 易混淆点
+
+- “附近的海底捞”如果只是查找或推荐，偏餐饮服务；如果说“导航到附近的海底捞”，偏地图导航。
+- “xxx 在哪”在旧规则里常偏地图，但如果 xxx 是餐饮/酒店/旅游 POI，且用户意图是生活服务信息，也可能需要结合端侧和上下文判断。
+- 车载端和导航上下文中，和当前位置、路线、目的地强相关的问题更容易进入地图导航。
+
+## 输出建议
+
+分析边界样本时，不要只看关键词“附近”或 POI 名称。先判断用户要的是“找/推荐/了解”还是“去/导航/路线”。
+
+如果当前任务要求旧 Agent 包装，输出可以是：
+
+```text
+Agent(tag="地图导航")
+Agent(tag="餐饮服务")
+```
+
+如果当前任务要求 intent，输出 intent 名即可。不要在没有确认 function 化定义时编造地图或餐饮 function。

skills/label-master/knowledge/边界/高频混淆/地图问答-餐饮服务-旅游.md

@@ -0,0 +1,65 @@
+# 地图问答-餐饮服务-旅游
+
+## 适用场景
+
+当 query 涉及 POI、附近、周边、沿途、目的地附近、餐饮、景点、酒店、路线信息时，容易在 `地图问答`、`地图导航`、`餐饮服务`、`旅游`、`酒店`、`QA()` 之间混淆。
+
+## 候选集合
+
+- `地图导航`：用户要去某地、导航、带路、路线规划。
+- `地图问答`：用户问路线、当前位置、限速、路况、到达时间、距离、途经城市、目的地信息等地图上下文问题。
+- `餐饮服务`：餐饮 POI 查找、推荐、比较、问答。
+- `旅游`：景点、游玩、门票、攻略、开放时间、适合季节、景区问答。
+- `酒店`：订酒店、找酒店、酒店价格/位置/评价。
+- `QA()`：泛知识，不依赖当前位置、地图上下文或生活服务能力。
+
+## 决策顺序
+
+1. 先判断动作诉求：
+   - “导航去、带我去、怎么去、去 xxx、路线、途经点”：优先 `地图导航`。
+   - “到目的地多久、堵不堵、限速、沿途城市、这里是哪”：优先 `地图问答`。
+   - “推荐、找、附近有什么、评分、营业时间、排队”：继续看 POI 类型。
+2. 再判断 POI 类型：
+   - 餐厅、美食、奶茶、海底捞、火锅、咖啡：优先 `餐饮服务`。
+   - 景点、公园、博物馆、攻略、门票、游玩：优先 `旅游`。
+   - 酒店、民宿、住宿：优先 `酒店`。
+3. 再看上下文和设备：
+   - 导航中、车载端、query 依赖当前位置或路线，地图类候选权重更高。
+   - 无地图上下文，只是知识问答，生活服务或 `QA()` 权重更高。
+4. 最后判断输出形态：
+   - 如果使用旧 tag 体系，可能是 `Agent(tag="餐饮服务")` / `Agent(tag="地图导航")`。
+   - 如果使用 intent 体系，输出 intent 名。
+   - 如果 function 化定义不完整，不要伪造 function。
+
+## 正例
+
+| query | 推荐 | 原因 |
+| --- | --- | --- |
+| 导航去附近的奶茶店 | 地图导航 | 明确导航动作 |
+| 附近有什么好吃的 | 餐饮服务 | 餐饮 POI 推荐，没有导航动作 |
+| 前面怎么走比较好 | 地图问答 | 路线/导航上下文问答 |
+| 途径哪些城市 | 地图问答 | 路线途经信息 |
+| 广州有什么好玩的 | 旅游 | 旅游/景点推荐 |
+| 故宫门票多少钱 | 旅游 | 景区门票信息 |
+| 附近的酒店 | 酒店 | 住宿 POI |
+
+## 反例
+
+| query | 不应给 | 推荐 |
+| --- | --- | --- |
+| 附近的海底捞评分怎么样 | 地图导航 | 餐饮服务 |
+| 怎么去最近的海底捞 | 餐饮服务 | 地图导航 |
+| 兰州拉面来源于哪里 | 餐饮服务 | QA 或美食问答，需按当前标签体系确认 |
+| 襄阳古城位于我们的西边吗 | 旅游 | 地图问答 |
+| 颐和园简介 | 地图导航 | 旅游或 QA，按当前生活服务优先规则确认 |
+
+## 输出建议
+
+- “找/推荐/问答”不等于地图，“去/导航/路线”才强指向地图导航。
+- POI 类型优先用于区分生活服务类候选；动作诉求优先用于区分地图导航。
+- 如果 query 同时包含生活服务 POI 和导航动作，导航动作优先。
+
+## 仍需确认
+
+- 当前任务是否要求 `Agent(tag="xxx")` 包装。
+- 生活服务问答是否统一进入 `餐饮服务` / `旅游`，还是回退 `QA()`。

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

@@ -0,0 +1,67 @@
+# 系统控制-设备控制-车载控制
+
+## 适用场景
+
+当 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 是否已经有正式函数化定义。

skills/label-master/knowledge/边界/高频混淆/通用问答-文档总结-Summarize.md

@@ -0,0 +1,59 @@
+# 通用问答-文档总结-Summarize
+
+## 适用场景
+
+当 query 包含“总结一下、概括、提炼、分析这个、这篇文章、这个网页、这个文档、屏幕上的内容”等表达时，容易在 `文档总结`、`Summarize()`、`QA()`、`文本创作`、`图片问答` 之间混淆。
+
+## 候选集合
+
+- `文档总结`：旧 tag 或 Agent 包装候选。
+- `Summarize()`：function program，适合已经确认有文档、URL 或资源对象时。
+- `QA()`：泛知识问答，没有可总结资源，或用户问的是开放知识。
+- `文本创作` / `Generate(object=Text)`：用户不是要求总结已有内容，而是要求生成新文本、评论、文案、文章。
+- `VisionQA()`：用户问题依赖图片、屏幕、拍照或视觉指代，且不是明确文档/URL 总结。
+
+## 决策顺序
+
+1. 先判断是否存在可总结资源：
+   - 明确文档、网页、URL、附件、屏幕文章、图片形式的文档。
+   - 多轮上下文里上一轮刚上传或打开了资源。
+2. 如果有资源，再判断资源类型：
+   - 文档：`x0=Resource(type="DOC")` + `Summarize(object=x0)`。
+   - URL/网页：`x0=Resource(type="URL")` + `Summarize(object=x0)`。
+   - 未知资源但明确“总结一下”：可以使用 `Summarize()`，并在结果中标注资源待系统补全。
+3. 如果没有资源，只是问知识：
+   - “总结一下红楼梦”：通常是 `QA()`，不是文档总结。
+   - “介绍一下孔乙己”：通常是 `QA()`。
+4. 如果用户要求基于已有内容生成新文本：
+   - “根据这篇文章写一段评论”：需要区分任务是否要求总结，还是创作。可以先总结资源，再进入文本创作，但最终 target 需按当前任务定义确认。
+5. 如果 query 依赖视觉内容：
+   - “屏幕上这段话是什么意思”：如果屏幕内容是文档/文章，偏 `Summarize()`；如果是图片、图标、题目或视觉指代，偏 `VisionQA()`。
+
+## 正例
+
+| query | 推荐 |
+| --- | --- |
+| 总结一下这个文档 | `x0=Resource(type="DOC")` + `Summarize(object=x0)` |
+| 这个网页讲了什么 | `x0=Resource(type="URL")` + `Summarize(object=x0)` |
+| 总结一下 | `Summarize()`，资源由上下文或系统补全 |
+| 总结一下这篇论文的核心观点 | `Summarize()`，如果已知是文档则补 `Resource(type="DOC")` |
+
+## 反例
+
+| query | 不应给 | 推荐 |
+| --- | --- | --- |
+| 总结一下红楼梦 | `Summarize()` | `QA()` |
+| 孔乙己这篇文章主要讲什么 | 无上下文资源时不要强行文档总结 | `QA()` |
+| 写一段关于这篇文章的朋友圈文案 | 单纯 `Summarize()` | 需要确认是否文本创作，或先总结再生成 |
+| 这个图标是什么意思 | `Summarize()` | `VisionQA()` 或图片问答 |
+
+## 输出建议
+
+- 如果当前任务使用 function program，优先输出 `Summarize()` 或 object + `Summarize(object=x0)`。
+- 如果当前任务仍使用旧 tag，使用 `Agent(tag="文档总结")` 前必须确认这批数据要求 Agent 包装。
+- 如果只是“总结一下某个知识实体”，不要因为出现“总结”两个字就给 `Summarize()`。
+
+## 仍需确认
+
+- 资源是否真实存在，还是用户只是问一个知识实体。
+- 当前数据集 target 要求是 function program、intent，还是 `Agent(tag="xxx")`。