模板降低门槛但限制表达
别名: 向导式创建 · 规则模板 · recipe 模板
概念解释
应对条件语句门槛的主流产品方案是模板（template / recipe）：预置「日落时打开某某灯」这样的规则骨架，用户只填设备、时间几个空。模板把「写规则」变成「填表」，门槛骤降；同时它设定了表达上限——用户能建立的自动化，囿于模板作者预想过的形状。
这是一个刻意的交换：用表达力的窄化换取可及性的扩大。问题在于交换的条款没有写在任何地方，用户不知道自己被限制在什么范围里。
机制
模板降低门槛的机制是设计决策的转移。布尔结构、事件与状态的区分、触发条件的量词、防抖与生效时段——这些难点由模板作者预先决定，用户只在参数层活动（选哪个灯、几点）。难点没有消失，只是从用户侧挪到了作者侧。
表达受限则是同一枚硬币的反面：模板空间是作者想象的投影。用户的真实需求里超出模板形状的部分——「空调调到比室外低三度、但不超过二十六度」「除我之外有人在家时别推送」——在模板体系里无处安放，只能放弃需求，或拼凑一个近似模板然后接受它的偏差。
还有一个更慢的后果：模板塑造需求。用户从模板清单里「挑」需求，而不是把需求「表达」出来。清单上没有的自动化不会进入用户对系统的想象，长期使用会把用户对「这套系统还能干什么」的预期收敛到模板库的边界上——表达能力限制最终变成想象力限制。
怎么研究
终端用户编程（end-user programming）研究对向导式构造的比较结论是稳健的：模板路径的构造正确率显著高于自由构造，但可表达的意图类别显著少于自由构造；在触发-动作编程的实地与调查研究中，用户想要但所选平台的模板无法覆盖的自动化，是弃用与不满的稳定来源之一。
常用方法：给同一批用户分别用模板与自由构造表达同一组标准化意图，比较正确率、完成时间与「无法表达」的比例；再以日记法或访谈追踪真实家庭数月，看模板体系里长期存活的规则种类分布是否收敛。
方法论注意点：实验室里「无法表达」的比例会被低估——被试拿到的是实验者挑好的、通常恰好适配模板的意图；真实需求的长尾只有在自由汇报（你还有什么想让家里自动做的）里才显形。
边界
- 模板对高频共性需求是正确工具。 开灯、关灯、定时、离家——这些占日常自动化的大头，模板的窄化在它们身上没有代价。损失集中在长尾，评估时要看长尾被切掉多少，而不是平均正确率。
- 「模板 + 自定义」混合不是免费午餐。 它保留了两条通路，也就把两套心智模型叠给用户：什么时候该找模板、什么时候该进自定义，这本身是新的判断负担。
- 上限随模板库扩张而缓解，但不消失。 增加模板摊薄检索成本上升的问题——一千个模板里找不到想要的，与没有这个模板，用户体验上差别不大。
怎么落地
- 把模板做成起点而非终点：每条模板可以「解包」成完全可编辑的规则，让用户从近似的形状出发改到自己的形状，而不是在填空与编程之间二选一。
- 模板库按生活任务组织（起床、离家、看护、节能），不按设备类型组织——用户带着任务来，不带着设备型号来。
- 在模板清单的尽头放显式出口：「没找到想要的？从空白规则开始」——死路会教用户「系统就只能干这些」。
- 验证办法：统计模板创建后七日内的解包率与二次编辑率（模板是否被当作起点）；统计「浏览模板库后未创建任何规则即离开」的比例（上限是否在拦截需求）。