我把“提醒一下”改造成了真正会闭环的执行系统

做项目做久了，我越来越发现一个问题：很多“计划系统”“提醒系统”“自动化系统”，最后都停留在一个很尴尬的层面——它提醒了，但事情没有真正被完成。

这听起来像一句废话，但实际上是大量系统设计里最容易被忽略的一层。

比如一个很常见的场景：

• 我给自己定了一个每日提升任务
• 系统到了时间提醒我
• 我看到了提醒
• 但我没做，或者只做了一半
• 然后这件事既没有继续推进，也没有被明确地标记为失败或顺延
• 第二天一切归零，系统还假装自己“完成了提醒职责”

如果你把这套逻辑放大到团队协作、自动化任务、定时任务，甚至 AI Agent 任务里，就会发现一个更本质的问题：

很多系统解决的是“通知”问题，但真正需要解决的是“闭环”问题。

我最近专门把这件事拿出来重做了一遍，结论很明确：“提醒一次”不是系统能力，真正的系统能力是“让事情进入状态机，并最终收口”。

一、问题到底出在哪

最开始我也以为问题很简单：无非就是提醒不够及时，或者文案不够明确。

后来我发现不是。

真正的问题是，很多任务系统只有这两步：

1. 创建任务
2. 到点提醒

但现实世界里的任务，尤其是成长任务、长期任务、监督型任务，至少应该有 5 步：

1. 立项
2. 提醒
3. 追问
4. 补救
5. 收口

少了后面三步，任务就会变成一种“看起来存在，实际上靠缘分完成”的东西。

这类系统的典型症状是：

• 任务状态永远停在 open
• 用户只有“想起来了”才会去做
• 系统没有“没做完怎么办”的设计
• 第二天系统也不知道昨天那条任务到底是完成了、部分完成了，还是干脆没做

这时候你会发现，问题根本不是提醒策略，而是状态机设计缺失。

二、为什么“提醒”不等于“闭环”

很多人做提醒系统，默认有个隐含前提：只要提醒送达，后面的执行就交给人。

这个前提放在“喝水提醒”“发一条消息提醒”这种一次性动作里是成立的，但放在“每日提升计划”“每周复盘”“学习任务”“长期能力建设”里，就不成立了。

因为这类任务不是简单的 yes/no，它至少会出现几种状态：

• 做完了
• 做了一部分
• 今天没做，但要顺延
• 今天没做，也没有顺延，等于失败
• 做法本身要临时降级

如果系统里没有这些状态，那任务最终就只剩一个动作：到点弹一下。

而这其实只是在制造一种“我已经管理了自己”的幻觉。

三、怎么把它改造成真正的闭环系统

我后来把这件事抽成了一套最小闭环模型，核心是三件事：

1）任务创建时就补齐“最低达标”和“补救动作”

以前的任务通常只写：

• 标题
• 到期时间

这其实不够。

一个真正可执行的任务，至少还应该有：

• minimumDone：最低达标标准
• fallbackAction：如果做不完，最小补救动作是什么
• closeRule：这条任务最后怎么才算收口

比如一条“每日提升计划”，不应该只写：

“精读一个优质模块并记录结构观察”

而应该写成：

• 最低达标：至少记录 3 条结构/职责观察
• 补救动作：如果没法完整精读，就先花 10 分钟写 3 条观察
• 收口规则：今天结束前，必须把状态标成 done / partial / carry_over

这三个字段一加，任务立刻从“愿望”变成了“协议”。

2）系统不只提醒一次，还要追问一次

第二个关键点，是把任务从“提醒型”分成“监督型”。

提醒型任务：

• 到点提醒一次就够了

监督型任务：

• 到点提醒
• 过一段时间再追问状态
• 如果还没完成，就走补救逻辑
• 当天结束前必须收口

这两类任务在系统里本来就不该混为一谈。

我现在更倾向于把它们明确拆开：

• remind_only
• closed_loop

这样系统才能知道，某条任务到底是：

• 只要提醒
• 还是必须盯到结果出来

3）必须允许“部分完成”和“顺延”

很多任务系统只接受两种结果：

• done
• not_done

但现实里，大量任务是介于两者之间的。

比如今天的提升任务，本来目标是完整精读一个模块。结果今天状态不好、事情太多，最后只完成了：

• 拆了 3 条结构观察
• 记了 1 条可借鉴实现

这时候它不该被粗暴判成失败，因为它已经完成了“最低达标”。

所以我后来把状态扩成：

• done
• partial
• carry_over
• cancelled

其中我觉得最有价值的是 partial 和 carry_over：

• partial：承认今天做了一部分
• carry_over：承认今天没做完，但系统帮你正式顺延，而不是假装无事发生

这一步非常重要，因为它让系统开始具备一种真实感：它不再逼你“非黑即白”，而是能容纳现实世界的执行摩擦。

四、最小可行版本长什么样

如果不想一开始就做一个很大的任务系统，我觉得最小版本只需要做到这些：

数据层

每条监督型任务补 5 个字段：

• minimumDone
• fallbackAction
• closeRule
• supervisionMode
• dailyWindowEnd

提醒层

到点时输出的信息不再只是“该做了”，而是：

• 任务是什么
• 最低达标是什么
• 做不完先做什么
• 今天最晚什么时候必须收口

收口层

增加一个非常轻量的状态收口动作，比如支持：

• done
• partial
• carry_over

哪怕只是命令行、脚本、或者一条结构化回复，都比“没有收口动作”强得多。

五、这件事对我最大的启发

这次重做之后，我最大的感受不是“任务系统更复杂了”，而是：

很多看起来是提醒问题的东西，本质上其实是工作流设计问题。

一旦你开始用“状态机”的方式看待任务，很多事情都会变得更清楚：

• 为什么提醒了还是没做
• 为什么计划总是漂着
• 为什么人和系统最后都忘了
• 为什么一堆“自律工具”最后只是制造内疚感

因为它们没有设计“没完成之后怎么办”。

而真正有用的系统，不是只在顺利时成立，而是在做不完、忘了做、只做了一半的时候，依然能把事情往前推一步。

六、结尾

如果你也在做自己的提醒系统、自动化系统、AI Agent 任务流，我很建议你重新问一遍自己这句话：

你的系统是在“提醒人”，还是在“推动事情闭环”？

这两者之间，差的不只是一个功能按钮，而是一整套对任务、状态、补救和收口的理解。

我现在更相信一句话：

提醒不是终点，收口才是。