企业官网建设流程全解析

使用“突发-延迟”策略，重新设计手机干预弹窗

iOS 的“屏幕使用时间”、Android 的“数字健康”以及各类专注 App，本质上都在解决同一个问题：手机如何夺回了我们的注意力。但多数工具只做了“统计”和“限制”两层工作——告诉用户今天解锁了多少次，到了设定时间就锁住应用。真正困难的部分在于，用户在被拦截的那一刻往往处于无意识滑手机的状态，冷冰冰的锁屏和剩余时间倒计时很难触发反思，反而容易养成“点掉弹窗继续刷”的肌肉记忆。

Haserupt 这个项目提出的思路很有意思。它没有把“减少手机使用”当作一个简单的计时器问题，而是把每次解锁、打开社交应用的过程，设计成一次有叙事节奏的打断体验。用户不是面对“今日已使用 3 小时”的统计数字，而是会先看到一段突发提示，经历一段延迟等待，再在情绪和注意力都被拉回现实之后，自行选择是否继续进入应用。这篇文章会围绕这种“突发-延迟”的干预模式，拆解它背后的产品逻辑、状态流转、配置体系和技术实现思路，并给出一个可以本地跑通的最小示例。

国内做防沉迷和数字健康产品时，通常会遇到几个实际问题：系统级限制权限难以获取、不同手机厂商对后台弹窗的管理策略差异很大、用户绕过限制的成本太低。Haserupt 这类方案最大的参考价值在于，它没有试图从系统层“锁死”应用，而是通过更聪明的交互设计，在用户和应用之间插入一个反思窗口。只要用户愿意停留在这个窗口里，产品目标就已经完成一半。

1. 先理解 Haserupt 解决的问题：注意力干预不是靠权限，而是靠交互节奏

1.1 为什么传统的“限制时长”方案很容易失效

先看一个非常常见的场景。用户给抖音设置了 30 分钟限额，时间到后系统弹出提示“已到达使用限额”。很多人的第一反应不是关掉手机，而是点击“忽略限额”继续使用。即便系统提供了“再多用 15 分钟”的选项，这个过程也几乎没有带来任何认知负担。

问题出在哪里？问题在于传统限制方案的“干预点”放在了错误的位置。它在用户已经沉浸大量时间之后才出现，此时用户处于多巴胺驱动的连续浏览状态，突然冒出的系统提示只是一个需要被关闭的弹窗。关闭弹窗的成本极低，而继续刷内容带来的即时满足却非常强，人的本能会倾向选择后者。

更关键的是，“剩余时间倒计时”这类统计信息需要用户具备足够的自制力才能转化为行动。但数字健康产品的核心用户，恰恰是自制力不足以自行对抗算法推荐的人。如果产品把行为的最终决定权完全交还给用户，同时又不提供任何心理缓冲，那它实际上没有完成“干预”的任务，只是在“记录”。

1.2 突发-延迟机制是如何改变用户决策路径的

Haserupt 的干预模型可以拆成三个阶段：突发提示、延迟等待、自主选择。

突发提示相当于在用户即将无意识进入应用时，先用一条有叙事感的消息打断自动化行为。它不是“你又超时了”这种指责性语言，而更像是一个意外事件，比如“你上次打开相册时，发现了一张 2019 年拍的照片。需要我帮你找回来看看吗？”这种提示的核心目的是打破动作惯性，让用户从“手指自动点开应用”切换成“意识到自己正在打开应用”。

延迟等待是在用户点击“仍然要继续”之后，再插入一段短暂的等待时间。这段时间不需要很长，几秒钟就足以让大脑从前额叶皮层从被动状态切换到主动思考状态。TikTok 类的短视频产品之所以让人停不下来，关键就是内容切换之间的间隔几乎为零，用户没有机会产生“我该停下来了”这个念头。反过来，如果一个产品刻意制造 3 到 5 秒的等待，用户就会开始评估自己“打开应用”这个行为的必要性。

最后才是自主选择。经过突发提示和延迟等待之后，用户如果再点击“进入应用”，说明他已经做出了有意识决定。此时产品不应该再拦截，而是放行，并且可以记录这一次决定供后续分析。这个设计非常关键，它把工具从“家长监控模式”转换成了“自我决策辅助模式”，用户的抵触感会明显降低。

1.3 Haserupt 的产品定位：不是锁手机，而是调节手机的使用节奏

Haserupt 的命名里带有“爆发”的含义，它强调的不是阻止，而是“在某个瞬间突然唤起注意”。这和冥想类、正念类产品的克制风格不同，它更直接、更有存在感。但从干预效果来看，这种主动打断恰恰是当前数字健康工具缺少的一环。

类比一下物理世界的“防沉迷”：超市里想控制自己买零食，最有效的不是出门前把零食锁进柜子里，而是每次伸手拿薯片时，货架旁突然弹出一张“你已经连续买了三天薯片”的提示卡，并且收银台还要多等五秒才能结算。Haserupt 做的就是这个“货架提示卡”和“收银等待”的角色。

作者在算法、交互和文案上选择了“沉浸式打断”路线。它面向的用户不是完全不刷手机的那批人，而是意识到自己用手机太多、但单靠意志力很难改变的人。对这批用户来说，一刀切的封锁并不可行，真正需要的是一个能反复打断循环、并给用户留出决策空间的中间层。

2. 核心架构：状态机、拦截点、提示生成器三块缺一不可

2.1 干预流程的完整状态流转

把 Haserupt 的“突发-延迟”流程做工程化拆解，整个交互可以建模为一个状态机。每个状态都有明确的进入条件、停留事件和退出条件，这样可以避免出现用户被连续弹出多个提示、或在某个环节死循环的情况。

状态机设计如下：

IDLE -> TRIGGERED -> PRESENTED -> WAITING -> ADMIT / DISMISS -> IDLE

• IDLE：用户当前没有需要干预的行为，系统只做后台监测。
• TRIGGERED：用户打开了目标应用或超过了设定阈值，干预条件被触发。
• PRESENTED：系统已经显示了突发提示弹窗，等待用户响应。
• WAITING：用户点击了“我仍然要继续”，进入延迟等待阶段，显示倒计时或进度动画。
• ADMIT：用户完成等待后再次确认，放行目标应用。
• DISMISS：用户在突发提示阶段或延迟等待阶段退出，回到桌面或系统界面。

实现这套状态机时，最重要的一点是把“状态”和“界面”解耦。也就是说，突发提示弹窗显示到什么进度、用户点击了哪个按钮，这些是界面层的事件；而处于哪个状态、下一步应该跳转到哪里，则是状态机层的逻辑。否则产品经理一旦调整交互文案，开发就必须跟着大规模重构。

2.2 可注册的拦截点：不是只能拦截应用启动

Haserupt 的拦截点设计应该比传统方案更细。常见的拦截时机包括：

在 Android 端，无障碍服务可以监听窗口变化，也能读取当前前台应用包名，这是实现“应用启动拦截”相对可行的路径。更细粒度的“应用内场景拦截”需要应用本身配合，比如通过深度链接进入特定页面时拦截，这对第三方应用来说受限很多。因此现实中的实现策略是：优先做系统级可到达的拦截点，再根据自身产品能力，做应用内 SDK 级别的拦截。

2.3 提示生成器：为什么不能用固定的“别玩了”文案

不少防沉迷应用只提供固定的“该休息了”“今日使用时间已达上限”文案。这种文案的问题在于，用户第一次看到还有一点触动，到第十次就完全麻木了。真正有效的突发提示需要具备两个特点：一是与用户当前行为之间有关联，二是每次出现有变化感。

Haserupt 的提示生成器在实现上应该包含模板库和变量池。模板库负责定义提示的句式和类型，变量池则从用户的使用记录中抽取信息，比如最近打开的应用、长时间未查看的照片、昨天完成的待办事项。把模板和变量组合起来，才能生成“你昨天保存了五张截图，还没有整理进相册”这类贴近个人情况的提示。

实现思路可以简化为三层：

数据采集层 -> 用户画像/行为记录 -> 提示渲染层

数据采集层负责记录行为日志；行为记录层产出提示所需的变量；提示渲染层从模板库中挑选模板，结合变量生成最终展示给用户的文案。这里要格外注意隐私边界，所有行为数据都应当只在本地处理，不上传到云端。

3. 技术选型与项目结构：从最小可用版本开始搭建

3.1 用 Android 无障碍服务作为首个载体

如果从零实现一个 Haserupt 这样理念的产品，优先选择 Android 平台会比 iOS 容易很多。iOS 的 Screen Time API 面向的是家长的“限制”场景，应用难以为自身获取足够的屏幕观测权限；而 Android 的无障碍服务在用户授权之后，可以监听窗口变化、读取当前应用，并模拟一定的交互，这给“拦截-提示-延迟-放行”的完整链路提供了实现基础。

无障碍服务本身很敏感，Play 商店和国内应用市场对用途审核都相当严格。开发者在申请该权限时，应当明确声明服务只用于数字健康场景，不读取用户输入内容，不采集密码或支付信息，并在隐私政策中清晰说明数据用途。

3.2 项目目录设计

按照模块职责拆分，一个最小可运行的项目可以这样组织：

haserupt/ ├── app/ │ ├── src/main/java/com/haserupt/app/ │ │ ├── service/ │ │ │ └── BlockerAccessibilityService.kt │ │ ├── state/ │ │ │ ├── InterventionStateMachine.kt │ │ │ └── InterveneEvent.kt │ │ ├── engine/ │ │ │ ├── RuleEngine.kt │ │ │ └── TriggerCondition.kt │ │ ├── content/ │ │ │ ├── PromptTemplate.kt │ │ │ ├── PromptGenerator.kt │ │ │ └── BehaviorStore.kt │ │ ├── ui/ │ │ │ ├── HazeDialogActivity.kt │ │ │ └── DelayFragment.kt │ │ └── config/ │ │ └── AppConfig.kt │ └── src/main/res/ │ ├── layout/ │ │ ├── dialog_haze.xml │ │ └── fragment_delay.xml │ └── values/ │ └── strings.xml └── build.gradle

service包负责系统级事件监听；state包对应前文的状态机；engine包是规则判断；content包负责提示文案的生成和本地行为存储；ui包展示突发提示和延迟等待界面。模块之间单向依赖：ui依赖state和content，state依赖engine，engine依赖content的存储结果。

3.3 依赖清单：尽量少，尽量稳定

对于最小版本，第三方依赖可以控制得非常少：

不建议在一开始就引入网络请求库和云同步 SDK。本地单机版本把核心链路跑通之后，再考虑账号体系和跨设备同步更稳妥。

4. 核心代码实现：状态机、规则引擎和提示生成器

4.1 状态机实现

用 Kotlin 实现一个安全的状态机，重点是把“非法跳转”拦截在代码层。

sealed class InterventionState { object Idle : InterventionState() object Triggered : InterventionState() object Presented : InterventionState() object Waiting : InterventionState() data class Admitted(val timestamp: Long) : InterventionState() object Dismissed : InterventionState() } sealed class InterveneEvent { object OnAppOpened : InterveneEvent() object OnPromptShown : InterveneEvent() object OnContinueClick : InterveneEvent() object OnDelayFinished : InterveneEvent() object OnExitClick : InterveneEvent() } class InterventionStateMachine { private lateinit var currentState: InterventionState fun transition(event: InterveneEvent): InterventionState { currentState = when (currentState) { InterventionState.Idle -> when (event) { InterveneEvent.OnAppOpened -> InterventionState.Triggered else -> currentState } InterventionState.Triggered -> when (event) { InterveneEvent.OnPromptShown -> InterventionState.Presented else -> currentState } InterventionState.Presented -> when (event) { InterveneEvent.OnContinueClick -> InterventionState.Waiting InterveneEvent.OnExitClick -> InterventionState.Dismissed else -> currentState } InterventionState.Waiting -> when (event) { InterveneEvent.OnDelayFinished -> InterventionState.Admitted(System.currentTimeMillis()) InterveneEvent.OnExitClick -> InterventionState.Dismissed else -> currentState } else -> currentState } return currentState } fun isIdle() = currentState is InterventionState.Idle }

这里的状态机没有实现“自动恢复到 Idle”的逻辑。实际使用时，需要在用户回到桌面或经过一定冷却时间后，主动把状态重置为 Idle，否则会出现“拦截一次之后，后续所有打开操作都不再触发”的问题。

4.2 规则引擎：判断是否触发干预

规则引擎不负责弹窗，它只回答一个问题：当前场景需要干预吗？把规则和界面分离，后续调整算法时就不会动到 UI 代码。

data class UserContext( val currentPackageName: String, val todayUsageMinutes: Long, val lastTriggerTimestamp: Long, val currentStreakCount: Int ) class RuleEngine( private val targetPackages: Set<String>, private val dailyThresholdMinutes: Long = 60L ) { fun shouldIntervene(context: UserContext): Boolean { val isTargetApp = context.currentPackageName in targetPackages val isOverDailyLimit = context.todayUsageMinutes >= dailyThresholdMinutes val isCooldownFinished = System.currentTimeMillis() - context.lastTriggerTimestamp > 10 * 60 * 1000 return isTargetApp && (isOverDailyLimit || isCooldownFinished) } }

这段代码展示的是两个判断维度：命中目标应用且超过日限额，或命中目标应用且冷却期已结束。实际产品中，规则配置可以从本地文件或 DataStore 中读取，让用户能自定义哪些应用需要干预、每日限额多少、冷却时间多长。

4.3 提示生成器：从行为记录生成突发文案

提示生成器需要聚合行为数据并渲染文案。下面是一个简化实现：

data class BehaviorSnapshot( val unorganizedScreenshotCount: Int, val unreadMessageCount: Int, val lastSavingTime: String, val lastPhotoYear: Int? ) class PromptGenerator(private val behaviorStore: BehaviorStore) { private val templates = listOf( "你还有 {screenshotCount} 张截图没有整理，确定现在要继续下滑吗？", "上次打开这个应用前，你正在处理 {lastSavingTime} 保存的文档。", "相册里有一张 {year} 年的照片，要先去回忆一下吗？" ) fun generate(): String { val snapshot = behaviorStore.getSnapshot() val template = templates.random() return template .replace("{screenshotCount}", snapshot.unorganizedScreenshotCount.toString()) .replace("{lastSavingTime}", snapshot.lastSavingTime) .replace("{year}", snapshot.lastPhotoYear?.toString() ?: "久远") } }

实际项目里模板和变量要做好比例控制，不能每次都随机选择导致用户产生“提示内容与我无关”的感受。更好的做法是依据用户当前的时间、最近行为、上次干预结果来打分，选择得分最高的模板。

4.4 延迟等待界面

延迟等待界面是整个交互中技术含量最低、但体验影响最大的部分。它不需要复杂动画，核心是让用户清晰感知到“我在等待”，并且给用户一个随时可以退出的出口。

一个简单的 Compose 实现如下：

@Composable fun DelayScreen( totalMillis: Long = 5000L, onDelayFinished: () -> Unit, onExitClick: () -> Unit ) { var remain by remember { mutableStateOf(totalMillis) } val animation = remember { Animatable(0f) } LaunchedEffect(Unit) { while (remain > 0) { delay(100) remain -= 100 } onDelayFinished() } Column( modifier = Modifier.fillMaxSize(), horizontalAlignment = Alignment.CenterHorizontally, verticalArrangement = Arrangement.Center ) { Text(text = "稍等一下", style = MaterialTheme.typography.headlineSmall) Spacer(modifier = Modifier.height(24.dp)) LinearProgressIndicator( progress = { 1f - remain / totalMillis.toFloat() } ) Spacer(modifier = Modifier.height(24.dp)) TextButton(onClick = onExitClick) { Text(text = "回桌面") } } }

4.5 无障碍服务中的拦截逻辑

无障碍服务负责监听窗口变化，并调用状态机和规则引擎。

class BlockerAccessibilityService : AccessibilityService() { private val stateMachine = InterventionStateMachine() private val ruleEngine = RuleEngine(targetPackages = setOf("com.ss.android.ugc.aweme")) private val promptGenerator = PromptGenerator(BehaviorStore(context = this)) override fun onAccessibilityEvent(event: AccessibilityEvent?) { if (event == null) return val packageName = event.packageName?.toString() ?: return if (event.eventType == AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED) { val context = buildUserContext(packageName) if (ruleEngine.shouldIntervene(context)) { showHazeDialog(packageName) } } } private fun showHazeDialog(packageName: String) { val prompt = promptGenerator.generate() val intent = HazeDialogActivity.createIntent(context = this, prompt = prompt) intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) startActivity(intent) } override fun onInterrupt() { // 服务被系统中断时的兜底 } }

需要注意，Android 12 及之后对无障碍服务启动 Activity 的限制更严格，背景启动 Activity 会被系统阻止。实际开发中要考虑使用系统窗口（Toast 型全屏弹窗）或使用SYSTEM_ALERT_WINDOW权限来展示干预层。

5. 关键参数配置与推荐值

5.1 突发提示、延迟时长、释放条件的参数关系

Haserupt 的体验极大程度依赖三组参数：突发内容强度、延迟等待时长、释放条件。三者的关系不是孤立的，提示越强，延迟就可以适当越短；提示太弱，延迟就应拉长，给用户更多反思时间。

5.2 不同场景的差异化配置

同一个用户，在不同时间段、不同应用上的干预策略也应当不同。白天通勤时刷短视频可以允许更快的释放，睡前刷社交软件时延迟时间则应该加长。

这些参数在生产环境中应该支持 A/B 测试，而不是拍脑袋定死。无代码策略配置平台或者远程配置中心可以解决“不同版本用户看到不同参数”的问题。

5.3 配置化：不把参数写死在代码里

把参数集中定义在一个配置类或配置文件中，避免散落到各个 Fragment 和 Activity。

{ "global": { "cooldownMinutes": 10, "dailyLimitMinutes": 60 }, "apps": { "com.ss.android.ugc.aweme": { "enabled": true, "delaySeconds": 5, "promptStyle": "SCREENSHOT_REMIND" }, "com.tencent.mm": { "enabled": false, "delaySeconds": 3, "promptStyle": "WORK_REMIND" } } }

上文 JSON 采用本地配置文件是理解逻辑用的，生产环境建议使用远程配置中心下发，并保留本地缓存兜底。这样产品经理调整参数时不依赖发版。

6. 运行验证：从单元测试到用户调研

6.1 单元测试：至少覆盖状态流和规则引擎

状态机是整个项目最容易出 bug 的地方。用单元测试把所有合法跳转和非法跳转都覆盖到，比手动点击验证快得多。

class InterventionStateMachineTest { @Test fun `idle to presented when app opened and prompt shown`() { val machine = InterventionStateMachine() val afterTrigger = machine.transition(InterveneEvent.OnAppOpened) val afterPresent = machine.transition(InterveneEvent.OnPromptShown) assertEquals(afterPresent, InterventionState.Presented) } @Test fun `continue click moves to waiting`() { val machine = InterventionStateMachine() machine.transition(InterveneEvent.OnAppOpened) machine.transition(InterveneEvent.OnPromptShown) val afterWait = machine.transition(InterveneEvent.OnContinueClick) assertEquals(afterWait, InterventionState.Waiting) } }

6.2 真机验证清单

单元测试通过之后，需要准备一份真机验收清单：

• 目标应用首次启动时，是否弹出突发提示。
• 点击“继续”后，延迟等待界面是否稳定显示，进度条是否平滑。
• 延迟结束后，目标应用是否被正常放行。
• 点击“回桌面”后，是否回到桌面且不会再次触发弹窗。
• 冷却时间内再次打开目标应用，是否不再触发。
• 无障碍服务在系统重启后是否能自动重连。

每个检查点都要有一个预期结果。拿“冷却时间内不再触发”来说，预期是打开应用后直接进入，没有任何弹窗或延迟。

6.3 小范围用户调研：关注拒绝率和撤销率

产品上线后的核心指标不是“每日干预次数”，而是“干预后继续进入应用的比例”和“用户主动卸载无障碍服务的比例”。前者说明打断是否带来了反思，后者说明产品是否过于烦人。两个指标需要放在一起看：如果干预次数很高，但用户第二天就卸载，那说明提示或延迟策略强度过强，需要回调参数。

在产品早期，建议招募 10 到 20 名目标用户做短周期测试，收集内容除了问卷，还应有主动退出拦截后的访谈。用户“为什么在延迟等待 2 秒时放弃”比“你觉得这个功能好用吗”更能指导迭代。

7. 落地过程中的常见问题与排查路径

7.1 无障碍服务被系统回收

现象：刚开启时功能正常，使用一两天后，打开目标应用不再出现任何提示。

可能原因：国产 ROM 对无障碍服务的后台行为有严格限制，或服务内部抛出了未捕获异常导致服务被系统关闭。

排查方式：

• 在系统设置里查看“无障碍-已下载的服务”状态。
• 查看adb logcat --pid=$(pidof com.haserupt.app)日志，确认服务是否仍存活。
• 检查服务是否实现了onInterrupt()，这是服务异常终止的入口。

解决方式：在onInterrupt()中增加日志和状态重置逻辑；引导用户将应用加入电池优化白名单；对华为、小米、Oppo 等主流机型分别测试。

7.2 弹窗频繁触发或完全不触发

现象：用户在五分钟内连续被拦截三次，或者设置了阈值后一次都不触发。

可能原因：规则引擎中的“冷却时间”计算逻辑使用了错误的系统时间来源，或包名白名单没有匹配到前台应用。

排查方式：先开启日志，打印每次事件的currentPackageName，确认无障碍服务是否真的识别到了目标应用。再打印规则引擎的判定结果和时间戳。

解决方式：时间比较统一使用System.currentTimeMillis()，不要混用elapsedRealtime。包名比较时注意去掉进程号后缀，只比较纯包名。

提示：真机上弹出的应用包名可能带有冒号后缀，比如com.ss.android.ugc.aweme:push，直接用event.packageName.toString()做精确匹配会漏判。建议总是取冒号前的部分再比对。

7.3 延迟等待界面状态错乱

现象：用户点击“回桌面”后仍会再次弹出等待框，或者延迟结束后没有跳转到目标应用。

可能原因：状态机没有在正确时机重置；Activity 的启动模式设置错误，导致多个弹窗实例叠加。

排查方式：查看onNewIntent和onDestroy的调用顺序，确认用户在退出后是否触发了多余的生命周期回调。

解决方式：为 HazeDialogActivity 配置android:launchMode="singleInstance"，并把状态机重置动作放在目标应用恢复前台或用户回到桌面的事件里，而不是放在弹窗界面的onDestroy中。

8. 最佳实践与扩展方向

8.1 可复用的发布前检查清单

在把这类数字健康产品推向更大规模前，应该逐项确认以下内容：

• 无障碍服务的用途说明是否清晰，隐私政策是否声明不采集敏感信息。
• 所有行为数据是否只保存在本地，或至少完成匿名化。
• 每个目标应用都有独立的提示模板和延迟参数，没有使用全局统一配置。
• 状态机覆盖三种用户路径：接受等待、中途退出、后台被杀。
• 冷却时间设置合理，避免同一时段重复打扰。
• 卸载或关闭无障碍服务后的兜底逻辑是否平稳，不会导致应用崩溃。
• 在主流国产 ROM 上测试后，服务存活率达标。
• 有监控日志上报，能远程查看服务被回收、规则异常等关键事件。

8.2 扩展方向一：从“应用级拦截”升级为“内容级反思”

目前的拦截点都在应用层面，用户通过“打开应用”这个动作触发提示。更进一步的方案是在应用内部接入 SDK，当用户准备进入短视频信息流或开始搜索商品时触发提示。这种方案对第三方应用不现实，但可以做成开源 SDK，让自家生态应用接入，或在浏览器插件维度实现类似能力。

8.3 扩展方向二：让突发提示成为“个人时间管理助手”

Haserupt 的风格天然适合扩展为“个人时间管理助手”。它可以读取用户的日历、待办事项和真实生活目标，在用户使用手机到失控边缘时，把用户的注意力拉回“现实世界”。但这种能力带来两个代价：其一，需要更多个人数据，必须把隐私说明做透；其二，提示从“该休息了”变为“你有一个会议马上要开”之后，用户会产生被监控感，产品调性需要重新拿捏。

8.4 扩展方向三：家庭模式与共同干预

未成年人防沉迷场景下，家长的诉求是“限制”，孩子的诉求是“独立空间”。完全把 Haserupt 的“自主选择”理念照搬进家庭模式并不现实。比较合理的做法是，家长可以设置更长的延迟时间和不可跳过的提示，但每一次强行跳过或放弃使用，都会向家长端生成一份记录。这种方式既保留了“延迟-反思”的机制，又兼顾了家庭场景对权威的诉求。

8.5 对开发者最重要的建议

Haserupt 这类产品真正复杂的地方不在于技术，而在于产品理念能否从“惩罚性限制”转化为“建设性干预”。代码层面，障碍服务、状态机、提示模板都不难实现；难的是判断什么时候该打断用户、用什么样的语气打断，以及用户在被打断之后有没有获得一个“自己做出选择”的出口。

如果要做类似方向的项目，建议先从一个目标应用、一种提示风格开始。跑通核心循环之后，再慢慢扩展规则、内容模板和平台边界。等用户愿意主动开启并长期保留你的无障碍权限，这个产品才算真正成立。