Skill: dueros-mcp/xiaodu-leave-home-mode-official (version 1.0.1)

--- name: xiaodu-leave-home-mode-official description: 基于已安装的 xiaodu-control-official 编排离家场景。当用户说“出门了”“离家模式”“出门前检查一下”“帮我把家里设备关一下”时使用。这个 skill 会复用 xiaodu-control-official 的现有脚本，对小度智能屏和小度 IoT 设备执行 scene-first 的离家编排，同时在出门前汇总天气、日历和提醒事项等信息，帮助用户确认“出门前有没有漏掉什么”。不是单纯的关灯 skill，而是出门前一站式安全检查清单。 --- # xiaodu-leave-home-mode-official ## 运行边界声明 - 这是一个**编排 skill**，不直接实现底层设备控制或账户系统集成。 - 它运行时会调用同一 workspace 下、相邻目录里的依赖 skill：`skills/xiaodu-control-official/scripts/*`。 - 它默认只应读取： - `skills/xiaodu-control-official/scripts/*` - 当前 skill 自身目录下的文件 - 用户明确允许的偏好文件（如 `XIAODU_CONTEXT.md`、`MEMORY.md`） - 它不会主动读取未声明的本地隐私数据库；信息汇总默认通过智能屏 query 获取。 - 它默认不应读取或写入其他未声明的持久文件。 - 它不会自己索取新的外部凭证；运行时依赖的设备访问能力来自 `xiaodu-control-official` 已有配置。 ## 定位 一个基于 `xiaodu-control-official` 的**离家前安全检查 orchestrator**。 它的本质不是“关灯”，而是： > 用户说“出门了” → 系统先关闭家里电器 + 汇总出门前关键信息（天气 / 日历 / 提醒）→ 给用户一个清晰的出门前状态清单 两个并行 track，合并汇报： - **Track A（设备关闭）**：灯 → 窗帘 → 空调/风扇 → 门锁（二次确认） - **Track B（信息汇总）**：天气 → 日历日程 → 提醒事项 --- ## 核心原则 **出门前最怕忘事。离家模式的核心价值是“让用户出门时心里有底”：哪些设备关了、今天有没有漏掉的日程或提醒。** 不默认带娱乐内容。不默认上锁（需要二次确认）。不默认控全屋（优先客厅 + 主卧）。 --- ## 基于 xiaodu-control-official 事实能力全集的统一规划框架 所有离家规划都只能建立在 `xiaodu-control-official` 和本地 Mac 已有的脚本能力上。 不要加入想象中的设备族、动作或参数。 允许使用的规划 bucket 共 8 个： 1. **scene** - 来源：`list_scenes.sh` / `trigger_scene.sh` 2. **lights（灯光关闭）** - 来源：`list_iot_devices.sh` / `control_iot.sh` 3. **curtains（窗帘关闭）** - 来源：`list_iot_devices.sh` / `control_iot.sh` 4. **thermal comfort（空调/风扇关闭）** - 来源：`list_iot_devices.sh` / `control_iot.sh` - 仅限关闭动作，不做温度调整 5. **smart-screen speech（智能屏播报）** - 来源：`list_devices.sh` / `speak.sh` 6. **weather information（天气信息）** - 来源：`control_xiaodu.sh --command "播下今天的天气"` 7. **calendar information（备忘录信息）** - 来源：`bash ../xiaodu-control-official/scripts/control_xiaodu.sh --command "查看我今天的备忘录信息并播报"` 8. **alarm/reminder information（闹钟提醒）** - 来源：`bash ../xiaodu-control-official/scripts/control_xiaodu.sh --command "查看我今天的闹钟"` 规划顺序： 1. 先判断这次请求涉及哪些 bucket。 2. 再检查当前环境真实支持哪些 bucket。 3. 删除不支持的 bucket。 4. 把剩余 bucket 按两个并行 track 排列： - Track A（设备关闭）内部串行 - Track B（信息汇总）内部串行 - Track A 和 Track B 之间可以并行 5. Track A 和 Track B 都完成后，做产品化合并汇报。 6. 如果缺少继续执行所必需的信息，只问一个最小确认问题。 7. 执行结束后，把用户的调整吸收为后续偏好。 ## 偏好记忆与复用 把用户对离家流程的调整当成可复用偏好。 如果用户修正了默认设备范围、是否上锁、优先关闭的房间等，下次应优先沿用。 至少要支持沉淀这些偏好： - 离家默认设备范围 - 只关灯 / 只关空调 / 只关窗帘 / 全部关 - 客厅优先 / 主卧优先 / 全部 - 离家是否自动上锁 - 每次问 / 直接上锁 / 不上锁 - 默认避免关闭的设备 / 房间 - 确认风格 - 先问再做 - 只有一个明确目标时直接执行 存储规则： - 小度 / 家庭场景的短中期偏好，优先写入 `XIAODU_CONTEXT.md`。 - 长期稳定偏好，写入 `MEMORY.md`。 - 如果没有真的写入文件，就不要假装“已经记住”。 复用规则： - 下次执行前，先检查已有偏好能否直接解决设备选择问题。 - 如果已有偏好足够明确，就直接执行，不要重复问。 - 如果已有偏好与当前环境或当前用户表达冲突，优先当前请求，并在执行后更新偏好。 ## 标准执行流程 ### 1）先确认依赖可用 最小检查： 1. 确认 `skills/xiaodu-control-official` 存在。 2. 确认关键依赖脚本存在。 3. 如果要读日历/提醒，确认本地脚本路径可用。 4. 如果这次请求涉及 IoT，先读场景，再读 IoT 设备。 5. 如果需要智能屏播报，解析出一个可用智能屏。 ### 2）优先尝试 scene-first 1. 用 `list_scenes.sh` 读取现有场景。 2. 优先寻找高匹配场景，例如： - 离家 - 出门 - 外出 - 离开 3. 如果找到高置信度场景，优先触发。 4. scene 触发后，走完整的 Track A + Track B + 合并汇报。 ### 3）没有 scene 时，进入双 track 并行 fallback #### Track A：设备关闭（串行执行） 读取 IoT 设备后，按以下顺序执行： 1. **关灯**（读取当前状态，只对"开着"的灯发关闭命令） 2. **关窗帘**（只对"开着"的窗帘发关闭命令） 3. **关空调/风扇**（只对"开着"的空调/风扇发关闭命令） 4. **门锁上锁**（需要二次确认，未确认前不执行） Track A 内部必须严格串行： - 上一条命令返回后，才能发下一条 - 如果某步失败，继续执行后续步骤 - 最终汇报时说明哪些成功了、哪些失败了 #### Track B：信息汇总（串行执行） 在 Track A 启动后，同时启动 Track B： 1. **查天气** - `bash ../xiaodu-control-official/scripts/control_xiaodu.sh --command "播下今天的天气" ...` 2. **查备忘录（今天的日程安排）** - `bash ../xiaodu-control-official/scripts/control_xiaodu.sh --command "查看我今天的备忘录信息并播报" ...` 3. **查闹钟提醒** - `bash ../xiaodu-control-official/scripts/control_xiaodu.sh --command "查看我今天的闹钟" ...` Track B 内部串行执行。 Track A 和 Track B 可以并行，互相不阻塞。 #### 合并汇报 两个 track 都完成后（或 Track A 完成后，Track B 仍在处理时做初步汇报），做产品化合并汇报： 1. 先说设备关闭结果 2. 再说天气/日历/提醒摘要 3. 最后提示门锁是否需要处理 ### 4）门锁二次确认规则 **门锁是唯一默认不自动执行的高敏感动作。** - 如果检测到智能门锁且用户未明确说“上锁”，先汇报其他结果，然后问： > 检测到有智能门锁，是否需要帮你上锁？ - 如果用户说“上锁”“锁门”，再执行上锁动作 - 如果用户说“不用”“忽略”，跳过门锁步骤 --- ## 通用 leave-home 实际调用链 对于"出门了"这类高层请求： ### Track A（设备关闭） 1. `bash ../xiaodu-control-official/scripts/list_scenes.sh --server xiaodu-iot` 2. 如果有高置信度离家 scene：`trigger_scene.sh` 3. 否则： - `bash ../xiaodu-control-official/scripts/list_iot_devices.sh --server xiaodu-iot` - 对状态为"开着"的灯：`bash ../xiaodu-control-official/scripts/control_iot.sh --action turnOff ...` - 对状态为"开着"的窗帘：`bash ../xiaodu-control-official/scripts/control_iot.sh --action close ...` - 对状态为"开着"的空调/风扇：`bash ../xiaodu-control-official/scripts/control_iot.sh --action turnOff ...` ### Track B（信息汇总） 1. `bash ../xiaodu-control-official/scripts/control_xiaodu.sh --command "播下今天的天气" ...` 2. `bash ../xiaodu-control-official/scripts/control_xiaodu.sh --command "查看我今天的备忘录信息并播报" ...` 3. `bash ../xiaodu-control-official/scripts/control_xiaodu.sh --command "查看我今天的闹钟" ...` ### 合并汇报 Track A 完成后立即出初步汇报，Track B 结果出来后补全信息层。 --- ## 面向用户的汇报风格 **这是离家模式最关键的一层，必须说清楚三件事：** 1. **设备侧：哪些关了、哪些没关、哪些失败了** 2. **信息侧：天气怎么样、今天有什么日程、有没有提醒** 3. **门锁侧：是否上锁或是否需要上锁** ### 推荐综合汇报口径 > 已帮你把出门模式安排好了。 > **设备这边**：灯已全部关闭，空调已关闭，窗帘已拉好。 > **出门信息**：今天下午3点有个会，晚上记得买菜。今天天气晴转多云，18-25度，出行没问题。 > **门锁这边**：需要帮你锁门吗？ ### 设备失败时的汇报 > 已帮你把出门模式安排好了。灯已全部关闭，空调已关闭，不过窗帘关闭这次没成功——如果方便的话可以回头检查一下。门锁这边还没动，需要上锁吗？ ### 信息层失败时的汇报 如果天气/日历/提醒读取失败： > 已帮你把出门模式安排好了。灯已全部关闭，空调已关闭。出门信息这边今天暂时没读到日程，不过天气方面你可以放心。门锁需要帮你上锁吗？ --- ## 失败处理 这个 skill 对局部失败应当有容错，但汇报必须诚实。 - **没有 scene →** 自动改走 Track A + Track B - **灯全部已关 →** 跳过关灯步骤，不重复发命令 - **关灯失败 →** 继续窗帘和空调步骤，汇报里说明 - **天气读取失败 →** 跳过天气，继续日历和提醒，汇报里简要说明 - **日历/提醒读取失败 →** 跳过该项，继续其他步骤 - **没有智能门锁 →** 不询问门锁，直接完成汇报 - **门锁未确认 →** 不执行上锁，汇报末尾问一次 --- ## 防误控规则 - 不要默认控全屋，优先客厅 + 主卧。 - 不要重复关已经关闭的设备（先读状态再决定是否发命令）。 - 门锁没有二次确认不能执行。 - 不要说"全部设备已关闭"，除非真的全部成功。 - 不要编造日程、提醒或天气内容。 - 不要在门锁之外的高敏感动作（阀门类、燃气类）上默认执行。 --- ## 为什么不能重做底层 除非必要，不要绕过 `xiaodu-control-official`，因为它已经： - 分清了 `xiaodu` 与 `xiaodu-iot` - 带有更安全的脚本约束 - 定义了能力边界与 schema 预期 - 让排障更容易聚焦在同一依赖层 --- ## 按需阅读的引用文档 - 需要看更细的编排说明时，读 `references/usage-notes.md` - 需要看测试边界与验证项时，读 `references/test-cases.md`


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)