联动条件设置对非技术用户存在较高门槛
别名: 条件配置门槛 · trigger 设置 · 联动规则创建困难
概念解释
场景的「动作侧」（做什么）用户大体能对付；真正卡住非技术用户的是条件侧（什么时候做）。「日落且家里有人时开灯」这样的联动，要求用户把日常语言翻译成系统触发器、理解多个条件的组合方式、分清「触发」与「前提」的区别。经验研究反复发现：用户建得出的联动远比他们想要建的简单，差距主要落在条件侧。
这不是态度问题——愿意学也未必学得会，因为条件语义里有几个连程序员都会踩的坑。
机制
门槛是三层叠加的，一层比一层隐蔽。
第一层：语言到触发器的映射。「天黑了」对应哪个触发器？日落时刻？光照传感器低于阈值？还是「日落加三十分钟」？每个日常说法对应系统里好几个候选，选哪个取决于房屋朝向、季节、传感器位置——这些知识用户没有，系统也不给建议。
第二层：组合语义。 多条件用什么连接——「与」「或」各是什么效果？嵌套怎么读？经验上用户对 AND/OR 的混用率很高，且错误不被察觉，因为组合错了的规则看起来和正确的一样。
第三层（最隐蔽）：事件与状态的混淆。「触发器」是事件——发生一次（「门打开了」），而「条件」是状态——持续成立（「家里有人」）。联动「门打开且家里无人时报警」的语义取决于「家里无人」是状态判断还是事件序列，两者的行为差异在边界情形（人刚走、传感器延迟）显形。这组区分连受过训练的人都会弄错。
再叠一个结构性原因：条件没有试错回路。按钮按错立刻看到结果，可以试出来；而触发条件要等世界真的产生那个状态才知道对不对——「等下雨来验证雨量联动」在时间上不可操作。图形界面之所以可自学，靠的就是「试-看-改」的紧回路；条件配置恰恰没有这个回路，学不会是结构注定的。
怎么研究
- 创作+预测范式：请用户创建联动后，再让他们预测给定情境下规则是否触发（呈现具体场景：「晚上八点，家里没人，门开了——会报警吗」）。预测正确率是条件语义理解的最干净度量，比自评或完成率都硬。Ur 等人 2014 年对 IFTTT 用户的调查发现用户对规则行为的预测经常失准，且希望存在的触发器大量缺失——想要的条件在系统里找不到，是门槛的第一现场。
- Huang 与 Cakmak 2015 年（CHI）对触发-动作编程心智模型的研究直接考察用户如何理解触发与条件的因果结构，并测试帮助理解的表达方式；这一系工作把「用户怎么误解」变成了可实验操纵的变量。
- 入户构建观察：真实家庭搭联动的出声思考记录，能捕捉预测任务测不到的「放弃在翻译开始之前」的案例。
方法论注意点：实验室预测任务用文字情境，真实触发依赖传感器的时间与空间细节（运动传感器在哪个房间、几点后算夜间）；两边的错误率不能直接比，报告时要说明情境呈现方式。
边界
- 单触发单动作是可达的。 IFTTT 式的一条线规则，非技术用户大量在用且用得对；门槛在组合与时间语义，不在「规则」概念本身。评估要区分这两级。
- 技术背景降低但不消除门槛。 会编程的人组条件快，但事件/状态混淆照样发生——这是语义设计问题，不是用户水平问题。
- 语音入口改变门槛形状而非消除门槛。 口头说「到家时开灯」容易，但口头修一个嵌套条件（「刚才那个改成只有工作日」）比图形界面更难核对——改条件阶段的门槛反而可能升高。
怎么落地
- 条件保存时回显为日常语言：「工作日 18:00 后，且家里有人 → 开客厅灯」，让用户核对语义而不是核对结构。
- 提供**「现在会触发吗」测试器**：一键检查当前时刻各条件真假，部分重建被缺掉的试错回路；不能实时验证的（如下雨）给出最近一次满足的时间。
- 组合默认单层与关系，嵌套作为高级模式隐藏；「触发/条件」的区别在界面上用显式文案区分（「当……发生」vs「且……成立时」），不靠用户悟。
- 预设高频条件组（有人在家 / 夜间 / 工作日白天）作为可复用块。
- 验证办法：创作+预测任务里非技术用户的预测正确率；上线后统计「创建后 48 小时内被编辑」的比例——大量立刻返工说明创建时语义没对齐。