Z5.07.2Concrete action preview设计
预演结果需要展示将被触发的具体动作
别名: 动作级预演 · 具体预演 · preview specificity
概念解释
预演的价值取决于它展示到多细。「规则有效」「语法正确」「将触发 1 条自动化」这类抽象反馈近乎无用——它验证的是规则可运行，不是规则对不对。有效的预演必须落到设备级动作清单：「将执行：廊灯调至 100% 并保持 10 分钟；向妈妈的手机发送通知『门已开』」。用户拿这张清单对照自己的意图，对得上才启用。
抽象与具体的分界线就一条：用户能否从展示内容走到「和我想要的一样吗」的判断。「会触发」到不了这个判断，「触发后做什么、对哪个设备、什么参数、通知谁」到得了。
机制
为什么必须具体到动作级？因为规则错误的形态几乎都藏在从条件到动作的映射链上，而抽象反馈把这条链折叠掉了：
- 目标错：条件没错，动的设备错了（廊灯 vs 客厅灯）——只在设备级清单里可见。
- 参数错：设备对了，值错了（10% 亮度 vs 100%）——只在参数展开时可见。
- 范围错：动作作用到「所有灯」还是「这盏灯」，是规则语言里最静默的歧义，清单里「客厅灯、餐厅灯、卧室灯……」一列出来就自明。
- 顺序与竞争错：多个动作的执行顺序、与其他规则的覆盖关系，只有逐项展开才能对照。
抽象反馈「有效」验证的是语法层；上述四类全是语义层错误，语法层完全通过。预演如果只报「有效」，等于只做了用户本来就知道的事（保存成功已经说明语法没错），把真正的验证任务空转了一圈。
具体展示还有一层认知机制：对照需要锚点。用户判断「这是不是我想要的」，靠的是把展示内容与记忆中的意图逐项比对——工作记忆里没有展开的清单就没有可比对的锚点，判断退化为整体直觉（「感觉差不多」），而直觉恰恰是创建规则时已经出错的那套东西，再用它验证等于用被告审被告。
边界
- 具体度有阅读成本的上限。 动作超过十条的规则（全屋离家断电）逐项展示自身成为负担；正确做法是分组摘要 + 可展开（「关灯 ×12（展开）」），而不是全部折叠成一行数字，也不是倾倒全部细节。
- 「将被触发」的确定性受预演类型限制。 历史回放说「上月会触发 4 次」，是统计陈述不是未来承诺；展示措辞要如实（「按上月数据」），把确定性说满会制造新的错误信任。
- 具体动作 ≠ 物理后果。 清单展示到「插座断电」，不展示「烘干中的程式会被中断」——后果推演层（这对家里正在发生的事意味着什么）超出动作清单的表达力，重后果规则需要另行提示，不能指望清单自己说清。
- 通知类动作的展示有隐私边界。 「将向妈妈发送通知」的预演不应真的渲染完整通知文案给在场所有人看——预演本身的展示也要分场合。
怎么落地
- 预演输出固定为三段清单：条件何时为真（时间与来源）、将执行的动作（设备、参数、顺序）、将发出的通知（给谁、内容摘要）——三段各自可展开，默认展开动作段。
- 范围歧义显式化：动作对象是「组」时列出组成员（「所有灯 = 客厅、餐厅、卧室、走廊」）；组员变了规则行为会跟着变，这个联动关系在清单里就要可见。
- 通知与消息类动作预演真实渲染一条样例（用一个真实模板示例），参数占位填入演示值——用户对通知的感知就是文案本身，抽象描述「发送通知」无法验证。
- 多规则交互的预演列出同场景其他规则：「此条件还会触发『节能模式』，两者对空调的指令冲突，当前按优先级执行节能」——规则不是孤立生效的，预演只看单条会漏掉竞争。
- 验证办法：让用户看完预演清单后复述「这条规则会做什么」，再与实际规则比对——复述遗漏点与清单折叠点重合的位置，就是具体度不够的位置；上线后统计「预演后修改」的规则里改动落在哪个字段（设备？参数？范围？），那是展示已经在救人的地方。