把提醒写进日历，比只让机器人到点发消息更可靠。
windows-bot-memory/reminder-workflow
提醒看起来很小，也很容易被做成一个“到点发消息”的玩具功能。
在聊天里说一句“半小时后提醒我”，机器人到点发一条消息，好像就结束了。
但实际用下来，提醒是一件需要留下状态的小任务。
尤其是那些来自截图、自然语言和临时变化的提醒，如果只靠聊天消息，很容易丢、很难改、也不好确认是否创建成功。
所以我更倾向于把提醒落到日历里。聊天负责触发，日历负责承载状态，这个分工比单独维护一个机器人计时器可靠得多。
聊天消息适合触发，不适合承载状态
聊天是很好的入口。
人不会为了一个小提醒打开任务管理器，最自然的方式就是随口说一句：
一会儿提醒我做某件事明天上午提醒我处理某个问题截图里的时间到了叫我这些表达都很轻。
但聊天不适合当提醒的唯一记录。因为它有几个问题：
- 消息流会被新消息冲走。
- 修改提醒时很难知道应该改哪一条。
- 多端同步不一定可靠。
- 机器人重启后不一定还记得待提醒队列。
- 用户很难确认提醒是否真的被系统接管。
所以聊天更适合做触发器，日历才适合留下提醒记录。
日历天然适合承载提醒
日历系统有几个很朴素但重要的能力：
- 有明确开始时间。
- 能被手机、电脑、网页多端看到。
- 支持提醒通知。
- 支持修改和删除。
- 支持重复事件。
- 能和其他日程放在同一个时间轴里。
这些能力如果自己重做一遍，复杂度会很高。
机器人接到“提醒我”这类请求时，默认不应只开一个临时计时器，更好的做法是创建一个日历事件。
这等于把一句聊天请求变成了一个可见、可修改、可同步的系统状态。
最容易出错的是时间解析
提醒流程里，最容易出错的往往是时间理解，而不是创建事件本身。
自然语言时间经常很模糊：
- “半小时后”
- “明天上午”
- “今天晚点”
- “截图里那个时间”
- “改到十点半”
这里至少要做三件事。
第一，确定基准日期。用户说“今天”或“明天”，必须结合当前时区和当前日期。
第二，处理缺省信息。只有“十点半”时，要判断是今天、明天，还是基于上一条提醒修改。
第三，避免过度猜测。时间不明确时，机器人应该停下来问一句，而不是自信创建错时间。
把这些逻辑抽成一个小脚本，比每次在对话里临时推理更可靠。
截图提醒是一个有趣入口
有些提醒来自截图。
比如界面右侧显示一个到点时间，人只想把截图发给机器人，然后让它按界面上的时间提醒。
这时候流程会变成：
截图 -> 识别时间 -> 解析日期 -> 创建日历事件这很像一个很小的视觉自动化任务。
但这里也要保守：截图识别出来的时间最好在创建前形成明确文本；如果有歧义，比如“今日”和当前日期跨天、界面显示不完整，就应该要求确认。
它主要省去了用户重新输入时间的步骤。
为什么要写脚本
一开始直接通过工具调用创建日程也能完成。
但如果每次都让模型在对话里拼参数、查日历、调用接口，速度会慢，而且容易出现细节不一致。
后来我把这套固定流程写成了脚本：
输入：标题 + 时间表达 + 可选日期处理：解析时间、缓存默认日历、设置提醒策略输出：创建或 dry-run 验证结果这样模型只负责判断“用户想要什么”，脚本负责“怎么稳定执行”。
这也是我做本地自动化时越来越喜欢的分工：模型处理模糊语义，脚本处理确定动作。
默认设置要符合生活场景
提醒脚本的默认设置也很重要。
对于个人提醒，我更希望默认：
- 事件是私密的。
- 状态是空闲的，不占用日程。
- 不自动创建会议。
- 到点提醒即可。
- 支持先 dry-run，确认解析结果。
这些默认设置比“功能很多”更重要。提醒是很频繁的小动作，默认设置如果不舒服，每次都要补参数，用户很快就不用了。
修改比创建更考验设计
创建提醒只是第一步。
真实生活里，时间经常会变。
用户可能会说：
改到十点半应该是今天不是明天以后看到这种截图就按上面的时间改这时系统需要知道“改的是哪一个提醒”。如果提醒只是聊天消息，修改会很难；如果提醒是日历事件，至少还有一个明确对象可以更新。
所以提醒系统最好从一开始就把创建结果变成可追踪对象，而不是只发一句“好的”。
提醒最后还是要落地
提醒不是一个大功能，但它很能检验机器人是否真的融入日常。
好的提醒流程应该是：
聊天触发时间解析日历落地可见可改到点提醒聊天负责低摩擦入口，日历负责长期状态，脚本负责稳定执行，模型负责处理自然语言和上下文。
这样提醒会在日历里留下记录，不会只停在聊天里的一句回复。
继续读