状态一致性
跨语义、声音、表情与生理线索
驾驶提醒
注意力、紧张与疲劳相关提示
DRIVEalert
多模态输入
摄像头、麦克风与毫米波信号
CAM
MIC
MMW
个体基线
连续交互里的状态趋势
情绪到动作
把结果交给界面、声音或设备动作
1
选择一个你关心的场景
每个 demo 只回答一个问题，几分钟就能看清 EmoraOS 会如何参与一次真实交互。
Demo 01
多模态状态一致性体验
当文字说“没事”，声音和表情却不一样时，看看 EmoraOS 会如何理解。
DRIVEalert
Demo 02
驾驶状态提醒
用一段模拟驾驶素材，看系统如何发现注意力、紧张和疲劳相关变化。
CAM
MIC
MMW
Demo 03
情绪解释对比
比较“只给一个标签”和“说明为什么”两种结果，找到更适合产品的表达。
Demo 04
个体基线 / 情绪趋势
用一段连续互动，比较眼前状态和这个人平时的习惯。
Demo 05
情绪到动作反馈
把理解交给灯光、声音、角色或设备动作，直接比较不同反馈。
2
一次体验，四个画面
不用猜系统内部发生了什么，关键输入、理解和反馈会依次呈现。
01
多模态输入
先看到文字、声音、表情或生理信号发生了什么。
02
状态理解
再看 EmoraOS 如何结合当时的情境，理解状态和变化。
03
API 输出
应用收到结构化结果，知道发生了什么，也知道结果有多确定。
04
交互反馈
最后比较语言、界面、灯光、声音或动作会带来什么不同。
3
把看见的效果带回你的产品
体验结束后，你会更清楚 EmoraOS 是否适合自己的设备，以及接下来该从哪里开始。
场景脚本
用一个具体的人、设备和时刻，把产品设想讲清楚。
理解依据
看到哪些信号影响了当前结果，也看见系统拿不准的地方。
参数调节
调整提醒时机、触发条件和反馈方式，比较哪种体验更自然。
下一步接入
确认需要的 API、示例项目和传感器，再开始自己的设备验证。
4
有些决定，应该始终由人来做
Playground 帮助团队理解和改进产品，不替代医生、法官、招聘者或其他专业人员作决定。
先让参与者知道
体验开始前，清楚说明会读取什么、为什么读取，以及是否保存。
重要决定交给人
不要用 demo 结果判断一个人的资格、品格、健康或法律事实。
拿不准就直说
信号矛盾或不足时，明确告诉用户“还不能确定”，不要强行下结论。
最后看人是否受益
真正的标准是用户是否更容易理解和使用产品，而不是 demo 是否炫目。
想把自己的场景放进 Playground？
告诉我们你在做什么产品、用户是谁、设备会在什么时刻回应，我们可以一起准备更贴近实际使用的演示。