Proposal:消息提醒模块(V2)
1 功能描述
消息提醒用于在合适时间让用户感知 Schedule、Todo、Task,以及已经生成的 ReviewReport 和待确认 ReschedulePlan。提醒是附加触达能力,不拥有业务事实,也不能因为权限、注册、取消或同步失败阻断业务对象、报告或方案的保存。
P0 使用当前设备的 iOS/Android 本地通知。事项提醒在用户明确开启后注册;自动 ReviewReport 和被动 ReschedulePlan 使用系统事件通知设置。通知点击只负责展示对应内容,不代表完成事项、确认报告建议或应用重排方案。
提醒配置随对应业务对象保存,当前设备负责本地调度和恢复;P0 不承诺多设备实时一致性或跨设备去重。
2 用户
目标用户
- 需要在 App 外感知固定安排、普通事项和 Goal Task 的用户。
- 希望及时看到自动复盘和系统发现的待确认重排方案的用户。
- 希望控制提醒时间、可以关闭提醒,并在通知权限不可用时继续使用核心功能的用户。
用户故事
| 场景小故事 |
对应能力 |
价值 |
| 我 15:00 有固定会议。 |
Schedule 提前/准点提醒 |
提前准备 |
| 我 22:00 前要提交材料。 |
Todo 截止提醒 |
避免错过截止 |
| 我今晚 20:00 有 Goal Task。 |
Task 执行提醒 |
目标计划进入现实执行 |
| “买打印纸”没有截止和计划时间。 |
独立提醒时间 |
系统不替用户猜测 |
| 会议改期、Todo 延期或 Task 被重排。 |
旧通知失效并按新事实恢复 |
避免错误/重复触达 |
| 周报自动生成了。 |
ReviewReport 系统通知 |
没有复盘入口也能被触达 |
| 系统生成一份待确认重排方案。 |
ReschedulePlan 通知 |
及时查看,但不自动应用 |
| 通知关联对象已删除。 |
安全兜底 |
不崩溃、不泄露数据 |
3 现有做法及不足
| 现有做法 |
可以解决 |
仍然存在的问题 |
| 只做 App 内红点 |
无需系统权限 |
用户不打开 App 就无法感知 |
| 各模块分别实现通知 |
快速接入单一业务 |
权限、去重、更新和点击规则容易漂移 |
| 服务端实时推送 |
远程触达 |
多端设备、失败补偿超出 P0 |
| App 首次启动立即申请权限 |
尽早获得授权 |
用户尚未理解用途,拒绝率和打扰更高 |
| 原 #47 只明确 Schedule/Todo 和泛化系统结果 |
覆盖主干 |
缺少 Task 生命周期及 AI Tab 报告/方案落点 |
核心问题是需要一套统一、可降级、可恢复并能避免错误触达的提醒生命周期。
4 产品范围
事项提醒
- Schedule、Todo、Task 通过统一能力设置、查看、修改和关闭提醒。
- 用户首次主动开启任一事项提醒时才申请系统通知权限。
- 日程可提供提前 30 分钟等可见建议;有截止 Todo 可提供提前 1 小时等可见建议;Task 可根据其开始时间提供可见建议。
- 默认值只是建议,可修改、可关闭,不能在用户不知情时静默开启。
- 无截止且无计划时间 Todo 开启提醒时必须选择独立触发时间。
- 允许提前或准点,不允许晚于 Schedule/Task 开始或 Todo 对应截止/计划约束。
- Schedule/Todo/Task 的时间变化、完成、取消、删除或重排应用后,更新或取消尚未触发通知。
- 同一用户、同一关联对象、同一触发事实只存在一条有效事项通知。
系统事件通知
- 自动 Goal ReviewReport 和自动周 ReviewReport 成功落库后发送通知;同一报告版本最多一次。
- 被动 ReschedulePlan 成功生成并保存后发送待确认通知;同一有效方案最多一次。
- 用户可以分别关闭复盘通知和重排通知;关闭通知不影响报告/方案生成和保存。
- 点击 ReviewReport/ReschedulePlan 通知进入 AI Tab 并定位对应内容,不自动执行任何业务动作。
权限、恢复与失败
- 权限拒绝后不反复强制弹窗,展示不可用状态和前往系统设置入口。
- 本地注册、取消或同步失败可见、可记录、可重试,但不回滚业务操作。
- 设备重启、重新登录、权限恢复、系统时间或时区变化后,根据当前用户仍有效的提醒配置重建本地通知并清理失效项。
- 点击不存在、已删除或无权限对象的残留通知时进入安全兜底,不泄露标题或内容。
明确不做
- 服务端实时推送、短信、邮件、电话和营销运营通知。
- 多端实时一致性和跨设备通知去重。
- 完整消息中心、每日摘要、贪睡和重复提醒。
- AI 自动决定并静默开启提醒时间。
- 通过通知点击自动修改对象状态、确认画像、应用重排或应用复盘建议。
- 在本 Proposal 冻结数据库字段、操作系统实现和重试算法。
后续可拓展
- 服务端推送、多端一致性、消息中心和可配置重复策略。
- P1 基于经确认画像给出提醒时间建议,仍需用户确认。
5 关键决策
| 决策点 |
方案 |
结论 |
理由 |
| 业务接入 |
每类对象分别实现 |
不选 |
生命周期规则重复且易漂移 |
| 业务接入 |
统一提醒能力 |
采纳 |
一套规则服务事项和系统事件 |
| 触达方式 |
仅 App 内红点 |
不选 |
App 外没有价值 |
| 触达方式 |
当前设备本地通知 |
P0 采纳 |
注册后可离线触发,范围可控 |
| 权限申请 |
首次启动即申请 |
不选 |
缺少明确用户意图 |
| 权限申请 |
首次主动开启事项提醒时申请 |
采纳 |
请求时机可理解 |
| 默认提醒 |
系统静默开启 |
不选 |
用户不知情 |
| 默认提醒 |
展示建议、用户确认 |
采纳 |
兼顾便捷和控制 |
| 业务失败关系 |
提醒失败回滚业务 |
不选 |
附加能力成为单点故障 |
| 业务失败关系 |
业务先成功,提醒独立恢复 |
采纳 |
核心闭环可用 |
| Task |
不纳入提醒 |
不选 |
Task 已有明确执行时间 |
| Task |
与 Schedule/Todo 共用提醒 |
采纳 |
支撑 Goal 执行 |
| 系统结果 |
只在 App 内等待用户查找 |
不选 |
复盘无入口、被动方案容易被遗漏 |
| 系统结果 |
ReviewReport/ReschedulePlan 通知 |
采纳 |
及时触达且不自动应用 |
| 配置恢复 |
只保存操作系统通知实例 |
不选 |
重启/权限变化后无法可靠恢复 |
| 配置恢复 |
业务配置持久化,当前设备本地调度 |
采纳 |
支持恢复且不引入 P0 多端推送 |
6 边界与异常
边界规则
- 提醒必须绑定当前用户和有效业务对象/报告/方案。
- 提醒触发时间必须晚于当前时间;事项提醒不能晚于其业务语义允许的时间。
- 默认提醒只作为建议,必须有用户确认;系统事件通知遵循用户的类别开关。
- 通知触发或点击不改变任何业务状态。
- 同一业务事实不能产生两条有效通知。
- 所有时间按用户时区解释;时区变化后重新校验尚未触发通知。
- 锁屏内容遵循最小披露原则,详情在解锁进入 App 后展示。
异常场景与处理方式
| 场景 |
系统行为 |
原则 |
| 提醒时间已过 |
不注册;业务对象仍可保存 |
避免无效触达 |
| 提醒晚于业务时间 |
阻止提醒配置并提示修改,业务编辑仍可继续 |
语义有效 |
| 无时间 Todo 未选提醒时间 |
不保存提醒配置,Todo 本身可保存 |
不替用户猜测 |
| 权限未请求 |
用户首次主动开启时申请 |
按需权限 |
| 权限被拒绝/关闭 |
业务成功,显示不可用及设置入口 |
附加能力隔离 |
| 注册/取消失败 |
记录并可重试,不回滚业务 |
可恢复 |
| 对象改期/重排 |
旧通知失效,新通知按新事实生成 |
避免错误触达 |
| 对象完成/取消/删除 |
取消尚未触发通知 |
生命周期一致 |
| 重复事件 |
不生成第二条有效通知 |
幂等 |
| 点击残留通知 |
安全提示并进入兜底页面/AI Tab,不泄露内容 |
安全降级 |
| 设备环境变化 |
重建有效通知并清理失效项 |
恢复能力 |
| 系统事件通知失败 |
报告/方案保持成功,通知独立重试 |
触达不阻断派生数据 |
| 当前用户不匹配 |
拒绝路由和操作 |
数据隔离 |
7 基本概念与信息结构
| 概念 |
含义 |
| Reminder |
用户对 Schedule/Todo/Task 的提醒配置,不是业务事项 |
| Notification |
一次本地触达实例 |
| 事项通知 |
生命周期跟随 Schedule/Todo/Task |
| 系统事件通知 |
关联 ReviewReport 或 ReschedulePlan |
| 通知类别开关 |
用户对复盘/重排等系统通知的偏好 |
| 本地调度 |
当前设备向操作系统注册/取消通知 |
| 兜底路由 |
对象不存在或不可访问时的安全落点 |
信息结构:事项提醒在对应编辑/详情上下文设置;复盘和重排通知在个人通知设置中按类别控制;通知点击后,事项进入对应详情,报告/方案进入 AI Tab 对应卡片。
8 验收标准
| 用例 |
操作 |
通过标准 |
| Schedule 提醒 |
15:00 会议采用提前 30 分钟建议 |
用户确认后 14:30 本地触发 |
| Todo 提醒 |
22:00 截止 Todo 采用提前 1 小时 |
用户确认后 21:00 触发 |
| Task 提醒 |
20:00 Goal Task 开启提醒 |
按确认时间触发并进入 Task 详情 |
| 无时间 Todo |
主动开启提醒 |
必须选择独立时间,Todo 本身不受影响 |
| 准点提醒 |
设置为开始/截止时刻 |
允许并准点触发 |
| 离线触发 |
注册后设备断网 |
按本地通知能力触发 |
| 重排更新 |
Task 或可移动 Schedule 改期 |
旧通知失效,新通知按确认结果生成且不重复 |
| 提前结束 |
提醒前完成/取消对象 |
尚未触发通知被取消 |
| 自动 ReviewReport |
报告落库 |
每个版本最多通知一次,点击进入 AI Tab 报告 |
| 被动 ReschedulePlan |
方案自动保存 |
最多通知一次,点击进入 AI Tab 待确认方案,不自动应用 |
| 类别关闭 |
用户关闭复盘通知 |
报告仍生成并可查询,但不触达 |
| 权限拒绝 |
用户拒绝系统权限 |
业务保存成功,显示不可用和设置入口 |
| 注册失败 |
模拟系统注册失败 |
业务不回滚,记录失败并允许重试 |
| 设备恢复 |
重启/时区变化后同步 |
重建仍有效通知并清理失效项 |
| 残留通知 |
关联对象已删除 |
不崩溃、不泄露,进入安全兜底 |
Proposal:消息提醒模块(V2)
1 功能描述
消息提醒用于在合适时间让用户感知 Schedule、Todo、Task,以及已经生成的 ReviewReport 和待确认 ReschedulePlan。提醒是附加触达能力,不拥有业务事实,也不能因为权限、注册、取消或同步失败阻断业务对象、报告或方案的保存。
P0 使用当前设备的 iOS/Android 本地通知。事项提醒在用户明确开启后注册;自动 ReviewReport 和被动 ReschedulePlan 使用系统事件通知设置。通知点击只负责展示对应内容,不代表完成事项、确认报告建议或应用重排方案。
提醒配置随对应业务对象保存,当前设备负责本地调度和恢复;P0 不承诺多设备实时一致性或跨设备去重。
2 用户
目标用户
用户故事
3 现有做法及不足
核心问题是需要一套统一、可降级、可恢复并能避免错误触达的提醒生命周期。
4 产品范围
事项提醒
系统事件通知
权限、恢复与失败
明确不做
后续可拓展
5 关键决策
6 边界与异常
边界规则
异常场景与处理方式
7 基本概念与信息结构
信息结构:事项提醒在对应编辑/详情上下文设置;复盘和重排通知在个人通知设置中按类别控制;通知点击后,事项进入对应详情,报告/方案进入 AI Tab 对应卡片。
8 验收标准