Z5.04.1Trigger-action programming设计研究
条件语句对非专业用户门槛高
别名: TAP · 条件动作编程 · 条件触发规则
概念解释
多设备编排的事实标准表达是条件-动作规则：当某个条件成立时，执行某个动作。这套范式通常叫触发-动作编程（trigger-action programming, TAP）——「日落时开廊灯」「离家后关掉所有插座」。它对工程师是自然形式，对普通用户是真实的编程门槛：大量用户想要自动化，却写不出（或写错）自己想要的规则。
门槛不是「不会操作界面」，而是形式语言的构造本身。规则要无歧义地可执行，这就要求用户掌握一套日常语言里没有对应训练的表达能力。
机制
门槛具体来自三层：
一是语法层。正确的条件需要区分事件（一次性发生：门被打开）与状态（持续成立：门是开的）、需要布尔组合（与/或/非）和量词（任何一个/全部）。这些是形式语言的构件，日常交流不训练。同一个触发词在产品 A 里是事件、在产品 B 里是状态，用户更无从建立稳定预期。
二是语义精确性。规则引擎要求把模糊的生活描述压成精确参数，而用户的意图天然是模糊的。「晚上到家」——几点算晚上，日落还是时钟？「到家」以什么传感为准，GPS 进入围栏还是门磁开合？每一个「显然」都藏着一次用户没意识到的决策。
三是词汇层。组装规则前必须先学会平台的概念清单：哪些设备、哪些属性、哪些比较符、触发与动作各自的边界在哪。这个名词空间本身就是一套术语表。
怎么研究
- Ur 等人 2014 年在 CHI 发表的「Trigger-Action Programming in the Wild」用互联网样本考察普通用户的 TAP 能力：大量用户表达过自动化愿望，但从愿望到正确规则的成功率分布很差，对规则语义的理解错误常见。
- Huang 与 Cakmak 2015 年的系列实验考察 TAP 的表达形式如何影响非专业用户：把触发器与动作封装成语义化的预定义描述（而不是裸的比较表达式），用户构造规则的正确率显著提高。
- 常用方法：给被试一段自然语言描述的自动化愿望，请其在真实平台或纸面构件上组装规则，按正确性计分；反向任务是给规则请被试复述含义——复述错误率是门槛的直接量度，比组装任务更能暴露理解问题。
方法论注意点：实验室组装任务的正确率会高估真实水平——被试知道自己在被考察、有实验员在场可问；真实家庭里用户面对的是「要不要建这条规则」的自愿决策，门槛在「没想到可以」「怕建错」处就拦截了人，任务根本不会发生。
边界
- 门槛是形式语言问题，不是能力问题。 有编程经验的用户不受此限；把它当成「用户太笨」会导出错误的对策（更多教程），正确的对策是换表达形式。
- 简单规则门槛可接受。 单触发单动作、语义明确的规则，多数用户能正确建立；门槛随组合复杂度陡增。评估门槛要按目标规则复杂度分层，不能笼统说「TAP 难」。
- 语音入口不缓解语法门槛。 用语音念出规则只是换了输入通道，布尔组合与参数精确性的要求原封不动。
怎么落地
- 默认入口只暴露单触发、单动作的结构；布尔组合、多设备动作折叠进二级「高级」层，让第一层保持零语法。
- 用语义化组件替代裸比较符：「天黑之后」而不是「光照度 < 80 lux 且持续 5 分钟」；参数藏在组件默认值里，允许展开修改。
- 把事件与状态的区分做成显式选择项（「当门打开的那一刻」/「当门处于打开状态时」），不要让用户从触发器清单里自己悟。
- 验证办法：找目标用户做只读复述——呈现规则，请其用自己的话说出「什么时候会发生什么」。复述错误率高的构造（布尔组合、时间限定、多动作顺序）就是需要封装的构造。