条件触发动作是基本模型
别名: 触发-动作编程 · TAP · 条件自动化
概念解释
智能家居与多设备自动化的基本构建单元是触发-动作编程（trigger-action programming, TAP）：当某条件成立时，则执行某动作。「日落时开客厅灯」「检测到人离开家，关掉所有电器」「湿度低于 40%，打开加湿器」——每条自动化都是这个句式的一次填空。
它是一种编程：用户在用规则给系统写程序，只是语法被压缩到一次下拉选择加两次点击。这解释了它为什么既是门槛最低的自动化形式（不需要学控制流、循环、变量），又继承了程序的全部麻烦——规则会交互、会冲突、会失效，只是账单延迟到运行时才寄到。
机制
TAP 之所以能成为默认模型，是因为它把编程削减到了三个都已在用户词汇表里的成分：事件（来自传感器或平台渠道——日落、回家、有人移动）、条件（可选的限定）、动作（对设备的指令）。三者都映射到用户已有的世界知识，不需要引入任何计算概念。
更深一层，规则句式复用了人解释日常行为时本来的因果结构。「下雨就收衣服」是人本来就有的推理格式，TAP 只是把主语从人换成了系统。学TAP 不是学新语法，是学「哪些传感器信号可以被引用」——这是真实的学习负担所在，也是各平台差异最大的地方。
模型的能力上限也内嵌在这个句式里：一条规则只描述一个触发场景到一个动作序列的映射。规则之间怎么配合、冲突了听谁的、动作改变了状态之后另一条规则怎么反应——这些都不在任何单条规则的表达范围内。基本模型天然把复杂度留给运行时。
怎么研究
trigger-action programming 有成型的在野研究线：
- Ur 等 2014 年的 CHI 研究调查了 IFTTT 真实用户的规则集：绝大多数规则是单触发、单动作的简单形态，集中在同步与通知类例行事务；多触发、多动作的组合极少使用。这说明普通用户会自发把使用停留在模型的表达力底部。
- Dey 等 2014 年的 CHI 工作（iCAP）探索了面向物理空间的低门槛 TAP 工具，把触发与动作都锚定到用户身边的设备与传感器，检验「不抽象出计算概念」能走多远。
- Huang 与 Cakmak 2015 年比较了 TAP 的不同表达方式，发现对触发与动作给出语义化描述（而不只是设备-事件列表）能显著降低创建规则的出错率。
常见做法是规则语料分析：从平台或研究部署中收集真实规则集，统计触发源分布、动作分布、规则复杂度与共享设备的程度。这类数据既是模型能力的经验刻画，也是冲突与规模问题的预测输入。方法论注意点：平台语料受渠道供给影响——某个触发源用得多，可能只因为它被平台推广，不代表需求本身。
边界
- TAP 是易用性与表达力的折中，不是自动化设计的终点。 时序依赖（先 A 后 B）、跨规则状态引用、「否则」分支，都超出基本句式；平台靠叠加特例语法（延时、条件组）补洞，每补一个都在提高学习成本。
- 真实用户规则集的简单性是回避不是上限。 简单规则的占绝大多数，既说明模型对入门友好，也说明复杂需求被默默放弃了——用户不是不需要时序，是表达不出来就不再尝试。把「大家只用简单规则」读成「简单规则够用」会得出错误的产品结论。
- 规则的生命周期绑定平台渠道。 触发源是平台供给的服务，服务变更或下线时规则静默死亡——这是平台生态问题，此处只作为模型的结构性风险记一笔。
怎么落地
- 把所有自动化暴露为同一种规则对象：不管用户用语音、向导还是模板创建的，最终都落到可统一查看与管理的规则模型上——用户的心智里只该有一个「自动化」的类别。
- 触发条件优先用设备已有的信号（在场、门磁、照度），少依赖平台专属渠道；动作端给「一组设备」的批量化（「关所有灯」）。
- 规则命名用效果语言而不是配置语言：「离开家关灯」好于「移动传感器 A 触发→灯组 X off」。
- 验证办法：让老用户复述自己某条规则的触发条件与动作，复述失败率高的规则就是会被误归因、误操作的候选。