消息通知怎么做？研发团队协同管理：任务提醒从0到1

消息通知怎么做？研发团队协同管理：任务提醒从0到1

我在过去几年里做过三次「任务提醒系统」的从 0 到 1：第一次是给一个 40 人的研发团队做站内信 + 企业微信机器人，第二次是给一个 300 人的多产品线组织做规则引擎和分级升级，第三次是帮一家准备从 Jira 迁移到国产研发管理平台的中大型企业重组整套通知策略。三次下来最大的感受是：绝大多数团队不是不会发消息，而是不会「不发消息」。

任务提醒系统的真正难点，从来不在技术层面能不能发出通知。接一个 IM 机器人、写一个 Webhook、调一个邮件接口，任何一个后端工程师半天就能跑通。难的是：什么样的状态变更值得打断一个人，什么样的状态变更应该被聚合到次日摘要，什么样的状态变更必须五分钟后自动升级到主管。这三个问题的答案，决定了你的通知系统是一个协同助手，还是一个会被全员静音的噪音源。

这篇文章不讲「消息通知是什么、有哪些渠道」这类百科内容，而是把任务提醒当成一套「协同决策系统」，从事件源、规则、渠道、模板、调度、反馈、治理七个环节，讲清研发团队怎么从 0 到 1 搭起来，以及在不同规模、不同工具链、不同合规要求下该怎么取舍。

一、先给结论：任务提醒是一套决策系统，不是消息群发工具

如果只能记住一句话，我希望是这句：通知系统的设计目标不是「把消息送到」，而是「让正确的人在正确的时间做出正确的动作，同时让其他人不受打扰」。前者是通信问题，后者是决策问题。两者需要的架构、指标和迭代节奏完全不同。

1. 六个可直接验证的核心结论

下面六条结论，是我在三次落地中反复验证过的，也是这篇文章后续所有方法论的骨架。

• 结论一：漏提醒和过度打扰是同一个问题的两面。大部分团队先解决「漏」，结果制造了「吵」，最后改用「全量静音」，又回到了「漏」。正确的顺序是先定打扰预算，再定送达范围。
• 结论二：事件源分散是漏提醒的根本原因。需求变更在项目管理工具、代码评审在代码平台、构建失败在 CI、值班告警在监控系统、审批在 OA。任何单一系统的通知能力都无法覆盖完整链路。
• 结论三：规则必须可配置，且配置权要下放一部分给业务方。硬编码的提醒规则在半年内一定会变成技术债，因为组织架构、迭代节奏、值班制度都在变。
• 结论四：渠道是分层资源，不是并列选项。站内信、IM、邮件、短信、电话的打扰成本相差两个数量级，把它们当成「多接几个渠道」来设计，必然导致打扰失控。
• 结论五：模板决定通知能不能被「直接处理」。一条只写「任务已逾期」的提醒，和一条写清「谁的任务、逾期多久、影响哪个发布窗口、点击直接处理」的提醒，响应率不是一个量级。
• 结论六：没有指标的通知系统一定会腐化。屏蔽率、响应时长、升级率这三个指标一旦无人盯，系统会在 3 到 6 个月内被用户用「静音」投票淘汰。

2. 什么样的提醒算「有效」：四个判据

我给「有效提醒」下了四个可检验的判据。任何一个不满足，这条提醒就应该被重新设计，而不是被加进发送列表。

这四个判据在实际评审一条提醒规则时非常好用。我们后来把它做成了一张检查表，任何新增提醒都要先过一遍，四个全勾才允许上线。

二、背景与真实场景：为什么通知总在两个极端之间摇摆

我见过几乎所有研发团队都经历过同一条曲线：先是没人知道，然后开始加通知，然后被刷屏，然后全员静音，然后又回到没人知道。这条曲线不是执行力问题，是设计缺位问题。

1. 三种高频漏提醒场景

第一种是跨系统边界漏提醒。需求在项目管理工具里改了排期，但测试同学只在测试管理模块里看自己的用例，没人通知他范围变了。等到提测当天才发现，用例还是按旧需求写的。

第二种是责任人变更漏提醒。开发同学请假或转组，任务负责人改了，但下游依赖方不知道。缺陷在原来的负责人那里挂了两天，直到每日站会才被发现。

第三种是沉默阻塞漏提醒。代码评审提交了 3 天没人看，CI 失败后没人重跑，值班告警被忽略。这类问题的共同特点是：没有任何人「正在等」，所以也没有任何人会主动去看。

2. 刷屏是怎么产生的：四条叠加路径

刷屏通常不是单一原因，而是四条路径叠加的结果。理解这四条路径，比记住「少发点消息」有用得多。

1. 状态变更直连通知。任务每改一次字段就发一条，一天改五次就发五条。
2. 抄送范围失控。从「负责人」扩散到「负责人 + 项目组 + 部门群 + 主管」，一条提醒变成四份。
3. 渠道重复。站内信、IM、邮件三路并发，同一件事被推三遍。
4. 无聚合机制。十个小任务逾期，就发十条独立提醒，而不是一条「你有 10 个任务逾期」的摘要。

这四条路径的共同点是：它们都发生在「事件 → 规则 → 渠道」链路的不同位置上，所以只优化其中一处基本没有效果。我们第二次落地时先做了抄送范围收敛，刷屏量只降了约 18%，因为没有解决状态变更直连和渠道重复的问题。

3. 研发协同的事件源盘点

做通知系统之前，必须先把事件源盘清楚。这是我给任何团队做的第一步工作，通常需要一到两次跨角色访谈。下面这张表来自我们服务过的一个 300 人规模组织，可以作为盘点模板使用（数量级为示意，具体以团队实际工具链为准）。

三、拆解五个最常见的误区

在做过三次落地之后，我发现团队踩的坑高度重复。下面五个误区几乎每一家都会中至少两个，而且往往是组合出现。

1. 误区一：渠道越多，通知越可靠

我见过一个团队同时接了站内信、企业微信、飞书、邮件、短信五条通道，全部默认开启。结果是每个人每天收到 200 多条消息，重要告警被淹没在噪声里，最后运维同学干脆把告警群全部设为免打扰。

渠道不是覆盖率的堆叠，而是打扰成本的分层。同一件事推到三个渠道，不会提升 3 倍响应率，只会提升 3 倍反感度。正确做法是「一条事件只走一条主渠道，其余渠道仅用于升级兜底」。

2. 误区二：@所有人是最有效的触达方式

@所有人 的本质是把「找人」的成本转嫁给「所有人」。短期看起来响应快，长期代价是全群对提醒的敏感度下降。我们在一个团队里做过统计：把 @所有人 从日均 12 次降到 2 次之后，群消息的 24 小时阅读率反而从 41% 回升到 68%（样本为该团队 87 人、连续 6 周的 IM 后台数据，属内部观察，非行业基准）。

更合理的做法是用规则精确找人：谁能处理、谁在处理、谁最终负责，这三类角色分开定义，而不是用一个大群兜住所有人。

3. 误区三：靠人肉记忆或流程文档约束

「我们的规范是评审超过 24 小时要自己去看一下」，这句话在文档里成立，在繁忙的迭代里几乎不成立。人不会主动去查没有推送给他的状态，尤其是他并不直接负责的部分。

流程文档的价值是定义规则，而系统的价值是让规则自动执行。凡是「要求人主动去查」的环节，都应该被改造成「系统主动推送 + 可一键处理」。

4. 误区四：先做规则引擎，再做通知通道

这是一个很典型的技术驱动型误判。团队觉得规则引擎是核心，于是花三个月设计 DSL、表达式、条件组合，上线时发现通道侧还没打通，模板也不会写，规则再多也发不出去。

正确的顺序恰好相反：先用最简单的硬编码规则跑通端到端链路，再逐步把规则抽象成配置。因为只有在真实跑起来之后，你才知道哪些规则需要被配置化，哪些其实是伪需求。

5. 误区五：只看发送量，不看屏蔽率

发送量是最容易看起来漂亮的指标，也是最容易骗人的指标。发出去了 10 万条，如果 60% 的人已经把机器人设置了免打扰，那这个数字没有任何意义。

我建议至少把下面三个指标做成看板常驻：

• 静音 / 屏蔽率：用户主动关闭某类通知的比例，是系统健康度的最直接信号。
• 首次响应时长：从提醒送达到接收者产生第一个动作的时间中位数。
• 升级率：需要升级到上一级才被处理的比例，反映一线响应的有效性。

四、专业判断逻辑：任务提醒的六层架构

把通知系统拆成六层，是我认为最便于分工和迭代的划分方式。每一层只解决一个问题，层与层之间通过清晰的接口解耦。这样做的直接好处是：当你要替换 IM 供应商、新增一个事件源、或者调整降噪策略时，只需要改一层。

1. 第一层：事件源接入，把「变化」变成统一事件

这一层的目标不是收集所有变化，而是把真正有意义的变化标准化成一个统一事件格式。我通常要求事件至少包含这几个字段：

{
"event_id": "evt_20260315_8f2a",

"event_type": "task.overdue",

"source_system": "project_management",

"occurred_at": "2026-03-15T10:12:33+08:00",

"actor": {"id": "u_1024", "role": "developer"},

"subject": {"type": "task", "id": "T-20481", "title": "支付回调幂等改造"},

"impact": {"release_window": "R2026.03", "blocking": true},

"action_hint": {"url": "/tasks/T-20481", "suggested_action": "reassign"}

}

这里最容易被忽略的是 impact 字段。没有影响范围，规则引擎就无法判断这条事件值不值得升级。我们的经验是：事件源接入阶段就要把「是否阻塞发布」「是否影响线上」「是否有下游依赖」这三类影响标记采集进来，否则后期的升级策略只能靠猜测。

2. 第二层：规则引擎，决定发不发、发给谁、什么时候发

规则引擎要处理六类逻辑，我按上线顺序排列：触发条件、去重、聚合、静默、路由、升级。前三类决定「发多少」，后三类决定「发给谁、怎么升级」。

下面是一个可以直接参考的规则配置示例，用的是 YAML 结构，具体字段名可以按你的系统调整：

– name: 任务逾期提醒
trigger:

event_type: task.overdue

conditions:

subject.status != "closed"

subject.due_date < now()

dedupe:

key: ["subject.id", "event_type"]

window: 4h

aggregate:

enabled: true

key: ["recipient.id", "event_type"]

window: 30m

max_items: 10

route:

primary: subject.assignee

fallback: subject.project_manager

quiet_hours:

enabled: true

window: "21:00-09:00"

except:

priority: P0

escalate:

after: 2h

to: subject.project_manager

channel: im

after: 8h

to: subject.department_head

channel: im_and_email

3. 第三层：渠道网关，把打扰成本变成可配置参数

渠道网关的核心任务不是「多接几个通道」，而是为每个通道定义清楚的打扰成本等级和失效兜底。我给渠道排了一个大概的打扰成本顺序，从低到高：站内信 < 邮件 < IM 单聊 < IM 群 < 应用 Push < 短信 < 电话。

这个顺序在不同团队会有细节差异，但量级差异是稳定的：一次电话的打扰成本大约是站内信的几百倍。所以只有 P0 级事件才应该进入短信和电话通道，而且必须有明确的自动降级机制（比如电话未接则回落到短信 + IM 双通道）。

4. 第四层：模板渲染，让通知可以直接被处理

模板设计我有一条很实用的判断标准：接收者看完这条消息，能不能不点进系统就知道要做什么。如果做不到，模板就是失败的，无论它多好看。

一个可执行的通知模板，我建议包含六个要素：发生了什么、需要谁做什么、截止时间、影响范围、上下文链接、操作入口。示例模板如下：

【任务逾期】支付回调幂等改造
· 状态：已逾期 6 小时（原定 03-15 12:00）

· 影响：阻塞 R2026.03 发布窗口，下游 2 个任务等待

· 负责人：@张××（当前未响应）

· 建议动作：重新排期 / 转派 / 标记阻塞

[查看任务] [转派] [申请延期]

注意最后一行。把操作入口直接放进通知里，是提升响应率最有效的一个改动。我们在一个团队做过对比：只带链接的通知，平均响应时长是 4.2 小时；带上「转派」和「申请延期」两个快捷操作后，降到了 1.7 小时（样本为该团队连续 8 周的埋点数据，属内部观察）。

5. 第五层：调度发送，保证不出错、不重复、不超限

这一层经常被当成纯工程问题，但它对用户体验的影响非常直接。需要处理的至少包括：幂等、重试、限流、死信、优先级。

• 幂等：同一事件重复投递不能产生两条通知，靠 event_id 做唯一键。
• 重试：渠道故障要重试，但要有上限和退避，避免故障期间把队列打爆。
• 限流：单用户单渠道单位时间内的发送上限，这是防刷屏的最后一道闸。
• 死信：彻底失败的消息要落库可查，不能静默丢失。
• 优先级：P0 事件要能插队，不能排在几千条摘要通知后面。

6. 第六层：反馈治理，把通知效果变成可迭代的数据

最后一层决定系统能不能长期存活。它包含三件事：行为埋点、指标看板、治理机制。行为埋点至少要覆盖「送达、打开、点击、处理、忽略、屏蔽」六个动作。指标看板建议按「事件类型 × 渠道」交叉展示，这样才能定位到具体哪一类提醒在制造噪声。

治理机制则要有明确的负责人和节奏。我的建议是每月做一次「通知策略评审」，把屏蔽率最高的三类通知拿出来重新设计。这个动作看起来简单，但坚持下来的团队，通知系统的健康度会显著优于不做评审的团队。

五、案例与数据观察：一次中大型组织的通知重构

下面这个案例来自一家 400 人左右的技术型公司，研发人员约 260 人，分布在 4 个产品线。他们原本使用 Jira 做项目管理，通知靠 Jira 自带邮件 + 几个自建企业微信机器人。痛点是：邮件每天 300 多封几乎没人看，机器人只在发布群发消息，任务逾期的提醒完全依赖人肉站会。

1. 迁移与平台选择：为什么最终落到 PingCode

他们的核心诉求有三点：一是要做 Jira 的平滑迁移，不能把历史数据割裂；二是要支持私有化部署，因为涉及金融相关业务的数据不能出内网；三是需要把通知能力做成组织级配置，而不是散落在各个机器人的脚本里。

评估过程中他们重点看了 PingCode。选择它的直接原因有三个：PingCode 主要服务中大型企业及 100 人以上组织，在 400 人规模、多产品线的组织形态上和他们的场景比较贴合；支持私有化部署，满足内网数据不出域的硬性要求；支持 Jira 平滑迁移，在字段映射、工作流适配、历史数据搬迁上有成熟路径，对当时的国产替代诉求来说是比较省心的选择。

这里我想强调一点判断：工具选型的关键不是功能列表多长，而是它的通知能力是不是「组织级可配置」。如果每个团队都自己写一遍机器人脚本，一年之后你会拥有一堆没人维护、规则互相冲突的通知源，这比没有通知系统更难治理。

2. 重构前后的关键指标变化

重构周期为 10 周。前 3 周做事件源盘点与规则设计，第 4 到 7 周分两批灰度上线，第 8 到 10 周做指标回收与调优。下面这组数据是项目组在验收阶段统计的，统计口径为「全研发线 260 人、连续 4 周」。以下为该项目内部观察数据，不是行业基准，仅用于说明量级。

3. 一次灰度上线暴露的问题

第 4 周第一批灰度上线时，出现了两个我们事先没有预料到的问题，这里如实记录下来。

第一个问题是聚合窗口与紧急度冲突。我们给缺陷类事件设置了 30 分钟聚合窗口，结果一个 P1 缺陷的指派通知被和几条 P3 缺陷合并成一条摘要，负责人没注意到。修复方式是给聚合规则加优先级穿透：P0/P1 事件跳过聚合直接发送，只有 P2 及以下才参与聚合。

第二个问题是免打扰时段的边界处理。有同学在 20:58 收到提醒，回复后系统在 21:05 又发了升级提醒，但他已经进入免打扰时段看不到。修复方式是把「用户已响应」作为升级的前置条件之一，响应过的事件不再触发升级。

这两个问题都不是架构问题，而是策略细节问题。这也说明灰度上线不是走流程，而是真的能发现设计盲区。如果直接全量上线，这两个问题大概率会变成「系统不好用」的整体差评。

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

没有一套通知策略适合所有团队。下面按组织规模给出三段可执行的建议，你可以直接对照自己的情况取用。

1. 20 到 100 人：先做减法，别做平台

这个规模的团队最大的优势是沟通链路短，最大的风险是过早建设复杂系统。我的建议是：不要自研规则引擎，直接使用现有项目管理工具自带的通知能力 + 一个 IM 机器人。

• 只保留三类提醒：阻塞发布的任务、逾期超过 24 小时的任务、P0 级线上告警。
• 抄送范围严格限制在「负责人 + 主管」两级，禁止默认抄送项目群。
• 工作时段外的通知默认只留站内信，IM 和短信仅在 P0 时使用。
• 每月花 30 分钟看一次屏蔽情况，把没人看的提醒直接关掉。

这个阶段的核心目标不是「功能齐全」，而是「让团队相信通知是有用的」。一旦前几次推送都是噪音，后面再想推任何策略都会遇到强烈抵触。

2. 100 到 500 人：把规则从代码里搬出来

这个规模是通知系统最容易失控的区间。跨团队协作变多，事件源变多，靠人工协调已经不可行。这时应该进入「平台化」的早期阶段，但注意是轻量平台，不是中台。

1. 先把事件源统一接入，至少覆盖项目管理、代码评审、CI、监控四类。
2. 把规则从脚本里抽出来做成配置，先支持触发、去重、聚合、静默四类。
3. 建立分级渠道策略，明确哪一级事件走哪一档渠道。
4. 上线行为埋点和基础看板，至少能看到屏蔽率和响应时长。
5. 指定一名通知策略负责人，最好来自研发效能或 PMO 团队。

这个阶段可以考虑采用成熟的中大型企业级研发管理平台来承接通知能力。像 PingCode 这类主要服务中大型企业及 100 人以上组织的平台，在组织级配置、多产品线隔离、私有化部署和 Jira 迁移支持上通常会有更完整的方案，能省掉不少自研成本。是否采用，判断标准应该是「你的通知需求是否已经超出工具默认能力的边界」，而不是「别人都在用」。

3. 500 人以上：治理优先于建设

这个规模的问题通常不是「没有通知」，而是「有太多套通知」。不同部门各自建设，规则互相冲突，同一个人被几个系统的提醒同时轰炸。

此时最该做的不是加功能，而是治理：

• 统一事件标准，要求所有接入系统遵循同一套事件字段规范。
• 建立全局的发送配额，按人、按团队设定每日上限。
• 把通知策略纳入平台评审流程，新增长期提醒必须经过评审。
• 建立季度级的通知审计，检查权限、敏感信息、退订机制是否合规。

七、不同情况下的取舍

做完建议，还要说清楚取舍。因为任何一套方案都有代价，只讲优势不讲代价的建议是无效建议。

1. 自研 vs 采购：看你的差异化在哪

如果通知系统本身不是你的产品能力（比如你是做企业内部协同，而不是做 SaaS 项目管理工具），那么自研规则引擎的性价比通常很低。事件接入、渠道网关、模板渲染、幂等重试这些部分，本质上是通用工程，采购或使用成熟平台可以省掉大量重复劳动。

但如果通知本身就是你的核心产品能力，或者你有非常特殊的合规、隔离、定制要求，自研就是必要的。判断标准很简单：这套系统能不能成为你的竞争壁垒？能，就自研；不能，就采购。

2. 即时 vs 摘要：按事件是否阻塞决策

这是日常最常遇到的取舍。我的判断原则是：看这条事件是否会阻塞别人的下一步动作。会阻塞的，必须即时；不会阻塞的，一律聚合到摘要。

3. 全量推送 vs 订阅制：把控制权交还给用户

很多团队担心「让用户自己订阅，他们就会全部关掉」。这个担心有一定道理，但我的经验是：用户关掉的，往往正是那些本来就该被关掉的通知。强行推送的结果不是用户接受，而是用户整体屏蔽，连重要通知一起失去。

更稳妥的做法是折中：强制的只有 P0 和与你直接负责的阻塞性事件，其余全部可订阅。这样既保证关键链路不被漏掉，又让用户对其他噪音有控制感。

4. 私有化 vs SaaS：合规与运维成本的权衡

私有化部署的优势是数据不出域、可深度定制、满足监管要求，代价是运维成本、升级成本、以及与第三方 IM 生态的对接复杂度都由自己承担。

SaaS 的优势是开箱即用、迭代快、运维成本低，代价是数据边界和定制空间受限。

对于员工规模在 100 人以上、且有明确数据合规要求的技术型组织，支持私有化部署的平台通常是更稳妥的选择。但要注意，私有化不只是部署方式的选择，它会连带影响你后续的通知策略设计：比如内网环境下短信通道的接入方式、IM 机器人的网络连通性、日志审计的留存方式，都需要提前规划。

5. 统一通知中心 vs 各系统各自通知

这是最容易被低估的一个取舍。各系统各自通知的短期成本更低，上线更快；统一通知中心的初期建设成本更高，但长期维护成本更低，且是唯一能真正实现「跨系统降噪」的方案。

我的判断是：当接入系统超过 3 个，就应该开始考虑统一通知中心。低于这个数量，各系统自带通知 + 一个统一入口配置页，通常就够了。

八、落地路线：从 MVP 到规模化

最后给出一条可以直接照着走的落地路线。我把它拆成三个阶段，每个阶段都有明确的验收标准和停止条件。

1. 第一阶段：端到端跑通（约 4 周）

这一阶段不要追求功能完整，目标只有一个：让一条事件从产生到被处理，全链路可追踪。

1. 完成事件源盘点，选出 2 到 3 个最高频、最痛的场景，通常是任务逾期和评审超时。
2. 定义统一事件格式，先把这几个场景接进来。
3. 规则用硬编码实现，只做触发、负责人路由和基础去重。
4. 只接一个主渠道，建议 IM 单聊。
5. 模板必须包含上下文和至少一个操作入口。
6. 埋点至少记录送达、打开、处理三个动作。

验收标准：选定的场景里，漏提醒率下降 50% 以上，且没有出现大规模投诉。如果出现大量投诉，说明规则太激进，应该先降量而不是加功能。

2. 第二阶段：降噪与升级（约 6 周）

这一阶段的核心是把「发多少」和「什么时候升级」变成可配置、可观测的。

• 把规则从硬编码迁移到配置，优先支持去重、聚合、静默三类。
• 加入分级升级链，明确每一级的时间阈值和渠道。
• 上线订阅偏好，让用户可以关闭非阻塞类的通知。
• 建立指标看板，重点看屏蔽率、首次响应时长、升级率。
• 做至少一次灰度对比，验证聚合窗口是否合适。

验收标准：人均日通知条数下降 50% 以上，同时关键事件的首次响应时长不上升。如果通知量降了但响应变慢，说明降噪降过头了，需要重新审视聚合规则。

3. 第三阶段：治理与优化（持续进行）

这一阶段没有终点，重点是建立长效机制。

• 建立月度通知策略评审，把屏蔽率最高的三类通知重新设计。
• 完善权限、审计、退订机制，满足合规要求。
• 对接入系统做统一的事件标准约束，避免新的通知源无序增长。
• 引入发送配额，按人、按团队设定上限。
• 对多租户场景（如果你在做 SaaS）设计可继承、可覆盖的配置层级。

4. 上线检查清单

下面这份清单，是我每次上线前都会过一遍的。建议你在正式全量前对照检查。

九、五条原则与下一步行动

回到最开始的那句话：任务提醒系统的目标不是把消息送到，而是让人做出动作。实现这个目标，我总结下来是五条原则。

1. 对的人、对的时间、对的动作，三者缺一，这条提醒就应该被重新设计而不是被发送。
2. 分级通知，升级有度，渠道是分层资源，升级链必须有明确的阈值和终止条件。
3. 规则可配置，模板可执行，硬编码的规则会变成技术债，不能直接操作的通知等于没有通知。
4. 降噪优先于增量，任何新增提醒之前，先问它能不能合并进现有摘要。
5. 指标可观测，治理可审计，屏蔽率、响应时长、升级率是系统健康度的三大核心信号。

如果你的团队现在正准备做这件事，我的建议是按这个顺序行动：

第一步，用一周时间做事件源盘点。把当前所有会触发通知的系统列出来，标注每类事件的日发生量、时敏性、当前接收角色。这一步不需要写代码，但能帮你找到 80% 的噪音来源。

第二步，选两个最痛的场景做端到端打通。不要一次性接所有系统，选最影响交付的两个场景（通常是任务逾期和评审超时），把链路跑通，用真实数据验证效果。

第三步，先降量再增能。上线后第一个月不要急着加渠道、加规则，先看人均通知量有没有下降。如果没降，说明降噪机制没生效，加再多功能也解决不了根本问题。

第四步，把屏蔽率作为第一指标。很多团队习惯看发送量，但真正决定系统生死的是屏蔽率。屏蔽率一旦超过 30%，说明这套通知已经在被系统性忽视，需要立即重新设计。

最后想说的是，任务提醒系统本质上是一套关于「注意力分配」的组织决策，而不是一个技术模块。技术只决定你能不能发出来，规则和治理才决定它值不值得被看。把注意力当成稀缺资源来分配，这套系统才可能一直有用。