DailyPresence

项目起点是一个具体现象：高强度运转期间，日子会连成一片，失去分段。 日期可查，但对「今天」的切身感知会消失——上一次真正「过完一天」是什么时候，往往答不上来。

这类问题通常被归入时间管理，对应工具也已成熟：清单、番茄钟、看板、时间块。 它们的共同假设是：使用者缺少的是管理手段，而不是「今天」这件事本身。

因此产品方向被定为反向路径——不管理时间，而是恢复对当天的感知。

目标不是提升任务完成量，而是让人确信「今天确实发生过」。

开发之前进行了三周基础调研：记录十几位使用者在一天中打开与关闭效率类应用的时间点。

三条反复出现的现象：

• 注意力在一整天里反复起落。按「固定时段」设计的产品，都假设了一个并不存在的稳定状态。
• 大部分人不需要完成更多，需要感觉到进度。真正让人焦虑的不是事情没做完，是「今天什么都没发生过」。
• 愧疚感能带来短期数据，但带不来留存。几乎所有被卸载的工具，最后一条通知都是指责式的。

第三条是本项目的核心约束。把「连续打卡断签」做成恐惧机制的产品， 短期数据可观，但用户离开时带有情绪，不会回流。

如果把目标从「完成任务」换成「重新察觉到今天」，产品的形态会完全不一样。它应该有三个支点：

• 一天只出现一次的锚点。不是提醒列表，是每天一个问题。答完就结束，不追问。
• 一个不用打开 App 就能完成的最小动作。只要需要打开、等待、加载，这件事就不会被长期坚持。
• 一个不作评价的反馈。不给分数，不给排名，不做「今天不如昨天」的比较。

由此推出一条约束，并成为整个项目的核心原则： 如果这个系统需要投入更多注意力才能使用，它必然失败。

这条约束反直觉但成立——号称解决注意力问题的产品，第一步是尽可能少占用注意力。 初版设计中约一半的功能因此被砍掉。

目前运行的是 v0.3，包含四个部分，界面加起来不超过五屏。

今日锚点

每天一次，一个问题。可能关于今天，也可能关于昨天。回答只需十秒，且不要求认真作答。

一日三段

把一天切成早、中、晚三段，每段只有一个最小动作。早上写下一个词，中午做一个十秒的停顿，晚上交给系统一句话。

Observer

产品中最复杂、也最不该被察觉的一块。它决定「什么时候打扰最不令人反感」，详见下节。

时间线

不是成就列表，而是一份原始记录。像天气日志一样平淡、连续、可回看。三个月后可以看出自己的节奏在何时收缩、何时扩张。

选择小程序作为载体，原因是两项能力要求——可被通知，以及打开成本足够低。这两点上小程序明显优于网页。

技术上是常规的单体结构：前端小程序、后端接口、关系库存事件流。真正需要说明的是两个设计决定。

数据模型从「按天」改成「按事件」

初版数据表以「一天一行」建模。两周后确认该模型不成立：一天不是一条记录，而是一串事件。 改成事件流之后，「今天过得怎么样」这个问题第一次可以被真实地回答。

Observer 本质上是一个打分器

不做预测，只做加权。当前触发条件由三个量组合而成：使用者的空闲概率、距上次交互的时间、当天已完成的段落数。

时机分 = 空闲概率 × 上一次交互距离 × 当天完成度

公式朴素，但把「定时提醒」变成了「按条件触发」——差别很大，详见下节。

AI 用在哪

两处。一是把零散输入整理成可读的当日摘要；二是构造评估集——为判断「摘要是否像人写的」，反过来用模型生成一批反例来校准标准。

做一个行为类产品和做工具类产品，最大的区别在于：工具的成功由「能做多少」定义，行为的成功由「能不做多少」定义。

• 「不做什么」比「做什么」更难。砍掉打卡功能的那一周，数据是下降的。接受下降，比加上一个功能需要更大的决心。
• 靠愧疚运转的系统会反过来伤害产品。短期指标会奖励它，长期会惩罚它，而奖励总是先出现。
• 能把触发条件用一句话说清的产品，通常活得更久。说不清触发条件的，最后都退化成定时推送。

方法论层面：完整功能地图先行设计的习惯在本项目失效。 三次最有价值的改动，全部来自上线后的真实使用反馈。

Growing开发中 更新于 2026 年 9 月

v0.3 已在小范围运行六周。当前推进的事项：

• Observer 的时机分还在调参，主要问题是它对「出差」和「假期」这两种非常规日子完全失效。
• 时间线目前只能按月看，正在做「季节视图」——用更长的时间尺度看自己的节奏变化。
• 尚未对外发布。待 Observer 在非常规日期上表现稳定后，再评估开放。

相关手记：为什么我把 DailyPresence 的观察者重写了一遍