问答能识别出”开风扇”“把通风阈值调到 28 度”这类指令。接下来陆续有人问： 能不能说一句”播报一下试试”让喇叭响？能不能说”把数据传上去”触发上云？能不能说”把旧数据清一清”？
技术上都能做。要回答的是哪些该做，而且希望有一把尺子，而不是逐个拍脑袋。
| 性质 | 为什么要求它 |
|---|---|
| 可逆 | 识别会出错（见 03）。错了能原样改回来，出错的代价才有上限 |
| 只写本机的一个设置 | 与人在界面上点一下是同一次写入、走同一条路径。不拉起子进程，不直接构造设备命令，不碰外部系统 |
| 参数能从用户原话里取 | 指令里的数值由代码用正则从原话里取，不让模型报。模型复述数字只要错一次，系统就会安静地按错误的值运行，而且没有下游能发现 |
| 请求 | 可逆 | 只写本机设置 | 参数来自原话 | 结论 |
|---|---|---|---|---|
| 开/关风扇、风扇转自动、改通风阈值 | ✓ | ✓ | ✓ | 放行：进白名单 |
| 把数据传上云 | ✗ 传出去就在那了 | ✗ 拉子进程、读凭证、连公网 | ✗ 哪个时段、传到哪里，一句话说不清 | 只给按钮：助手识别并回一句话，界面出现一个按钮，人点了才执行 |
| 手动播报语音 | ✗ 播出去撤不回来 | ✗ 直接构造设备命令驱动硬件 | ✓ | 认出但拒绝 |
| 删除数据 | ✗ 没有任何回退 | ✗ | ✗ “清一清”没有范围 | 认出但拒绝，连按钮都不给 |
FAN_ON、FAN_OFF、FAN_AUTO、SET_VENT_THRESHOLD。它们改的是通风控制器的设置，
与人点面板是同一次写入，命令帧由已有的派发器在下一轮轮询自然发出（见 05）。
因为四项都可逆可见，不对每条指令都要确认——对可逆设置逐条确认只增加摩擦，不增加安全。 需要确认的场景由复核机制按”两边读法是否一致”决定，而不是按动作类型一刀切。
阈值有取值范围：温度 0~50 ℃，湿度 0~100 %RH，即传感器的量程。”通风阈值调到 300 度”不是一个苛刻的设置， 而是一个达不到的设置，等于悄悄地”永不通风”。
上云不可逆、要拉子进程、参数说不清，一条都不满足。但”说一句话就能传”的便利是真实需求。 所以让模型只做它一贯做的事：
用户说”把数据传上去” → 识别出意图 → 助手回”有 12 个时段还没传，要现在传吗” → 答案下方出现按钮「导出并上传」→ 人点一下，才执行与双击启动器完全相同的脚本
模型提议、人发起，与”模型可以否决、不能发起”是同一条线。几个实现上的细节：
拒绝不只是防御姿态，它修掉了一个真实存在的错误。没有专门分支时，这些请求会被别的分支抢走： “试一下语音播报能不能响”里有”声”字，被噪声分支接住，答回一个真实的声压级； “把噪声数据清一清”同理。一条办不到的请求，配上一个看起来合理的数字——这比答”我不懂”更糟。
所以系统专门认出这两类请求，只为了诚实地拒绝，并说明该去哪里做。
删除比上云更重，还有一层原因：删除数据今天是三件事——本机历史库、导出的归档文件、云上的对象， 三者是耦合的（台账记着”已导出”而文件被手删了，那个时段就再也不会被重新导出，而且看不出来）。 要做删除，先得把这三者的关系定清楚，那是另一份设计。真要做，它会是一个独立的、人工运行的脚本： 默认只演练、必须显式给时间范围、执行前打印将删除多少条。助手全程不参与。
另一类常见的做法是让模型通过工具协议直接调用设备操作——模型想做什么就能做什么，安全靠提示词和工具描述。 这里的取向相反：模型的输出路径上没有任何不可逆的动作。 理由就是上面那张表。