Proposal： 通过语音配置时间与地点提醒

[LUPENGHAN]

动机 / 用户故事

用户不仅希望在固定时间收到提醒，也希望在到达/离开某地或返回某个记录位置时收到提醒，例如“到家拿快递”或“回来时提醒我车停在哪里”。用户希望通过语音完成这些设置，而不填写提醒表单。

目标用户

需要时间提醒、地点提醒，并希望使用语音快速配置的 Android 用户。

现有做法及其不足

传统日历主要围绕时间提醒设计。地点相关事项通常依赖用户记忆或另行记录，提醒强度也往往固定，难以适应不同重要程度的事项。

本期范围

• 通过语音创建、查询、修改和删除提醒配置。
• 每条日程最多配置两个提醒。
• 支持时间提醒：
  • 指定时间。
  • 相对日程开始时间。
  • “开始前四十五分钟提醒”属于普通相对时间提醒，不表示系统计算了四十五分钟通勤时间。
• 支持到达指定地点提醒。
• 支持离开指定地点提醒。
• 支持返回记录地点提醒：
  • 创建时记录当前位置。
  • 用户离开该位置范围后启用返回检测。
  • 用户再次进入该位置范围时触发提醒。
• 支持低、中、高三级提醒强度。
• 未明确指定提醒时，使用产品文档中的默认提醒规则。
• 未明确指定强度时，默认使用低强度。
• 修改提醒时支持“第一个提醒”“第二个提醒”“地点提醒”等指代。
• 提醒配置保存到云端，并同步到本地用于执行。

明确不做

• 同一日程超过两个提醒。
• 通勤时间估算和自动出发提醒由 Proposal 05 承接；天气、导航、关联日程等通用上下文决策由 Proposal 06 承接。
• 第三方日历提醒导入。
• 云端计算时间或地理围栏。

关键决策与依据

决策一：每条日程最多两个提醒

• 备选方案：只允许一个提醒，或允许任意数量提醒。
• 选择方案：最多两个提醒。
• 选择理由：一个提醒不足以覆盖部分重要事项；无限提醒会增加语音指代、展示和触发管理的复杂度。两个提醒在能力与简单性之间取得平衡。

决策二：默认创建低强度提醒

• 备选方案：默认不提醒，或要求用户每次明确设置。
• 选择方案：非全天日程默认提前十五分钟低强度提醒；全天日程默认在当天上午十点低强度提醒。
• 选择理由：Timeflow 的核心价值是避免遗漏，默认提醒比默认静默更符合产品定位，同时低强度可降低打扰。

决策三：提醒规则由云端保存、本地执行

• 备选方案：云端负责触发并推送提醒。
• 选择方案：云端只保存提醒配置，设备本地计算和执行。
• 选择理由：保证断网情况下已配置提醒仍然可达，并避免云端轮询位置。

基本概念与信息结构

• 提醒配置：与日程关联、可同步的产品规则。
• 时间提醒：按指定时间或相对日程开始时间触发。
• 出发提醒：当前不支持，后续由 Proposal 05 定义，并单独决定是否占用最多两个提醒的名额。
• 离开提醒：离开指定地点范围时触发。
• 到达提醒：进入指定地点范围时触发。
• 返回提醒：记录位置后先离开，再返回该范围时触发。
• 提醒强度：低、中、高。
• 提醒序号：第一或第二个提醒，用于语音指代。

交互示例

时间提醒

用户：“开会前一小时高强度提醒我。”
系统：“已将‘和张三开会’的提醒改为开始前一小时，高强度。”

到达地点提醒

用户：“提醒我到家拿快递。”
系统：“已创建‘到家拿快递’，将在你到达家时提醒。”

离开地点提醒

用户：“提醒我离开公司时去买菜”
系统：“已创建‘离开公司去买菜’，将在你到离开公司时提醒。”

返回记录地点提醒

用户：“记住我停车的位置，回来时提醒我车停B25。”
系统：“已记录当前位置。你离开并再次返回这里时，我会提醒你停车位置。”

超过数量限制

用户：“再加一个提前五分钟的提醒。”
系统：“这条日程已经有两个提醒。请先删除或修改其中一个提醒。”

验收标准

• 用户可以通过语音创建、查询、修改和删除提醒配置。
• 每条日程不得保存超过两个提醒配置。
• 默认提醒规则必须按全天和非全天日程正确应用。
• 到达提醒仅在进入目标地点范围时触发。
• 返回提醒必须先检测到离开记录位置，之后再次进入才触发。
• 用户未指定强度时必须采用低强度。
• 位置权限不可用时不得创建地点提醒，并应说明如何开启权限。