xiaodu-movie-mode-official

by dueros-mcp

Install this Skill

curl -fsSL -o xiaodu-movie-mode-official.zip https://skill.seembox.com/api/v1/skills/xiaodu-movie-mode-official/download && unzip xiaodu-movie-mode-official.zip

Download xiaodu-movie-mode-official.zip

SKILL.md About

---
name: xiaodu-movie-mode-official
description: 基于已安装的 xiaodu-control-official 编排观影场景。当用户说“开始观影模式”“我要看电影”“把房间调成适合看电影的状态”“准备看电影了”时使用。这个 skill 会复用 xiaodu-control-official 的现有脚本，对小度智能屏和小度 IoT 设备执行 scene-first 的观影编排，而不是重做底层控制。
---

# xiaodu-movie-mode-official

## 定位

一个基于 `xiaodu-control-official` 的**观影场景 orchestrator**。

它不是电影搜索 skill，也不是播放器 skill，而是：

> 用户一句高层表达（“开始观影模式”）→ 系统先把房间和播放设备准备到“可以开始看”的状态 → 用户明确指定内容时，再继续进入播放层。

## 核心原则

**观影模式默认负责“把房间和设备准备到可以开始看”的状态；只有在用户明确指定内容时，才继续进入内容播放层。**

不默认替用户选电影，不默认自动播放一个平台里的内容。

---

## 基于 xiaodu-control-official 事实能力全集的统一规划框架

所有观影规划都只能建立在 `xiaodu-control-official` 已明确记录的能力 bucket 上。
不要加入想象中的设备族、动作或参数。

允许使用的规划 bucket 只有 7 个：

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. **display / playback device preparation（显示 / 播放设备）**
   - 来源：`list_iot_devices.sh` / `control_iot.sh`
   - 包括：电视、投影、机顶盒、音量、信号源、模式切换
   - 这是观影模式最核心的特有 bucket
6. **smart-screen speech（智能屏播报）**
   - 来源：`list_devices.sh` / `speak.sh`
7. **smart-screen assistant/media（智能屏助手 / 内容）**
   - 来源：`list_devices.sh` / `control_xiaodu.sh` / `push_resource.sh`
   - 仅在用户明确指定内容时才进入

规划顺序：

1. 先判断这次请求涉及哪些 bucket。
2. 再检查当前环境真实支持哪些 bucket。
3. 删除不支持的 bucket。
4. 把剩余 bucket 排成最安全的观影执行顺序。
5. 按 bucket 逐步执行，能做几步做几步。
6. 同一条观影流程里的所有命令都必须**串行执行**。
   - 上一个命令返回后，才能发下一个命令。
   - 不要把 `xiaodu` 或 `xiaodu-iot` 的控制命令并发打出去。
   - 如果上一个命令失败，后面的命令直接继续执行，不要因为单点失败中断整条流程。
7. 如果缺少继续执行所必需的信息，只问一个最小确认问题。
8. 执行结束后，把用户的调整吸收为后续偏好。

## 偏好记忆与复用

把用户对观影流程的调整当成可复用偏好。
如果用户修正了默认设备、信号源、音量、灯光风格、是否继续内容层等，下次应优先沿用。

至少要支持沉淀这些偏好：

- 观影默认设备
  - 电视 / 投影 / 智能屏
- 观影默认房间
  - 客厅 / 卧室 / 默认房间
- 默认信号源
  - HDMI / 电视主页 / 机顶盒
- 默认音量
  - 小 / 中 / 大
- 灯光风格
  - 全暗 / 柔和 / 留一点灯
- 窗帘风格
  - 全关 / 半关
- 是否自动进入内容层
  - 只做准备
  - 自动开平台
  - 自动切 HDMI
- 默认避免控制的设备 / 房间
- 确认风格
  - 先问再做
  - 只有一个明确目标时直接执行
- 环境偏好
  - 偏凉 / 偏暖 / 不动空调

存储规则：

- 默认**不主动写入**持久偏好文件。
- 只有在用户明确表达“记住这个偏好 / 以后都这样 / 下次也这样”时，才允许持久化。
- 小度 / 家庭场景的短中期偏好，优先写入 `XIAODU_CONTEXT.md`。
- 只有在确实属于长期稳定偏好、且用户明确要求记住时，才写入 `MEMORY.md`。
- 如果没有真的写入文件，就不要假装“已经记住”。

复用规则：

- 下次执行前，先检查已有偏好能否直接解决设备或内容选择问题。
- 如果已有偏好足够明确，就直接执行，不要重复问。
- 如果已有偏好与当前环境或当前用户表达冲突，优先当前请求，并在执行后更新偏好。

## 标准执行流程

### 1）先确认依赖可用

只做这次请求真正需要的最小检查：

1. 确认 `skills/xiaodu-control-official` 存在。
2. 确认关键依赖脚本存在。
3. 如果这次请求可能涉及 IoT，先读场景，再读 IoT 设备。
4. 如果这次请求需要智能屏播报或设备确认，先解析出一个可用智能屏。

如果依赖 skill 不可用，就停止并明确说明此 skill 依赖 `xiaodu-control-official`。

### 2）优先尝试 scene-first

1. 用 `list_scenes.sh` 读取现有场景。
2. 优先寻找高匹配场景，例如：
   - 观影
   - 影院
   - 电影
   - 家庭影院
   - 看电影
3. 如果找到高置信度场景，优先触发。
4. 触发成功后，再补一句简短播报。

推荐观影模式播报口径：

- 已经帮你把观影模式安排好了。
- 房间已经调整好了，可以开始看了。
- 观影模式已开启，准备好享受电影了。

如果 scene 触发失败，不能假装成功。

### 3）没有 scene 时，进入基于事实 bucket 的 fallback 规划

如果没有匹配 scene，不要直接退化成只说一句话。
而是继续基于事实 bucket 做结构化 fallback。

1. 读取 IoT 设备。
2. 只考虑这些 fallback bucket：
   - **lights**：把可用灯光调暗、关闭或调成更适合观影的亮度
   - **curtains**：如果有窗帘就关闭
   - **thermal comfort**：只有用户明确说闷 / 热 / 冷时，才考虑空调 / 风扇
   - **display / playback device preparation**：打开电视 / 投影、调音量、切信号源、切到观影模式
   - **smart-screen speech**：做一段简短确认播报
   - **smart-screen assistant/media**：只有用户明确指定内容时才进入
3. IoT bucket 只允许使用同时满足以下条件的设备：
   - 真实存在于当前设备列表
   - 与目标房间相关，或已被用户明确指定
4. 安全执行顺序：
   - scene（如果有）
   - lights
   - curtains
   - thermal comfort
   - display / playback device preparation
   - smart-screen speech
   - conditional smart-screen assistant/media
5. 某个 bucket 没有合适设备就跳过，不影响其他 bucket。
6. 如果多个目标都可能合理，只问一个最小确认问题。

关键原则：
**没有 scene，不等于退出；而是进入基于事实能力的结构化 fallback。**

### 4）把观影环境和设备准备纳入默认主流程

对于以下高层表达：

- 开始观影模式
- 我要看电影
- 把房间调成适合看电影的状态
- 准备看电影了

默认主流程应该是：

1. 先做可做的观影环境调整
2. 再做显示 / 播放设备准备（电视 / 投影 / 机顶盒 / 音量 / 信号源）
3. 再做一句简短但明确的确认播报
4. 只有用户明确指定内容时，才继续进入内容播放层

也就是说，产品默认理解不是：
- 一上来就打开某个平台播放随机内容

而是：
> **先把房间和设备准备到“可以开始看”的状态，用户说要看了再继续内容层。**

覆盖规则：
- 如果用户明确指定了具体设备或内容，就按用户指定执行。
- 如果已有偏好定义了环境 / 设备 / 信号源的顺序，就按偏好执行。
- 如果当前环境不适合做某项环境调整，也不要直接退出，仍然要完成设备准备和确认播报，并尽可能补齐后续步骤。

### 5）通用观影模式实际调用链

对于这种高层请求：

> 开始观影模式

默认调用链应当是：

1. `bash ../xiaodu-control-official/scripts/list_scenes.sh --server xiaodu-iot`
2. 如果存在高置信度观影 scene：
   - `bash ../xiaodu-control-official/scripts/trigger_scene.sh --scene-name "..." --server xiaodu-iot`
3. 否则：
   - `bash ../xiaodu-control-official/scripts/list_iot_devices.sh --server xiaodu-iot`
   - 如果有相关且可达的灯，用 `bash ../xiaodu-control-official/scripts/control_iot.sh ...` 调暗或关闭
   - 如果有窗帘，用 `bash ../xiaodu-control-official/scripts/control_iot.sh ...` 关闭
   - 如果有电视 / 投影 / 机顶盒 / 音量设备，做对应的准备动作
4. `bash ../xiaodu-control-official/scripts/list_devices.sh --server xiaodu`
5. `bash ../xiaodu-control-official/scripts/speak.sh ...`
6. 如果用户明确指定了内容，继续：
   - `bash ../xiaodu-control-official/scripts/control_xiaodu.sh --command "..." ...`
   - 或进一步的 IoT 设备控制

这条链路能保证整条编排链是分层且显式的。
除非用户明确说要自动播放内容，否则不要跳过环境和设备准备阶段，直接进入内容播放。

## 内容层的默认边界

### 默认不做这些
- 不默认替用户选具体电影
- 不默认自动打开某个影视平台播放随机内容
- 不默认搜索片单
- 不默认把“观影模式”理解成“马上开播”

### 只有在用户明确指定时才做
- 播电影 / 放《xxx》
- 打开爱奇艺 / 腾讯视频 / 优酷 / B站
- 切到 HDMI / 电视主页 / 机顶盒
- 打开投影看电影
- 打开电视开始播放

## 极简确认规则

### 需要确认的情况
- 同时有电视和投影，用户没说用哪个
- 同时有多个信号源都合理
- 不问就容易误控（比如客厅电视和卧室电视都在线）

### 不需要确认的情况
- 只有一个合理目标设备
- 用户已经明确指定
- 已有历史偏好

## 面向用户的汇报风格

面向用户时，优先给**产品化、自然汇报**，不要给技术动作日志。
一段好的自然汇报通常覆盖：

1. 已经帮用户安排好了什么
2. 现在正在发生什么
3. 接下来用户还可以让系统继续做什么

而且要把**真实已经成功的关键动作**讲出来，不要把价值藏在后台。
如果灯光确实调暗了、窗帘确实关闭了、电视确实打开了、信号源确实切好了，就应该体现在用户可听见的汇报里。

示例：

- 已经帮你把观影模式安排好了。
- 我刚刚把灯光收暗了，房间也调整得更适合看电影，电视这边也已经准备好。
- 现在已经可以开始看了，如果你想指定电影或者平台，我接着帮你切过去。

避免这样对用户说：
- 我先执行了 list_scenes
- 我调用了 control_iot
- 我刚刚执行了脚本

## 失败处理

这个 skill 对局部失败应当有容错。
不要因为一个动作失败就让整个观影流程中断。

好的降级示例：

- 没有 scene -> 自动改走设备 fallback
- 投影失败 -> 继续做灯光、窗帘、电视等后续动作
- 切信号源失败 -> 保持已准备好的设备状态，继续其他可做动作
- 没有智能屏 -> 仍可完成 IoT 环境与设备动作
- 某个属性不支持 -> 跳过这个属性继续后面动作
- 内容层失败 -> 保持在“环境和设备已准备好”的状态，不假装电影已开始播放

## 为什么不能重做底层

除非必要，不要绕过 `xiaodu-control-official`，因为它已经：

- 分清了 `xiaodu` 与 `xiaodu-iot`
- 带有更安全的脚本约束
- 定义了能力边界与 schema 预期
- 让排障更容易聚焦在同一依赖层
续后面动作
- 内容层失败 -> 保持在“环境和设备已准备好”的状态，不假装电影已开始播放

## 为什么不能重做底层

除非必要，不要绕过 `xiaodu-control-official`，因为它已经：

- 分清了 `xiaodu` 与 `xiaodu-iot`
- 带有更安全的脚本约束
- 定义了能力边界与 schema 预期
- 让排障更容易聚焦在同一依赖层

_meta.json Metadata

{
  "ownerId": "kn7fxwq929kf8pz75n6a55wgrs82vxvs",
  "publishedAt": 1775206578814,
  "slug": "xiaodu-movie-mode-official",
  "version": "1.0.1"
}