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 预期
• 让排障更容易聚焦在同一依赖层