Skip to content

Product Design Report

Jump to bottom
Lupeng Han edited this page Jul 17, 2026 · 2 revisions

1. TimeFlow 是什么

TimeFlow 是一款以 AI 对话为主要操作方式的个人时间管理产品，由三个一级 Tab 和五类 AI 子能力组成：日程 Tab 负责年/月/日时间展示和手动操作；AI Tab 负责文字、语音、主动上传图片、多轮对话和能力编排；目标 Tab 负责 Goal、Task、进度和轻量 AI 状态摘要。

TimeFlow 不是普通待办清单，也不是替用户静默接管日程的自动排程工具。它解决的核心问题是：

用户需要把长期 Goal 直接变成有明确开始和结束时间的 Task，在现实打断计划后快速得到可确认的恢复方案，并通过真实 Feedback 和可追溯 ReviewReport 理解执行偏差；同时，用户不应为了调用这些能力而学习复杂页面和表单。

与普通待办、日历和 AI 排程工具相比，TimeFlow 的关键差异有五个：

  • AI 是统一交互入口：用户只在 AI Tab 中对话，不在多个页面寻找不同 AI 功能。
  • Goal 直接落到时间：Goal 只包含 Task；每个 Task 创建时必须具有完整开始/结束日期时间，并自动安排到空闲时段。
  • 打断后恢复节奏：主动或被动生成 ReschedulePlan；系统可以自动发现并生成方案，但不能自动应用。
  • 事实、候选和表达分离：Feedback 和业务状态由用户确认；代码计算事实；AI 只生成候选、方案和解释。
  • 复盘可追溯：周期复盘与目标复盘版本化落库、自动通知，只通过 AI 对话查询和展示。

本期产品判断是：8 周内不做完整时间管理平台，而是验证“AI 输入 → Goal/事项落盘 → Task 自动排期 → 执行 Feedback → 主动/被动重排 → 版本化复盘”这一条闭环是否成立。

2. 背景与战略决策

2.1 背景与机会

时间管理工具已经覆盖记录、待办、日历、番茄钟和自动排期，但用户推进长期目标时仍然经常失败。问题不只是缺少功能，还在于用户需要先判断入口、对象类型和字段；Goal 从一开始难以落到每天，计划一旦被打断，用户又要重新承担拆解、估时、排序和补救成本。

原调研样本 n=59 显示：

  • 面对两周以上复杂任务，仅 32.2% 的用户会立即拆解成小步骤；37.29% 只是“大概想想不写下来”；16.95% 知道要做但不知道从哪开始。
  • 计划未完成的首要原因是“突发紧急任务插入”和“高估了自己的精力/专注力”，两项均为 59.32%。
  • “需要一个能在被打乱后自动重新排期的工具”评分为 3.24/5，是问卷最高单项。
  • 仅 25.42% 希望 AI 全程盯着并接管，47.46% 更希望系统提供提醒和反馈，但最终由自己掌控。
  • 49.15% 希望 AI 生成复盘报告，49.15% 希望获得个性化改善建议。

这组数据指向三个机会：降低操作入口摩擦；让 Goal 直接变成有时间的可执行 Task；在打断后生成可确认方案，并把执行事实转成可追溯复盘。

2.2 目标人群定义

TimeFlow 按行为条件而非身份标签定义本期目标用户：

  1. 有需要自己拆解和负责的长期 Goal。
  2. 日程存在较高不确定性，计划容易被课程、会议、加班、订单或临时事务打断。
  3. 希望 AI 降低操作与规划成本，但不希望 AI 未经确认修改事实。
用户类型 典型 Goal/场景 主要痛点 本期匹配能力
学生 考试、竞赛、论文、作品集 不会拆计划，课程和社团容易打断 Goal 拆分、Task 自动排期、重排、目标复盘
自我提升型职场人员 转岗、考证、学习、健身 加班挤占个人目标时间 跨日重排、Feedback、显式画像、周期复盘
自由职业者 项目交付、客户拓展、能力积累 订单临时插入，缺少稳定时间结构 Goal/Task、Schedule 协调、恢复方案
日常管理型用户 会议、预约、普通待办 不一定需要 Goal，但日程容易混乱 Schedule、Todo、Feedback、重排、周期复盘

本期核心成功判据仍以“长期 Goal + 高不确定性”的前三类用户为主；日常管理用户是 Schedule/Todo 闭环的兼容场景。

2.3 用户故事

场景小故事 功能 价值 模块 对应人群
我在 AI Tab 说“明天下午三点开项目会”，确认后创建 Schedule AI CRUD 不必寻找页面和填写完整表单 AI Tab/CRUD 全部
我主动上传聊天截图，系统 OCR 后生成 Todo 草稿让我确认 主动图片输入 降低图片录入成本且不后台读取 AI Tab/快速记录 全部
我手动在日程 Tab 添加“买药”Todo 手动 CRUD 不使用 AI 也能完成核心操作 日程 Tab 全部
我说“两周完成产品需求报告”，AI 追问后把 Task 自动放到空闲时间 Goal 拆分与排期 Goal 直接变成可执行日程 Goal 拆分 核心人群
没有足够空闲时间，系统列出延长期限、减少 Task 等方案 容量不足处理 不制造看似完整但无法执行的计划 Goal 拆分 核心人群
新会议占用了已有 Task，系统自动生成重排方案并通知我 被动重排 及时恢复计划，但不替我应用 重排 全部
我说“这个 Task 完成了，实际用了 90 分钟” 语言 Feedback 一次确认更新状态并保存事实 Feedback 全部
我在日程 Tab 点击事项并通过表单反馈 表单 Feedback 保留明确、可见的手动方式 Feedback 全部
系统每周自动生成周期复盘，我也可以问“复盘一下今天” 周期复盘 了解整体执行节奏 复盘 全部
Goal 完成后自动生成目标复盘，我可在 AI 中查询历史版本 目标复盘 理解目标偏差且可追溯 复盘 核心人群
我手动维护“工作日晚上有空”，P1 再确认系统提出的历史画像建议 用户画像 先显式可控，再逐步个性化 用户画像 核心人群

2.4 用户痛点

痛点 具体表现 调研/设计依据 对应人群
Goal 太大、不会排到每天 只有大目标，不知道具体何时做什么 仅 32.2% 会立即拆解；91.52% 对自动拆任务时间线有兴趣 核心人群
计划被打断后恢复成本高 临时会议、加班、任务超时后需要逐条手动调整 突发事项和高估精力均为 59.32% 全部
操作入口和表单过多 用户先判断对象类型，再寻找页面和字段 产品流程审查；需通过手动/AI 对照验证 全部
自动化掩盖问题 系统静默顺延、覆盖计划或移动重要会议 47.46% 更希望提醒反馈但由自己掌控 全部
执行事实不完整 只有完成状态，没有实际耗时和原因 49.15% 希望复盘与个性化建议 全部
复盘不可追溯 AI 给出泛泛总结，用户不知道依据 AI 稳定性与信任边界 核心人群
通用计划不符合个人节奏 生成结果没有利用用户作息和容量 显式画像的冷启动需求；历史画像放 P1 核心人群

2.5 解决方案

一句话价值主张：

TimeFlow 让用户通过一个持续 AI 对话管理时间：把 Goal 自动拆成有具体时间的 Task，根据真实 Feedback 自动生成待确认重排方案，并用可追溯复盘帮助用户在变化中持续推进重要目标。

产品结构：

flowchart LR
    CAL[日程 Tab<br/>年 / 月 / 日] --- AI[AI Tab<br/>文字 / 语音 / 主动上传图片]
    AI --- GOAL[目标 Tab<br/>Goal / Task / 进度摘要]
    AI --> ORCH[母 Agent]
    ORCH --> CRUD[CRUD]
    ORCH --> FB[Feedback]
    ORCH --> RP[重排]
    ORCH --> RV[复盘]
    ORCH --> GP[Goal 拆分与排期]
Loading

核心链路：

AI/手动输入
→ 用户确认 Schedule/Todo/Goal/Task
→ 日程 Tab 统一展示时间安排
→ 执行后提交统一 Feedback
→ 系统自动或用户主动生成 ReschedulePlan
→ 用户确认后原子应用
→ 自动/主动生成 ReviewReport 并通知
→ AI 对话查询报告与历史

3. 市场调研和竞品分析

3.1 时间管理软件的主流流程和存在的解决方案

五个流程 市面上常见解决方案总结
捕获 手动/自然语言录入；语音、邮件、IM、图片转任务；AI 提取时间与标题
组织 项目—任务—子任务；标签、优先级、依赖、清单；AI 自动分类与拆解
规划/调度 手动拖拽；AI 建议+用户批准；全自动排程；冲突、缓冲、动态重排
执行/专注 番茄钟、专注模式、时间保护、App 屏蔽、执行中调整
复盘 完成率、计划/实际用时、周期报告、AI 归因与改进建议

3.2 竞争总结

详细竞品分析见 GitHub Issue #45。

流程环节 市场格局与代表方案 主要结论
捕获 Akiflow 多来源入口、Amie 内容转任务、Todoist 自然语言输入 捕获已成熟，竞争点是统一入口和确认边界，不是增加渠道
组织 Todoist 多层项目、Notion 自由数据库、Sunsama 焦点目标 组织越深输入负担越高；
调度 Motion/Reclaim 偏自动，Morgen 建议+批准，Sunsama 偏手动 核心差异是最终决定权属于系统还是用户
专注 Forest/App 阻断、TickTick 番茄钟、Focus Time 已有成熟产品；TimeFlow 主张应对打断而非消灭打断
复盘 Sunsama/BeforeSunset 仪式和数据展示，Reclaim 时间分布 AI 化、证据可追溯并回到计划的复盘仍不足

3.3 市场空缺与机会判断

市场空缺 用户需求 竞品不足 数据支撑 TimeFlow 机会
Goal 拆解与调度不连续 Goal 需要直接落到每天具体时间 多数产品以单 Task 排程，无 Goal 上层追溯 自动拆任务时间线兴趣合计 91.52% Goal → Task，Task 创建即自动排到空闲时段
打断后缺少可控恢复 用户不愿逐条移动，也不愿黑箱自动改 全自动产品易让用户“和算法打架”，纯手动恢复成本高 自动重排需求评分 3.24/5 自动生成方案、用户部分选择、确认后原子应用
复盘缺少 AI 归因和证据 用户希望知道偏差原因与改进方式 深度复盘多依赖人工仪式或只展示统计 49.15% 希望复盘和个性化建议 代码统计事实，AI 表达，ReviewReport 版本化落库
AI 只是传统页面外壳 用户仍要理解页面、对象和字段 多数 AI 只做输入或局部建议 产品流程假设，需本期验证 单一 AI Tab + 母 Agent 编排五类能力
自动化容易掩盖问题 逾期、冲突和无法安排应如实可见 静默顺延和自动覆盖削弱信任 仅 25.42% 希望 AI 接管 所有事实写入需确认；无空闲时展示取舍而非假方案

4 产品定位与本期范围

4.1 功能主线与深度分配

节点 深度 本期做法 理由
捕获/交互 中度投入，统一入口 AI Tab 文字、语音、主动上传图片；页面保留手动兜底 降低入口摩擦，但不扩展第三方来源
组织/展示 基础但完整 日程/AI/目标三 Tab；Schedule/Todo/Goal/Task 清晰分工 降低层级，避免万能 Task 与重复页面
规划/调度 深耕核心 Goal 拆分、Task 自动排期、容量不足方案 直接解决“不会拆、不会排”
执行/恢复 深耕核心 统一 Feedback、主动/被动重排、确认后原子应用 打断后的恢复是核心差异化
复盘/个性化 深耕差异化 两类 ReviewReport；P0 显式画像，P1 候选画像 让执行事实回到理解与下一轮计划

4.2 本期做什么

三 Tab 主链：

用户在日程 Tab 手动管理，或在 AI Tab 输入 → 母 Agent 读取数据并调用子 Agent → 用户确认业务候选 → 日程 Tab 展示 Schedule/Todo/Task → 目标 Tab 展示 Goal/Task/进度。

Goal 闭环：

创建 Goal → AI 多轮追问 → 读取显式画像和空闲时间 → 生成带完整时间的 GoalPlanDraft → 用户确认 → 批量创建 Task → 执行 Feedback → 重排 → Goal/周期复盘。

反馈与重排闭环：

语言或表单 Feedback → 原子更新对象状态和 Feedback → 命中条件时自动生成待确认 ReschedulePlan → 通知用户 → 用户修改/部分选择 → 确认后原子应用。

复盘闭环：

每周自动周期复盘；Goal 到期或全部 Task 结束时自动目标复盘；日/月/阶段复盘可主动生成 → ReviewReport 版本化落库 → 通知 → 只在 AI 对话中查询和展示。

用户画像：

P0 用户在设置或 AI 中手动维护显式画像；P1 有余力时从长期 Feedback、Task 执行和重排选择生成候选，经确认后进入同一画像。

4.3 明确不做

不做事项 理由 依据
Subtask、无限层级、任务依赖图 降低认知和实现复杂度；Goal 只含 Task 减法设计、8 周资源约束
多会话列表、其他 Tab 自动携带 AI 上下文 产品是持续时间助理，不是通用聊天工具 单一心智模型
邮件/IM/第三方日历聚合 接入风险高，非差异化重点 工程资源约束
自由图片理解、后台监听、外部页面截屏 P0 只做主动上传 OCR，控制隐私与范围 #24 Denied、#27 NoPlan
AI 静默写业务事实 违背用户控制；易产生错误和不可追溯修改 调研与设计心理学
团队协作、多人排期 引入权限、协同和共享语义 JTBD 与资源边界
番茄钟、游戏化、通用专注模式 产品主张应对打断，不是消灭打断 差异化战略
服务端实时推送与多端去重 P0 只验证本地通知 工程范围
独立复盘页/入口/列表 复盘只通过 AI 对话触发和查看 三 Tab 信息架构

4.4 后续可拓展

能力 状态 本期关系
历史行为画像 P1，有余力时 只生成候选，经用户确认后进入画像
深度复盘/设备使用监控 #16 NoPlan 不进入本期开发验收
应用使用控制 #20 NoPlan 不进入本期开发验收
应用分类 #25 NoPlan 不进入本期开发验收
通知栏图片入口 #27 NoPlan 不进入本期；图片只在 AI Tab 主动上传
任意界面无障碍截屏 #24 Denied 不作为默认未来路线
服务端推送、多端通知 后续独立 Proposal P0 只做本地通知

4.5 核心使用流程

  1. 用户可在设置中维护显式画像，也可直接开始使用。
  2. 用户在 AI Tab 通过文字、语音或主动上传图片表达意图；也可在页面手动操作。
  3. 母 Agent 读取必要事实并调用子 Agent；子 Agent 只返回结构化候选。
  4. 用户确认后，母 Agent 调用确定性业务能力写入 Schedule、Todo、Goal、Task、Feedback 或画像。
  5. 创建 Goal 时，AI 通过多轮对话生成带完整时间的 GoalPlanDraft。
  6. 空闲时间不足时不创建 Task，展示多种调整方案并重新排期。
  7. 正式 Task 自动出现在目标页和日程 Tab。
  8. 用户通过语言或表单提交 Feedback；系统原子更新状态与反馈。
  9. 命中被动条件时自动生成 ReschedulePlan 并通知；未确认前原安排不变。
  10. 用户可修改或取消部分动作，最终确认后全部应用或全部回滚。
  11. 系统按规则自动生成 ReviewReport；用户也可通过 AI 主动生成或查询历史版本。
  12. 全部 Task 完成后仍需用户确认 Goal 完成，随后生成最终目标复盘。

4.6 MVP 核心假设

# 假设类型 核心假设 验证方式 通过标准 失败退路
1 AI 入口 单一 AI Tab 能降低高频操作成本 AI 与页面手动操作对照 ≥4/8 用户认为 AI 更省步骤或更快 AI 收缩为查询、创建和 Goal 拆分
2 三 Tab 日程/AI/目标足以承载核心功能 完成统一用例并访谈入口理解 ≥6/8 能找到核心功能 调整 Tab 文案和日程/目标信息密度
3 Goal 排期 用户需要 Goal 直接生成有时间 Task 让用户确认 GoalPlanDraft ≥4/8 认为比手动拆排更省力 收缩到少数 Goal 模板
4 容量透明 无法安排时展示取舍比制造假计划可信 对比强行排期和取舍方案 ≥6/8 选择先调整再排期 默认只生成可行 Task 子集
5 统一 Feedback 语言+表单能提高事实覆盖且负担可接受 三类对象反馈测试 总体提交率 ≥50% 先收状态和耗时，其他按需追问
6 被动重排 自动生成但不自动应用能兼顾及时与掌控 冲突/延期场景 方案应用或部分应用率 ≥50%，误应用为 0 只提示风险，用户主动点生成
7 Schedule 排期判断 AI 在排期时根据 title 临时判断是否应调整 Schedule，且不会产生未确认移动 会议、健身等 title 混合测试 未确认移动为 0 不移动既有 Schedule，只安排剩余空闲时间
8 复盘价值 自动落库和通知能促进用户查看复盘 周期/Goal 报告通知测试 查看率 ≥50%，数据引用可追溯 报告收缩为短卡片
9 用户掌控 候选+确认比静默执行更可信 对比两种流程 ≥6/8 偏好确认后应用 优化确认卡，不取消确认
10 显式画像 P0 显式画像能改善计划贴合度 同 Goal 默认/画像方案对照 ≥4/8 偏好画像方案 只保留可用时间和偏好时段
11 P1 画像 候选式历史画像不会削弱控制感 有余力时验证候选确认 候选确认后修改率可接受且无自动覆盖 保持 NoPlan
12 单一对话 持续对话和历史查询满足时间助理心智 跨日历史查询测试 ≥6/8 能找到历史计划/报告 增加日期筛选而非多会话

说明：5–8 人原型测试用完成人数报告，不把小样本百分比解释为统计显著；运营指标需在不少于 30 名真实试用用户后计算。

4.7 产品边界与异常处理

产品边界

功能边界

  • 平台：iOS/Android 手机端，Android 优先；不支持 Web/桌面端。
  • 用户：单用户个人工具，不支持团队和多人协作。
  • 语言：P0 仅中文。
  • 一级入口：只有日程、AI、目标三个 Tab。
  • Goal 层级：只有 Goal → Task，不存在 Subtask。
  • Task：每个正式 Task 必须属于 Goal，并有完整开始和结束日期时间。
  • AI：只从 AI Tab 进入，不从其他 Tab 自动带入页面上下文。
  • 图片：只允许用户主动上传，P0 仅 OCR。
  • 复盘：支持 PERIOD/GOAL 两类；报告版本化落库，但没有独立入口或列表页。
  • 画像：P0 显式信息；P1 才生成历史画像候选。

数据与权限边界

  • 只有母 Agent 读取数据层并向子 Agent提供必要上下文。
  • 子 Agent 不直接读库或写库。
  • 母 Agent 在用户确认后调用确定性业务能力，不能绕过权限、版本、冲突和事务校验。
  • 自动 ReviewReport、待确认 ReschedulePlan 和系统通知是无需确认的派生数据例外，但不得自动改变业务事实。
  • 所有对话持久化；产品设计不冻结上下文窗口、摘要和历史检索算法。
  • 语音转写后删除原音频；图片 OCR 后默认删除原图，用户主动保留时才作为附件保存。

通知边界

  • P0 只做当前设备本地通知。
  • 覆盖 Schedule、Todo、Task、ReviewReport 和待确认 ReschedulePlan。
  • 用户可分别关闭事项、复盘和重排通知。
  • 系统杀后台或设备重启后的送达依赖操作系统，不承诺 100%。

关键异常场景与处理方式

场景 触发条件 系统应对 依据/原则
AI 无法判断意图/对象 输入模糊或多个同名对象 追问或展示候选，不生成写操作 不猜测事实
OCR/ASR 失败 无有效文字 允许改用文字输入，不创建空草稿 降级可用
Goal 条件不足 无法形成可执行计划 继续追问，不输出可确认计划 计划必须可执行
Task 缺少时间 没有完整开始/结束时间 只保留草稿，不允许正式创建 Task 创建即排期
空闲时间不足 Task 无法放入可用时段 展示延长期限、减少任务、调整时间/强度等方案 不制造假计划
Schedule 调整判断不合适 AI 根据 title 提出用户不希望的 Schedule 移动 候选中展示具体移动动作和理由；用户可删除该动作或要求重新排期；确认前不改变 Schedule 用户最终决定
Feedback 对象不明确 无法唯一关联 Schedule/Todo/Task 要求用户选择，不保存反馈 事实必须有来源
Feedback 原子操作失败 状态或反馈一侧失败 两者全部回滚 数据一致性
被动重排方案未确认 已生成但用户未处理 保存待确认方案并通知，正式安排不变 自动生成不等于应用
重排无可用空档 约束冲突 展示冲突和取舍，不强行插入 如实展示问题
重排应用部分失败 多对象写入失败 全部回滚，保留方案 不留半成品
Goal 全部 Task 完成 系统检测完成 提示用户确认 Goal 完成，不自动关闭 Goal 由用户确认
Goal 到期但未完成 存在未完成 Task 生成复盘和调整建议，不自动关闭 不隐藏偏差
复盘数据不足 样本不足 说明数据不足，不做强归因 证据边界
自动复盘失败 AI/网络异常 记录失败并允许重试，不保存不完整报告 派生数据完整性
历史询问过宽 用户问“以前都说过什么” 要求缩小时间或主题 避免无边界读取
AI 服务不可用 网络/模型故障 页面手动 CRUD 和表单 Feedback 继续可用 核心功能降级

5. 产品级关键决策与依据

决策点 备选方案 选择 理由 理论/依据
目标用户定义 身份标签 / 行为条件 行为条件 不同身份可能有相同 Job JTBD
一级信息结构 多功能页 / 三 Tab 日程、AI、目标 最少入口覆盖执行、交互和目标 一致性映射、减法设计
AI 入口 全局悬浮 / 只在 AI Tab 只在 AI Tab 避免上下文不透明和入口重复 用户可预期性
对话 多会话 / 单一持续对话 单一对话 时间助理需要连续历史而非话题空间 产品心智一致性
任务层级 Goal→Task→Subtask / Goal→Task Goal→Task 降低认知和实现复杂度 减法设计、MVP 边界
Task 时间 可未排期 / 创建必须排期 必须完整时间 Goal 拆分应直接产生可执行计划 行动可执行性
排期方式 只生成清单 / 自动找空闲 自动找空闲 避免用户二次排期 降低决策负担
容量不足 强行排 / 展示多种取舍 展示取舍后重排 不用完整性掩盖不可行 用户控制与诚实反馈
Schedule 调整判断 在 Schedule 上保存分类 / 用户每次手动分类 / AI 排期时判断 不保存分类；AI 每次排期根据 Schedule title 临时判断 Schedule 本身保持简单，同时让排期理解会议、健身等语义差异 语义匹配、最小建模
Feedback 按对象拆分 / 统一概念 统一，界面渐进 同一执行事实不应有两套模型 概念一致性
Feedback 入口 仅表单 / 仅语言 / 两者 语言+表单 AI 主入口与手动兜底并存 渐进增强
被动重排 只提醒 / 自动应用 / 自动生成待确认 自动生成待确认 兼顾及时性与掌控 用户控制与自由
重排应用 整体不可改 / 部分选择后原子应用 后者 用户可取舍，同时保证一致性 可逆性、事务一致性
复盘范围 单一报告 / PERIOD+GOAL 两类 整体节奏和目标结果是不同问题 关注点分离
复盘存储 临时生成 / 覆盖旧版 / 版本化落库 版本化 支持通知、历史与证据追溯 可追溯性
复盘入口 独立 Tab / 目标入口 / 只在 AI 只在 AI 保持三 Tab，避免报告页膨胀 减法设计
数据访问 子 Agent 自行读写 / 母 Agent 统一编排 母 Agent 统一 控制数据范围和写入路径 最小权限、关注点分离
画像 P0 自动学习 / 显式P0+候选P1 后者 冷启动可控，历史建议需证据和确认 渐进式个性化
AI 语气 严格式 / 如实但不苛责 后者 保留事实同时不削弱胜任感 自我决定理论
平台 Web优先 / 手机优先 手机优先 高频时间管理场景与训练营约束 资源约束

6. 功能模块设计

主链

6.1 AI Tab 与快速记录

  • 功能：单一持续对话；文字、语音、主动上传图片；母 Agent 统一数据读取、子 Agent 路由、候选展示和确认后写入。
  • 满足价值：用户不用理解页面和模块边界，同时写操作仍可控。
  • 典型场景：用户说“把明天会议改到三点”，母 Agent 查询对象、调用 CRUD 子 Agent、展示修改候选，确认后写入。
  • 详细设计：Proposal #19：AI Tab 与快速记录。

6.2 日程 Tab 与统一展示

  • 功能：年/月/日视图统一展示 Schedule、已排期 Todo 和 Task；保留未排期 Todo 区域。
  • 满足价值：一处看清所有时间占用，同时不合并业务对象。
  • 典型场景：日视图同时看到会议、已安排买药 Todo 和 Goal Task。
  • 详细设计：Proposal #46：日程模块、Proposal #18：待办模块。

6.3 Goal 与 Task 管理

  • 功能：目标页展示 Goal 列表、Task、确定性进度和轻量 AI 摘要；支持手动与 AI CRUD。
  • 满足价值：Goal 和执行任务保持可追溯关系。
  • 典型场景：用户手动补充一个 Task，填写时间后同步到日程 Tab。
  • 详细设计：Proposal #14：长期安排模块。

6.4 Goal 拆分与 Task 自动排期

  • 功能：AI 多轮追问，读取显式画像和空闲时间，生成带完整时间的 GoalPlanDraft。
  • 满足价值：把“拆什么、何时做”一起交给 AI，但最终由用户确认。
  • 典型场景：两周报告 Goal 被拆为多个 Task；AI 根据现有 Schedule title 和时间生成无冲突方案，需要移动 Schedule 时把动作明确列入候选。
  • 详细设计：Proposal #14：长期安排模块。

6.5 统一 Feedback

  • 功能：Schedule、Todo、Task 使用同一 Feedback；支持语言和表单；确认后原子更新状态与反馈。
  • 满足价值：执行事实可以稳定进入重排和复盘。
  • 典型场景：“任务完成，实际 90 分钟”一次确认完成两项写入。
  • 详细设计：Proposal #23：执行反馈。

6.6 主动与被动重排

  • 功能：用户主动请求，或系统基于冲突、Feedback、Goal 变化和容量不足自动生成待确认方案。
  • 满足价值：计划被打断后及时恢复，但不由系统静默应用。
  • 典型场景：临时会议占用 Task，系统通知待确认 ReschedulePlan。
  • 详细设计：Proposal #17：智能时间重排。

6.7 统一复盘与 ReviewReport

  • 功能：PERIOD/GOAL 两类复盘；代码统计事实、AI 生成表达；自动/主动生成并版本化落库。
  • 满足价值：复盘可追溯、可查询，不只是一次性 AI 文本。
  • 典型场景：每周报告自动生成，用户在 AI 中问“看看上周复盘”。
  • 详细设计：Proposal #13：目标复盘、Proposal #15：周期（基础）复盘。

6.8 用户画像

侧支

6.9 消息提醒

  • 功能：Schedule、Todo、Task、ReviewReport 和待确认 ReschedulePlan 的本地通知。
  • 满足价值：事项和自动生成结果能在 App 外触达。
  • 典型场景：自动周复盘生成后通知，点击进入 AI Tab 展示报告。
  • 详细设计：Proposal #47：消息提醒。

6.10 未来方向（本期不做）

主流程图

flowchart TD
    IN[AI Tab 或手动页面] --> M[母 Agent / 确定性页面操作]
    M --> C[结构化候选]
    C --> Q{改变业务事实?}
    Q -- 是 --> U[用户确认]
    U --> W[确定性校验与落库]
    Q -- 派生数据 --> D[自动保存 ReviewReport / 待确认方案]
    W --> DATA[Schedule / Todo / Goal / Task / Feedback / Profile]
    DATA --> CAL[日程 Tab]
    DATA --> GOAL[目标 Tab]
    DATA --> RP[重排]
    DATA --> RV[复盘]
    RP --> C
    RV --> D
    D --> N[本地通知]
Loading

7. 全局基本概念与信息结构

7.1 基本概念总览

概念 定义 作用 边界
Conversation 用户唯一的持续 AI 对话 多轮交互和历史查询 无多会话列表；历史不等于当前授权
Schedule 有完整开始/结束时间的安排 时间占用、提醒、冲突判断 不保存固定/可移动分类；AI 只在排期时根据 title 临时判断是否提出调整动作
Todo 不属于 Goal 的普通完成型事项 低摩擦日常管理 可以没有计划时间；逾期不静默顺延
Goal 需要持续推进的长期目标 Task 的上层对象 不含 Subtask；用户确认完成
Task Goal 下唯一一层执行任务 将 Goal 落到具体时间 必须属于 Goal 且有完整时间
ActionDraft AI CRUD 等待确认的结构化候选 防止 AI 直接写事实 未确认不落库
GoalPlanDraft Goal 拆分和排期草稿 确认后批量创建 Task 所有 Task 候选必须有时间
Feedback Schedule/Todo/Task 的执行事实 触发重排并支撑复盘 用户确认；与状态原子写入
ReschedulePlan 主动/被动生成的待确认重排方案 恢复时间安排 可自动保存但不能自动应用
ReviewReport PERIOD/GOAL 复盘派生数据 历史查询与改进建议 自动/主动生成并版本化；不自动改事实
UserProfile 显式信息及 P1 经确认的候选建议 个性化拆分与重排 当前输入和硬约束优先
Reminder 事项和系统事件本地通知 App 外触达 失败不回滚业务结果

7.2 对象关系

User
├─ Conversation
├─ UserProfile
├─ Schedule
├─ Todo
├─ Goal
│  └─ Task
├─ Feedback → Schedule / Todo / Task
├─ ActionDraft
├─ GoalPlanDraft
├─ ReschedulePlan
├─ ReviewReport → PERIOD / GOAL
└─ Reminder → Schedule / Todo / Task / ReviewReport / ReschedulePlan

7.3 Schedule、Todo 与 Task 的区别

对比项 Schedule Todo Task
核心语义 某段时间发生什么 有一件事需要完成 为 Goal 推进的可执行任务
是否属于 Goal 否 否 是
时间 必须有开始/结束 可无计划时间 必须有开始/结束
创建方式 AI + 手动 AI + 手动 Goal 拆分 + AI/手动补充
日程 Tab 直接展示 已排期时进入时间轴；未排期在待办区 必然进入时间轴
重排 AI 在排期时根据 title 临时判断是否提出调整，不保存分类 调整计划时间，不静默改截止 调整时间但不违反 Goal 截止
Feedback 统一 Feedback 统一 Feedback 统一 Feedback
复盘 周期复盘 周期复盘 周期复盘 + 目标复盘

7.4 一级信息结构

一级入口 承载内容 设计理由 关键对象
日程 年/月/日、Schedule、Todo、Task、Feedback、主动重排 用户执行时需要看时间而非后台类型 Schedule、Todo、Task、Reminder
AI 持续对话、输入、确认卡、计划、重排、复盘和历史查询 所有智能能力共享同一交互入口 Conversation、Draft、Plan、Report
目标 Goal 列表、Task、进度、轻量摘要 长期目标需要跨天整体管理 Goal、Task

右上角设置承载 UserProfile、通知设置、账号和授权，不作为一级 Tab。

7.5 跨入口全局能力

能力 出现位置 作用 说明
手动 CRUD 日程、目标 AI 不可用或用户不想对话时的兜底 调用同一确定性业务能力
AI 编排 仅 AI Tab 查询数据、调用子 Agent、展示候选 不从其他 Tab 自动带上下文
Feedback AI Tab、日程 Tab 记录统一执行事实 语言与表单同源
重排 AI Tab、系统被动触发、日程手动入口 生成可确认恢复方案 自动生成不自动应用
复盘 自动触发、AI 主动询问 生成和查询 ReviewReport 无独立页面入口
提醒 系统通知层 事项、报告和待确认方案触达 点击进入对应 Tab/内容，不自动执行

8. 验收标准

8.1 统一用例

统一用例：用户在 14 天内完成一份“AI 时间管理 App 产品需求报告”，同时存在 title 分别为“小组会议”和“健身”的两个普通 Schedule、普通 Todo 和临时加班；Schedule 本身均不预先分类。

说明：信息结构和用户流程由原型串联验证；GoalPlanDraft、重排、Feedback、ReviewReport 由统一用例实测验证。

统一输入：

输入项 内容
Goal 14 天内完成一份 AI 时间管理 App 产品需求报告
当前基础 已有选题和问卷，没有完整结构
显式画像 工作日 20:00 后可用；周末 3 小时；偏好 45 分钟任务；保留缓冲
Schedule 1 周三 10:00–11:00 小组会议
Schedule 2 周四 19:00–20:00 健身
Todo 周五 18:00 前提交课程材料
打断 周二临时加班，导致一个 Task 未完成
AI 输入 文字创建、语音 Feedback、主动上传图片 OCR
验证目标 三 Tab、母/子 Agent、Goal/Task、自动排期、统一 Feedback、重排、两类复盘、提醒、画像

现状（不用本产品）

  • Goal、会议和 Todo 分散在不同工具。
  • Goal 计划只停留在阶段描述，没有具体 Task 时间。
  • 临时加班后需要逐条手动移动。
  • 执行结果没有统一事实，复盘只能凭印象。

提议后形态（逐条可判过/不过）

验收项 通过标准 说明
全流程 ≥4/8 用户无需讲解完成“Goal 输入→计划确认→执行→Feedback→重排→复盘” 主链可运行
三 Tab ≥6/8 能正确找到日程、AI、目标能力 信息结构可理解
AI 单入口 其他 Tab 不出现独立会话，AI Tab 支持多轮和历史 统一交互
GoalPlanDraft 生成不少于 5 个有完整时间且属于 Goal 的 Task 计划可执行
自动排期 Task 与现有 Schedule 不产生未确认冲突；如 AI 根据 title 提出移动 Schedule，动作必须明确展示 调度有效
手动兜底 页面可完成 Schedule/Todo/Goal/Task CRUD 和表单 Feedback AI 非单点
统一 Feedback 三类对象语言/表单均可提交，状态和 Feedback 原子一致 事实稳定
被动重排 加班/冲突后自动生成方案并通知，未确认原计划不变 控制权
部分选择 用户可取消或修改动作；应用后无半成品 可控且一致
周期复盘 自动周复盘落库、通知、可在 AI 查询 整体节奏
目标复盘 Goal 到期/完成后自动生成，历史版本可查 目标归因
画像 P0 显式画像生效；P1 不自动写入候选 个性化边界
提醒 五类对象/事件按设置触达，失败不回滚业务 触达可靠边界
数据权限 子 Agent 不直接读写数据；母 Agent 确认后调用业务能力 架构边界

边界与非法情况

场景 系统必须如何处理
Task 没有完整时间 不允许创建正式 Task
AI 提出用户不接受的 Schedule 移动 用户删除该动作或要求重新生成；未确认前 Schedule 不变
待办调整导致截止被改 必须单独确认截止变化，不能静默修改
计划草稿未确认 不生成正式 Task
重排方案未确认 不修改正式安排
Feedback 对象不唯一 要求选择，不落库
Review 数据不足 不输出强归因
AI 服务不可用 手动 CRUD 和表单 Feedback 可继续
本期不验收 Subtask、团队协作、第三方日历、自由图片理解、应用控制、复杂数据大屏

8.2 分模块验收标准

模块 验收标准 详细设计
AI Tab/母 Agent 单一对话、三种输入、多轮与历史；母 Agent 统一读写，子 Agent 不读写数据 #19
日程 Tab 年/月/日展示三类对象，未排期 Todo 有独立区域 #46、#18
Goal/Task Goal → Task，无 Subtask；Task 必须有时间 #14
Goal 拆分 读取画像和空闲时间，生成可确认 GoalPlanDraft #14
Feedback 三类对象统一，语言/表单同源，状态与反馈原子写入 #23
重排 四类被动触发，自动生成不自动应用，部分选择后原子提交 #17
复盘 PERIOD/GOAL，自动/主动生成，版本化落库，只在 AI 查看 #13、#15
显式用户画像 P0 用户主动维护，AI 修改仍需确认 #55
历史执行校准 P1 从 Feedback/Task/重排历史生成候选，确认后加入画像 #33（NoPlan）
消息提醒 Schedule/Todo/Task/ReviewReport/ReschedulePlan 本地通知 #47

8.3 用户理解验收

用户需要能回答的问题 通过标准
TimeFlow 和普通日历/待办有什么区别？ ≥4/8 能说出 Goal 自动排期、Feedback、重排或复盘
三个 Tab 分别做什么？ ≥6/8 能正确区分日程、AI、目标
Goal、Task、Todo、Schedule 有什么区别？ ≥6/8 能说明 Task 属于 Goal，Todo 不属于 Goal，Schedule 是时间安排
为什么没有 Subtask？ ≥4/8 能理解 Task 已是 Goal 唯一执行层
为什么 Task 必须有时间？ ≥6/8 能理解 Goal 拆分要直接落到可执行安排
被动重排会不会自动改计划？ 8/8 明确知道只自动生成，确认后才应用
复盘在哪里查看？ ≥6/8 知道只能在 AI 中询问，不存在复盘 Tab
AI 为什么不能直接写事实？ ≥6/8 理解候选确认用于避免误操作
P0 是否自动学习历史画像？ ≥6/8 知道 P0 只用显式信息，P1 候选也需确认

8.4 数据指标验收

指标用于不少于 30 名真实试用用户；5–8 人原型测试只报告人数、失败位置和定性原因。

指标 目标值 说明
AI 输入到候选完成率 ≥60% 从开始输入到出现有效候选
AI 操作任务成功率 ≥80% 导航外的查询/CRUD/Feedback/计划标准任务
三 Tab 功能找到率 ≥85% 用户能找到指定核心功能
Goal 创建完成率 ≥60% 从输入 Goal 到生成可确认计划
GoalPlanDraft 应用率 ≥60% 直接或小幅修改后确认
Task 时间完整率 100% 正式 Task 均有开始/结束日期时间
自动排期无未确认冲突率 ≥95% 不与未纳入确认动作的既有 Schedule 重叠；所有 Schedule 移动都在方案中明确展示
容量不足透明率 100% 无法排期时展示原因和调整方案
Feedback 提交率 ≥50% 已处理三类对象中提交反馈比例
Feedback 原子一致率 100% 状态与反馈不出现单边成功
被动重排触发准确率 ≥90% 标准冲突/延期/容量场景正确生成
未确认重排误应用率 0 未确认不得改变安排
重排后无新冲突率 ≥90% 应用后不产生新硬冲突
周期复盘生成成功率 ≥95% 到点后完整报告落库
ReviewReport 事实一致率 100% 报告数字与底层统计一致
周期复盘查看率 ≥50% 用户收到通知后在 AI 查看
目标复盘查看率 ≥50% 用户在 Goal 完成/到期后查看
提醒更新一致率 ≥95% 修改/重排/取消后旧通知正确失效
高风险误执行率 0 删除、批量创建、重排等未确认不执行
用户价值识别率 ≥60% 用户能说出产品差异和适用场景

8.5 不通过时的收缩路径

失败信号 可能原因 收缩方案
用户不使用 AI Tab 响应慢、候选不准、确认过重 先聚焦查询、创建、Feedback、Goal 拆分四类高频意图
三 Tab 仍难理解 日程/目标内容混杂 日程只突出时间，目标只突出 Goal/Task，减少次要信息
GoalPlanDraft 应用率低 Task 过多、时间不合理 限制输出规模，使用少数 Goal 模板，强化容量校验
空闲不足频繁发生 显式画像或约束不完整 生成前快速确认可用时间和计划强度
Feedback 提交率低 问题太多、价值不明显 默认只问状态和耗时，原因按条件追问
Schedule 调整判断不可靠 AI 仅凭 title 提出的移动不符合用户预期 不建立分类字段；收缩为默认不移动 Schedule，或只展示少量可删除的移动动作
被动重排没人应用 方案改动过大或不可信 收缩为少量候选移动卡片，增加原因说明
自动复盘没人看 通知无价值、报告过长 改为“一个问题+一个原因+一个建议”的短报告
历史查询不准确 查询范围过宽 先要求时间/Goal/关键词，再检索
用户觉得系统接管感强 自动生成太频繁或确认不清 降低被动触发频率，强化“未应用”状态和取消入口
P1 画像候选信任低 证据不足或表述像推断 保持 P1/NoPlan，只使用手动显式画像

Clone this wiki locally