# 拾时 MVP 产品需求文档 v0.1

日期：2026-09-29  
修订：2026-09-29，第三次修订（技术验证状态更新，需求范围不变）。

状态：产品需求讨论稿，已确认规则与待验证项分别标明。

规则来源：本次讨论确认的《拾时信息理解与提醒规范 v0.2》。本文件作为需求与规则的统一来源，后续提示词、程序、测试据此更新。

实现映射已整理为《拾时信息理解与提醒规范 v0.5》：它不改变本PRD的产品边界，负责说明规则如何进入编号规则库、系统提示词、结构化协议、本地校验和评测样本。项目顺序与阶段退出标准见《拾时项目推进计划》。

## 1. 产品目标与验证目标

拾时是一款轻量 Android 应用。用户主动交入通知，应用整理为待办，并在时间依据可靠时安排提醒；同时提供独立的简单笔记。

核心价值：减少通知整理和日程录入步骤，帮助用户在需要行动时找到信息。界面克制，不通过多轮聊天或逐条确认增加负担。

产品约束：跨Android厂商适配、轻量、省电、不依赖后台常驻。vivo X100s仅是首台测试设备，不限定产品支持范围。应用只在用户操作、到期提醒或必要的系统事件发生时执行相应工作。

首批验证对象暂定为可接触的大学生；这一安排用于招募和取样，不限制未来服务职场人。现有证据为用户提供的六张校园通知截图及讨论，尚未完成访谈和实际试用。

### 1.1 用户问题与使用场景

目标用户为经常从聊天、截图和口头通知中接收安排的学生与职场人。共同问题是信息分散、手动整理成本高、时间表达不统一，且原通知在办理时难以重新找到。

| 场景 | 用户需求 | 产品结果 |
|---|---|---|
| 收到报名或登记通知 | 不手动逐项填写，也不会错过关键时间 | 提取开放/截止节点，附办理入口，按需提醒 |
| 收到会议或活动截图 | 从截图识别行动、地点与时间 | 创建事项，保留原图，关键歧义才确认 |
| 记录没有时间的任务 | 先记住事情，不被迫选时间 | 创建无提醒待办，可随时完成或补充时间 |
| 收集文案、图片或网址 | 单纯保存，不被自动转成任务 | 在独立笔记入口存储和查找 |
| 已在其他应用办完事情 | 迅速停止后续提醒 | 从通知或详情标记整件事完成 |

### 1.2 产品验证目标

首轮验证问题：
- 用户是否愿意主动交入通知，录入步骤是否比原有方式省事？
- 自动创建的行动、时间和提醒是否可信，是否出现多余确认？
- 在真实目标手机上，提醒是否可靠，内容是否足以支持办理？

不预设准确率、节省时间或留存成绩；所有结果由实际测试记录。

## 2. 范围与分阶段交付

### 2.1 已确认的 MVP 能力

| 模块 | 范围 |
|---|---|
| 导航 | 日程、笔记、设置三个底部入口 |
| 输入 | 文字输入/粘贴、图片选择及补充文字、语音转写、系统分享 |
| 理解 | 图片直接使用视觉大模型；文本本地优先，复杂文本使用文字大模型 |
| 事项 | 有时间与无时间待办、主要事项及细则、多提醒节点、原始依据 |
| 确认 | 对影响结果的歧义一次选择或补充；多事项无法判断主次时允许取舍 |
| 提醒 | 按事项含义安排、通知内完成与稍后提醒、权限和失败状态说明 |
| 状态 | 整件事完成/恢复；重复事项完成本次/结束重复 |
| 笔记 | 创建、查看、编辑、删除、搜索，文字与图片，主动提取为日程 |
| 存储 | 输入与用户内容持久化，失败重试不丢失；开发方案暂按本地保存设计 |

所有输入方式保留在 MVP 目标内，以下开发顺序不等于取消功能。

### 2.2 建议交付顺序

1. 核心闭环：文字/图片 → 解析 → 确认 → 事项 → 实际提醒 → 整件事完成。
2. 补齐入口与基础功能：语音、分享、笔记、搜索、设置。
3. 完善复杂状态：重复、改期/取消候选、重复导入、恢复、权限和系统条件变化。
4. 真机验收、用户试用、缺陷修复与版本评审。

建议暂缓账号、跨设备同步、团队协作、复杂文件夹、外部日历同步、自动监听其他应用、PDF/ZIP正文解析、自动执行报名。以上属于范围建议，未作为永久产品限制。

网页分享第一版保证保存实际收到的链接/文字，不默认抓取网页全文。模型供应商、OCR辅助优化、语音实现尚未选定。OCR不作为图片理解的MVP前置步骤。

## 3. 页面与主要流程

| 页面/状态 | 展示 | 主要操作 |
|---|---|---|
| 日程首页 | 待办；有时间安排与未设时间分区；解析待处理状态 | 提取新事项、打开详情、进入已处理；长按批量完成/恢复或删除 |
| 统一录入 | 文本区、图片入口、语音入口、图片补充说明 | 交给拾时 |
| 语音 | 转写结果；明确录音中/已结束 | 开始/结束、修改后提交 |
| 处理中 | 内容已保存、正在整理 | 可返回首页，不强迫等待 |
| 必要确认 | 原文摘要及一个相关选择组或必要字段 | 选择后继续；未处理可保留 |
| 事项详情 | 行动、细则、节点、提醒状态、原始依据 | 完成、编辑；删除回到列表长按选择 |
| 已处理 | 已完成与用户主动结束的事项，标签区分 | 查看、恢复适用事项 |
| 笔记首页/编辑 | 笔记列表；标题与完整正文/图片 | 新建、保存、搜索、提取日程；长按批量删除 |
| 设置 | 通知能力状态、少量提醒和隐私偏好 | 必要配置；不引入账户入口占位 |
| 系统分享 | 实际接收内容预览 | 提取日程/保存笔记 |
| 系统通知 | 当前行动、时间、可用办理信息；必要时显示一个确认问题 | 完成或完成本次、稍后提醒；直接选择常见答案；点正文进入详情或补充页 |

详情页提供完成和编辑入口，初版不在每个列表行堆叠多个操作按钮。删除只在列表长按后的选择状态出现，并支持批量操作。

### 3.1 正常创建
进入日程 → 录入 → 提交并保存 → 解析/校验 → 保存事项 → 按需登记提醒 → 简短反馈，可查看或撤销。

### 3.2 必要确认
解析发现关键歧义 → 保存候选和待确认状态 → 发送系统通知 → 用户可在通知栏直接选择常见答案，或进入补充页选择/填写 → 后台重新校验 → 创建。不能把等待确认的候选描述成已成功安排，也不要求用户停留在前台等待。

### 3.3 系统分享
选中拾时 → 选择用途 → 保存输入 → 日程走解析链路；笔记直接保存。不能假定来源应用一定提供图片、消息时间或正文。

### 3.4 完成
通知栏或详情完成 → 持久化状态 → 撤销该事项未来提醒与适用的当前通知 → 进入已处理。App内可恢复；同一操作重复执行不得产生额外副作用。

## 4. 信息理解与提醒规则

### 4.1 意图与主体
- 日程提交代表希望整理和安排，不再问参与意愿；笔记默认不解析提醒。
- 一次输入优先一个主要事项。图片中明确无关部分排除，相关细则保留。
- 文本也可能有多个独立事项。无法可靠确定主体时一次勾选保留项，不默认全建。
- 用户选择多个事项后分别维护状态；一个事项内部仍只有整件事完成状态。
- 不从群名、他人头像等推断用户身份。已提供身份不重复询问。

### 4.2 内容与依据
- 提取标题、行动、时间及含义、地点、入口、条件/细则、原文依据、歧义。
- 没有结束时间、地点等不补造；操作说明不拆为逐条勾选。
- 保留原图和原文，摘要不覆盖正文。附件名不是附件内容，网址不是已读取的网页。
- 模型输入属于待分析数据，其中的指令不能改变系统解析规则。

### 4.3 时间
- 区分当前时间、导入时间、消息时间、事项时间、提醒时间。
- 截图/粘贴相对时间依可靠消息日期解释；用户直接表达相对提醒以当前时间为参照，转述旧消息除外。
- 状态栏时钟不能冒充消息时间。截图日期分隔线需对应正确消息。
- 年份不明、日期与星期冲突、相对时间参照缺失，影响安排时确认。
- 保留日期/上午/晚上/预计等原有精度；未知时刻不自动设为23:59或19:00。
- 历史统计范围、学年和他人工作时间不自动建节点。
- 原文已过期不顺延。不补发过去的多个提前提醒。
- 默认提醒时刻是产品策略，不得冒充原文事实。

### 4.4 无时间与不确定
- 原文确实没有时间：保存待办，不提醒、不追问。
- 原文有时间但看不清/无法解释：待补充或解析失败，不静默降级为无时间。
- 原通知尚未公布时间：保留待定，可按规则提醒关注安排，明确不是活动发生时刻。
- 某节点不确定不必阻止其他可靠节点保存；详情明确列出已安排与待定，不能全局显示“全部已安排”。

2026-10-12执行补充：时间明确修饰“提醒我”时按指定时刻通知；仅提供事项发生时刻时才使用默认策略。原文明确提前要求优先；直接提醒钟点省略日期仅在当天尚未过去时默认今天。单字段补充后先尝试本地校验，只有复杂内容重新调用模型。现行信息理解与提醒规范为v0.6。

### 4.5 提醒类型

| 含义 | 初始策略 |
|---|---|
| 活动开始 | 开始前提醒；结束不默认通知 |
| 截止任务 | 提前留出办理时间 |
| 报名窗口 | 开放时；未完成则截止前 |
| 只有开放 | 开放提醒，不补造截止 |
| 窗口内完成一次 | 窗口内适时提醒，未完成则临近截止 |
| 持续活动 | 开始前提醒，不默认每日 |
| 明确重复 | 按周期，完成本次不影响后续 |
| 长期任务 | 提前准备与截止前，不擅自拆工作计划 |
| 无时间 | 不提醒 |

具体提前量、休息时段、延后选项是待验证配置，不能在开发中隐式定死。技术验证可使用可配置测试值；实际试用前需明确默认值，不将测试值当作已确认产品规则。大多数单节点事项以一至两次为初始目标，不无限催促。

### 4.6 完成与结束
- 普通事项整体完成，取消全部未来节点提醒。细则与节点不设独立完成按钮。
- 多节点通知使用“整件事已完成”，不让“已进群”错误结束后续答辩。
- 划掉通知、查看详情、打开链接不改变完成状态。
- 截止/活动结束仅为时间状态，不自动完成，不自动移入已处理。
- 普通事项恢复后仅安排未来有效提醒，无未来时间仍可恢复为待办，明确没有未来提醒。
- 重复事项“完成本次”作用于当前周期；“结束重复”作用于整个系列，不批量改写历史完成记录。
- 规则自然到期停止生成新周期，最后一次仍可待完成。若仍有未处理周期，不能仅因规则到期将其认定已处理。
- 重复系列结束后的恢复语义需要单独细化，MVP先不提供含义不清的一键恢复系列按钮。

## 5. 处理架构与业务状态

### 5.1 理解链路

```mermaid
flowchart TD
    A[用户在日程入口提交内容] --> B[保存原始输入与时间上下文]
    B --> C{输入类型}
    C -->|图片| D[视觉大模型结合原图理解]
    C -->|文字| E[本地规则尝试解析]
    C -->|语音| F[语音转写，允许用户修改后提交]
    F --> E
    E -->|简单明确| G[事项候选结果]
    E -->|单字段缺失| J[用户一次选择或补充]
    E -->|复杂或无法可靠处理| H[文字大模型理解]
    D --> G
    H --> G
    G --> I[本地统一校验]
    I -->|关键歧义或多个事项难以取舍| J[用户一次选择或补充]
    J --> K[更新候选结果，必要时重新解析]
    K --> I
    I -->|校验通过| L[保存待办事项]
    L --> M{时间信息情况}
    M -->|有可靠时间| N[本地规则生成并登记提醒]
    M -->|原文没有时间要求| O[无提醒待办]
    M -->|原通知时间尚未公布| P[保留待定状态]
    N --> Q{提醒登记结果}
    Q -->|成功| R[显示已安排提醒]
    Q -->|权限受限或失败| S[显示已保存、提醒未启用或失败]
```

图中为主要成功与确认路径。任一解析步骤失败时，保留原始输入并显示可重试状态；原文时间无法识别不等于原文没有时间，不得静默降级为无提醒待办。多节点事项逐节点判断时间与提醒状态，可部分已安排、部分待定。图中“已安排”指登记成功，不等同于已经验证实际送达。

图片：保存 → 视觉模型理解 → 统一校验。
文字：保存 → 本地有限规则 → 明确则校验；复杂则文字模型 → 校验。
语音：转写、允许编辑 → 文字链路。
校验后：必要确认或创建 → 有可靠时间则生成提醒，否则待办/待定。

AI输出候选，不直接决定系统提醒。系统提示词承载理解规则，结构化输出承载依据和不确定项，本地程序执行可确定检查和状态变更。模型自报置信度不是唯一放行条件。

### 5.2 分开保存状态，避免混用

| 对象 | 状态/属性 |
|---|---|
| 输入处理 | 已保存、解析中、待补充、解析失败、处理完成 |
| 普通事项 | 待完成、已完成；删除为单独操作 |
| 时间状态 | 未开始、进行中、已截止/已结束、无时间、待定，按节点计算 |
| 提醒状态 | 无需提醒、待安排、已安排、部分已安排、受限/失败、已停止 |
| 重复系列 | 有效、用户已结束、规则到期；周期单独记录完成情况 |

核心数据对象：原始输入、候选结果、事项、时间节点、提醒记录、重复系列与周期。提醒与事项状态关联，细则不创建完成状态。

## 6. 功能需求与验收条件

| 编号 | 要求 | 可验收结果 |
|---|---|---|
| IN-01 | 提交即持久化 | 解析失败或重开App仍能找到输入，重试不要求重新录入 |
| IN-02 | 图片及补充一起理解 | 已写“六级非毕业生”时不重复询问类别 |
| IN-03 | 语音仅在用户操作时录入 | 有录音状态，结束后可改文字；拒绝麦克风权限可改用文字 |
| IN-04 | 分享明确用途 | 相同内容分别可保存笔记或进入日程解析，不默默选用途 |
| AI-01 | 明确信息自动创建 | 简单完整通知没有逐条审批页 |
| AI-02 | 多事项选择 | 保留选中事项，未选部分不安排提醒 |
| AI-03 | 关键歧义确认 | 只补充缺失事实，已有信息不重问；取消后保留待补充 |
| AI-04 | 有依据输出 | 明确日期/地点可回看对应原文；缺失字段留空 |
| TD-01 | 无时间待办 | 出现在未设时间区域，不出现通知、不逼选日期 |
| TD-02 | 编辑与补时间 | 保存后展示新内容，旧提醒撤销，新未来提醒按新规则安排 |
| TD-03 | 整件事完成 | 所有未来节点提醒停止，重复点击不产生副作用 |
| TD-04 | 恢复待完成 | 不补发历史提醒，无未来提醒时状态如实显示 |
| TD-05 | 重复控制 | 完成本次不影响下次；结束重复不再生成后续周期 |
| NT-01 | 权限与安排结果真实 | 权限拒绝仍保存事项，但不显示“提醒已启用” |
| NT-02 | 通知操作同步 | 通知完成后App显示已完成；打开/划掉通知不改状态 |
| NT-03 | 稍后提醒 | 不改原截止事实、不标记完成；延后时间越过有效窗口时不能静默安排 |
| NT-04 | 真机到达 | 目标机型、系统版本、锁屏/后台等条件和实际触发偏差有记录 |
| NB-01 | 笔记隔离 | 带日期的笔记也不自动提醒；正文完整保留 |
| NB-02 | 笔记转日程 | 主动触发解析，原笔记保留，解析失败不损坏笔记 |
| ST-01 | 重试与重复回调 | 同一次提交重复返回不重复创建事项/提醒 |
| ST-02 | 改期与取消 | 不确定对应关系时先确认，不误删另一事项 |
| ST-03 | 删除 | 取消未来提醒；删除交互必须可理解，并提供适当误操作保护 |

搜索至少覆盖笔记标题和正文；日程全局搜索暂不作为首个闭环的必需功能。重复导入与改期的内容匹配策略仍需验证，不能只靠标题相同自动覆盖。

## 7. 提醒可靠性与数据处理要求

### 7.1 跨厂商兼容

- 面向支持Android应用的设备，不绑定vivo或某个厂商专有服务。当前工程最低API 26（Android 8.0）为初始兼容边界；最终支持范围由兼容测试确定，不用“可安装”代替功能验收。
- 核心待办、本地存储和本地提醒不依赖Google Play服务，也不依赖厂商推送账号。不能运行Android应用的系统不属于本Android版本的覆盖范围。
- 验证覆盖Android版本、厂商系统、通知/精确提醒权限、休眠、省电模式与后台限制的组合，记录通过与未验证情况，不声称已覆盖某个市场比例。
- 权限设置优先使用标准系统入口；特定厂商的设置指引只在确有问题时补充，不要求所有用户执行复杂的后台配置。

### 7.2 轻量与省电

- 不以常驻服务、前台保活通知、持续唤醒锁、定时轮询或无关的周期性网络请求维持提醒。
- 用户创建/修改事项后，将提醒交给系统调度；应用进程可以退出，到期由系统触发短时工作并展示通知。正常退出不等同于系统设置中的强制停止，后者及厂商限制需单独测试和说明。
- 提醒触发只读取本地所需数据，不在触发时调用大模型、下载图片或执行长时间任务。
- 模型解析仅因用户提交或主动重试发生；失败不进行无限重试。
- 需要准点的用户可见提醒使用适当的精确调度；可容忍时间窗口的提醒优先合并或使用非精确调度。缺少精确提醒权限时显示可能延迟，不假称准点。
- 完成、删除或修改事项时取消失效提醒；正常页面切换不重复登记未变化的提醒。设备重启等必要事件重新登记未来有效提醒，不补发历史提醒。
- 不默认要求忽略电池优化或保持App锁在最近任务中；若实际测试发现系统限制，提供有针对性的说明和修复入口。
- 控制依赖、安装包体积与图片解码内存；使用系统选择器按需读取图片，不扫描整个相册。包体、启动耗时、内存和后台唤醒次数应持续测量；模型/语音完整接入前不宣称最终体积或耗电量。

### 7.3 可靠性与数据处理

- 区分“已登记提醒”和实际成功送达，不能承诺忽略系统限制仍必达。
- 真机验证通知权限、前后台、锁屏、进程被结束、重启、系统时间/时区调整等场景；强制停止等限制需按实测说明。
- 设计模型调用的受控服务端入口，不将供应商长期密钥打包进Android客户端；具体部署方案待选。
- 用户需知道复杂文本/图片会发送至所选模型服务；仅传本次理解需要的内容，不自动上传整份历史。
- 日志默认避免完整通知、图片、个人链接和录音；调试样本使用授权并脱敏的材料。
- 删除和保存期限需落实到本地数据与服务端临时数据，供应商的数据政策选择后再明确。

### 7.4 非功能验收

| 编号 | 验收内容 |
|---|---|
| NF-01 | 无事项、无用户操作的空闲场景不出现应用主动周期轮询、后台网络请求或保活服务 |
| NF-02 | 应用进程自然回收后，具备所需权限的未来提醒仍可由系统触发；结果按设备记录 |
| NF-03 | 完成/删除后没有该事项的后续提醒触发；重复打开页面不反复登记相同提醒 |
| NF-04 | 无Google Play服务的兼容Android设备能够使用核心本地功能 |
| NF-05 | 多厂商和多个Android版本按测试矩阵验证，未实测项明确标注 |
| NF-06 | 记录APK与安装后体积、启动耗时、内存及待机期间的唤醒/耗电测试条件，不把开发包大小视为最终指标 |

## 8. 真实样本与验证计划

样本起点：奖学金答辩、信息采集、四六级报名、离返校登记、二课自查、积极分子考试六类。保留完整原始上下文，正式共享前脱敏。

每个样本标注：主事项、时间表达/参照、适用条件、正确节点、应忽略内容、必要确认、提醒方向。样本出处与授权另行记录。

验证分三层：
1. 解析：主事项、时间、条件、漏提、编造、多余确认。
2. 业务：自动创建/待补充、完成/恢复、重复、幂等和失败保存。
3. 设备与用户：提醒实际表现、操作耗时、改错原因、用户是否愿意再次使用。

开发样本与保留测试样本分开；六张截图足以起步，不足以推断整体准确率。指标同时记录样本数、失败类型与测试条件。

## 9. 开发前需要完成的验证与决策

| 项目 | 下一步 | 是否影响推进 |
|---|---|---|
| 目标Android手机/系统 | 用户确认为vivo X100s / Android 16，基础版界面和通知正常；完整专项及其他厂商待验证 | 影响提醒技术验证 |
| 模型供应商与预算 | DeepSeek文字/图片已完成少量脱敏样本调用验证，预算与代表性质量评估仍待完成 | 不能凭少量样本定准确率 |
| 语音转写方式 | 比较设备能力与服务方案 | 不阻塞文字/图片闭环 |
| 提醒默认值 | 提出可配置初值，试用后调整 | 提醒策略验收前明确默认值 |
| 跨时区/重复边界 | 明确本地时钟与固定时刻语义，周期延迟操作如何归属 | 影响高级提醒验收 |
| 数据保留与删除 | 明确录音、原图、服务临时数据期限 | 影响实际试用说明 |

## 10. 产品阶段与验收门槛

按需求依赖和验证结果推进，不以固定日期替代完成条件。具体工程排期放在开发计划中维护；范围变化需同步修订本PRD及对应验收项。

| 阶段 | 目标 | 进入下一阶段的条件 |
|---|---|---|
| M1 需求基线 | 明确范围、交互和业务规则 | 核心流程无相互矛盾的规则；待定项明确影响范围；确认对应阶段验收条件 |
| M2 技术可行性 | 验证图片理解、模型调用和Android提醒 | 授权样本获得可校验结果；真机提醒实际触发；记录准确性、耗时、限制与成本 |
| M3 核心流程 | 打通输入、理解、确认、事项、提醒、完成 | 输入可持久化；失败可恢复；完成可停止提醒；无时间待办不提醒 |
| M4 MVP功能验收 | 实现第2.1节所列功能 | 文字、图片、语音、分享、笔记与重复等功能按验收条件检查；不存在阻断关键操作的问题 |
| M5 小范围试用 | 验证实际使用价值和可靠性 | 记录样本量与设备条件；分析误判、漏提醒、多余确认和操作负担；完成问题修复与复测 |
| M6 发布评审 | 判断是否具备对外提供服务的条件 | 确定支持范围、已知限制、隐私说明、服务配置及故障处理方式；未通过项有明确结论 |

### 10.1 质量与体验指标

| 指标 | 统计口径 |
|---|---|
| 自动创建正确率 | 经人工核对行动、关键时间及适用条件均正确的自动创建事项数 / 被核对的自动创建事项数 |
| 关键节点漏提率 | 未提取的应有行动时间节点数 / 标准答案中的应有行动时间节点数 |
| 多余确认率 | 经人工核对可直接从输入确定、却向用户追问的提交次数 / 被评估提交次数 |
| 提醒触发成功率 | 具备记录中规定的权限与测试条件且实际触发的提醒数 / 同条件下应触发的提醒数；同时报告受限场景 |
| 录入处理耗时 | 从用户开始录入到事项保存的总时长，另记录解析耗时与必要确认耗时 |
| 用户修改情况 | 记录修改字段与原因，区分识别错误、语义错误和用户主动改变安排 |

具体达标阈值在基线测试后、试用或发布评审前确定并记录，不预填未经验证的成绩。指标不替代缺陷判定：出现数据丢失、完成后继续提醒、虚构关键时间等问题，必须排查、修复并复测。

### 10.2 变更控制

导航、事项状态、理解链路、提醒策略或数据处理方式发生实质变化时，同步更新需求、设计、相关测试与CHANGELOG，通过Git提交和里程碑标签保留历史。开发阶段完成不等于整版MVP通过验收。

## 11. 变更记录

- v0.1：合并理解与提醒规范v0.2，固定图片直达视觉模型链路；增加页面、状态、需求编号、验收条件、阶段交付和待验证清单。
- 第二次修订：聚焦产品需求，补充用户场景、按阶段验收门槛和质量指标口径，更新目标测试机与模型验证方向。
- 第三次修订：记录用户确认的Android 16及DeepSeek初步调用验证；具体已实现与缺口见understanding-implementation.md，不缩减MVP范围。
- 第三次修订：确认跨厂商兼容、轻量、省电与不依赖后台常驻为产品约束，补充非功能验收。