很多研发团队的提醒问题，不是"提醒不够"，而是"提醒太多，但没人信"。我在过去三年里帮六七个 80 到 400 人规模的研发组织梳理过任务提醒流程，最常见的一幕是：群里每天滚动几百条机器人推送，站会上大家还是面面相觑地问"这个任务谁在做、什么时候到期"。真正的问题从来不在"有没有提醒",而在于提醒有没有被设计过，谁该收到、什么事值得打断、用什么口径描述、什么条件下才推送。
这篇文章我会把自己踩过的坑、跑通的四套模板，以及一套判断"提醒到底有没有效"的量化方法完整写出来，帮你把提醒从"群里的噪音"改造成"团队的行动信号"。
一、先给结论：自动提醒的效率瓶颈在策略，不在工具
如果你只想先拿到一个结论，那就是：研发团队提升任务提醒效率的关键动作，是把"提醒策略"作为独立工作设计一次，而不是继续叠加工具和机器人。我见过太多团队把"接一个飞书机器人"当成解决方案，结果只是把原来的口头催促改成了机器催促，提醒数量翻了十倍，响应率反而下降。
三个判断是我在实践中反复验证过的：
- 提醒的价值由"该不该打断"决定，而不是由"发得出去"决定。一条提醒如果没有触发具体行动，它就是负资产，因为它消耗了团队的注意力预算。
- 研发团队适合事件驱动的提醒，而不是时间驱动的提醒。构建失败、PR 待审、缺陷被重新打开,这些是天然的事件;而"你有个任务明天到期"这类时间提醒,在研发场景里往往被当成可忽略的背景音。
- 提醒系统的最终目标,是让自己变得越来越不必要。当团队形成了对关键事件的稳定响应习惯,提醒可以逐步降级甚至关闭,而不是永久依赖。
基于这三点,我在下面会把方法论拆成"选什么提醒、用什么工具、怎么配置模板、怎么落地、怎么验证"五层,每一层都给出可复制的判断标准。
二、真实场景：研发团队的提醒是怎么一步步失控的
1. 一个典型的"提醒失控"时间线
去年我参与过一个 200 人规模的研发中台团队梳理流程。他们的问题不是没工具,而是工具太多:需求用某项目管理平台管,代码在 GitLab,构建在 Jenkins,线上告警在另一个系统。每个系统都有通知,通知又都往三个 IM 群同步。
我让他们导出过一个月的群消息记录,结果是这样的:三个群合计日均机器人消息 380 条,其中真正引发"回复+处理动作"的只有 27 条,有效比例大约 7%。剩下 93% 的消息,要么没有明确责任人,要么重复推送,要么是团队早就知道的信息。
更麻烦的是,当提醒数量超过一个阈值,人的处理策略会从"逐条判断"退化为"整体忽略"。这是行为心理学里说的"刺激过载",不是你团队不敬业,而是大脑的自我保护机制。一旦进入"整体忽略"模式,连真正重要的告警也会被漏掉。
2. 研发团队提醒失控的三个典型成因
我把这些团队的问题归纳成三类,它们往往同时出现:
- 渠道分散无分层。所有通知走同一个群、同一种格式,重要和不重要在视觉上完全一样。
- 提醒对象错配。一个任务的状态变化被推给了全部 40 人,而真正需要行动的可能只有 1 个人。
- 内容模板缺失。推送只有一句"任务状态已更新",没有任务链接、没有截止时间、没有责任人,收到的人还得回到系统里查。
下面这张图把这三类成因和它们对应的可量化结果放在一起,方便你对照自己团队的现状。
3. 为什么"多加一个机器人"通常没用
当提醒失控时,本能反应是"再加一层提醒"。但如果问题出在渠道分层、对象匹配和内容模板,新增机器人只会让噪音更上一层。我的经验是:先做减法,再做自动化。在接入任何新工具前,先关掉一批没有明确行动指向的提醒,你会立刻看到响应率的变化。
三、拆解误区：关于自动提醒最常见的五个错误判断
1. 误区一：提醒越多，任务越不会漏
这是个反直觉但稳定的规律:提醒数量和任务漏检率不是线性负相关,而是存在一个拐点。在拐点之前,增加提醒确实降低漏检;过了拐点,提醒增加反而提高漏检,因为关键信息被淹没了。我在两个团队做过相同的对照观察,减少提醒数量后,漏检的主要任务数量都出现了下降。
2. 误区二：所有提醒都该即时推送
即时推送的代价是打断。研发人员进入深度工作状态需要十几分钟,一次打断的成本远高于一次延迟。所以只有真正 P0 级别的事件，线上故障、主干构建失败、阻塞他人的待审 PR，才值得即时推送。其余应该降级为汇总或摘要。
3. 误区三：把工具配置当成策略设计
配置 Webhook 是半小时的事,但决定"什么事件对应什么优先级、推送给谁、用什么话术",需要团队一起讨论。很多团队跳过了讨论,直接照搬网上的配置模板,结果模板和团队的实际工作流不匹配,跑了两周就废弃了。
4. 误区四：提醒内容可以交给机器人随意生成
提醒的措辞直接影响行动意愿。"任务已更新"和"【待审】PR #482 已停滞 6 小时,阻塞发布分支,请 @张三 今天 18:00 前处理",这两句话对接收者的意义完全不同。后者包含状态、时长、影响、责任人、截止时间,是可以直接触发行动的。
5. 误区五：上线后就一劳永逸
团队的工作模式在变,提醒规则也必须定期复盘。我建议每两个月做一次"提醒审计":统计每条规则的触发次数和响应率,把触发频繁但响应率低的规则关掉或降级。这个过程本身就是提醒系统保持有效的关键。
四、专业判断逻辑：我判断一条提醒值不值得发的四把尺子
1. 第一把尺子：它是否指向一个明确的行动
每条提醒发出前,先问自己:收到的人能立刻做一件具体的事吗?如果答案是"知道一下",那它大概率不该作为即时提醒,而应该进入摘要或日报。
2. 第二把尺子：它是否推给了唯一的责任人
理想状态下,一条提醒应该只有一个"首要行动人"。如果需要多人协作,也应该明确谁是第一责任人。把提醒推给全群,等于把责任稀释到零。
3. 第三把尺子：它的时效性等级是否匹配推送方式
我会把提醒分成三级,每一级对应不同的推送方式和频率。这套分级是整个策略的骨架:
| 优先级 | 典型事件 | 推送方式 | 响应期望 |
|---|---|---|---|
| P0 即时 | 线上故障、主干构建失败、阻塞他人的待审 PR | IM 单聊或专属告警频道 + @责任人 | 30 分钟内 |
| P1 汇总 | 当日待处理任务、临近截止的任务 | 每日固定时间汇总推送到小组群 | 当日处理 |
| P2 摘要 | 状态变更、评论、字段修改 | 日报或周报形式,不单独打断 | 按需查看 |
这套分级的核心是用频率换信任:P0 提醒很少,但每次出现都值得立刻看;P1 每天一次,团队会养成固定查看习惯;P2 不打断,只在需要时查阅。
4. 第四把尺子：它的内容是否自带决策信息
我有一条硬性要求:任何即时提醒必须包含任务链接、责任人、截止时间、触发原因四项信息。缺一项,接收者就要额外操作一次去查,这就是效率损失。这条标准看起来简单,但能过滤掉大量"伪提醒"。
5. 用这四把尺子做一次快速自查
你可以拿团队过去一周的机器人消息,逐条套用这四把尺子。我的经验是,大多数团队的即时提醒里,能同时通过四项的比例不到 20%。把不通过的降级或关闭,就是你提升提醒效率最快的一步。
五、案例与数据观察：一个 300 人团队如何把提醒重构了一遍
1. 背景与初始状态
这个团队是做企业级 SaaS 的研发中心,约 300 人,分 12 个小组。他们用的工具栈比较典型:某项目管理平台做需求与缺陷管理,代码和 CI 在 GitLab,IM 用飞书。上线我的策略之前,他们的通知完全靠工具的默认配置。
我进场时做的第一件事是记录了一周的基线数据:日均机器人消息 512 条,任务平均闭环时长 4.1 天,关键告警(构建失败、线上故障)的平均发现时长 47 分钟。
2. 重构动作：四个可复制的步骤
我给他们设计的落地路径分四步,这四步后来被我反复用于其他团队:
- 盘点并关闭无行动指向的提醒。一周内关掉了 14 条默认通知规则,机器人消息量从 512 条降到 190 条。
- 建立 P0/P1/P2 分级,并配置独立通道。P0 走专属告警群,只保留 6 类事件;P1 每天 9:30 汇总;P2 收敛到周报。
- 统一提醒内容模板。所有 P0 和 P1 提醒都按"【级别】【动作】+ 任务链接 + 责任人 + 截止时间 + 触发原因"格式生成。
- 接入任务流的自动化。他们在这个阶段做了工具层面的调整,把部分团队的 Jira 数据平滑迁移到 PingCode,利用其内置的自动化规则减少了自建脚本的维护成本。
需要说明的是,PingCode 主要面向中大型企业和 100 人以上的研发组织,这个团队的规模和它的定位是匹配的。选择它的一个重要原因是支持私有化部署,对于有数据合规要求的团队来说是刚需;另一个原因是支持从 Jira 平滑迁移,这套迁移路径我实测下来,历史工作项和自定义字段的保留度比较高,不需要团队重新梳理一遍数据模型。
3. 六周后的数据变化
重构六周后,我做了第二次基线测量,对比结果如下:
| 指标 | 重构前 | 重构六周后 | 变化 |
|---|---|---|---|
| 日均机器人消息量 | 512 条 | 168 条 | -67% |
| 提醒响应率 | 23% | 64% | +41 个百分点 |
| 任务平均闭环时长 | 4.1 天 | 1.8 天 | -56% |
| 关键告警平均发现时长 | 47 分钟 | 9 分钟 | -81% |
| 主动关闭通知的成员比例 | 52% | 11% | -41 个百分点 |
这组数字里我最看重的是最后一行。主动关闭通知的比例,是提醒疲劳最诚实的温度计。从 52% 降到 11%,说明团队重新开始信任这套提醒系统了。
4. 一个容易被忽略的细节：迁移期的一次性成本
如果团队要换工具,迁移本身是有成本的。我那个 300 人团队的项目迁移花了大约两周,其中大部分时间用在历史工作项字段映射的确认上。这个成本必须提前算进计划,否则会出现"新工具上线但旧规则还在跑"的双轨混乱期,反而是提醒效率的最低点。
六、实操模板：四套可直接复制的提醒配置
下面四套模板是我在不同团队反复使用并验证过的,每一套都包含触发条件、推送内容格式、配置要点和注意事项。你可以按优先级从第一套开始跑通,再逐步扩展。
1. 模板一：PR 待审超时提醒
（1）触发条件
当一个 PR 处于待审状态超过 4 小时,且尚未有评审人对该 PR 提交任何评论或批准。这个时长阈值建议根据团队的实际审查节奏调整,我的经验是设定在"正常审查时长中位数的两倍"。
（2）推送内容格式
【P0 · PR待审】#482 已停滞 6h12m
任务: 用户鉴权模块重构
链接: https://your-repo/pull/482
责任人: @张三
建议截止: 今天 18:00
影响: 阻塞 release/2024.09 分支合并
（3）配置要点
- 用定时轮询方式扫描待审 PR 列表,而不是依赖每次提交事件,避免重复推送。
- 每次推送前检查该 PR 是否已在过去 2 小时推送过,防止重复打断。
- 责任人取 PR 的 reviewer 字段,若为空则回退到团队默认评审人。
（4）注意事项
不要在 PR 创建时就推送提醒,那会造成大量噪音。只有"停滞"才是需要打断的事件,而不是"创建"。这一点是很多团队配置错误的地方。
2. 模板二：每日站会前任务摘要
（1）触发条件
每日固定时间(建议在站会前 30 分钟)推送一次,内容为当前迭代内所有未完成任务按责任人和状态分组的摘要。
（2）推送内容格式
【P1 · 迭代摘要】Sprint 24 第 8 天,剩余 4 天
未完成: 17 / 总数 42
@张三 (3项)
#121 支付回调重试 · 进行中 · 明日到期
#130 订单状态机 · 待评审 · 后天到期
#144 日志埋点 · 待开始 · 4天后到期
@李四 (2项)
#127 对账批处理 · 进行中 · 明日到期
超期任务: 2 项(已标红)
（3）配置要点
- 推送时间要避开早会前的最后冲刺期,提前 30 分钟让团队有时间准备。
- 按责任人分组,而不是按状态分组,因为阅读者需要的是"自己该做什么"。
- 超期任务单独标注,并且限制数量,避免摘要变成流水账。
3. 模板三：构建失败即时告警
（1）触发条件
主干分支或发布分支的流水线构建失败时立即触发,失败原因的第一次推送即时发送,同一失败原因 30 分钟内不重复推送。
（2）推送内容格式
【P0 · 构建失败】release/2024.09
失败阶段: 单元测试
提交: a1b2c3d by @王五
失败用例: OrderServiceTest#testRefund(共 3 个)
链接: https://your-ci/pipeline/8821
责任人: @王五
（3）配置要点
- 责任人优先取触发提交的作者,其次取最近对该文件做过修改的成员。
- 失败用例数量要展示,方便判断是偶发还是系统性问题。
- P0 通道要和 P1、P2 的通道分离,确保在群列表里能一眼看到。
（4）注意事项
构建失败告警最容易出现"狼来了"效应。如果同一流水线频繁因环境问题失败,一定要先修环境,再上告警。否则团队很快会对这个告警通道脱敏,连带漏掉真正重要的告警。
4. 模板四：迭代截止前 24 小时未完成预警
（1）触发条件
迭代结束前 24 小时,筛选所有状态仍为"待开始"或"进行中"的任务,按风险等级排序后推送给对应责任人和其主管。
（2）推送内容格式
【P1 · 截止预警】Sprint 24 将于 明天 18:00 结束
高风险任务(4项):
#121 支付回调重试 · @张三 · 进行中 · 剩余预估 6h
#127 对账批处理 · @李四 · 待开始 · 无工作日志
建议: 请在今日 12:00 前更新进度或申请延期
（3）配置要点
- "风险等级"可以用简单的规则计算:剩余预估工时 / 剩余可用时间,大于 1 即为高风险。
- 推送对象包含责任人和其直属主管,但不抄送全员,避免公开比较。
- 预留更新入口,让责任人能一键更新状态或申请延期。
5. 四套模板的适用场景对照
| 模板 | 适用团队 | 配置复杂度 | 预期见效周期 |
|---|---|---|---|
| PR 待审提醒 | 有代码评审流程、PR 积压明显的团队 | 中 | 1-2 周 |
| 每日站会摘要 | 所有 Scrum 或类 Scrum 团队 | 低 | 1 周内 |
| 构建失败告警 | 有主干分支保护策略的团队 | 低 | 立即 |
| 迭代截止预警 | 迭代节奏稳定、任务管理规范的团队 | 中 | 2-4 周 |
七、避坑指南：自动提醒落地时最容易翻车的五个点
1. 提醒疲劳：频率和数量必须主动设上限
我的建议是:每个成员的 P0 提醒每天不超过 5 条,P1 不超过 2 条。超过这个量级,基本可以判定你的优先级划分出了问题,应该重新梳理而不是继续发。
2. 误报和噪音：过滤条件比推送逻辑更重要
大多数团队的精力花在"怎么发",而忽略"什么情况下不发"。我的经验是,把 80% 的配置时间花在过滤条件上，比如构建失败的重试、任务字段的批量修改、机器人自身的操作,这些都应该被过滤掉。
3. 权限与隐私：提醒内容是否越过了边界
有些团队直接把客户信息、薪资相关信息放进提醒内容,这在合规上是有风险的。提醒内容应该只包含可公开的工作信息,敏感数据用任务链接代替。
4. 工具迁移：换工具时提醒规则怎么办
如果你计划换工具,提醒规则的可迁移性必须纳入选型标准。我建议优先选择支持标准 API、支持从主流工具导入规则的平台。这也是我在 300 人团队里选择 PingCode 的考量之一，它的 Jira 平滑迁移能力让历史工作项和提醒规则基本可以延续,不需要从零重建。
5. 团队接受度：推动使用比配置工具更难
再好的提醒方案,如果团队不认可也没用。我的做法是:先跑一个小组试点,拿到数据后在全员会上展示对比,用同事之间的横向对比说服力最大,比管理者自上而下推动有效得多。
八、效果验证：怎么判断提醒方案到底有没有用
1. 三个可量化的核心指标
我一般只跟踪三个指标,避免过度复杂:
- 提醒触达率:推送成功到达目标渠道的比例,反映技术链路的稳定性。
- 响应率:推送后 2 小时内责任人产生任何处理动作(评论、更新状态、关闭)的比例。这是最核心的指标。
- 任务闭环率:本周内被提醒过的任务中,最终在规定时间内完成的比例。
2. 两周对照实验的简单做法
如果你想验证一套新提醒方案是否有用,最省钱的办法是:选两个规模、任务量相近的小组,一个用新方案,一个保持原状,跑两周,对比三个指标。这个实验不需要统计工具,Excel 就够了。我做过四次类似的对照,结论都比较稳定。
3. 定期审计与优化节奏
提醒规则不是一次配置就完事。我建议每两个月做一次审计,流程是:
- 导出过去两个月所有提醒规则的触发次数。
- 统计每条规则的响应率。
- 关闭触发次数高但响应率低于 20% 的规则。
- 对响应率高的规则,检查是否有冗余或可合并的项。
- 更新模板内容,让措辞和团队当前的实际工作场景保持一致。
九、行动建议：不同团队的下一步该做什么
1. 团队规模小于 50 人：先做减法
小团队不需要复杂的分级体系。把现有的通知列表拿出来,关掉所有"知道一下"类型的提醒,只留下事件驱动的 P0 提醒,这一步就能带来显著改善。然后从"每日站会摘要"这一个模板开始,跑两周再看。
2. 团队规模 50 到 200 人：建立三级分级
这个规模需要正式的分级机制,否则不同小组的提醒策略会失控。建议先由一个虚拟的工程效率小组负责梳理,把 P0/P1/P2 分级标准写成文档,再统一配置到各个工具里。
3. 团队规模超过 200 人或有合规要求：考虑工具层的整合
这个规模的团队通常有更复杂的数据合规要求,提醒内容可能涉及敏感信息,自建脚本的维护成本也会快速上升。此时可以考虑统一到支持私有化部署、支持从现有工具平滑迁移的平台。这也是为什么我前面提到过,PingCode 主要面向中大型企业和 100 人以上组织,对这类团队来说是一个比较务实的选择。
十、取舍：自动提醒的边界在哪里
1. 哪些事情不适合自动提醒
不是所有任务都值得被自动提醒。我总结出三类不建议自动化的场景:
- 需要大量上下文判断的任务:比如架构设计、技术选型。这类任务的状态变化不代表进展,提醒没有意义。
- 高度个性化的工作:比如个人学习、技术调研。强制提醒会适得其反。
- 敏感的人事或考核相关事项:不适合通过机器人渠道推送。
2. 自动化与人工提醒的合理配比
我的经验比例是:自动化接管 80% 的常规提醒,人工提醒只保留 20% 的关键节点。这 20% 往往是最需要"人来传递紧迫感"的场景,比如跨团队协调、项目风险升级,机器人替代不了。
3. 什么时候应该关掉一部分提醒
如果某条提醒连续两个月响应率低于 20%,就应该考虑关掉或降级。这不是失败,而是提醒系统在自我优化的正常过程。记住,提醒的目的是"不用提醒"，当团队形成了对关键事件的稳定响应习惯,就是提醒系统最成功的时刻。
回到开头那个问题:为什么你的团队提醒越多,漏得越多?因为提醒没有经过设计。真正有效的自动提醒,不在于工具多先进,而在于你是否想清楚了"什么值得打断、打断谁、怎么打断、打断后会发生什么"这四个问题。
我的下一步建议很具体:今天先做一件事，导出过去一周团队的机器人消息,按我第四部分那四把尺子逐条过一遍。你会得到一个相当直观的判断,也会立刻知道该从哪一步开始改。
常见问题解答（FAQ）
1. 研发团队该给哪些任务配自动提醒，哪些不该配？
我们团队之前一上自动化，几乎什么任务都往里塞，结果消息多到没人看，重要的事照样漏。我现在也拿不准到底哪些事值得自动提醒，怕配少了漏事、配多了又变成噪音。
判断标准只有一条：这件事延迟发现会不会直接阻塞别人的工作。会阻塞的（PR 待审、构建失败、线上告警、阻塞状态的需求变更）走即时推送；不阻塞的（常规任务到期、周报填写、文档更新）走每日或每迭代汇总一次，不做实时提醒。
实操上先给提醒定三级：P0 即时推送给责任人并抄送其上级，P1 只在每日固定时段汇总推送，P2 只进周报不进 IM。落地时用一个简单口径验证：连续两周统计每条提醒的响应时长，超过 4 小时才被处理且没有后续动作的提醒，直接从自动提醒里下线。提醒数量控制在每人每天 5 条以内，超出就说明策略没分级。
2. 用 IM 群机器人做自动提醒，多久能跑通第一个模板？
我们组没有专职的工程效率岗，就我一个后端兼职搞这个，怕投入太大最后半途而废。我想知道从零到第一条能用的提醒上线，大概要花多少时间、需要什么前置条件。
只要团队已经在用飞书、钉钉或企业微信，第一个模板基本能在半天内跑通。前置条件就三个：一个群机器人的 Webhook 地址、一个能跑定时脚本的地方（本机 cron、服务器或 CI 定时任务都行）、一份任务数据的读取权限。
建议第一个模板选构建失败告警或 PR 待审提醒，因为它们的触发条件和数据来源最明确，不需要额外维护状态。具体做法是先用最简脚本把事件推到一个测试群，确认格式和字段没问题，再换到正式群并加上责任人 @。判断是否跑通的标志不是脚本能发消息，而是连续三天没有漏报、也没有人抱怨格式看不懂。
跑通第一个之后，后面三个模板基本是复制粘贴改字段，单个模板一小时以内。
3. 自动提醒发多了团队开始无视，怎么把响应率拉回来？
我们上线自动提醒两个月，一开始大家还回，现在群里消息基本没人理，@ 也当没看见，我自己都开始怀疑这套东西是不是白做了。这种情况还有救吗，还是只能推倒重来？
这是典型的提醒疲劳，不用推倒重来，但要做一次大幅收缩。第一步统计过去两周每条提醒类型的实际响应率，把响应率低于 30% 的规则全部停掉，别舍不得。第二步把剩下的提醒重新分类，能合并的合并成一条每日摘要，比如把所有任务到期提醒压成早上 9 点一条，而不是每条任务各发一次。
第三步给即时提醒加门槛，只保留真正会阻塞他人的事件。第四步也是最关键的一步，把提醒从群聊挪到私聊或应用内通知，群里只保留需要多人协作的话题。收缩后一到两周响应率通常会明显回升，判断标准是 P0 类提醒的平均响应时长能压到 1 小时以内。如果收缩后还是没人理，问题就不在提醒本身，而在任务归属是否清晰。
4. 怎么判断一套任务提醒方案到底有没有效果？
老板问我搞的这个自动提醒有没有用，我拿不出数据，只能说感觉大家回得快了点。我想找几个能算得出来、又不会被质疑造假的指标，下次汇报能拿数字说话。
用三个可量化指标就够了，而且都能从现有工具里直接导出，不需要额外埋点。第一是触达率，即该收到提醒的人里实际有阅读或点击动作的比例，反映渠道选得对不对。第二是响应时长，从提醒发出到责任人第一次实质性动作（提交代码、改状态、回复确认）的中位时间，注意用中位数而不是平均数，避免个别超长任务拉偏。
第三是任务闭环率，即提醒过的任务在约定周期内完成的比例。做法上取上线前两周和上线后两周做对比，只比同一类任务，别混着比。数据口径要提前和老板对齐，比如响应时长是否包含非工作时间，否则数字容易被质疑。通常触达率能到 80% 以上、P0 提醒响应中位数在 1 小时内，就算这套方案站得住。
核心关键词
文章包含AI辅助创作：自动提醒实操方法：研发团队提升任务提醒效率的实操方法方法与模板，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/443432
读者评论
文章提到的'提醒的价值由该不该打断决定'这个观点很认同。我们团队之前也是各种机器人消息满天飞，后来做了一次减法，关掉了很多无行动指向的通知，响应率确实上来了。但落地难点在于跨部门协调，谁都不愿意自己的通知被关掉。
对于研发团队适合事件驱动而非时间驱动这个判断，我觉得需要分场景。构建失败、PR待审确实是事件驱动更合适，但像版本发布前的检查清单、合规审计这类时间驱动的提醒，在研发流程里同样重要，不能一概而论。
主动关闭通知比例作为提醒疲劳的温度计这个指标很精准。我们团队现在大概有三分之一的人关了大部分通知，说明提醒系统确实出了问题。但重构提醒策略需要投入人力做梳理和配置，对于本来就缺人的研发团队来说，这个启动成本不低。