去年冬天，我帮一家做工业 SaaS 的研发团队做协作流程复盘。他们 CTO 给我看了一张截图：团队自研的提醒机器人当天往项目群里推了 417 条消息，其中真正被点开处理的只有 63 条，处理率 15.1%。更扎心的是，有 4 个 P0 级线上缺陷的升级提醒被淹没在"任务即将到期""评论有新回复""状态已变更"的洪流里，最长的一条躺了 9 个小时才被人看到。CTO 说了一句让我记到现在的话："我们不是没做提醒，我们是把提醒做成了噪音。"
这件事几乎浓缩了"任务提醒如何做好消息通知"这个问题在研发团队里的全部难点。绝大多数团队并不缺发送能力，缺的是一套能判断"什么该发、发到哪、发几次、谁负责、出错怎么办、怎么验证有效"的制度设计与操作路径。我过去六年陆续参与过二十多个研发团队的通知体系改造，从十几人的创业小队到 300 人以上的中大型研发组织都见过，踩过的坑和验证过的方法都在这篇里。下面我按结论、场景、误区、判断逻辑、案例数据、行动建议、取舍七个层次讲清楚。
一、先给结论：做好任务提醒通知，是把"发送"升级成"六段链路治理"
如果只让我给一句话结论：任务提醒通知做不好的根因，几乎从来不是渠道不够多、工具不够强，而是没有把"通知"当成一条有起点、有终点、可度量、可兜底的链路来治理。大多数团队停留在"触发即发送"的单点思维，而有效的做法是把整件事拆成六段：触发，渠道，频率，责任，兜底，复盘。
1. 六段链路各自要解决的核心问题
我把它整理成一张对照表，这六段是全文的骨架，后面所有章节都是围绕它展开的。
| 链路环节 | 要回答的核心问题 | 典型失败表现 |
|---|---|---|
| 触发 | 什么事件值得触发一条通知？ | 所有状态变更都发，噪声爆炸 |
| 渠道 | 这条通知应该走哪个通道触达？ | 全部走 IM，重要信息被稀释 |
| 频率 | 同一对象多久提醒一次？如何合并？ | 无上限重复，用户直接屏蔽 |
| 责任 | 谁配置规则、谁维护、谁兜底？ | 规则写死在代码里，没人认领 |
| 兜底 | 漏发、重复、发送失败怎么办？ | 无监控，出了问题靠人反馈 |
| 复盘 | 怎么判断通知是否真的有效？ | 只看"发了多少条"，不看"处理了多少" |
这六段里，触发和频率决定"噪声下限"，责任和兜底决定"系统能不能长期活着"，复盘决定"它会不会越用越好"。很多团队只优化了第一段和第三段，所以短期有效、长期崩坏。
2. 为什么是"治理"而不是"配置"
我刻意用"治理"这个词。配置是一次性动作，治理是持续过程。研发团队的组织结构、项目节奏、人员流动都在变，一套三个月前好用的提醒规则，三个月后可能就失效了。我见过太多团队把通知当成"上线一次就完事"的功能，结果半年后规则烂成一片，没人敢动。
还有一个反常识的点：减少通知数量，往往比提升通知质量更能立竿见影地改善效果。前面那个 417 条消息的团队，我们做的第一件事不是优化文案，而是砍掉了 60% 的触发源，处理率直接从 15.1% 跳到 41%。原因很简单，人的注意力是有限资源，删掉干扰项比美化每一项的边际收益高得多。
二、真实场景：研发团队的任务提醒为什么天然难做
要理解为什么这件事难，得先看清研发团队和普通职能团队在通知场景上的本质差异。这不是"研发比较特殊"的客套话，而是几个结构性事实叠加的结果。
1. 研发团队的三重结构性矛盾
第一重是深度工作与即时响应的矛盾。研发做的是需要连续专注的脑力工作，一次上下文切换的恢复成本，业界普遍引用的观察是 15 到 25 分钟才能重新进入状态。一条不合时宜的提醒，代价不是 3 秒，而是可能打断一整段心流。
第二重是信息量大与注意力有限的矛盾。一个 50 人的研发团队，每天产生的任务状态变更、评论、提交、构建结果、缺陷流转动辄上千条。全发是灾难，不发又怕漏。
第三重是责任分散与要求明确的矛盾。通知的"有效性"需要有人负责，但配置通知的往往不是用通知的人，维护通知的又常常不是配置通知的人，责任链条天生就容易断。
2. 一个典型的日常切面
我观察过一个 80 人研发团队的普通工作日：早上 9 点站会前，群里先涌入一批"任务今日到期"提醒；上午开发时段，"代码评审被指派""构建失败"的消息穿插进来；下午密集提交时，"状态流转""评论回复"持续轰炸；临下班又是一批"明日到期预告"。到晚上，值班同学还会收到"未处理升级"。
把这些按来源归类后你会发现，真正需要"立即响应"的不到两成，绝大多数属于"知道就好"或"批量处理即可"。团队不是不会发通知，而是把所有通知都按同一个紧急级别发，等于没有分级。
3. 为什么"人肉提醒"总在早期有效、后期失效
很多团队早期靠项目经理在群里 @ 人维护进度，短时间看确实有效。但它有两个致命问题：一是强依赖个人，项目经理休假或离职，提醒就断；二是不可复制、不可扩展，项目一多，人就盯不过来。这正是要从"人肉"过渡到"制度+工具"的原因，也是本文后半部分操作步骤存在的意义。
三、拆解常见误区：八个让通知越做越差的做法
在讲正确方法前，先把坑说透。下面八个误区是我在复盘里出现频率最高的，几乎每个失控的通知体系都能对号入座。
1. 误区一：所有提醒都走同一个渠道
把 P0 故障、日常到期、评论回复全部塞进项目群，是最常见的做法，也是最致命的。结果是重要信息被平均稀释，用户对整条渠道脱敏。渠道分层的本质是"用不同的打扰成本匹配不同的重要程度"。
2. 误区二：提醒频率没有上限
"任务快到期了，每 2 小时提醒一次"，听上去很负责，实际上是逼用户屏蔽。没有合并、没有静默、没有升级上限的重复提醒，会把用户训练成"看到就忽略"。
3. 误区三：制度写了，但没人维护
我见过一份写得非常漂亮的《通知规范》，整整 12 页，但没人知道规则配置在哪里、改了谁审批、过期了谁清理。半年后，规则库里躺着 200 多条互相冲突的规则。没有明确责任人的制度，等于没有制度。
4. 误区四：把"催办"当"提醒"发
这是我特别想强调的一点。提醒和催办是两回事，前者是信息同步，后者是责任触发，二者混用会造成两个问题：该硬的地方不够硬，该软的地方太打扰。
5. 误区五：只统计"发了多少条"
把发送量当 KPI，是方向性错误。发得多不代表做得好，很可能代表噪声大。真正该看的是处理率、闭环率、漏提醒率。
6. 误区六：规则写死在代码里
规则写死意味着每调整一次都要改代码、走发布，成本极高，最终没人愿意调整。规则必须可配置，这是工程上的基本共识。
7. 误区七：忽略发送失败和漏发
通知链路会失败，接口超时、额度限制、用户离职导致接收方失效、时区问题。没有失败监控和重试兜底，问题只能靠"事后被发现"，而漏掉的往往是关键的。
8. 误区八：上线即终点
通知系统是活的，需要定期复盘和调优。上线后不再迭代，等于放任它慢慢腐化。
四、专业判断逻辑：从"发送"到"闭环"的五个决策点
误区讲完，进入判断逻辑。我在给团队做咨询时，从不直接给方案，而是先帮他们过五个决策点。这五个决策点理顺了，具体怎么配置就是水到渠成的事。
1. 决策点一：这条通知，用户"必须现在知道"吗？
这是所有触发的第一道闸门。我会让团队对每个触发源问三个问题：不知道会不会出事？现在不知道、一小时后知道行不行？批量知道行不行？三个问题里但凡有一个答案是"行"，这条通知就不该走即时渠道。
判断标准可以收敛成一句话：只有"延迟知晓会导致不可逆损失"的事件，才配得上即时打断。线上故障、阻塞他人工作的依赖、临近的关键截止，属于这类；状态流转、普通评论、构建成功，不属于。
2. 决策点二：用户"应该在哪"看到它？
渠道选择不是按喜好，而是按"打扰成本的阶梯"。我通常把渠道分成四级，从高到低：
- 强打断级：电话、专项告警通道。只留给 P0 级、影响线上、需要立即拉起人的事件。
- 即时通信级：IM 定向消息或专属告警群。用于需要当日响应的评审、到期、阻塞。
- 待办聚合级：系统内待办、每日摘要。用于可批量处理的任务类信息。
- 静默归档级：系统内留痕、可搜索记录，不主动推送。用于纯记录类变更。
关键原则：高级别渠道是稀缺资源，只能被真正重要的事件占用。一旦 IM 群里混入大量低价值消息，整条渠道的可靠性就崩了。
3. 决策点三：同一件事，多久提醒一次才不烦？
我的经验法则是"三三制"：同一任务的到期提醒，默认不超过 3 次（临期、到期、逾期），且间隔逐步拉长而非均匀。均匀高频提醒（如每 2 小时）制造的焦虑远大于价值。
同时要设置"合并窗口"：窗口期内的多条同类通知合并成一条摘要再发。比如 30 分钟内的所有评论回复合并推送，用户看到的是"你有 5 条新评论"，而不是 5 次单独打扰。
4. 决策点四：谁对这条通知负责？
每一类通知都必须落到一个明确角色：谁配置、谁维护、谁兜底。我建议至少指定一个"通知规则 owner"（通常是研发效能或 PMO 角色），负责规则库的整体健康。规则散落无人认领，是制度崩坏的开端。
5. 决策点五：怎么证明它有效？
最后一个决策点是定义"有效"。没有度量，就没有迭代方向。我通常要求至少盯住四个指标：触达率、打开率、处理率、漏提醒率。具体定义在第五节展开。
五、案例与数据观察：一个真实的六级触达改造
抽象逻辑讲完，看一个我实际参与过的落地案例。这是一家做企业级协作软件的公司，研发团队约 220 人，横跨 6 个产品线，用的是某项目管理平台做研发过程管理。改造前的核心问题就是开头说的：通知泛滥、处理率低、关键信息被淹没。
1. 改造前的基线数据
我们先花了两周做基线采集，数据来自平台的通知日志和用户行为埋点：
| 指标 | 改造前 | 说明 |
|---|---|---|
| 日均通知总量 | 约 1.2 万条 | 覆盖 6 个产品线全部成员 |
| 人均日接收通知 | 约 54 条 | 远超注意力承载上限 |
| 通知打开率 | 约 21% | 大量消息无人点开 |
| 打开后处理率 | 约 15% | 打开≠处理，进一步流失 |
| 关键提醒平均响应时长 | 约 4.7 小时 | P0/P1 事件从触发到被看到 |
| 主动屏蔽/静音的用户占比 | 约 38% | 超过三分之一用户已脱敏 |
2. 我们做的六级触达改造
核心动作是把原来"一刀切"的通知，重构成按重要度分级的六级触达体系，这套体系我在多个团队复用后做了固化：
- P0 事故级：走专项告警通道 + 值班电话，5 分钟未确认自动升级到 TL。
- P1 阻塞级：IM 定向消息 + 专属告警群，30 分钟未处理升级。
- P2 当日处理级：进入个人系统待办 + 每条每日最多一次 IM 摘要。
- P3 协作响应级：系统内待办，30 分钟合并窗口，不主动打扰。
- P4 知晓级：每日一次摘要推送。
- P5 归档级：仅系统留痕，不推送。
改造的关键不是新增渠道，而是把 78% 的低优先级通知从"即时打断"里挪出去。这是处理率提升的主要来源。
3. 改造后的数据变化
运行三个月后，我们重新采集了同一组指标：
| 指标 | 改造前 | 改造后 | 变化 |
|---|---|---|---|
| 日均通知总量 | 约 1.2 万条 | 约 4200 条 | 下降 65% |
| 人均日接收通知 | 约 54 条 | 约 19 条 | 下降 65% |
| 通知打开率 | 约 21% | 约 52% | 提升 31 个百分点 |
| 打开后处理率 | 约 15% | 约 43% | 提升 28 个百分点 |
| 关键提醒平均响应时长 | 约 4.7 小时 | 约 0.9 小时 | 缩短 81% |
| 主动屏蔽用户占比 | 约 38% | 约 12% | 下降 26 个百分点 |
需要说明：这组数据来自该团队单点样本，用于说明改造方向和量级，不代表所有团队都能达到同等幅度，具体幅度取决于改造前的失控程度。
4. 一个关键工程细节：规则可配置
这次改造能持续运转，很大程度归功于把通知规则从代码里抽出来，做成可配置的规则引擎。规则以声明式配置管理，示例结构大致如下：
{
"rule_id": "task_due_p2",
"trigger": {
"event": "task.due_soon",
"priority": "P2",
"window": "T-24h"
},
"channel": ["in_app_todo", "im_digest"],
"frequency": {
"max_per_task": 3,
"merge_window_minutes": 30,
"silence_hours": [22, 8]
},
"escalation": {
"enabled": false
},
"owner": "dev_ops_team"
}
可配置带来的直接好处是：运营人员无需改代码就能调整规则，调整周期从"两周一次发布"缩短到"当天生效"。这是制度能长期活下去的技术前提。
5. 关于平台选择的说明
这次改造用的是某项目管理平台，它的通知规则引擎支持按事件类型、优先级、频次上限、合并窗口、升级策略做细粒度配置，也支持把规则以配置文件形式纳入版本管理。对于中大型研发组织来说，这类能力是刚需，因为通知规则本身就是需要持续迭代的"活配置"。
如果你的团队正在做研发管理平台的国产替代或迁移，需要重点确认三件事：通知规则是否可配置、是否支持分级升级、是否有发送失败监控。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，可以作为国产替代的候选之一。这里我不展开对比，只强调一个选型判断：通知能力的天花板，往往不在"能不能发"，而在"规则够不够灵活、兜底够不够扎实"。
六、行动建议：不同规模团队怎么从零落地
逻辑和案例都有了，接下来是能直接照做的部分。我给出一套从 0 到 1 的六步操作步骤，并针对不同团队规模给出差异化建议。
1. 操作步骤：从 0 到 1 的六步
每一步我都标明输入、动作、输出，方便直接对照执行。
- 步骤一：梳理任务节点与提醒对象。输入=现有任务流程文档；动作=列出所有会触发通知的事件，并标注"谁应该知道"；输出=触发源清单。判断依据：把"知道但不用处理"的事件标为可归档。
- 步骤二：确定渠道优先级与降级方案。输入=触发源清单；动作=给每个事件匹配渠道级别（强打断/即时通信/待办聚合/静默归档）；输出=渠道映射表。判断依据：宁可降级，不可升格。
- 步骤三：配置提醒规则（合并、静默、升级）。输入=渠道映射表；动作=设置频次上限、合并窗口、静默时段、升级条件；输出=规则配置。判断依据：默认限频，升级要谨慎开启。
- 步骤四：设置异常兜底与人工介入点。输入=规则配置；动作=定义发送失败的监控、重试和升级到人的条件；输出=兜底预案。判断依据：关键事件必须有失败监控。
- 步骤五：小范围试运行并收集反馈。输入=完整规则；动作=选 1-2 个产品线试跑 2-4 周，收集打开率、处理率、投诉；输出=试运行报告。判断依据：先小范围验证，再全量推广。
- 步骤六：固化为团队规范并定期复盘。输入=试运行报告；动作=把规则写入团队规范、指定 owner、设定月度复盘；输出=制度文档+复盘机制。判断依据：制度是活的，必须带复盘。
2. 按团队规模差异化建议
不同规模的团队，重点完全不同，我按三档给建议：
| 团队规模 | 核心矛盾 | 优先动作 |
|---|---|---|
| 20 人以下 | 人手少，避免流程复杂化 | 只做渠道分级 + 合并窗口，规则尽量少 |
| 20-100 人 | 协调成本上升 | 建立频次上限与升级规则，指定 owner |
| 100 人以上中大型组织 | 多产品线，规则复杂 | 规则引擎化 + 失败监控 + 指标看板，考虑支持细粒度配置与私有化部署的平台 |
特别说一下 100 人以上的中大型组织：这个阶段靠"人肉约定"已经彻底撑不住，必须依赖可配置、可监控、可分级的规则引擎。选型时把"通知规则灵活性"和"兜底能力"列为硬性指标，比看功能列表长度重要得多。
3. 最小可执行的第一步
如果你现在就想动手，只做一件事：把当前所有即时通知列出来，把其中"批量处理也行"的全部降级到待办或摘要。这一步通常能砍掉 50% 以上的即时打扰，且几乎不需要任何工具投入。
七、取舍：什么该做、什么别做，什么情况该放弃
最后讲取舍。做通知优化不是"越精细越好"，过度设计本身就是一种成本。我给出三组明确的取舍判断。
1. 该做 vs 别做
该做：渠道分级、频次上限、合并窗口、失败监控、指定 owner、指标复盘。这六项是投入产出比最高的基础动作。
别做：为每条通知单独设计精美模板、追求 100% 触达率、给每个事件都开升级、让所有人都收到所有通知。这些要么收益极低，要么制造新噪声。
2. 自动化 vs 人工介入的取舍
自动化的边界是"规则清晰、判断确定"的事件；人工介入的边界是"需要上下文判断、涉及跨团队协调"的事件。不要试图把需要判断的事完全自动化，也不要让人去做机器能做的重复提醒。我见过强行把跨团队协调全自动化的团队，最后升级链条乱七八糟，反而更乱。
3. 什么情况下"少做"甚至"不做"更好
如果你所在的团队处于极早期（比如 10 人以下、单产品线、成员坐在一起），过度设计通知制度反而是负担。这时候靠群内口头同步加简单待办，效率可能更高。制度是等协调成本超过沟通成本之后才值得投入的。
反过来，当出现下面三个信号时，就必须立刻启动通知体系治理：一是成员开始主动屏蔽通知；二是关键事件被漏掉过；三是项目经理开始靠人肉补提醒。这三个信号出现任意一个，说明人肉模式已经到极限了。
八、总结：制度不是文档，是一组能跑起来的最小动作
回到最初那个 417 条消息的团队。他们后来没有写什么宏伟的通知规范，只做了三件事：把低优先级通知从群里挪到系统待办、给所有到期提醒加了 3 次上限和合并窗口、指定一名同学做规则 owner 并每月复盘一次。三个月后，处理率从 15% 升到 40% 以上，关键提醒响应时长从数小时压到 1 小时以内。
这印证了我贯穿全文的核心判断：做好任务提醒通知的关键，不是发得更多、更炫，而是把"触发，渠道，频率，责任，兜底，复盘"六段链路逐段治理，用减少噪声换取注意力，用可配置换取可持续，用度量换取迭代方向。制度从来不是一份躺在文档库里的规范，而是一组能真正跑起来、有人负责、能被度量、能持续调优的最小动作。
如果你正准备动手，我建议的下一步是：今天就列出你团队当前所有即时通知，圈出其中"一小时后再看也没关系"的那部分，把它们降一级渠道。这一步不需要任何工具、不需要审批、不需要开会，但它往往能带来立竿见影的变化。等这一步验证有效，再按第六节的六步流程，把整套通知体系补全。通知治理这件事，最好的开始时间是一年前，其次就是现在。
常见问题解答（FAQ）
1. 研发团队的任务提醒该走哪些通知渠道，怎么分层？
我们团队现在所有提醒都往一个 IM 群里发，结果任务节点的提醒、代码评审的通知、日报催收全堆在一起，大家慢慢就都不看了。我一直想搞清楚，到底哪些提醒该走 IM、哪些该走邮件、哪些应该只在系统内显示，有没有一个不容易踩坑的分层思路。
渠道分层要按‘是否需要即时打断’来切，而不是按消息类型切。建议分三层：第一层是即时打断层，只放真正阻塞他人、错过就要出事故的事件，比如线上告警、卡在你这环导致整条链路停摆的任务，走 IM 单聊或专属告警通道，不用群；
第二层是异步查阅层，放代码评审请求、任务状态变更、文档待确认这类当天看到即可的事件，走系统内消息中心或邮件，不主动弹窗；第三层是归档层，放日报提醒、周会提醒、周期性汇总，走日历或系统内列表，允许用户自己关掉。
判断依据很简单：问一句‘这条提醒如果晚看两小时，会不会有人因此停下来等我’，会就放第一层，不会就往下沉。另外每一层都要有降级方案，第一层的通道如果发送失败，要自动兜底到第二通道并记录失败原因，否则最该看到的提醒反而是最容易漏的。
2. 提醒频率怎么定，研发才不会把通知屏蔽掉？
我之前负责过一个内部工具，上线时提醒做得特别积极，结果两个月内就有同事把通知权限直接关了，后面真正的紧急提醒也收不到。我一直在想，频率到底该怎么设才合理，是不是要给每个渠道加一个上限，还是按人按项目分别控制。
频率控制的核心不是‘少发’，而是‘可预期’。可执行做法有三条：一是设置合并窗口，同一任务在 5 到 10 分钟内产生的多条变更合并成一条发出，避免一次提交触发五六条通知；二是设置静默时段，比如非值班人员的即时提醒在夜间只落到系统内不推送，由值班通道承担真正的紧急事件；
三是设置每人每日的非紧急提醒上限，超过上限后自动转入次日汇总，具体上限不要照搬别人的数字，先统计你们团队一周的实际提醒量，取中位数再压缩三成作为起步值。判断依据是屏蔽率而不是发送量：如果某个渠道连续两周出现员工主动关闭通知或长期不点开的情况，就说明该渠道的提醒信噪比不够，应该先减量再谈优化。
制度里要明确一点，任何人不得以‘怕漏’为理由给某个事件单开无上限的推送，否则频率规则会很快被架空。
3. 提醒和催办到底该怎么区分，制度上怎么落？
我们团队经常出现一种情况：任务提醒发出去没人理，负责人就在群里手动 @ 一遍，久而久之大家都把提醒当成催办，觉得看到提醒就等于被点名了。我想弄明白，提醒和催办在产品设计和制度设计上应该怎么分开，不然两边都做不好。
提醒解决的是信息同步，催办解决的是责任触发，两者必须在触发条件、接收人和话术上分开。提醒的触发条件是‘事件发生变化’，接收人是所有需要知情的人，内容是中性描述，比如任务进入待验证状态、截止时间还剩一天；
催办的触发条件是‘责任人在约定时限内没有动作’，接收人只针对责任人及其直接上级，内容要明确写出超期事实和要求的下一步动作。制度上要做三件事：第一，明确催办的启动阈值，比如任务超过约定时间 24 小时未更新状态才允许催办，不允许人为随意催办；
第二，催办要留痕，记录发起人、时间、原因，避免变成情绪化施压；第三，把提醒和催办放在不同渠道，提醒走系统内或邮件，催办走单聊或站内强提醒。判断标准很直接：如果一条消息的接收人里包含了不需要行动的人，那它就只能是提醒，不能写成催办口吻。
反过来，如果需要有人行动却只发了群提醒，那就是在用提醒逃避责任划分，这类模糊地带最容易导致制度失效。
4. 制度的维护责任人该是谁，漏提醒了怎么兜底？
我们之前也写过一版任务提醒的规范文档，但过了三个月就没人更新了，节点变了、渠道变了，提醒规则还停在旧版本，最后大家又开始手动在群里喊。我想知道这种通知制度到底该由谁来维护，以及万一真的漏发了提醒，应该有什么兜底机制。
维护责任要拆成三个角色，不能笼统地丢给‘项目组’。第一是规则负责人，通常由项目管理或研发效能岗担任，负责定义什么事件触发提醒、走哪条渠道、阈值是多少，并在流程变更时同步更新规则；第二是配置执行人，由各项目负责人担任，负责把规则落到具体的任务节点上，规则变了他要跟着改；
第三是异常兜底人，由值班或指定接口人担任，负责处理发送失败、重复发送、渠道不可用这类故障。兜底机制要写进制度：一是发送失败要有自动重试和失败告警，连续失败必须通知兜底人；二是设置人工补发入口，允许责任人在确认漏提醒后手动补发并标记原因；
三是每月做一次抽样核对，从任务系统里随机抽若干已完成任务，回查它们的提醒记录是否完整。判断制度有没有真正跑起来，不看文档写得多全，而看两件事：规则最近一次更新时间，以及上一个月的漏提醒补发记录有没有被复盘。如果这两项都是空的，说明制度只是写在纸上，需要先把维护责任落到具体的人头上再谈优化。
核心关键词
文章包含AI辅助创作：任务提醒如何做好消息通知？研发团队制度设计与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/443633
读者评论
条只处理63条，问题真不在工具，在于所有通知都按同一紧急级发。我们团队也是P0被淹没，后来砍掉一半触发源，处理率立刻上来了，减少确实比优化更管用。
六段链路里最容易被忽略的是兜底和复盘。我们之前漏发了一条线上故障提醒，事后才发现接收人已离职，接口一直静默失败。没有失败监控，通知系统就是个定时炸弹。
规则写死在代码里这点太真实了。改一条提醒频率要走发布流程，半年后规则库没人敢碰。必须把配置权交给规则owner，否则通知体系一定会腐化，上线只是开始。