| 问题 | 答案 | 置信度 / 概率 |
|---|---|---|
| 尚无请求 | ||
设备状态只存在于本页面，刷新即恢复初始值。
推测式扇出。每条指令只发一次请求，里面放着程序可能用到的全部问题：请求类别、房间、设备、场景、是否复合指令、是否需要确认，以及“如果这是对灯的指令，要做什么”“如果这是对空调的指令，要做什么”这样针对每种设备的动作题和亮度、音量、温度等参数题。大部分问题对某一条指令来说是用不上的，但象信一号对同一份状态并行求值所有问题，多问一个几乎不增加耗时。答案回来后，由代码按类别和设备挑出需要的那几个（上表中的 ●），其余丢弃。
以“把全屋的灯都关掉”为例，代码只看四个答案：类别 = 设备控制，房间 = 全屋，设备 = 灯，灯的动作 = 关闭。
错误做法：顺序调用。先问类别；确定是设备控制后再问房间和设备；确定是灯之后再问灯的动作。这样问的问题最少，却要等三轮网络往返。本演示的评测脚本对同一批指令两种做法都跑了一遍，耗时对比见说明页。
用概率做决定。needs_confirmation 是一道 Noul 题，开门、启动烤箱这类操作概率高，代码据此弹出确认；房间或设备的置信度偏低时，代码提示追问，而不是贸然执行。
与大模型配合。象信一号不生成文本。当 is_compound 判定一句话里有多个操作时，交给大模型拆成单条指令，再逐条交给象信；当类别是闲聊或常识时，交给大模型自由回答。本演示暂未接入大模型，这两种情况会显示“需要大模型（演示未接入）”。
在线与离线。在线模式把 {request, state, questions} 发往同源代理 /demo-api/smart-home，页面本身不含任何 API 密钥。代理不可用时自动切换到离线回放：回放的是我们在真实运行中录下的象信响应，只覆盖下方示例指令。