动机 / 用户故事
普通系统通知容易被忽略,不同事项需要不同程度的提醒。用户希望重要事项能通过声音、震动和弹窗送达,同时在网络或 TTS 不可用时仍保留基础提醒能力。
目标用户
需要可靠提醒,并希望根据事项重要程度控制打扰强度的 Android 用户。
现有做法及其不足
传统日历通常以统一通知方式提醒,重要事项与普通事项差异不足。依赖云端生成或推送的提醒在断网时也可能失效。
本期范围
- 时间和地点条件满足后,由本地触发提醒。
- 三级送达方式:
- 低强度:系统通知。
- 中强度:震动和屏幕弹窗。
- 高强度:声音、震动和屏幕弹窗。
- 高强度提醒在线且 TTS 可用时:
- 由大语言模型基于日程标题、开始时间和位置生成提醒内容。
- 使用 TTS 作为声音内容,同时进行屏幕展示。
- TTS 不可用时:
- 高强度提醒继续使用本地提示音、震动和弹窗。
- 不提供大语言模型生成的特定播报和增强展示内容。
- 可以显示本地已有的基础日程标题。
- 用户可以对已触发提醒执行延期。
- 用户未指定延期时间时,默认延期十分钟。
- 延期后的提醒由本地重新调度。
- 提醒触发时提供两个用户操作:
- 提醒完成。
- 提醒延期。
- “提醒完成”停止当前提醒实例,不修改日程本身。
- “提醒延期”默认延后十分钟,并由本地重新调度。
- 在线时支持通过语音执行“提醒完成”或“提醒延期”。
- 离线时不提供语音控制,但通知和弹窗中的两个操作仍然可用。
- 设备完成提醒下发后,可以记录“已送达”;它是本地系统事件,不是用户操作状态。
明确不做
- 云端轮询或下发提醒。
- 云端时间和地理围栏计算。
- 把提醒标记为待办“完成”。
- 本期不计算建议出发时间,也不生成出发提醒;预计通勤时间由 Proposal 05 承接,天气、导航、关联日程等通用上下文决策由 Proposal 06 承接。
- 在本 Proposal 中决定 Android 调度框架、定位算法或 TTS 服务实现。
- 多设备间同步提醒运行状态。
关键决策与依据
决策一:提醒下发完全由本地负责
- 备选方案:由云端计算并通过推送送达。
- 选择方案:设备本地判断条件并触发提醒。
- 选择理由:本地执行可以在断网时保持提醒可达,也符合云端不进行轮询和地理计算的边界。
决策二:提醒强度映射到固定送达方式
- 备选方案:允许用户自由组合通知、震动、弹窗和声音。
- 选择方案:首期提供低、中、高三档固定组合。
- 选择理由:减少用户配置成本和语音表达复杂度,并保证每一档强度含义稳定。
决策三:TTS 失败不影响高强度提醒
- 备选方案:TTS 不可用时取消整次语音提醒。
- 选择方案:退化为本地提示音、震动和弹窗。
- 选择理由:TTS 是增强内容,不应成为提醒可达性的单点依赖。
决策四:提醒操作采用“完成 / 延期”双通道
- 备选方案:只提供语音控制,或只提供通知按钮。
- 选择方案:通知和弹窗提供“提醒完成”和“提醒延期”;在线时语音可以执行同样的操作。
- 选择理由:按钮操作在离线和 ASR 不可用时仍然有效,语音则保留无 GUI 核心交互的效率。
决策五:默认延期十分钟
- 备选方案:每次要求用户指定时间。
- 选择方案:用户只说“延期”时默认延后十分钟。
- 选择理由:缩短提醒处置步骤,同时保留用户指定其他时长的能力。
基本概念与信息结构
- 提醒配置:云端可保存并同步的触发规则与强度。
- 提醒实例:本地根据提醒配置生成的一次待触发或已触发提醒。
- 送达方式:通知、震动、弹窗、本地提示音、TTS。
- 提醒完成:用户结束当前提醒实例;不修改日程。
- 提醒延期:为当前提醒实例生成新的本地触发时间。
- 已送达:设备已经执行对应送达方式的本地系统事件,不是用户操作状态。
- 提醒状态:当前用户操作只产生“提醒完成”或“提醒延期”两种结果。
保留的后续能力(不纳入本期验收)
预计通勤时间、建议出发时间和出发提醒由 Proposal 05“基于通勤时间的出发提醒”承接;天气、路线、关联日程、用户交互状态和通用智能提醒内容由 Proposal 06“基于上下文动态调整提醒”承接,均不纳入本 Proposal 验收。
交互示例
高强度提醒正常送达
系统播放由大语言模型生成的 TTS,同时震动并使用屏幕弹窗展示提醒。
TTS 不可用
系统继续播放本地提示音、震动并显示弹窗,不播放生成式语音内容。
默认延期
用户:“延期。”
系统:“已延期十分钟。”
验收标准
- 三种提醒强度必须对应固定的送达方式。
- 时间或地点条件满足后,提醒不得依赖云端下发才能触发。
- TTS 不可用时,高强度提醒仍必须执行本地提示音、震动和弹窗。
- 用户只说“延期”时,必须默认延期十分钟。
- 用户指定延期时间时,应使用用户指定的时间。
- 离线时不得承诺语音延期可用。
- “已送达”不得解释为用户同意、已读或完成事项。
- 通知权限不可用时,应展示说明并停止通知相关功能。
- 位置权限不可用时,应停止地点提醒,但不得影响已配置的时间提醒。
动机 / 用户故事
普通系统通知容易被忽略,不同事项需要不同程度的提醒。用户希望重要事项能通过声音、震动和弹窗送达,同时在网络或 TTS 不可用时仍保留基础提醒能力。
目标用户
需要可靠提醒,并希望根据事项重要程度控制打扰强度的 Android 用户。
现有做法及其不足
传统日历通常以统一通知方式提醒,重要事项与普通事项差异不足。依赖云端生成或推送的提醒在断网时也可能失效。
本期范围
- 提醒完成。
- 提醒延期。
明确不做
关键决策与依据
决策一:提醒下发完全由本地负责
决策二:提醒强度映射到固定送达方式
决策三:TTS 失败不影响高强度提醒
决策四:提醒操作采用“完成 / 延期”双通道
决策五:默认延期十分钟
基本概念与信息结构
保留的后续能力(不纳入本期验收)
预计通勤时间、建议出发时间和出发提醒由 Proposal 05“基于通勤时间的出发提醒”承接;天气、路线、关联日程、用户交互状态和通用智能提醒内容由 Proposal 06“基于上下文动态调整提醒”承接,均不纳入本 Proposal 验收。
交互示例
高强度提醒正常送达
系统播放由大语言模型生成的 TTS,同时震动并使用屏幕弹窗展示提醒。
TTS 不可用
系统继续播放本地提示音、震动并显示弹窗,不播放生成式语音内容。
默认延期
用户:“延期。”
系统:“已延期十分钟。”
验收标准