Z7.03.1Editing existing automations设计研究
用户需能调整已有的自动化
别名: 自动化的可调整性 · 规则编辑 · end-user modification
概念解释
已建立的自动化必须可调整：条件改一改、阈值挪一挪、动作换一换——而不是一次配置定终身、要改只能推倒重来。这条要求把用户放在「自动化的作者」这个位置上：终端用户编程（end-user programming）的传统立场——用户不只是自动化的使用者，还是它的维护者，而作者需要编辑权。
它与「可创建」不同。多数产品在创建侧投入巨大（向导、模板、一键场景），编辑侧却异常贫瘠：改一条规则要先找到它（埋在几层菜单里）、看懂它（当初的配置早忘了）、动它（没有局部修改，只能删了重建）。创建是一次性事件，调整是长期伴随的劳动——投入错配在这两侧之间普遍存在。
机制
为什么初始配置必然不完善？三个来源叠加：
配置基于想象的使用。 安装时刻的规则来自用户对生活的想象（「晚上十点后自动关灯」），真实使用会暴露想象的偏差（周末也十点关太早）。配置错误不是用户的失误，是想象与现实的正常落差——所以调整不是例外路径，是必经路径。
需求随使用浮现。 很多调整项在安装时根本想不到（猫触发了移动传感器、冬夏需要不同阈值），它们只有在系统运行一段时间后才会显形。可调整性决定了这些浮现的需求有没有出口。
向导式配置固化参数。 一次性向导把参数锁死在安装时刻的语境里，且往往不给回访入口——用户想改时找不到当初那个向导，也没有等价的编辑界面。
三者合起来：不可调整的自动化必然漂移出用户需求，剩下的只是漂移速度的差别。
怎么研究
- 终端用户编程传统：从电子表格到智能家居，终端用户编程研究的核心关切一脉相承——非专业用户能否安全地表达与修改逻辑。智能家居语境下的 trigger-action 编程（条件触发动作）研究系统考察了用户创建与修改规则的正确率、常见错误类型与表达力上限。
- 修改任务实验：给被试一条已存在的规则与一个修改目标（「让它在周末不执行」），度量完成率、耗时、错误类型。这一范式比「从零创建」更贴近长期使用的真实负载，也更能暴露编辑界面的缺口——创建向导帮不上修改任务。
- 长期部署的配置演变分析：收集数月的使用日志，统计规则被修改的频率、修改的类型分布（调阈值多于改动作？）与修改后存活率——用数据说明「配置是活的」。
方法论注意点：实验里的修改目标是给定的，真实生活中用户要先意识到不满可以靠修改解决——这个元认知步骤在实验室测不到；日志分析里「从未修改」既可能是满意也可能是放弃，需要访谈区分。
边界
- 编辑能力有学习成本。 编辑界面本身是界面，表达力越强学习成本越高；对只想用预设的用户，编辑权的价值趋近于零。调整能力要分层供给：轻量调整（时间、阈值）零门槛，复杂改写（条件逻辑）可以留给少数用户。
- 不是一切参数都该开放。 涉及安全与设备保护的参数（功率上限、防误触锁定）保持只读是正当的——开放编辑的对象是行为逻辑，不是全部内部状态。
- 可调整不等于可微调。 粒度过细（每个传感器单独的灵敏度、每条规则的防抖参数全部暴露）会把维护变成专业工作；默认值好用、少数参数可调，比全参数可调更可维护。
怎么落地
- 规则的条件、时间窗、动作三段各自独立可编辑，改任何一段不必删除重建；「删除重来」应是编辑失败后的退路，不是唯一路径。
- 提供差异保存：调整后的规则可另存为新版本而不覆盖旧版，改坏了一键回退——降低「动它」的心理成本。
- 编辑入口与执行结果同处可达：从「这条规则昨晚没生效」的提示一步进入该规则的编辑，而不是穿越设置菜单。
- 验证办法：给一批已使用三个月的家庭布置三个真实修改任务（调时间、加例外、换动作），统计无求助完成率与耗时；再把应用内「删除重建」操作与「局部修改」操作的比例拉出来——重建占比高，说明编辑路径没有真正存在。