- name
- xiaodu-senior-night-assist-official
- description
- 基于已安装的 xiaodu-control-official 编排老人夜间短时起身的安全辅助场景。当用户说“夜里起夜”“我要去卫生间”“帮我开一下夜灯”“夜间辅助模式”这类请求时使用。这个 skill 会复用 xiaodu-control-official 的现有脚本,对小度智能屏和小度 IoT 设备执行 scene-first 的夜间辅助编排,而不是重做底层控制。它的目标不是普通开灯,而是用最少的光、最短的话和最稳的收尾,帮助老人安全完成夜间短时活动。
xiaodu-senior-night-assist-official
仅在已确认 xiaodu-control-official 已安装,且 mcporter 已经配置好 xiaodu 与 xiaodu-iot 时使用本 skill。
目的
处理“老人半夜临时起身”的家庭场景请求。 这是一个安全辅助编排 skill,不是底层控制 skill。 所有底层控制都应优先复用 skills/xiaodu-control-official。
依赖与路由规则
- 优先复用这些现有脚本:
- skills/xiaodu-control-official/scripts/list_scenes.sh - skills/xiaodu-control-official/scripts/trigger_scene.sh - skills/xiaodu-control-official/scripts/list_iot_devices.sh - skills/xiaodu-control-official/scripts/control_iot.sh - skills/xiaodu-control-official/scripts/list_devices.sh - skills/xiaodu-control-official/scripts/speak.sh
- 本 skill 自己还提供一个自动收尾脚本:
- scripts/night_light_tail.sh
- 家电控制优先走
xiaodu-iot。 - 智能屏短播报优先走
xiaodu。 - 除非依赖脚本缺失或明显损坏,否则不要绕过依赖 skill 重写底层 MCP 调用。
典型触发词
把以下表达视为强触发:
- 夜里起夜
- 我要去卫生间
- 帮我开一下夜灯
- 夜间辅助模式
- 我起夜了
- 去趟厕所
- 太黑了
- 我要喝水,开一下灯
核心原则
1)路径安全优先
这个 skill 的第一目标不是“把灯打开”,而是:
让老人安全完成一小段夜间动线。
2)默认低刺激
默认只做这些:
- 暖光
- 低亮度
- 短播报
- 小范围照明
不要默认:
- 全屋大亮
- 冷白光
- 长篇播报
- 放音乐 / 新闻 / 其他内容
3)自动收尾属于主流程
夜间辅助模式必须默认自带收尾:
- 防止老人回床后忘记关灯
- 防止灯一直亮着
- 防止整晚高亮影响休息
4)保守控制
- 不默认全屋开灯
- 不默认控错房间
- 不默认调整空调
- 不默认放内容
基于 xiaodu-control-official 事实能力全集的统一规划框架
所有夜间辅助规划都只能建立在 xiaodu-control-official 已明确记录的能力 bucket 上。 不要加入想象中的设备族、动作或参数。
允许使用的规划 bucket 只有 5 个:
- scene
- 来源:list_scenes.sh / trigger_scene.sh
- lights(夜间灯光)
- 来源:list_iot_devices.sh / control_iot.sh - 用于夜灯、床边灯、走廊灯、卫生间灯等
- thermal comfort(体感舒适)
- 来源:list_iot_devices.sh / control_iot.sh - 仅在用户明确说冷 / 热 / 闷时才使用
- smart-screen speech(智能屏短播报)
- 来源:list_devices.sh / speak.sh
- timed tail / auto-off(自动收尾)
- 来源:本 skill 自带延时收尾脚本 - 用于几分钟后自动关闭本次开启的灯
规划顺序:
- 先判断这次请求涉及哪些 bucket。
- 再检查当前环境真实支持哪些 bucket。
- 删除不支持的 bucket。
- 再判断这次请求属于:
- 路径照明模式 - 局部照明模式
- 把剩余 bucket 排成最安全的夜间执行顺序。
- 按 bucket 逐步执行,能做几步做几步。
- 同一条 night-assist 流程里的所有命令都必须串行执行。
- 上一个命令返回后,才能发下一个命令。 - 不要把 xiaodu 或 xiaodu-iot 的控制命令并发打出去。 - 如果上一个命令失败,后面的命令直接继续执行,不要因为单点失败中断整条流程。
- 如果缺少继续执行所必需的信息,只问一个最小确认问题。
- 执行结束后,把用户的调整吸收为后续偏好。
偏好记忆与复用
把用户对夜间辅助流程的调整当成可复用偏好。 如果用户修正了默认夜灯、默认路径灯顺序、亮度、色温、自动收尾时间、是否播报等,下次应优先沿用。
至少要支持沉淀这些偏好:
- 默认夜灯设备
- 默认路径灯顺序
- 默认亮度
- 10% - 20% - 30%
- 默认色温
- 暖黄
- 默认自动关闭时间
- 3 分钟 - 5 分钟 - 10 分钟
- 是否默认播报
- 播一句 - 不播报
- 默认避免控制的灯 / 房间
- 默认优先模式
- 路径照明优先 - 局部照明优先
存储规则:
- 小度 / 家庭场景的短中期偏好,优先写入
XIAODU_CONTEXT.md。 - 长期稳定偏好,写入
MEMORY.md。 - 如果没有真的写入文件,就不要假装“已经记住”。
复用规则:
- 下次执行前,先检查已有偏好能否直接解决设备选择问题。
- 如果已有偏好足够明确,就直接执行,不要重复问。
- 如果已有偏好与当前环境或当前用户表达冲突,优先当前请求,并在执行后更新偏好。
标准执行流程
1)先确认依赖可用
只做这次请求真正需要的最小检查:
- 确认
skills/xiaodu-control-official存在。 - 确认关键依赖脚本存在。
- 如果这次请求可能涉及 IoT,先读场景,再读 IoT 设备。
- 如果这次请求需要短播报,先解析出一个可用智能屏。
- 确认本 skill 的自动收尾脚本存在。
如果依赖 skill 不可用,就停止并明确说明此 skill 依赖 xiaodu-control-official。
2)优先尝试 scene-first
- 用
list_scenes.sh读取现有场景。 - 优先寻找高匹配场景,例如:
- 夜灯 - 夜间 - 起夜 - 夜间辅助 - 晚上起身
- 如果找到高置信度场景,优先触发。
- 触发成功后,再补一句简短播报。
- 然后挂自动收尾。
推荐播报口径:
- 夜灯已经开好了,慢一点走。
- 路径灯已经打开了,注意脚下。
- 灯已经帮你开好了,别着急。
如果 scene 触发失败,不能假装成功。
3)没有 scene 时,进入基于事实 bucket 的 fallback 规划
如果没有匹配 scene,不要直接退化成只说一句话。 而是继续基于事实 bucket 做结构化 fallback。
- 读取 IoT 设备。
- 根据 query 判断是:
- 路径照明模式 - 局部照明模式
- 只考虑这些 fallback bucket:
- lights:打开、调低亮度、调暖色温 - smart-screen speech:一句简短安全播报 - thermal comfort:仅在明确说冷/热时附加 - timed tail:延时关灯
- IoT bucket 只允许使用同时满足以下条件的设备:
- 真实存在于当前设备列表 - 与目标房间相关,或已被用户明确指定
- 安全执行顺序:
- scene(如果有) - lights - smart-screen speech - thermal comfort(如明确需要) - timed tail
- 某个 bucket 没有合适设备就跳过,不影响其他 bucket。
- 如果多个目标都可能合理,只问一个最小确认问题。
关键原则: 没有 scene,不等于退出;而是进入基于事实能力的结构化 fallback。
4)路径照明 / 局部照明分流规则
路径照明模式
以下表达默认进入路径照明:
- 夜里起夜
- 我要去卫生间
- 我起夜了
- 去趟厕所
- 帮我开一下去卫生间的灯
默认顺序:
- 床边灯 / 夜灯
- 走廊灯
- 卫生间灯
局部照明模式
以下表达默认进入局部照明:
- 帮我开一下夜灯
- 太黑了
- 我要喝水
- 开一下床边灯
- 开个小灯就行
默认动作:
- 优先开最近的一盏柔和灯
- 不自动扩展成整条路径
- 自动收尾时间更短
温控附加条件
如果 query 同时带有:
- 冷
- 热
- 闷
则在主模式基础上附加轻微温控。
5)通用实际调用链
对于这种高层请求:
夜里起夜
默认调用链应当是:
bash ../xiaodu-control-official/scripts/list_scenes.sh --server xiaodu-iot- 如果存在高置信度 night-assist scene:
- bash ../xiaodu-control-official/scripts/trigger_scene.sh --scene-name "..." --server xiaodu-iot
- 否则:
- 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/list_devices.sh --server xiaodubash ../xiaodu-control-official/scripts/speak.sh ...- 如果用户明确提到冷 / 热,再做轻微温控:
- bash ../xiaodu-control-official/scripts/control_iot.sh ...
- 挂自动收尾:
- bash scripts/night_light_tail.sh --device-name "..." --delay-minutes 5
对于:
帮我开一下夜灯
则把第 3 步缩成单灯优先,不扩展整条路径,并把自动收尾改成更短时间。
降级原则
- 没有 scene -> 自动改走设备 fallback
- 找不到路径灯 -> 至少开一盏最接近的柔和灯
- 某个灯失败 -> 继续尝试后面的可用灯
- 没有智能屏 -> 仍然完成灯光动作,不假装播报已成功
- 色温 / 亮度不支持 -> 只做开灯,不终止整个流程
- 自动收尾脚本不可用 -> 明确说明“灯已经开好,但这次不会自动关”
极简确认规则
只有在继续执行确实缺信息时才问。
可能需要确认的情况:
- 有多个合理灯光目标,路径不清楚
- 同时有卧室灯 / 客厅灯 / 走廊灯,不知道该开哪个
- 不问就可能控错房间
推荐确认口径:
- 你是要去卫生间,还是只开床边灯?
不应该确认的情况:
- 只有一个明确夜灯目标
- 用户已经说了“走廊灯”“卫生间灯”
- 已有固定偏好
防误控规则
- 不要默认全屋开灯
- 不要默认最亮
- 不要默认冷白光
- 不要默认开电视
- 不要默认放内容
- 不要在没必要时调空调
- 不要长篇播报
- 不要控错房间
面向用户的回复风格
这个模式的汇报必须:
- 短
- 稳
- 低打扰
- 有安全感
- 不技术化
推荐口径:
- 夜灯已经开好了,慢一点走。
- 路径灯已经打开了,注意脚下。
- 灯已经帮你开好了,过几分钟我会自动关掉。
避免这样说:
- 我现在为你执行夜间安全辅助链路
- 我已经调用灯光系统
- 现在开始执行定时关灯
示例请求
- 夜里起夜。
- 我要去卫生间。
- 帮我开一下夜灯。
- 太黑了。
- 我要喝水,开一下灯。
- 夜间辅助模式。
按需阅读的引用文档
- 需要看更细的编排说明时,读
references/usage-notes.md - 需要看测试边界与验证项时,读
references/test-cases.md