Proposal：通过语音管理日程

[LUPENGHAN]

Proposal 01：通过语音管理日程

动机 / 用户故事

用户在通勤、驾驶、行走或处理家务时，不适合打开多层表单填写日程。用户希望点击一次麦克风按钮，用自然语言完成日程的创建、查询、修改和删除。

目标用户

需要频繁记录和调整个人日程，并希望减少 GUI 操作的 Android 用户。

现有做法及其不足

传统日历通常要求用户依次选择日期、时间、重复规则、位置和提醒。操作步骤多，移动状态下容易中断或填错，也不适合双手被占用的场景。

本期范围

• 通过首页麦克风按钮开始语音对话。
• 语音创建、查询、修改和删除日程。
• 支持日程基础字段、分类和重复规则。
• 日程开始时间只表示事项实际开始时间，不包含通勤时间。
• 使用产品文档中的默认创建规则补齐未指定字段。
• 支持“它”“刚才的日程”“下午的会议”等上下文指代。
• 匹配到多个日程时，通过语音追问消除歧义。
• 删除前进行二次确认。
• 修改或删除重复日程时，询问处理范围：
  • 仅处理本次。
  • 处理本次及所有未来日程。
• 操作成功后同时使用 TTS 和屏幕内容反馈结果。

明确不做

• GUI 创建、修改和删除日程。
• 离线语音操作。
• 待办事项。
• 多人邀请、参会回复和协作日历。
• 第三方日历接入。
• 本期不通过语音设置行程时间或创建自动出发提醒。
• 用户可以使用普通提醒表达“提前四十五分钟提醒我”，但这不代表系统计算了通勤时间。
• 在本 Proposal 中决定 ASR、LLM、WebSocket 或存储方案。

关键决策与依据

决策一：完整日程管理均使用语音

• 备选方案：语音只负责快速创建，其他操作使用 GUI。
• 选择方案：创建、查询、修改和删除都通过语音完成。
• 选择理由：只支持语音创建会迫使用户在后续操作中重新回到 GUI，无法形成一致的无 GUI 核心体验。

决策二：使用默认值减少追问

• 备选方案：字段缺失时逐项询问。
• 选择方案：优先使用产品文档定义的默认值，只有缺失信息会改变用户意图或存在歧义时才追问。
• 选择理由：减少对话轮数，符合“说一句话即可记录”的核心价值。

决策三：高风险和歧义操作必须确认

• 备选方案：识别到意图后立即执行。
• 选择方案：删除、重复日程范围和多对象匹配必须追问或确认。
• 选择理由：语音识别存在不确定性，错误删除和批量修改的恢复成本高。

基本概念与信息结构

• 对话请求：用户一次语音表达。
• 日程目标：本次操作指向的一条日程或一个重复日程序列。
• 操作类型：创建、查询、修改、删除。
• 字段变更：用户明确要求更新的字段；修改操作不改变未提及字段。
• 处理范围：仅本次、本次及未来。
• 确认状态：待确认、已确认、已取消。

交互示例

创建

用户：“明天下午三点和张三开会。”
系统：“已创建明天下午三点到四点的‘和张三开会’，将在开始前十五分钟（低强度）提醒你。”

修改与指代

用户：“把明天下午和张三的会议推迟半小时。”
系统：“将‘和张三开会’改为明天下午三点半到四点半，对吗？”
用户：“对。”

歧义处理

用户：“删除下午的会议。”
系统：“下午有两条日程：三点的‘项目评审’和五点的‘周会’，你要删除哪一条？”

重复日程删除

用户：“删除这周五的周会。”
系统：“仅删除本周五这一次，还是删除本周五及未来的周会？”

验收标准

• 用户可以完全通过语音完成日程的创建、查询、修改和删除。
• 缺失字段按照产品文档的默认规则补齐。
• 修改操作不改变用户未提及的字段。
• 多对象匹配时不得直接执行修改或删除。
• 删除操作必须确认。
• 重复日程修改和删除必须确认处理范围。
• GUI 不提供日程编辑入口。
• 离线语音请求必须明确说明当前不可用，不得产生部分修改。