如何让用户自主选择 AI 发送消息的时间和频率
用户应当有权决定 AI 是否可以联系他们、可以发送哪些类型的消息，以及这些消息何时送达。实用的设计应始于明确的自主选择加入（opt-in），允许用户设置时间表和频率，对本质上不同的消息类型进行分类隔离，并确保暂停和关闭控制易于找到。同时，它还应清晰说明所选的时区以及可能影响送达的因素。这些设置构成了对用户的明确承诺；产品的调度和推送系统必须能够兑现这一承诺。
从清晰、可选的选择性加入开始
在用户能够充分理解其同意内容的时机征求许可。用通俗易懂的语言描述联系类型：例如，用户请求的提醒事项或定期更新。说明通知将在何处显示以及发送频率。切忌仅凭一个没有解释的操作系统权限弹窗作为唯一说明；用户在做决定之前，需要了解应用打算发送什么内容。
美国 Web 设计系统（U.S. Web Design System）建议，仅针对服务实际能够支持的渠道收集联系偏好，并建议在可能的情况下说明联系的条件与预计时间表。应用于 AI 产品时，这意味着只展示真实的推送选项，并说明每个选项的用途。切勿将通知偏好作为使用不相关功能的先决条件。USWDS: Contact preferences
将选择加入视为用户可以随时更改的决定。Apple 的通知指南建议为不同通知类型提供明确的开启或关闭选项，并提供应用内管理通知设置的方法。产品可以遵循这一原则，通过一个总结当前选择的设置页面来呈现，而不是让用户在不相关的设备设置中翻找，以了解应用本身的时间规划。Apple: Managing notifications
明确具体的时间规划
让用户选择符合其日常生活习惯的时间段，例如工作日的下午 6 点至 8 点之间，或特定日期的固定时间。将日期与开始、结束时间一同展示。如果该设置定义的是一个“联系时间窗口”，应解释消息是在该时间段内的任意时刻送达，还是在某一特定时间送达。如果某一天没有符合条件的消息，需说明系统是跳过该日期还是将消息顺延。
实用的设计可以提供一些易于理解的预设选项，如“每周一次”或“仅工作日”，同时在产品支持的情况下允许自定义时间表。预设选项应对应直观可见的具体计划，而不是模糊的标签。例如，“每周”应显示所选的星期与时间，“每周最多三次”应说明“三次”是上限还是预期目标。这是一项设计建议：虽然平台文档支持定时推送，但产品团队必须自主决定并清楚描述自身的发送规则。
明确标注时区。使用具体的地理位置名称或设备当前的本地时区来标注时间表，并告知用户在旅行时时间表是跟随本地时区调整，还是保持在原有初始时区。仅标注一个未经修饰的 UTC 偏移量可能会在夏令时规则或政府时区法规变更时产生误导。IANA 的时区数据库记录了各地的规则，并会根据政体实体的变动持续更新，包括偏移量和夏令时规则的变更。IANA: Time Zone Database
一个良好的确认提示可以是：“每周二您当前本地时间的晚上 7:00 发送。该时间表将跟随您的设备时区调整。”只有在实际技术实现确实能跟踪用户当前时区的情况下，这种措辞才准确。如果时间表固定在某个选定时区，应指明该具体地点。当用户出行或设备时区发生改变时，展示当前生效的实际时间表，并提供检查确认的方式。
区分消息类型与渠道
用户可能需要某种类型的联系，但不需要另一种。将可选的提醒、产品更新以及其他独立类别分别设为可单独选择，而不是捆绑成一个“AI 通知”总开关。不要虚构与产品实际行为不符的类别，也不要为了向用户发送未选择的消息而巧立名目创建分类。
这种区分也与各平台系统的原生控制保持一致。在现代版本的 Android 中，通知必须归入各个渠道（channels），用户可以单独修改渠道行为；Android 指南建议通过渠道让用户自定义接收的通知。应用可以使用用户熟悉的术语来命名渠道（例如“定时提醒”），并说明各类别的具体内容。Android Developers: Create and manage notification channels
通知渠道列表应保持简短明了。一个渠道应当代表一项用户可能希望独立控制的有意义的选择。产品自身的设置页面仍应解释内容与时间表：操作系统的渠道控制虽然可以更改通知是否显示或以何种方式显示，但无法说明应用的发送策略，也无法替代应用内部的定时规则。
让暂停、恢复和关闭控制触手可及
提供临时暂停和永久关闭的开关。暂停功能应明确说明其持续时间——例如直到选定日期或直到用户主动恢复——并说明已排期的消息是被跳过还是被暂存保留。关闭控制应注明其影响的类别或渠道，并立即确认状态变更。恢复推送时不应在未告知后续安排的情况下，悄无声息地直接恢复之前的日程。
确保这些控制项可以在通知设置页面中轻松找到，并在可行的情况下，通过通知内的操作按钮或直接设置链接来提供。Android 支持在通知中添加快捷操作，并为用户提供了管理后续通知的系统级途径；这些控制项因设备和 Android 版本的不同而有所差异。因此，应用内路径在展示完整时间表和修改产品级偏好方面始终非常有用。Android Developers: Notifications
设备级的控制仍然至关重要。用户可以完全独立于应用自身的时间表，在操作系统级别关闭某个应用的通知或更改渠道行为。界面不应暗示应用内设置可以覆盖这些系统选择。如果系统通知已被禁用，应在用户访问设置页面时显示清晰的状态，并避免反复弹窗提示用户重新开启通知。
设定系统可切实执行的频率上限
为用户提供直观的频率选择：例如每天最多一条消息、每周上限，或由用户选择特定天数。明确计算周期的起止以及何种内容计入一条消息。如果多个类别都可以发送消息，应阐明该限制是针对单个类别还是适用于整个产品。按类别限制仍可能导致累积总量过高，因此实用的设计通常还会包含一个全局总量上限。
只有当所有对外发送途径都严格遵守时，上限才能真正生效。定时提醒、失败重试、延迟发送的消息以及由不同功能模块触发的消息，都应基于同一份偏好状态进行校验。如果某条消息发生延迟，需决定它是直接作废过期、在允许的时间窗口内补发，还是直接丢弃；向用户解释与其相关的处理逻辑。除非用户明确选择了该行为，否则设备重新联网后，应避免一次性连环发送多条错过的消息。
平台的送达机制不等同于产品的发送决策。Firebase Cloud Messaging 说明，消息通常会立即送达，但设备可能处于离线状态或送达发生延迟；该服务可以在其配置的存活时间内暂存消息并稍后尝试重新推送。这意味着产品不应承诺每条通知都会在精确到分的时间点弹出。产品可以承诺在指定的时间窗口内调度发送，同时向用户说明设备和平台网络状况可能会影响其实际显示的时间。Firebase: Set the lifespan of a message
这一区别同样会影响频率控制。如果某条通知曾处于排队队列中并且延迟送达，系统应检查用户在此期间是否已暂停或关闭了该类别，以及此时发送是否会超出当前的频率上限。诚信的设计应当在用户的最新选择使其不再符合条件时，取消或拦截陈旧的排队消息。
针对设计的简明决策流程
使用以下流程，将这些设置转化为对用户清晰透明的承诺：
列出产品实际能够发送的消息类型，并确保每个可选类别都通俗易懂。
让用户自主选择开启各个所需的类别和推送渠道。切勿默认勾选任何可选的联系方式。
允许用户选择星期、具体时间或时间窗口，以及最高频率。标明该上限是全局总量还是单类别上限。
显示时区，并说明当用户的设备时区发生改变时，日程计划是否跟随变动。
将暂停、恢复和关闭控制放置在显眼位置，随后展示当前状态以及下一次符合条件的联系时间。
在实际推送前，再次检查日程计划、频率上限、暂停状态和类别偏好。将设备端送达视为可能存在延迟，并仅就产品自身可控的范畴做出承诺。
精炼的设置摘要可使整体规则一目了然：“定时提醒：开启。当地时间每周二和周四晚 7–8 点。所有类别合计：每周最多两条。可随时暂停或关闭。”展示的选项必须真实反映系统的实现能力；如果产品无法严格执行显示的上限或无法可靠地跟随本地时区，则在提供相应控制之前，应当优化技术实现或收紧功能承诺。