规则直接依赖某个品牌的原始字段，换设备时就要重画全部流程。适配层可以保留业务语义。
本文使用米家设备、网关与 Node-RED 的架构研究，接入能力按具体型号确认。米家不是一个所有设备都开放相同本地接口的统一协议。设备型号、网关和固件会影响可用能力，本文不声称任意设备都能绕过云端或直接接受自定义控制。
1. 从现象推到机制
设备适配器把原始字段转换为统一能力，例如温度读取和灯状态，规则层只使用已确认能力。没有公开或授权接口的操作应标为不支持，不能通过填默认成功掩盖。
图中的四个节点分别表示设备接口、适配转换、规则层、状态回读。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先用虚拟设备实现统一输入和命令回读，再为一个确认支持的设备增加适配器。转换保留来源、质量和时间，便于定位错误；反馈另含 reported、observed_at 和 result。
1
2
{"device":"demo-lamp","capability":"switch",
"desired":"on","command_id":"cmd-7"}
先核对本人设备支持的公开接口与授权方式，再用模拟设备打通流程。凭据只在受控配置保存；不提供账户绕过、私有密钥提取或未经确认的实物控制命令。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 更换原始字段名称 | 应主要修改适配器映射 |
| 设备没有某项能力 | 明确返回不支持 |
| 转换丢掉时间和质量 | 规则可能误用过期状态 |
对照 1：更换原始字段名称
应主要修改适配器映射。观察时记录规则层是否仍依赖品牌字段。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：设备没有某项能力
明确返回不支持。观察时记录能力声明与实际接口。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：转换丢掉时间和质量
规则可能误用过期状态。观察时记录统一消息保留的来源字段。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
统一模型不能抹平真实差异。调光范围、反馈延迟和离线能力都应保留约束，不强行把所有设备包装成一样。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“转换丢掉时间和质量”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
