在站立远距、低频操作、语音优先的设备条件下，定义轻服务进入体验的时机与承接形态。
这是一个基于既有训练框架展开的短期合作项目。我参与和输出的不是训练主流程，而是音乐、天气与闹钟等轻服务的接入方案。重点解决这些轻服务如何在镜面终端中被承接，并在不同使用状态下以合适的方式进入体验。
FITURE 是一种站立远距、低频操作、语音优先的镜面设备。在训练、浏览与任务操作等不同使用状态下，轻服务不能平均出现，而要根据当前前台任务切换承载方式。
镜面终端上，音乐的角色更接近广播而非播放器——启动后不再需要操控，直到用户不得不做决策的那一刻。这个定位决定了所有交互逻辑。
主任务是训练反馈，音乐是背景层。用户播放后不再操控——播放即是最完整的交互。
切歌、音量等操作皆由语音确认，执行后以 Toast 瞬间确认，拒绝控件常驻。临近结束 10s 才是唯一决策时刻。
面对开放式语音指令，系统不应随机盲猜。模糊意图需要通过取单分类收敛，明确意图需要直接执行，兼顾发现性与效率。
课程音频含节拍信号，外部音乐为纯偏好。自动延续音乐 = 覆盖指令音频，两轨并行必定冲突。音乐的后台播放必须基于用户的「主动选择」，而非系统默认越权。课程主音轨的优先级不可动摇。
同一信息在不同前台状态下密度必须被重新分配；天气数据的终点，是对「当下适合做什么」的判断。
晴
晴·夜
阴
多云
小雨
雷阵雨
小雪
大雪
霾
雾同一份气象数据，在健身上获得了普通 App 里没有的解读——围绕「运动」而非「出行」。
分别展示各维度数据，用户仍需自行判断。系统应综合温度、空气质量、紫外线、风速，输出运动指数与最佳时段。
用户问「现在出去冷不冷？」，设备知道温度和设施，但真正的答案不只是温度，而是身体状态与环境的安全关系。
当天气判断完成后，系统应从「今天不适合出门」直接推送「这是今天适合做的训练」，并在计划中安时主动介入。
健身镜是固定终端——响铃时用户可能在训练、刚醒、或不在镜前。提醒事项的设计必须以用户当前状态为起点，而非以时间为触发器。
创建、修改、删除全部通过对话完成；系统在合适时机提示可设什么；跑过的一次性闹钟自动清理。
推断来源是关键：只有用户做过明确行为（预约课程），系统才有把握直接建立；否则一律先问，用户决定。
从「知道要训练了」到「开始训练」之间的摩擦最小，用户越容易实际执行。
音乐、天气、闹钟三个模块里反复出现的规律，本质上是所有语音优先、低频操作、远距交互的智能终端都需要面对的设计约束。
接入服务前先回答：它在什么状态下出现？剩下多少注意力？答案决定形态，而非内容本身。
用户不会停下来阅读——只在必须做决定时开口。服务终点应是「完成一件事」，而非「看信息」。如果是信息，看完之后要做什么？能不能帮他做？
用户不知道能说什么，就等于这个能力不存在。健身镜上没有菜单、没有引导流程，系统必须在合适的时机主动提示「你可以说什么」。
不是所有主动服务都该直接做。这个行为是用户已经表达过意图的，还是系统自己猜的。猜的就问，明确的才做。