重复日程怎么设计？修改范围与例外日期

重复日程要把“一整个系列”和“其中某一次”分开设计。用户修改时间、地点或取消会议时，先显示选中的具体日期，再让他选择本次、本次及以后或整个系列，并预览会影响哪些日程。已经单独改过的例外日期需要明确处理，不能在一次批量修改中悄悄恢复原样。

以每周三上午10点的项目例会为例：某周临时改时、下一周取消、后续更换会议室，分别影响不同对象。用Pixso原型设计把日历、单次详情、修改范围和结果日历接起来，可以直接演示这几种区别。

同样叫“项目例会”，也可能不是同一个编辑对象

先建立一组以北京时间（Asia/Shanghai）安排的六周日程：从2026年10月21日起，每周三10:00至10:30，在301会议室举行，直到11月25日。这是一条重复规则，它展开成六次具体会议。用户在日历上点击10月28日时，进入的是该日会议详情；页面应显示日期，而不只是“每周三项目例会”。

详情可以同时列出“本次：10月28日10:00”和“重复：每周三，11月25日结束”。前者帮助用户确认正在编辑哪一次，后者解释它属于一个系列。只有重复规则而没有本次日期，会让取消或修改的目标变得含糊。

Google日历的周期性活动说明也将重复周期、结束时间和更新应用范围分别处理。不同日历产品提供的选项会有差别，自己的设计应与日程服务能够执行的范围一致，而不是只模仿一个弹窗的文字。

先看日期，再决定改动范围

现在把10月28日的例会改为11:00至11:30，保持半小时会期。用户点击保存后，范围选择不宜只显示三个短词；可以在每个选项后补一句结果，让他理解修改会传播到哪里。

第三项尤其需要业务约定。系统是否允许改过去日程、是否覆盖之前单独修改过的会议，都不是“全部”两个字能回答的。如果服务不支持某个范围，就不展示看似可以执行的选项。能预览的情况下，列出受影响日期与数量；不能精确计算无限系列的数量时，使用明确的起止范围，不编造一个总数。

从详情返回而未保存时，保留用户输入还是丢弃也要有一致约定。关闭范围弹窗应回到尚未提交的编辑页，不能让用户误以为刚才修改已经生效。

单独改过的一次会议，需要看得出来

本例选择“仅本次”，于是10月28日变成11:00，其他日期仍是10:00。日历和详情可以用“本次时间已调整”说明例外，避免用户看到重复规则中的10点后以为日历出错。这个标记解释差异即可，不需要把内部数据结构展示给用户。

接着取消11月4日的会议。系列仍然存在，11月11日也应照常出现。日历是保留一个已取消条目还是移除它，要与参与者能否查看历史通知一致；即使列表隐藏，返回旧通知时也应能看到该次会议已取消，而不是无说明的空页面。

之后组织者准备从11月11日起换到502会议室。选择“本次及以后”只调整后续地点，10月28日的时间例外和11月4日的取消结果都属于此前日期，不应被这次修改恢复。若改整个系列，则需要再次说明既有例外如何处理，不能默认用新规则覆盖所有人工调整。

月末与时区不能靠加固定小时数解决

每周三上午10点表达的是某个时区的当地日历时间。跨地区成员查看时，应知道活动使用的时区以及自己看到的本地时间。涉及夏令时的地区，某段日期的时差可能变化；设计样例应使用明确日期验证显示，不把“每周”简单写成界面上永远相隔固定小时数。

每月31日更需要选择规则：没有31日的月份跳过，还是改到月末？两种都可能有合理业务用途，但必须在设置页用自然语言说明，并预览接下来几次日期。不能让选择器接受“每月31日”，保存后又悄悄改成每月最后一天。

同理，结束条件“到11月25日”要说明是否包含当天；“重复6次”要明确首次是否计入。输入控件的范围和快捷日期，可接着参考日期范围与时区的边界处理，但重复规则还需要这层实例预览。

让评审者从改动前看到改动后

在Pixso中并排制作四周日历的初始版和结果版，中间放10月28日详情及修改范围弹窗。结果版保留10月28日11点的例外、11月4日的取消标记，以及11月11日502室的新地点。画板里的日期和星期保持一致，不用一组互不关联的日历占位图。

演示时让评审者先只改10月28日，再取消11月4日，最后把11月11日之后的地点改为502室。每一步保存后都回到日历，让他看到发生变化的日期；不要只弹一个成功提示就结束演示。若服务端拒绝修改，例如组织者权限已变化，应回到仍可读的编辑内容，解释未保存的范围。

通知也应对应变更对象。只改一场会议时，参与者需要看到哪一天、哪项内容改了；改后续系列时，需要看到开始日期。保存前应让组织者知道这次是否会通知参与者、是否需要重新回应；保存后分别显示日程修改和通知的实际结果。把受影响日期与通知范围放在一起，参与者便能判断哪一场会议需要重新安排。