1 功能描述
用户即使看到深度复盘证明"分心确实存在",也未必能靠自己改变行为——知道了但下次还是忍不住点开。专注锁在任务执行时段内,把用户选定分类的 App 直接锁住:打开会看到拦截提示和剩余时段倒计时,而不是靠意志力硬扛。深度复盘证明分心存在,专注锁负责真正减少分心行为——两者是数据到干预的递进关系,这也是本模块必须建立在 5.10 已经跑通之上的原因。
核心规则:本期不做;暂定归属复盘,理由是白板原始 5 分法里只有复盘负责"监控",本模块是"监控"的自然延伸(干预动作,不是新的数据类别),且强依赖已确认归属深度复盘的 5.10 先落地——这是有依据的默认结论,供推进使用,不能当成已经拍板的既定事实。
2 用户
目标用户
深度复盘用户里的进一步转化子集:数据已经证明分心真实存在,但"知道了下次还是忍不住点开"、需要外部约束的人。
用户故事
| 场景小故事 |
对应能力 |
价值 |
| 复盘证明算法题时段我平均刷 40 分钟短视频,光知道没用,我下次还是会点开。 |
任务执行时段内按分类锁定 App |
从"看到问题"到"真的少分心" |
| 我不要一刀切的全天锁机,只想在做那类容易逃避的任务时锁一下。 |
专注锁绑定具体任务时段 |
干预精准,不影响正常使用 |
| 真有急事时我要能解锁,但别让我一秒冲动就放弃专注。 |
10 秒倒计时确认解除 |
留出口但有停顿,不是形同虚设 |
3 现有做法以及不足
| 现有做法 |
可以解决 |
仍然存在的问题 |
| Freedom、Forest、One Sec、Opal、ScreenZen等专注类工具 |
已做通用的App锁定/屏蔽能力 |
锁定和具体任务无关,不知道用户当下在执行哪个任务 |
| 用户仅凭意志力自我克制 |
零成本 |
调研 Q4"自动过滤/屏蔽干扰信息"需求占28.81%,说明单靠自觉对相当一部分用户不够用 |
核心问题:通用锁定类工具已是成熟赛道,本模块如果要做,差异化必须落在"锁定绑定具体任务"这一点上。
4 产品范围
本期范围(若确认排期)
- 用户可为某个任务的执行时段开启专注锁,选择要限制的 App 分类(复用 5.10 分类体系:短视频类、社交/即时通讯类、游戏类、其他)
- 专注锁生效期间,被限制分类的 App 打开时展示拦截提示
- 用户可提前结束专注锁,但需经过 10 秒倒计时确认流程,不能一键立即解除
- 与 5.10 共用同一套监控授权状态
明确不做
- 跨设备统一控制(同 5.10 边界)
- 除倒计时确认外的其他解除摩擦形式
5关键决策
| 类型 |
方案 |
结论 |
理由 |
| 解除方式·A |
一键立即解除 |
不选 |
起不到"专注锁"该有的约束力,功能形同虚设 |
| 解除方式·B |
点击"提前结束"后弹出确认对话框,需等待 10 秒倒计时结束才能点击"确认解除",倒计时期间展示"还有 10 秒,再坚持一下"一类提示文案 |
采纳 |
摩擦形式选倒计时等待而非多步操作或验证码,足够简单不引发额外挫败感,同时确实制造了一次"要不要放弃"的停顿;文案遵循第4节已确认的"如实但不苛责"语气原则 |
| 授权体系·A |
单独设计一套授权流程 |
不选 |
和5.10本质是同一类隐私敏感权限,分开设计增加理解成本 |
| 授权体系·B |
与5.10共用同一套授权状态 |
采纳 |
"先监控后控制"是自然的能力递进 |
6边界规则与异常处理
边界规则
- 未开启深度复盘授权的用户看不到"开启专注锁"入口
- 解除专注锁必须经过10秒倒计时确认,不能一键解除
异常场景与处理方式
|场景|触发条件|系统行为|依据/原则|
|-|-|-|-|
|用户未开启深度复盘授权|尝试寻找专注锁入口|入口不展示|复用5.10授权前置条件|
|用户提前结束专注锁|点击"提前结束"|弹出10秒倒计时确认对话框,倒计时结束前"确认解除"按钮保持禁用|呼应"解除方式"决策|
7 基本概念与信息结构
| 概念 |
含义 |
| 专注锁 |
关联到具体任务执行、限制的 App 分类集合(复用5.10分类体系)、开始时间、计划结束时间、实际结束时间(可能早于计划,主动解除时记录)、解除时使用的摩擦方式(10秒倒计时确认,倒计时未结束时"确认解除"按钮保持禁用) |
信息结构
| 一级结构 |
承载内容(二级/三级) |
信息组织的底层逻辑 |
| 任务执行页·专注锁入口 |
开启专注锁按钮、App分类选择 |
挂在具体任务的执行界面,不是独立Tab |
| 专注锁生效态 |
拦截提示、剩余时段倒计时、提前结束入口 |
以"还剩多久"为核心信息,弱化其他操作入口 |
对外输出:专注锁的实际结束时间可用于统计"用户平均能坚持完成计划专注时长的百分比",供后续复盘参考。
8 验收标准
| 用例 |
操作 |
通过标准 |
| 开启专注锁 |
已开启5.10授权的用户为某任务执行时段开启专注锁 |
可以选择要限制的App分类(依赖权限方案) |
| 拦截提示 |
专注锁生效期间打开被限制分类的App |
展示拦截提示,而非无响应或崩溃(依赖权限方案) |
| 摩擦解除 |
点击"提前结束" |
弹出倒计时确认对话框;倒计时未满10秒时"确认解除"按钮保持禁用;倒计时结束后按钮可点击并真正解除专注锁 |
| 实际结束时间记录 |
用户实际解除专注锁 |
记录的实际结束时间与操作时间一致 |
| 未授权无入口 |
未开启5.10授权的用户 |
看不到"开启专注锁"入口 |
1 功能描述
用户即使看到深度复盘证明"分心确实存在",也未必能靠自己改变行为——知道了但下次还是忍不住点开。专注锁在任务执行时段内,把用户选定分类的 App 直接锁住:打开会看到拦截提示和剩余时段倒计时,而不是靠意志力硬扛。深度复盘证明分心存在,专注锁负责真正减少分心行为——两者是数据到干预的递进关系,这也是本模块必须建立在 5.10 已经跑通之上的原因。
核心规则:本期不做;暂定归属复盘,理由是白板原始 5 分法里只有复盘负责"监控",本模块是"监控"的自然延伸(干预动作,不是新的数据类别),且强依赖已确认归属深度复盘的 5.10 先落地——这是有依据的默认结论,供推进使用,不能当成已经拍板的既定事实。
2 用户
目标用户
深度复盘用户里的进一步转化子集:数据已经证明分心真实存在,但"知道了下次还是忍不住点开"、需要外部约束的人。
用户故事
3 现有做法以及不足
核心问题:通用锁定类工具已是成熟赛道,本模块如果要做,差异化必须落在"锁定绑定具体任务"这一点上。
4 产品范围
本期范围(若确认排期)
明确不做
5关键决策
6边界规则与异常处理
边界规则
异常场景与处理方式
|场景|触发条件|系统行为|依据/原则|
|-|-|-|-|
|用户未开启深度复盘授权|尝试寻找专注锁入口|入口不展示|复用5.10授权前置条件|
|用户提前结束专注锁|点击"提前结束"|弹出10秒倒计时确认对话框,倒计时结束前"确认解除"按钮保持禁用|呼应"解除方式"决策|
7 基本概念与信息结构
信息结构
对外输出:专注锁的实际结束时间可用于统计"用户平均能坚持完成计划专注时长的百分比",供后续复盘参考。
8 验收标准