从 0 到 1，Codex 重置雷达小程序我是怎么实现的

昨天，我写了一篇文章，介绍了我做的「Codex 重置雷达」。文章发出后，反响比我预期更好。

不少朋友关心的，不只是“它能不能提醒”，还有两个更实际的问题：它怎么判断一条公开消息真的是新信号？又怎么保证不会反复打扰人？

今天不再讲它能做什么。我们就跟着一条 Tibo 的公开 X 推文走一遍，看看它怎样一步步变成一次微信提醒。

一条提醒，要过三道关

用户最后看到的，可能只是一句“发现新的 Codex 重置公开信号”。

这句话出现前，系统要先过三道关：这条信号来自谁，又是不是真的新事？同一件事是否提醒过？微信暂时发不出去，事情会不会丢？

每一关都对应一种用户真实会遇到的麻烦。

来源没核对，或者普通页面更新被当成新事件，提醒就会变成噪声；同一件事发两次，用户很快失去耐心；确认了却没送到，前面的判断也白做了。

Codex 重置雷达没有按“内容一变就转发”的逻辑来做。它更像一个克制的值班员：先认人，再认事，最后才敲门。

第一关：这是谁发的，真的是新事吗？

Tibo一条推文刚出现，系统先不急着发送。

它先看链接是否来自 Tibo 的公开 X 帐号，格式是否指向 x.com/thsottiaux/status/...；再看发布时间、重置类型和数据结构是否齐全。

最新记录和历史记录也要能对上。一边说刚刚有新重置，历史里却没有对应记录，这样的信号还不够稳。系统不会拿它覆盖旧记录，更不会先通知、后改口。

这一步，是为了让每一条提醒都留下可回看的证据。以后点进记录，至少知道自己看到的不是一段脱离来源的转述。

不过，确认它来自 Tibo，只解决了前半个问题。

更难的一步是：这条内容虽然可信，它说的是不是一件刚刚发生的新事？

统计信息更新、页面排版调整，甚至只是这一次采集的时间不同，都可能让一份记录看起来和上次不一样。

系统不按“只要不一样就通知”的规则做。它只盯一个核心条件：当前记录里的最新重置时间，是否比上一次更晚。

更晚，才算新事件；其他变化可以记下来，但不进提醒队列。

这一步是在把会变的“内容”翻译成可判断的“事件”。内容会修改，事件只有发生和没发生两种状态。确认出现了新事件，后面的通知才有意义。

提醒系统最怕的不是慢，而是把“内容变化”误认成“新事件”。

翻译成人话就是：看门牌，是确认来的是谁；看单号，是确认送来的是不是一件新的东西。

第二关：同一件事，只提醒一次

确认有新事件后，还有一个很实际的问题：采集任务会重复跑，服务可能重启，上游也可能反复给到同一条公开信号。

每次都把它当新事，用户就会收到两条一模一样的提醒，很快怀疑小程序是不是坏了。

系统会先给每个事件一张“身份证”。上游能提供推文 ID，就用推文 ID；没有时，再用重置发生时间兜底。

翻译成人话，就是快递单号。同一个单号，仓库扫三次，不能送三次货；同一个重置信号被采集三次，也只能对应一次提醒。

第三关：微信没发出去，事情不能丢

到了这里，才轮到微信。

把“发现信号”和“发送消息”写在同一步里最省事：发现了，马上发。但微信接口临时慢一点、报一次错，已经确认的新事件就可能什么也没留下。

我没有让采集器直接找用户，而是把它拆成两件事。

• 采集器负责发现并确认新信号；
• 小程序服务负责把已确认的事件放进待发送队列，再由后台任务发出订阅消息。

两者通过一个只给服务内部使用的接口交接。采集器不直接找用户，微信也不反过来决定那条信号是否成立。

就像餐厅的后厨和前台：后厨把菜做好是一件事，前台把菜端到桌上是另一件事。前台临时忙不过来，不能假装后厨根本没做过这道菜。

采集器交接失败时，系统会先短重试几次；仍未成功，就把交接记录写进本地补偿队列。下一轮采集开始前，先把没交出去的事件再试一遍。

小程序服务也是同样的处理。微信发送遇到可恢复错误，事件不会被删掉，而是隔一段时间再试；重试间隔会逐步拉长，避免一出问题就疯狂重发。

已经确认的信号，不能因为一次网络抖动就悄悄丢掉。

一条提醒，最终替你省掉什么？

Codex 重置雷达，做的事情很简单，是把刷 Tibo X 公开信息、判断是不是 Codex 重置信号、等到确实值得知道时，再提醒你一次。

他不会把每个变化都推到你面前，而是替你筛掉大部分不值得打扰的变化。等到有价值的重置信号再通知你

如果你也想偶尔知道“今天有没有新的 Codex Reset 公开信号”，可以来体验一下「徐公 AI 雷达」。