MindFlow开发记录

3月这段时间一直在折腾 MindFlow，这个项目想做的不是普通的番茄钟，而是一个会主动判断你有没有跑偏的专注 App。用户开始专注以后，系统不只是倒计时，还会结合前台应用、屏幕文本、截图内容去判断当前行为到底算不算和目标有关，如果连续分心就提醒，再往后就直接锁一段时间。

项目地址：Mind-Flow

这次开发其实不是从空仓库慢慢搭起来的，3月6日先把本地已经做过的一大版整体推上去，后面从3月9日到3月17日基本都在围着误判、锁机流程、登录回调这些问题连续修。第一次提交时骨架已经不小了，FocusService 管专注会话，AppMonitorService 盯前台页面变化，DistractionManager 负责把 AI 判定、白名单、冷却时间和锁机阈值串起来，外面还挂着权限引导、白名单管理、报表页和锁屏页这些东西。写到这里我才慢慢意识到，这项目表面看像效率工具，实际上更像是在和 Android 系统权限硬碰硬。

最麻烦的地方不是计时器，而是权限一串起来以后能不能真的稳定跑。无障碍要开，悬浮窗要开，通知监听要开，MediaProjection 要接，设备管理器和开机恢复也得考虑，不然所谓的分心提醒和锁机很多时候只存在于理想流程里。后面服务被从最近任务划掉后的自恢复、锁机状态恢复这些收尾，看起来不显眼，实际比做一个新页面更费心。

一开始我也想过把分心判断写得简单一点，比如看当前是不是微信、抖音、B站，或者看是不是切去了娱乐应用，满足条件就直接记一次分心。真做起来以后马上发现这套办法很容易误伤，浏览器不一定在摸鱼，微信也不一定在闲聊，同一个 App 里前一秒可能在看文档，后一秒就可能开始刷信息流。后面把这块收得更严了，AI 不能只看 App 名，得结合截图内容、页面标题、域名、搜索词一起判断，实在信息不够就返回 UNSURE，不要硬判。这个改动表面只是 prompt 和判定规则调整，实际上直接决定了后面的锁机会不会把用户逼疯。

锁机逻辑也是中间改得最多的一块。最后留下来的方案是渐进式干预，不是第一次分心就直接封，前两次先提醒，累计到第三次再锁，这样至少还有一点容错。DistractionManager 里后面又补了防抖、提醒冷却、连续工作恢复计数这些细节，因为如果每隔十几秒就弹一次“检测到分心”，那这个 App 本身就会先变成干扰源。16号又把锁机时长改成设置项，不再写死60秒，这种改动虽然小，但比起一刀切要实用得多。

这个仓库其实还分成两条线，一条是 MindFlowApp，一条是 MindFlowBackend。后者留了训练脚本、接口脚本和移动端导出脚本，用来做认知状态分类和打断性评分，最后还能往 Android 侧导模型或者权重。实际开发的时候，App 端和 AI 端更像是并行往前推，先把“能监控、能判断、能干预”这条链路打通，再慢慢去修判断质量和体验问题。

后面最花时间的边角反而是登录和找回密码。把 Supabase 接进来以后，登录注册本身不算难，真正难的是密码重置邮件点开以后怎么把流程接回 App。直接深链接回跳并不稳，参数解析、页面状态和用户提示稍不注意就会断，所以后面单独做了 callback-page，又把静态页放进 docs 里，方便直接挂到 GitHub Pages 上。3月16日先把可部署的回调页和 App deep link 接通，3月17日又把网页里多余的 resend 流程去掉，改成明确引导用户回到 App 里重新发起重置，这才算把这条链路收干净。

3月后面几次提交基本都在做收口，像启动页动画、登录输入框对比度、旧版登录布局清理这些都算是顺手补完，但真正让我觉得项目开始像样起来的，还是这些看不见的东西慢慢稳住了。MindFlow 到最后我比较满意的地方不是它接了 AI，也不是它会锁机，而是它终于不只是一个“能演示”的原型，开始有点像一个能连续跑起来的完整应用了