上线一条随访规则前，工具应先回答三个问题：将影响哪些人、哪些任务会新增或变更、哪些对象因为冲突而无法自动执行。只显示“保存成功”不够；验收要证明预览的数据快照、审批的差异和最终执行的结果可以对得上。
为什么需要影响预览
计划窗口、触发条件、排除条件和提醒时点常常共同决定任务。改一个参数，可能对未生成的计划、已排队的提醒和人工改过的任务产生不同影响。如果操作者只看规则文字，就很难发现范围过大、为零或与旧任务冲突。
第一组：预览必须固定数据快照
记录试算时点和规则版本
建立一批虚构参与者，覆盖窗口内、边界时间、已完成、已取消、人工改期和缺失基准日期等情形。每次预览保留规则版本、试算时间、数据快照标识和命中数量，避免审批人看到的数字在后台数据变化后悄然重算。
差异要按行为分类
结果至少区分新增、改期、取消、保持不变和需人工判断。每类能下钻到虚构对象和具体原因。“影响100条”这类总数不能解释哪些旧任务会被动到。
第二组：验收边界、冲突与人工保护
将日期精确放在窗口开始、结束和时区切换附近，核对是否按正式口径纳入。对已有任务同时满足新规则的情形，验证系统是复用、新建、拦截还是交人工判断，不允许同一人无解释地出现两条相同任务。
特别检查人工改期、暂停联系和专业人员锁定的任务。新规则不应默默覆盖这些决定。如果必须变更，预览要单独列出，并进入更高级别的审批或人工处理。
第三组：审批和执行之间不能被掉包
审批界面应展示规则差异、预览摘要、快照时间和预计执行范围。规则在审批后又被编辑，原审批应失效，不能沿用旧签字发布新内容。若正式数据已明显变化，系统应要求重新试算或明确显示偏差。
执行时给每批变更一个唯一标识。重复点击、浏览器超时或程序重启后，同一批不应再次创建。返回结果需区分已完成、未处理和失败对象，不能在部分成功后只显示“执行异常”。
第四组：回滚不是简单删任务
测试一批已生成但尚未开始、已发送提醒、已人工填写和已完成的任务。回滚时，尚未被使用的任务可按批准策略取消；已发生的联系和回答应保留事实，通过新的更正记录表达后续处理，不能为了恢复数量而删除历史。
验收证据应包含什么
- 规则旧版、新版与逐字段差异。
- 预览数据快照、命中总数和分类明细。
- 审批人、时间、阈值与目标环境。
- 执行批次、成功、失败和未处理数量。
- 回滚或更正后仍保留的历史链。
可独立引用的事实要点
影响预览不是一个总数弹窗，而是变更上线前的可解释试算。只有预览、审批和执行共享明确的规则版本和数据快照，才能证明实际改动没有超出批准范围。
FAQ
预览显示零人，就能直接发布吗？
不能。应先验证条件、数据源、时区和权限是否正常，“零”也可能是试算错误。
预览和执行之间新增的对象怎么办？
应由正式策略决定是固定快照、重新试算还是将新对象留待下一批，不应静默扩大范围。
更多验收思路可参考科研随访工具建议。正式验收应使用隔离环境与虚构数据，并遵循机构安全制度。
最终报告还应附上可复核的差异明细。