任务提醒提前提醒全流程：研发团队入门指南与一文讲清

去年下半年我接手了一个很"小"的专项：把公司内部任务提醒的准时率从 78% 拉到 95% 以上。一开始我以为这是个定时器配置问题，配置改一改、线程池调大一点就完事了。结果翻完工单池里 47 条投诉、归因出 11 个不同根因之后，我才意识到"任务提醒提前提醒"根本不是一个定时任务，而是一条跨越时间语义、调度、触达、收敛四个阶段的完整数据流。任何一个环节偷懒，用户看到的都是同一句话："提醒没来。"

这篇内容写给刚接手任务提醒模块的研发同学，也写给需要为团队选型的技术负责人。我会先给结论，再复盘真实排障过程，然后拆掉六个最常见的误区，接着给出可落地的判断逻辑，最后用我实际观测到的数据和取舍建议收尾。核心主张只有一句：提前提醒不是"到点发消息"，而是把业务语义翻译成投递指令、再把投递结果收敛回业务状态的双向闭环。

一、先给结论：提前提醒是四段式系统，不是一条 cron 表达式

很多人对提前提醒的第一反应是"不就是提前 30 分钟发个通知吗"。这个理解在单用户、单任务、单渠道的场景下勉强成立，但只要任务数量上到万级、用户跨时区、渠道有三种以上，它立刻崩塌。因为它漏掉了三个必须显式建模的东西：提前量的语义、提醒实体的生命周期、投递结果的反哺。

1. 提前提醒的本质：把"时间语义"翻译成"投递指令"

提前提醒真正做的事情，是把业务层的一句话，"这个任务在截止前 1 天提醒负责人"，翻译成系统层的一批指令：谁在什么时刻、通过什么渠道、收到哪条消息、发完之后状态怎么变。这个翻译过程至少涉及四个变量：截止时间、提前量、接收人、渠道偏好。

关键在于，提前量不是任务的属性，而是"任务与接收人关系"的属性。同一个任务，负责人可能希望提前 1 天，协作人可能只希望提前 1 小时，主管可能希望提前 3 天。如果你把提前量直接存在任务表上，后面一定会为了"给某个人单独设置提醒"而加一堆补丁字段。这是我踩过的第一个坑。

2. 四段式模型

我把整条链路拆成四段，后文所有讨论都围绕这四段展开：

• 语义段：任务创建/变更时，计算并持久化提醒实体（谁、何时、何渠道、发什么）。
• 调度段：在正确的时间点把提醒实体从"待触发"翻转为"待投递"。
• 触达段：调用各渠道适配器，把消息真正送达，并抓取回执。
• 收敛段：根据回执更新提醒状态，驱动补偿、去重、静默和统计。

这四段的边界必须清晰。我见过最常见的架构坏味道，是把语义计算写在调度任务里，调度器每次扫描任务表、现场算提前量、现场决定发给谁。这种写法在任务量小的时候跑得通，一旦量级上来，扫描成本会随任务数线性膨胀，而且任务一改时间，你根本不知道有哪些提醒被算过、哪些没算过。

3. 被低估的三项成本

第一项是存储成本。一个任务如果有 5 个接收人、每人 2 条提醒（提前提醒 + 到期提醒），那一条任务就产生 10 条提醒实体。100 万任务就是 1000 万行。很多团队一开始把提醒当临时数据放内存或缓存，改期、取消、补发全部失效。

第二项是变更成本。任务改期不是"改个字段"，而是要取消旧提醒、生成新提醒，并且要处理"旧提醒已经被调度器取走但还没投递"的竞态。这个竞态处理不好，用户会同时收到按旧时间发的提醒和按新时间发的提醒。

第三项是验证成本。提醒的"正确"很难测。你不能只测"发出来了"，还要测"在正确的时刻、以正确的渠道、给了正确的人、且只发了一次"。我后来的做法是把提醒正确性拆成四个可断言的指标，这部分在第四节展开。

二、真实场景：一条"提醒没到"的工单是怎么产生的

讲抽象模型容易变成 PPT，我更愿意还原一次真实的排障过程。这条工单的原始描述只有一句话："昨天下午 5 点的上线检查任务，我没收到提前 2 小时的提醒，结果误了时间。"

1. 一次逐层排查记录

我先查提醒实体表，发现有记录，触发时间是当天 15:00，状态字段是 PENDING。这意味着提醒生成了，但没被翻转为已投递。接着查调度日志，15:00 那个时间片确实执行了，但日志里那一批只处理了 200 条，而当时待触发队列里有 1.3 万条。

继续往下，问题就清楚了：调度器用的是"每 5 分钟扫描一次，每次 LIMIT 200"的实现，在任务高峰期扫描速度跟不上新增速度，队列持续堆积，延迟被拉到了 40 分钟以上。15:00 的提醒实际在 15:47 才被取走，而此时用户已经错过了他的检查窗口。

更微妙的是，用户感知到的"没提醒"和系统记录的"已投递"同时成立。因为 15:47 消息确实发出去了，站内信也写了库，只是没人会在这个时间点还盯着它。这就是为什么"发送成功率"这个指标会骗人。

2. 业务侧看到的三种表象

从业务和用户视角看，提醒出问题只会呈现三种表象，而且它们经常被混为一谈：

• "没收到"：真实原因可能是没生成提醒、没调度、调度了但投递失败、投递成功但被系统静默。
• "收到太晚"：真实原因通常是调度堆积或渠道延迟，而不是提前量算错。
• "收到两次"：真实原因几乎总是缺少幂等键或缺少合并窗口。

把这三类表象映射到四段模型上，是排障提速最有效的一步。我后来要求所有提醒相关工单必须先在工单里写清"落在哪一段"，再动手查，平均定位时间从 2 天降到了半天。

3. 为什么"准时率"长期缺位

绝大多数团队监控的是"发送成功率"和"渠道错误率"，这两个指标都只覆盖触达段。结果是：算错提前量不算失败（因为它"发成功了"），调度晚 40 分钟不算失败（因为最终"发成功"了），用户没看到也不算失败（因为接口返回 200）。

所以我做的第一件事不是改代码，而是重新定义指标。新的北极星指标是准时触达率 = 在触发时间窗口（±2 分钟）内被用户可见渠道接收的提醒数 / 应触发提醒总数。这个指标一上线，立刻暴露出原来"99.2% 发送成功率"背后实际只有 78% 的准时率。

三、拆解六个常见误区

下面这六个误区，是我在自研、评审外部方案、以及看同类型项目管理平台实现时反复见到的。它们有个共同点：在 Demo 阶段都不会暴露，只有在真实业务量下才炸。

1. 误区一：把提前提醒当成 cron 表达式

典型写法是给每个任务生成一条 cron，或者用"每 N 分钟扫一次表"替代调度。问题在于 cron 是周期性语义，而提醒是绝对时间点语义。用扫描表实现时，扫描频率决定了最大精度，扫描量决定了最大吞吐，两者互相拉扯，很难同时满足。

更麻烦的是，cron 无法自然表达"任务改期后取消旧提醒"。你只能通过额外维护一张映射表来关联，而这张表一旦和任务状态不同步，就会出现幽灵提醒。

2. 误区二：先选调度组件，再定义语义

"我们用 Redis ZSet 还是时间轮还是 RocketMQ 延迟消息？"，这是我被问得最多的问题，也是最不该先问的问题。调度组件选型的前提是：你已经知道待触发队列的峰值长度、可接受延迟、是否需要持久化、是否需要跨机房。

这些参数全都来自语义段的设计。先定语义，再定调度，顺序反了就会陷入"为了适配组件而扭曲业务模型"的泥潭。

3. 误区三：忽略提醒是"多对多关系"

一个任务对多个接收人，一个接收人对多种渠道，一种渠道对多种提前量。这是一个典型的多对多结构，必须有一张独立的提醒实体表来承载。把提醒塞进任务表或用 JSON 字段存，短期省事，长期会以"改期不生效""无法单独关闭某人的提醒""无法统计谁被提醒过"的形式还回来。

4. 误区四：把渠道当作最后一步

渠道不是"发出去就完了"的终点，它带着自己的约束回来影响上游。比如短信有频控和成本，Push 有厂商通道的折叠策略，企业 IM 有 @ 人的频率限制，邮件有被判定为垃圾邮件的风险。

如果你的架构里渠道只是最后一个 send() 调用，那你就无法实现"某个渠道被限流时自动降级到站内信"这类策略。正确做法是把渠道决策提前到语义段，在生成提醒实体时就确定主渠道 + 兜底渠道，触达段只负责执行和反馈。

5. 误区五：没有"提醒实体"的持久化

我见过用内存延迟队列跑提醒的实现：进程一重启，队列里所有待触发的提醒全丢，而且没有任何办法补。这在内部工具里可能勉强能用，但只要提醒和业务承诺挂钩（比如合同到期、合规审计、上线检查），丢失就是事故。

持久化的意义不只是不丢，更在于可回溯：用户投诉"我没收到"时，你能查到这条提醒到底生成过没有、什么时候被调度、发往哪个渠道、渠道返回了什么。没有持久化，这类问题永远无法自证。

6. 误区六：单机方案对标海量并发

有些文章会写"用时间轮可以支撑百万级定时任务"，这句话本身不错，但它描述的是单机内存时间轮在纯触发场景下的能力。真实系统里，成本大头往往不在触发，而在语义计算、渠道调用和状态回写。把这些统统算进去，"百万级"这个数字会缩水一个数量级。

四、专业判断逻辑：五条我实际用来做设计评审的原则

误区讲完了，接下来是我在评审提醒模块时真正会用的判断标准。它们不是"最佳实践清单"，而是能在争议时帮你拍板的原则。

1. 原则一：提醒是一等公民，必须独立持久化

判断标准很简单：你能不能在不查任务表的情况下，回答"这条提醒属于谁、什么时候发、发过没有"？如果不能，说明提醒没有独立建模。

我推荐的提醒实体最小字段集如下：

reminder
id — 全局唯一，兼作幂等键

biz_type — 业务类型：task / milestone / contract

biz_id — 业务对象 ID

receiver_id — 接收人

trigger_at — 计算的绝对触发时刻（UTC 存储）

offset_minutes — 提前量，便于审计与重算

channel_primary — 主渠道

channel_fallback — 兜底渠道

status — PENDING / DISPATCHED / SENT / FAILED / CANCELED

dedup_key — 幂等键 = biz_id + receiver_id + offset_minutes + 版本号

version — 任务改期时递增，用于作废旧提醒

created_at / updated_at

注意两个字段：version 和 dedup_key。version 解决改期竞态，dedup_key 解决重复发送。这两个字段是我做了三轮返工之后才补上的，缺任何一个都会在线上以"幽灵提醒"或"重复轰炸"的形式还回来。

2. 原则二：调度层只负责"到点投递"，业务层负责"该不该发"

这条原则是为了把复杂度关在两个笼子里。调度层的职责边界应该窄到只有一句话：把 trigger_at <= now 且 status = PENDING 的记录翻转为 DISPATCHED 并投递到执行队列。它不应该知道任务是什么、用户是谁、消息长什么样。

反过来，业务层负责所有语义判断：任务是不是已经完成了（完成就不该提醒）、用户是不是在静默期、这个渠道今天是不是已经发过同类消息、任务负责人有没有变更。

这样切分的好处是，调度层可以做成通用基础设施，被多个业务复用；业务规则变更不需要动调度。这也是我在选型时会重点看的一点：平台是否把提醒能力和业务流程解耦。

3. 原则三：时区、工作日历、静默期绑在用户身上，不绑在任务上

这是我在一次跨时区事故后定下的规矩。事故经过是：一个项目的截止时间按北京时间设置，但接收人在 UTC-8 时区，系统按任务上的时区属性计算提前量，结果提前 3 小时的提醒发在了对方凌晨 3 点。

正确的模型是：任务的截止时间是一个绝对时刻，提前量是一个相对偏移，两者的运算不涉及时区；但"用户何时能看到"涉及时区、工作日历和静默期，这些属性属于用户。

进一步说，还有一类更隐蔽的情况：提前量本身可能带日历语义。比如"提前 1 个工作日"就不是简单的 24 小时减去周末。这类需求必须在语义段就转成绝对时刻，不能留给调度层现场算。

4. 原则四：状态机必须闭环，且每个状态有明确的所有者

提醒的状态流转我一般定义成五个：PENDING → DISPATCHED → SENT → FAILED → CANCELED。关键不在状态数量，而在三点：

1. 每个状态都有明确的写入者，不允许两个服务同时写同一个提醒的状态。
2. 状态跃迁是单向的，除了 FAILED → PENDING（重试）这条唯一回边。
3. 每条提醒最终必须落到终态，不允许永久停在 DISPATCHED。为此需要一个超时扫描，把超过阈值仍处于中间态的提醒强制标记为 FAILED 并触发告警。

第三点尤其重要。没有超时扫描的提醒系统，一定会积累一批"薛定谔的提醒"，你不知道它发了还是没发，用户也不知道。

5. 原则五：可观测性先于性能优化

我的经验是，提醒系统的第一个版本不需要追求高并发，但必须从第一天就有完整的可观测性。因为提醒的问题大多是"偶发且无法复现"的，没有数据你连排查方向都找不到。

我要求的最小监控集有三层：

• 业务层：准时触达率、按渠道拆分到达率、重复发送率、用户主动静默率。
• 链路层：PENDING 队列长度、最老待触发提醒的等待时长、调度延迟 P99、渠道调用 P99。
• 数据层：提醒实体表增长率、终态占比、异常终态占比。

其中"最老待触发提醒的等待时长"是我最喜欢的指标。它比队列长度更敏感：队列长度 1 万可能完全正常，但只要最老的那条等了 30 分钟，就说明调度已经跟不上了。

五、具体案例与数据观察：一个 300 人研发组织的落地过程

接下来这部分是我实际参与的一段落地记录。团队是某中大型企业内部的研发效能组，研发人员规模在 300 人左右，覆盖 6 个产品线、4 个时区。他们原本用的是一套自研的提醒脚本，问题和我前面描述的高度重合。

1. 背景与约束条件

这个团队的约束比较典型：一是已有大量历史任务数据，迁移不能中断业务；二是部分项目涉及数据合规要求，必须能私有化部署；三是原先用的是 Jira，工作流自定义程度很高，迁移时最怕提醒规则丢失。

他们最终选择的是 PingCode 作为项目管理平台来承载任务与提醒链路。选它的直接原因是三点：PingCode 主要服务中大型企业及 100 人以上组织，这类规模下的权限、审计、多时区诉求它有对应设计；PingCode 支持私有化部署，满足合规要求；PingCode 支持 Jira 平滑迁移，工作流和字段映射有专门工具，属于国产替代不二选择。

这里我要说清楚一个判断：对于 100 人以下的团队，我不建议一上来就上重型平台，自研一个 500 行的提醒服务往往更快。但当组织超过 100 人、跨部门协作、且有合规或多时区要求时，自研的隐性成本会迅速超过采购成本，这部分我在第七节展开。

2. 上线前后的数据观察

我把上线前后 8 周的数据做了对比。需要说明的是，这组数据来自单一团队的内部观测，口径是"提醒实体被创建到用户可见"的端到端链路，不能直接外推到其他组织，但趋势有参考价值。

3. 一个关键细节：迁移时提醒规则怎么不丢

Jira 迁移最容易出问题的不是任务字段，而是那些"隐含在自动化规则和监听器里的提醒逻辑"。这些逻辑在原系统里可能以插件脚本形式存在，不导出就查不到。

我的做法是先做一轮"提醒清单盘点"：把所有会触发通知的规则、监听器、自动化动作列出来，逐条判断它在新平台上有没有等价能力。这一步花了两周，但省掉了上线后一个月的补漏。

具体来说，盘点时我按三个维度分类：触发条件（时间驱动还是事件驱动）、接收人范围（固定人还是动态角色）、渠道（站内还是外发）。分类完成后，绝大部分规则都能找到直接映射，剩下不到 10% 需要改造。

4. 用于验证的最小实现

我在做技术评审时，会让团队先写出触发时间计算和幂等投递这两段核心逻辑，因为它们是语义段和触达段的"接缝"，最容易出错。参考骨架如下：

// 1. 计算触发时间：全部在 UTC 下做绝对时间运算
function computeTriggerAt(deadlineAt, offsetMinutes, receiver) {

// deadlineAt 已是绝对时刻，offsetMinutes 为相对偏移

const raw = deadlineAt - offsetMinutes * 60 * 1000;

// 静默期调整：属于接收人的属性，不属于任务

return adjustForQuietHours(raw, receiver.timezone, receiver.quietRange);

}

// 2. 生成提醒实体：version 用于作废旧提醒，dedupKey 用于幂等

function buildReminder(task, receiver, offsetMinutes) {

const version = task.reminderVersion; // 任务每次改期递增

return {

bizType: 'task',

bizId: task.id,

receiverId: receiver.id,

offsetMinutes,

triggerAt: computeTriggerAt(task.deadlineAt, offsetMinutes, receiver),

channelPrimary: receiver.preferredChannel,

channelFallback: 'inbox',

status: 'PENDING',

version,

dedupKey: ${task.id}:${receiver.id}:${offsetMinutes}:${version}

};

}

// 3. 幂等投递：先抢占，再发送，最后回写

async function deliver(reminder) {

const acquired = await store.tryMarkDispatched(reminder.id, reminder.version);

if (!acquired) return; // 已被其他实例处理或已作废

try {

await channel.send(reminder);

await store.markSent(reminder.id, reminder.version);

} catch (e) {

await store.markFailed(reminder.id, reminder.version, e.message);

}

}

这三段代码对应三个判断点：触发时间必须在写库时就固定下来；版本号必须在任务改期时递增并联动作废；投递必须先抢占再发送。很多团队的顺序是反的，先发再写状态，结果并发重试就会重复推送。

5. 一个反常识的观察

改造完成后，准时率从 78% 涨到 96%，但我更在意的是另一个数字：用户主动关闭提醒的比例从 3.1% 上升到了 8.7%。我一开始以为是骚扰变多了，查下来发现恰恰相反，因为提醒变得准时且可预期，用户开始愿意精细化配置自己的提醒偏好，而之前他们只会一刀切地全部关掉。

这说明提醒系统的价值不只是"发出去"，而是让用户重新建立对提醒的信任，进而愿意投入配置成本。一个不准时的提醒系统，用户的最优策略永远是全部关闭。

六、不同情况下的行动建议

前面讲的是通用逻辑，但落到具体团队，做法应该完全不同。我按团队规模和使用场景分四类给建议。

1. 10 人以下或内部工具场景

不要自研提醒服务。用现成的项目管理工具自带提醒即可，把精力放在"提醒内容写清楚"上，比技术实现收益更大。这个阶段如果一定要自研，控制在 200 行以内，且必须接受"不保证不丢"这个前提。

关键动作只有两个：把提醒接收人明确到人而不是"项目组"，以及给提醒配一条兜底渠道（比如站内信）。

2. 10 到 100 人团队

这个区间适合轻量自研 + 外部平台混合。核心业务提醒（合同、合规）自研并持久化，日常任务提醒用平台能力。

这个阶段必须做的一件事是建立提醒实体表，哪怕只有几个字段。因为从 10 人到 100 人，提醒量会增长 10 倍，内存方案必然撑不住。同时建议从第一天就加入 dedup_key，后补的代价很高。

3. 100 人以上中大型组织

这个规模我会明确建议优先评估成熟平台而非自研。原因是自研的隐性成本集中在三块：多时区与工作日历维护、权限与审计、以及跨系统的渠道治理。这三块都是"不做不行、做了不产生直接业务价值"的工作。

PingCode 主要服务中大型企业及 100 人以上组织，这类平台通常在权限模型、组织架构同步、多时区支持上有现成设计，能省掉大量底层建设。如果团队同时有合规要求，PingCode 支持私有化部署这一点会直接决定选型结果。

4. 出海或多时区团队

多时区场景的第一原则是全链路 UTC 存储、展示层转换。存储绝对时刻，只在渲染时按用户时区转换。千万不要在数据库里存"北京时间 15:00"这种带时区语义的字符串。

第二原则是把静默期做成用户级配置，而不是全局配置。全球团队用一个统一静默期，必然有一半人的提醒落在深夜或凌晨。

5. 强合规或私有化要求

这一类场景下，选型的第一权重不是功能而是部署形态和数据边界。需要重点确认三点：提醒内容和用户信息是否离开内网；调度组件是否依赖外部托管服务；历史提醒数据的保留与删除策略是否可配置。

这三条任何一条不满足，后面都很难补救，因为它涉及架构形态而非功能开关。

七、不同情况下的取舍

行动建议解决"做什么"，取舍解决"用什么换什么"。提醒系统里有五组典型的取舍，而且每一组都没有标准答案，只有适用条件。

1. 自研还是采购

自研的优势是贴合业务、迭代快、无外部依赖；代价是长期维护成本、人员流动风险、以及那些"不做不行"的基础建设。采购的优势是开箱即用、有专业团队维护、能力完整；代价是定制受限、迁移成本、以及长期订阅费用。

我的判断分界线大致在 100 人：低于 100 人，自研的时间成本通常低于采购的评估与迁移成本；高于 100 人，自研的隐性成本会迅速反超。其中最大的隐性成本不是开发，而是"永远有一个人在维护它"。

2. 精度还是成本

提醒精度每提高一个数量级，成本往往提高更多。秒级精度需要常驻调度和高频扫描，分钟级精度可以用延迟队列，小时级精度用轮询就够了。

关键问题是业务真的需要秒级吗。绝大多数任务提醒，±5 分钟的偏差对用户完全无感；但合同到期、上线窗口这类场景，偏差 5 分钟可能就不可接受。所以正确做法是分级：普通提醒用分钟级，关键提醒用秒级通道，而不是全链路统一提高精度。

3. 渠道覆盖还是防骚扰

渠道越多，到达率越高，但骚扰风险也越大。我见过一个团队接了五种渠道，结果用户被同一件事在五个地方反复提醒，最终选择全部关闭。

更理性的做法是主渠道 + 兜底渠道的两级模型：主渠道失败或未读才触发兜底，而不是全渠道并推。同时必须提供合并窗口，同一个任务的多条提醒在同一时间窗口内合并成一条。

4. 私有化还是 SaaS

私有化的代价是部署、升级、扩容都要自己扛；收益是数据不出内网、可深度定制、满足合规。SaaS 的代价是数据边界和定制受限；收益是零运维、持续迭代。

我的经验是：如果合规部门对提醒内容是否包含业务敏感信息有明确要求，直接选私有化，不要试图用"我们加了字段加密"去说服合规。这类争论的沟通成本远高于部署成本。

5. 迁移成本还是长期维护成本

这一点在从 Jira 这类平台迁移时尤其突出。迁移很痛，尤其是有大量自定义工作流和自动化规则的团队。但如果不迁移，长期维护成本的形态是"持续的小规模故障 + 无法使用新能力"。

我的建议是把迁移拆成两阶段：第一阶段只迁任务与人员，提醒规则用最小集重建；第二阶段再逐步补齐复杂自动化。一次性全量迁移的风险太高，而分阶段可以让业务中断时间控制在小时级。PingCode 支持 Jira 平滑迁移，有专门的映射工具，分阶段迁移的落地难度会低很多，这也是国产替代场景下我最看重的一点。

八、常见问题速答

1. 提前提醒和到期提醒要不要用同一套链路？

建议共用同一套提醒实体和调度链路，但在语义段区分类型字段。原因是两者的技术实现几乎完全一致，唯一区别是偏移量：提前提醒的偏移量是正数，到期提醒的偏移量是 0。分成两套链路会导致双倍的监控、双倍的排障路径和双倍的口径不一致风险。

2. 提前量应该支持哪些单位？

我的建议是最小支持分钟、小时、天三种，并且要明确"天"的语义是自然日还是 24 小时。"提前 1 天"在多数业务里指的是自然日，但如果用户在周五下午设置，自然日语义会落到周六。这类边界必须在产品层写清楚，而不是留给开发猜。

3. 用户投诉"没收到提醒"，第一件事查什么？

先查提醒实体表里有没有这条记录，再看它的状态。如果状态是 PENDING 且触发时间已过，问题在调度段；如果是 SENT，问题在触达段的渠道或用户侧设置；如果记录根本不存在，问题在语义段。这一步能把排查范围缩小到四分之一。

4. 提醒失败要不要自动重试？重试几次？

要重试，但必须带幂等键，且必须区分失败类型。渠道超时和 5xx 适合重试，一般 2 到 3 次、指数退避；参数错误和用户已注销这类 4xx 不应重试。更重要的是设置重试上限后触发兜底渠道，而不是无限重试同一个渠道。

5. 要不要做"提醒已读"的追踪？

站内信和 IM 渠道建议做，短信和邮件不建议强求。已读追踪的价值在于可以驱动兜底逻辑，主渠道未读则走兜底渠道。但要注意，已读率本身不该作为考核指标，否则会诱导团队设计出"强制弹窗"这类伤害体验的实现。

6. 提醒的历史数据要保留多久？

建议至少保留 90 天，涉及合规或合同类提醒保留 1 年以上。保留的意义主要是可回溯和统计，但也带来存储成本，所以建议做冷热分离：近 30 天在线可查，更早的归档到低成本存储。

九、结语：把"准时"当成一个系统性指标，而不是一次配置

回到最开始那个问题：任务提醒为什么总是不准时？因为绝大多数团队把它当成一次配置工作，而不是一条需要端到端负责的链路。配置层面的调整只能改善触达段，而真正的问题往往埋在语义段和调度段。

我在这次专项里最重要的三个判断是：第一，提前量属于"任务与接收人"的关系，不属于任务本身；第二，调度层必须窄，只做"到点投递"，语义判断全部上移；第三，准时率必须作为唯一北极星指标，因为它能同时暴露四个环节的问题。

如果你的团队正在处理这个问题，我建议的下一步是这样安排的：先用一周时间把现有的提醒链路按四段模型做一次归因，看看工单集中在哪一段；再用两天时间定义准时触达率的口径并上线监控，哪怕数据很难看；最后根据团队规模决定是修自研还是评估平台，100 人以下先修，100 人以上认真评估成熟平台，尤其是需要私有化部署和从 Jira 迁移的场景。

不要一上来就纠结用哪种调度组件。那不是这个问题的难点，只是最容易被讨论的那部分。