Proposal：基于多维上下文动态调整提醒

[LUPENGHAN]

动机 / 用户故事

固定提醒只根据预先设置的时间或地点触发，无法反映用户当前是否来得及到达、天气是否影响出行、前后日程是否冲突，以及用户是否已经延期提醒。

用户需要的不是一个自行改变所有规则的黑盒，而是一套能够在用户明确授权后，基于可信上下文调整提醒时间和内容，并解释调整原因的机制。

例如，用户说：

“明天下午三点去客户公司开会，提醒我什么时候出发。”

Timeflow 根据日程开始时间、已确认地点、当前位置、出行方式、预计路程耗时和缓冲时间计算建议出发时间，并用该时间替代普通开始前提醒。

目标用户

• 日程密集、经常需要在不同地点间移动的 Android 用户。
• 希望提醒能够结合当前环境而不是只执行固定时间偏移的用户。
• 希望理解提醒为何发生或为何被调整的用户。

本期范围

1. 多维上下文

提醒规则可以使用以下产品信息：

• 日程标题、开始时间、结束时间和已确认地点。
• 用户设置的提醒时间、提醒类型和提醒强度。
• 当前时间、时区和设备位置。
• 出行方式、路线和预计路程耗时。
• 日程时间和地点对应的天气。
• 前后关联日程、时间冲突和地点衔接。
• 当前提醒实例的提醒完成或提醒延期状态。

任一增强上下文都允许缺失。缺失时必须执行对应规则定义的降级行为。

2. 动态调整提醒

• 多维规则可以调整现有提醒的触发时间、触发条件和展示内容。
• 调整必须来自明确的产品规则，不能由大语言模型自行决定。
• 规则需要用户主动创建、开启或授权后才能生效。
• 系统必须说明提醒发生或被调整的主要原因。
• 用户可以通过语音查询、修改或关闭某类动态提醒规则。
• 动态调整不得修改日程开始时间、结束时间或地点。

3. 基于路程耗时的出发提醒

• 用户可以通过语音请求“提醒我什么时候出发”。
• 该规则只适用于具有明确开始时间和已确认地点的非全天日程。
• 建议出发时间根据以下信息计算：
  • 日程开始时间。
  • 预计路程耗时。
  • 用户确认的缓冲时间。
• 出发提醒替代同一日程的普通开始前提醒，使用同一个提醒配置位置。
• 启用后不得再为同一配置额外生成普通开始前提醒。
• 日程开始时间仍然保留为事件时间。
• 用户设置的其他提醒不受影响。
• 路程耗时能力由 Issue 153 的开发设计提供，本 Proposal 不定义其技术实现。
• 路程耗时不可用时，恢复原有的普通开始前提醒；没有原有配置时使用默认提前十五分钟提醒。

4. 天气与提醒

• 天气可以作为 TTS 和屏幕内容的事实来源。
• 天气内容必须与当前日程时间和地点相关。
• 天气是否可以调整提醒时间，需要作为独立产品规则明确开启。
• 天气不可用时，不影响基础提醒和已经确定的出发提醒。

5. 关联日程与冲突

• 系统可以识别前后日程的时间冲突和地点衔接不足。
• 首期只向用户说明冲突，不自动修改日程。
• 是否根据前一条日程动态调整提醒时间，需要用户明确授权。
• 关联日程信息不可用时，继续执行当前提醒规则。

6. 提醒内容

• TTS 和屏幕内容可以使用经过验证的上下文事实。
• 内容只保留与当前提醒直接相关的信息。
• 系统应说明动态调整原因，例如“预计路程需要四十分钟”。
• 大语言模型只负责组织表达，不决定是否提醒、何时提醒或如何改变提醒状态。

7. 本地送达与用户处置

• 动态调整结果最终转换为本地可执行的提醒配置。
• 时间等待、地点判断、提醒触发和重新调度仍由本地执行。
• 提醒送达继续使用 Proposal 03 的低、中、高三级强度。
• 用户处置只有“提醒完成”和“提醒延期”。
• “提醒完成”只结束当前提醒实例，不修改日程。
• “提醒延期”默认延后十分钟，并由本地重新调度。

明确不做

• 不纳入当前 MVP。
• 不让大语言模型直接决定提醒时间、触发条件或用户处置状态。
• 不在未经用户开启或授权时静默调整提醒。
• 不自动修改日程开始时间、结束时间或地点。
• 不自动修改用户选择的提醒强度。
• 不因天气、路线或关联日程信息缺失而取消基础提醒。
• 不新增“提醒完成”和“提醒延期”之外的用户处置。
• 不实现持续导航、路线轨迹或转向提示。
• 不由云端轮询或下发提醒。
• 不在本 Proposal 中确定决策引擎、部署位置、数据结构、数据库字段、地图服务商或网络协议。

关键决策与依据

决策一：使用一个通用 Proposal 承接多维提醒

• 备选方案：为出发提醒、天气提醒和关联日程提醒分别建立产品 Proposal。
• 选择方案：统一在本 Proposal 中定义多维上下文参与提醒调整的产品规则。
• 选择理由：这些能力共享相同的授权、解释、降级和本地执行原则，适合形成统一产品边界。

决策二：具体场景必须由明确规则定义

• 备选方案：将全部上下文交给大语言模型自由决定。
• 选择方案：每个场景使用可测试、可解释的产品规则；大语言模型只生成文案。
• 选择理由：提醒时间和状态必须稳定、可复现，不能依赖不可预测的生成结果。

决策三：出发提醒替代普通开始前提醒

• 备选方案：额外增加一条独立的出发提醒。
• 选择方案：出发提醒使用普通开始前提醒的配置位置，并替代其触发时间。
• 选择理由：避免用户在同一事项上收到重复提醒，也不额外占用提醒名额。

决策四：动态调整必须经过用户授权

• 备选方案：系统根据上下文自动调整所有提醒。
• 选择方案：用户主动创建、开启或授权某项规则后，系统才可以调整对应提醒。
• 选择理由：上下文可能不完整或过期，系统不能在用户不知情时改变提醒行为。

决策五：上下文缺失时执行可预测降级

• 备选方案：缺少任一增强信息时取消提醒。
• 选择方案：每条动态规则必须定义降级结果；出发提醒退回普通开始前提醒，其他增强规则退回原提醒。
• 选择理由：多维能力是增强，不能降低提醒可达性。

决策六：提醒决策与本地执行分离

• 备选方案：上下文处理模块直接发送通知或播放声音。
• 选择方案：产品规则产生提醒调整结果，本地提醒模块负责实际调度和送达。
• 选择理由：保持本地提醒可达，并符合云端不轮询、不计算地理围栏和不下发提醒的边界。

基本概念

• 基础提醒：用户创建或默认生成的时间提醒或地点提醒。
• 上下文事实：位置、路线耗时、天气、关联日程和提醒处置状态等经过验证的信息。
• 动态提醒规则：用户开启后，根据上下文调整现有提醒的产品规则。
• 提醒调整结果：规则计算出的触发时间、触发条件和内容事实。
• 决策原因：向用户解释提醒为何发生或被调整的事实。
• 降级：增强上下文不可用时退回原提醒或默认提醒的行为。

与其他 Proposal 和 Issue 的关系

• Proposal 01 定义通过语音管理日程。
• Proposal 02 定义通过语音配置基础时间提醒和地点提醒。
• Proposal 03 定义提醒的本地触发、送达、提醒完成和提醒延期。
• Proposal 04 定义离线使用和网络恢复同步。
• “多维提醒决策引擎”属于本 Proposal 通过后的系统架构和模块 Design，不是独立产品 Proposal。

待决策内容

以下产品规则在本 Proposal 进入开发前必须确定：

• 用户如何开启和关闭每一类动态提醒规则。
• 出发提醒未指定出行方式时的默认方式。
• 出发提醒的默认缓冲时间，以及是否允许用户覆盖。
• 路程耗时、日程地点或开始时间变化后，重新计算和重新调度的条件。
• 多条动态规则同时调整同一个提醒时的优先级和组合方式。
• 天气是否只增强内容，还是允许在用户授权后调整提醒时间。
• 关联日程首期只提示冲突，还是允许调整提醒时间。
• 上下文发生变化后是否允许再次提醒，以及频率限制。

以下内容转入系统架构、模块 Design 和开发 Issue：

• 多维提醒决策引擎的模块边界。
• 路线、天气和定位服务的接入方式。
• 上下文缓存、有效期、数据保存和错误重试。
• 提醒调整结果的数据结构、同步字段和接口。
• 本地与云端的具体计算流程。

交互示例

出发提醒

用户：“明天下午三点去客户公司开会，提醒我什么时候出发。”

系统：“已将开始前提醒改为出发提醒，系统会根据预计路程耗时计算提醒时间。”

提醒时：

“你三点在客户公司有会议，预计路程需要四十分钟，建议现在出发。”

路程耗时不可用

系统：“暂时无法计算建议出发时间，已恢复为提前十五分钟提醒。”

日程冲突

“当前日程与三点的客户会议衔接时间不足，预计无法按时到达。”

天气增强内容

“你三点在客户公司有会议，目的地可能有雨。”

后续验收方向

• 用户可以通过语音开启、查询、修改和关闭动态提醒规则。
• 动态调整必须基于明确、可测试的产品规则。
• 未经用户授权，不得静默调整提醒触发时间或条件。
• 启用出发提醒后，不得同时生成对应的普通开始前提醒。
• 路程耗时不可用时，必须恢复原有的普通开始前提醒；没有原有配置时使用默认提前十五分钟提醒。
• 上下文缺失时，基础提醒必须继续触发。
• 大语言模型不得决定提醒时间、触发条件或用户处置状态。
• 每次动态调整必须提供可展示的原因。
• 调整结果必须能够由本地提醒模块执行。
• 提醒送达和处置必须符合 Proposal 03。