Proposal：深度复盘

[LUPENGHAN]

1 功能描述

目标复盘已经能把执行反馈里的"未完成原因"汇总成分布和总结，但这个分布的颗粒度有天花板——比如多条反馈都勾选了"被娱乐App干扰"，只能告诉用户"这是常见原因"，回答不了具体被什么App干扰、干扰多久、是不是集中在某类任务上。深度复盘用设备使用数据回答这些问题：用户授权后，系统记录拆解任务执行期间各App使用时长，把"我是不是总被手机分心"变成可验证的客观数据，而不是停留在自我报告层面。
核心规则：深度复盘是基础复盘用户里的一个转化子集功能，不是全体用户默认可见；本期只做"呈现"，不做"根据这些数据自动修改任务安排"。

2 用户

目标用户
基础复盘用户里的转化子集：怀疑"任务超时是被手机分走了"、愿意授权设备数据来验证这个怀疑的人。

用户故事

场景小故事	对应能力	价值
我总在反馈里勾"被短视频干扰"，但不确定这是真实原因还是给自己找的借口。	主客观交叉验证	归因从自我报告升级为可验证
我想知道具体是哪类任务最容易让我逃到手机里。	干扰-任务类型关联	知道对什么任务警惕，不是笼统"少玩手机"
有次任务没做完我没觉得被干扰，但其实刷了半个多小时没意识到。	设备记录 vs 勾选对照（没勾但数据多的情形）	发现自我认知盲区

3 现有做法以及不足

现有做法	可以解决	仍然存在的问题
用户在执行反馈里手动勾选"被娱乐App干扰"	至少有主观记录	没有客观数据佐证，容易被自己低估或选择性遗忘
Forest、One Sec、Freedom等专注类工具	能监控和限制App使用	和"任务执行"完全脱节，不知道这个时段对应哪个拆解任务
RescueTime一类自动时间追踪工具	能记录全天设备使用情况	不区分"这段时间本该在执行什么"，是设备侧记录不是任务侧复盘
苹果屏幕使用时间、Android数字健康	用户自己能看总量	未对第三方App开放同等精度的数据接口，权限方案存在不确定性

核心问题：深度复盘的差异化点不在监控技术本身，而在"监控数据能不能和具体任务执行状态绑定"，所以应该建立在5.8已经跑通之上，不是并行独立开发。

4 产品范围

本期范围（真正排期实现时）

• 使用时间监控：用户授权后，记录拆解任务执行期间各App使用时长
• 深度复盘展示：5.8/5.9报告追加"设备使用情况"版块，可下钻到具体任务，复用5.8已预留的扩展位
• 用户可随时关闭授权，历史数据默认保留、可选删除

• 展示的具体案例信息

版块	图表	图上展示什么	文字展示什么	示例
整体完成概览	双指标卡	轻事项、目标任务两组数字分开展示，不混算	一句对比	日程 8/9 · 待办 12/15 · 目标任务 7/11；"轻事项很稳，目标任务是短板"
周期内分布	按天柱状图	该周期内每天的完成数（单期内部，不做跨周期对比）	点出峰谷并关联原因	"周三、周四最低，正好是有临时会议的两天"
活跃目标进展	每目标一行（进度条）	目标名 + 本期完成数/本期计划数 + 总进度变化	一句概括	"Java 面试准备：本周 5/7，总进度 40%→65%"
未完成原因分布	条形图	各原因按次数降序（仅目标任务有原因数据）	格式"原因·次数·占比"，遵循引用阈值	"突发任务插入 · 3 · 60%"
重排使用情况	指标卡	本期触发/采纳次数	一句概括价值	"触发 2 次 · 采纳 2 次——挽回了周三被会议挤掉的 3 个任务"
分类时长分布	环形图	任务执行时段内短视频类/社交即时通讯类/游戏类各自用时占比（"其他"不计入干扰、不上图）	一句概括	短视频 3.2h · 社交 1.5h · 游戏 0.5h
任务下钻明细	列表（无图）	每行 = 任务名 + 执行时段 + 期间各分类使用时长	—	"复习 Redis · 周二 20:00–21:00 · 短视频 26 分钟"
干扰-任务类型关联	分组条形图	按任务类别分组，每组显示平均干扰时长	点出干扰重灾区	"算法类任务执行期间的干扰时长是背诵类的 2.8 倍"
主客观交叉验证	对照表	左列=用户勾选的干扰来源，右列=设备实际记录	三种情况分别措辞，如实不苛责	一致→"感受和数据一致，这个归因可靠"；勾了但数据少→"这 2 次 App 使用不到 5 分钟，卡住的原因可能在任务本身"；没勾但数据多→"周四没标记干扰，但短视频用了 38 分钟——可能刷的时候没意识到"
AI 总结	无图	—	可引用客观数据交叉验证；环比升→体现进步，降/平→聚焦任务不评判人	"完成率比上周提高 12%；你勾选的短视频干扰和设备记录一致，算法类任务是干扰重灾区"
下期建议	无图	—	具体可执行，可细化到任务类型	"周三下午例会前后各留 30 分钟缓冲；对算法类任务考虑开启专注锁"
专注锁效果对比（仅应用使用控制确认排期后加入）	双柱对比图	开锁 vs 未开锁时段的完成率、干扰时长各一组	一句结论	"开锁的 4 次任务完成率 100%、干扰 0 分钟；未开锁同类任务完成率 60%——专注锁对你确实有效"

明确不做

• App分类与控制模块，归属5.11，权限和技术复杂度更高
• 跨设备统一监控，本期只做当前设备
• 监控数据反向驱动AI自动调整计划，本期只做呈现
  后续可拓展
• App分类与控制（5.11）、跨设备监控、监控数据驱动的自动调整

5 关键决策

类型	方案	结论	理由
开发顺序·A	深度复盘和基本复盘并行独立开发	不选	深度复盘依赖执行反馈和拆解任务这套数据模型作为前提，并行会造成数据模型不一致
开发顺序·B	深度复盘作为5.8的增强层后置	采纳	得先有基本复盘的使用数据，才谈得上深度复盘值不值得做
数据呈现范围·A	展示全局总量	不选	不区分"这段时间本该在执行什么"，无法回答具体是哪次任务被干扰
数据呈现范围·B	数据必须能下钻到具体任务/时段	采纳	这是深度复盘区别于Forest/RescueTime一类工具的关键差异点
数据用途·A	监控数据反向驱动AI自动调整任务安排	不选	本期只验证"呈现"是否有价值，自动化决策超出验证范围
数据用途·B	本期只做呈现，不做自动修改	采纳	先验证核心假设，再考虑更深的自动化

6 边界规则与异常处理

边界规则

• 深度复盘版块仅在用户已开启授权时代替基础复盘来展示，未开启则完全不出现
• 用户关闭授权后不再产生新记录，历史记录仍可查看，除非额外选择删除
• 与5.11共用同一套授权状态，不为5.11单独设一套授权流程
• 权限技术方案（iOS DeviceActivity 与 Android UsageStatsManager 的能力差异）属于架构选型问题，不在本 Proposal 决策范围内；产品层面只需保证"用户能看到按分类下钻到任务的使用数据"这个结果，具体用哪套系统API实现留给架构设计
  异常场景与处理方式
  |场景|触发条件|系统行为|依据/原则|
  |-|-|-|-|
  |用户未开启授权|查看5.8/5.9复盘报告|深度复盘版块不出现或保持禁用|避免功能预期落空|
  |权限方案技术选型未定|相关验收项标注"依赖权限方案"|需技术选型确定后才能真正验证，本期先定好产品语义|权限技术方案是架构层决策|
  |用户中途关闭授权|已产生部分历史数据后关闭|不再产生新记录，历史数据默认保留，可选删除|隐私可控，用户主导|

7 基本概念与信息结构

概念	含义
App使用记录	关联到具体是哪次任务执行期间产生的、App名称/分类（分类体系待定）、使用时长、记录时间
设备监控设置	用户是否开启监控、开启时间、历史数据保留策略
复盘报告扩展位	复用5.8预留字段，填充为该目标或该周期下所有关联App使用记录按分类汇总后的时长分布，同时保留可下钻到具体任务的明细

信息结构

一级结构	承载内容（二级/三级）	信息组织的底层逻辑
授权开启引导	说明文案、开启入口	只在用户主动进入相关设置时出现
复盘报告·设备使用情况版块	按分类汇总的时长分布、可下钻的任务明细	挂在5.8/5.9报告页内，不单独开页面

对外输出：为5.8/5.9的扩展位提供数据；为5.11提供授权状态共享基础。本模块不负责App使用的限制或拦截。

8 验收标准

用例	操作	通过标准
数据关联	用户开启授权后执行任务	使用数据能正确关联到对应任务（依赖权限方案）
下钻展示	查看深度复盘版块	必须能下钻到具体任务/时段，不能只展示全局总量
关闭授权后行为	用户关闭授权	不再产生新记录；历史记录仍可查看，除非额外选择删除
未授权时隐藏	用户未开启授权查看复盘报告	深度复盘版块完全不出现
分类准确性	用构造好的测试数据验证	App使用时长分类展示与实际记录一致
核心假设验证	统计5.8/5.9活跃用户中选择开启深度复盘授权的比例	该转化率作为"用户是否愿意用设备数据换取更准确归因"这个核心假设的验证指标