收件箱不是喇叭：vibe 项目的站内通知中心实战

先分清三样东西：通知中心不是推送，也不是邮件

很多 vibe 项目的通知功能是从“发一条推送”开始的，越做越乱，最后变成三套系统各发各的：邮件发一遍、推送发一遍、应用里再弹一遍，用户关掉所有通知，团队却以为“触达率”很高。混乱的根源是概念不清：推送、邮件和站内通知中心是三种不同的东西。推送是把用户从别处拉回来的手段，适合紧急且时效性强的消息；邮件是留档和异步沟通的手段，适合需要保存、转发和事后查阅的消息；而站内通知中心是用户回到产品后查看“与我有关的事情”的收件箱，是唯一一个用户可以主动翻阅、逐条处理、按需清空的地方。把三者混成一套“通知系统”，结果就是每条消息都被迫同时符合三种场景的要求，最后哪种场景都不合适。

本篇的方法论是原创的，不依赖特定框架；文中的产品名与人物均为虚构示例，出现时会明确标注。先划清与本站已有指南的界线：邮件送达那篇讲的是邮件渠道本身的送达率与退信处理，本篇讲的是站内收件箱的设计与工程，不重复邮件渠道的细节；状态页那篇讲的是对外公开的事故沟通，本篇讲的是对内个人的待办与动态，两者的读者和时效完全不同；反馈分流那篇讲的是用户反馈如何进入团队的工作流，本篇讲的是系统事件如何到达用户——一个是向内收集，一个是向外告知，方向相反。如果你已经读过那几篇，本篇不会重复它们；如果你是第一次接触通知设计，本篇也可以独立成立。

第一步：给通知分三级，拒绝“所有消息都重要”

通知中心的第一项工作不是写代码，而是给所有可能产生的通知定级。建议只分三级，多了就等于没分。第一级是“需要你行动”：有人在文档里 @ 了你、有人把任务指派给你、你的付款失败了、你的导出文件已生成——这类通知的特点是：不处理会有后果，而且处理动作是明确的（回复、确认、重新付款、下载）。第二级是“值得你知道”：你关注的项目有新动态、你参与的讨论有了新回复、系统完成了你发起的批量操作——这类通知的特点是：知道了更好，但不处理也不会出问题。第三级是“仅供查阅”：每周摘要、功能上新公告、社区热门内容——这类通知的特点是：用户想看的时候自然会看，不需要主动打扰。

定级的检验标准只有一个：这条通知如果半夜发到用户手机上，用户会感谢你还是拉黑你？第一级可以打扰，第二级不应该在深夜打扰，第三级永远不应该以推送形式打扰。很多团队不敢定级，理由是“每条消息对某个用户都重要”——这句话在个体上成立，在系统设计上不成立。定级的意义不在于判断某条消息客观上重不重要，而在于给系统一个默认行为：当用户没有逐项设置偏好时，系统按级别决定是立即推送、只进收件箱，还是只出现在摘要里。没有默认行为的通知系统，最终会把所有选择成本都推给用户，而用户应对选择成本的方式只有一种：全部关掉。

虚构示例（以下产品与人物均为虚构，仅用于说明设计）：假设你做了一个协作白板工具“白板岛”，用户陈默一天会收到这些事件：同事在白板上 @ 他请他确认配色（第一级，需要行动）、他关注的白板有了 12 处新改动（第二级，值得知道）、平台上线了模板市场（第三级，仅供查阅）。按三级划分，第一条可以立即推送并置顶在通知中心，第二条只进通知中心并按白板聚合为一条，第三条只出现在每周摘要里。这样划分之后，陈默每天打开通知中心时，看到的不再是 40 条无差别消息，而是 3 条需要行动、8 条值得知道、1 份摘要——处理成本从“翻不完”降到了“两分钟能清完”。

第二步：数据模型只记四张表，关键是幂等与顺序

通知中心的工程实现可以从四张逻辑表讲清，不需要一上来就引入复杂的消息队列拓扑。第一张是事件表：系统里发生的原始事件（评论、指派、付款、导出完成），只记录事实，不记录“要通知谁”。第二张是通知表：事件经过规则展开后，生成给每个用户的通知记录，包含接收人、类型、级别、关联对象、创建时间、已读状态。第三张是偏好表：每个用户对每类通知的渠道偏好（站内、推送、邮件、都不接收）与免打扰时段。第四张是聚合表（或聚合字段）：同一对象、同一类型的多条通知，在展示时合并为一条并计数，避免“12 个人点赞了你的白板”变成 12 条通知。

这个模型里最容易踩的坑有三个。第一个是重复投递：同一个事件被重试、被两个服务同时处理、被回放，就会生成两条一模一样的通知。解决办法是给每条通知一个幂等键（事件 ID 加接收人加类型），写入时按幂等键去重，而不是事后靠展示层去重——展示层去重只能掩盖问题，不能解决计数错误。第二个是顺序错乱：用户先收到“任务已完成”，后收到“任务已指派给你”，收件箱的时间线就讲不通。解决办法是通知的排序键用事件发生时间，而不是通知生成时间，并且在展示层按关联对象分组时，组内按时间正序排列，让用户能读出事情的来龙去脉。第三个是“已读”状态的归属：已读状态属于“某个用户对某条通知”的关系，不是通知本身的属性——同一个人可以有多个设备，同一条通知在手机上已读、在电脑上也应当已读；反过来，团队共享的通知不能因为一个人已读就对所有人标记已读。把已读状态做成独立的“用户-通知”关系表，是避免这类 bug 最直接的办法。

还有一个经常被低估的设计点：通知应当支持“回查原文”。每条通知都要带一个深链接，点开后直达产生这条通知的对象（具体的评论、任务、文件），而不是只跳到首页或列表页。用户点开通知却找不到对应的事情，是通知中心最常见的体验失败——它比没有通知更糟，因为它消耗了用户的信任：用户会学会“通知点开也没用”，然后不再点开任何通知。深链接失效的常见原因是对象已被删除或权限已变更，处理办法是：对象不存在时，通知详情页要明确说明“该内容已被删除或你已无权查看”，而不是跳到一个空白页或报错页。

第三步：收件箱的交互，围绕“清完”而不是“看完”设计

通知中心的交互目标不应该是“让用户看完所有通知”，而应该是“让用户以最小成本把收件箱清到零”。围绕这个目标，有五条具体的交互规则。第一，未读数必须诚实：角标数字应当等于真实未读条数，不能把“未读”定义成“未点击过横幅”之外的任何花招；更不能为了活跃度而故意让角标清不掉——一个清不掉的角标，用户最终会用“关闭通知权限”来解决。第二，提供批量操作：全部标记已读、按类型标记已读、按对象归档，这三项是收件箱的标配；没有批量操作，用户面对 200 条历史通知时唯一的选择就是放弃整个收件箱。

第三，聚合展示要保留“展开看明细”的入口：聚合后的“12 处新改动”必须能点开展示 12 条明细，否则聚合就变成了信息丢失，而不是信息压缩。第四，每类通知都要有独立的开关和免打扰设置，并且开关的生效要是即时的——用户关掉“点赞通知”后，下一秒就不应该再收到点赞通知；如果开关有延迟生效期，必须在界面上明确写出延迟时间。第五，空状态要像样：收件箱清完时，不要只显示“暂无通知”，而是告诉用户“你已处理完所有通知，上次更新于某时”，并且提供一个查看历史通知的入口。空状态不是无事可写，而是给用户一个“已完成”的确认感——这种确认感，是用户愿意继续使用通知中心的原因。

还有一条容易被忽略的规则：通知中心不应该产生关于通知的通知。典型的反例是：用户收到一条新通知，系统又发一条“你有新通知”的通知；或者每周摘要里写“你有 3 条未读通知”，而这 3 条本身就是摘要的来源。系统应当区分“事件通知”和“系统提醒”：前者是业务事件的到达，后者是对收件箱状态的提醒，两者最多只保留一种提醒机制，并且提醒本身不能再被计入未读数。否则通知系统会陷入自我增殖的循环，用户看到的未读数永远降不下来。

第四步：用三个指标衡量通知中心，而不是用发送量

通知中心上线后，用发送量衡量它是最容易犯的错误：发送量上升可能只是系统变吵了。建议只盯三个指标。第一个是“处理率”：用户在 24 小时内处理（已读、归档、点击深链接）掉的第一级通知占比——这个指标衡量的是重要消息有没有被看见。第二个是“静音率”：用户主动关闭某类通知的比例，按类型拆分——某类通知的静音率突然上升，说明这类的定级或触发条件出了问题，而不是用户“不喜欢通知”。第三个是“清零时长”：用户从打开收件箱到把未读清零的中位时长——这个指标衡量的是收件箱的处理成本，清零时长越短，说明聚合、批量操作和定级越有效。

三个指标各有对应的行动阈值。第一级通知处理率连续两周低于 60%，应当检查定级是否过宽（太多消息被标为第一级，导致用户麻木）或深链接是否失效；某类通知静音率超过 20%，应当考虑把这类的默认级别下调一级，或把触发条件收紧（例如点赞通知改为聚合日报）；清零时长中位数超过 5 分钟，应当检查聚合规则和批量操作是否缺失。指标的意义不在于数字本身，而在于它们指向的修法：通知系统的问题，几乎总是可以通过“降级、聚合、给开关”这三招解决，而不是通过“发更多提醒”解决。

上线清单：从事件接入到灰度发布的八项

最后是一份可以直接照着做的上线清单。第一，事件接入先只接三类：@提及、任务指派、付款与导出结果——这三类是用户最不能错过的，先把它们做对，再扩展到动态与摘要。第二，幂等键、已读关系表、深链接三项工程基础必须在第一版就做对，事后补的成本比事前高得多。第三，默认偏好按三级设定：第一级默认站内加推送，第二级默认仅站内，第三级默认仅摘要；用户可以在设置页逐项修改，但默认行为本身就是产品判断的一部分。

第四，免打扰时段默认开启夜间免打扰（例如 22:00 至次日 8:00），第一级通知在免打扰时段只进收件箱不推送——除非用户主动关闭免打扰。第五，灰度发布先给 10% 的用户开通知中心，观察一周的处理率、静音率与清零时长，达标后再全量。第六，准备一份“通知故障”预案：通知服务挂掉时，事件不能丢失（先落事件表，恢复后补发），补发时要按事件时间排序，并且在摘要里说明补发原因，避免用户收到一堆过时通知却不知道为什么。第七，帮助文档里写清三件事：级别定义、开关位置、免打扰规则——用户找不到开关的通知系统，等于没有开关。第八，上线一个月后复盘一次：哪类通知的静音率最高、哪类第一级通知的处理率最低、清零时长有没有下降，按复盘结果调整定级与聚合规则，然后把调整写进更新日志。通知中心不是上线就完成的功能，而是一个需要持续调校的系统；它的成熟标志不是消息变多，而是用户打开它时，能在两分钟内处理完所有真正需要他处理的事。

补充：多设备同步、离线状态与无障碍，三处容易漏的细节

通知中心做到一定程度后，会遇到三处容易漏的细节，第一处是多设备同步。用户在手机上把通知标记已读，电脑上的角标应当随之清零；反过来也一样。实现这一点不难，关键是把“已读”状态放在服务端，而不是放在某个设备的本地存储里——本地已读状态在设备间永远对不上，最终表现就是用户在每个设备上都要重复清理一遍收件箱。离线状态是第二处：用户在没有网络时打开应用，通知中心应当展示上次同步的快照并明确标注“离线数据”，而不是显示空白或报错；恢复联网后，后台静默同步新增通知，不要用一次全量刷新打断用户正在看的内容。这两处细节都不涉及复杂的算法，但它们决定了通知中心在真实使用场景里是“顺手”还是“添乱”。

第三处是无障碍：通知中心是最需要无障碍支持的地方之一，因为它的用户包括所有使用辅助技术的用户。角标数字不能只用颜色区分已读与未读，必须同时有文字说明；通知列表必须支持键盘导航与屏幕阅读器的语义结构，每条通知的标题、时间、关联对象都要能被朗读出来；“全部标记已读”这类批量操作要有明确的操作反馈，不能只靠视觉变化告知结果。这些要求不是额外的加分项，而是通知中心作为“信息到达的最后一公里”的基本职责：如果一部分用户根本无法感知通知的存在，那么通知系统的覆盖率指标从一开始就是虚的。

最后补一条关于灰度与回滚的提醒：通知中心上线时，除了灰度发布，还应当准备回滚开关——一旦发现某类通知的触发条件写错（例如把全站广播误写成全员第一级推送），管理员应当能在不发布新版本的情况下，立即暂停该类通知的生成，而不是等下一个发布窗口。这个开关的成本很低，缺了它的代价却很高：一次错误的批量推送，足以让用户把通知权限关掉半年。通知系统的信任建立得很慢，摧毁得却很快；上线清单里留一个紧急制动，比事后写道歉公告要体面得多。

图：通知中心管道——事件发生 → 幂等分发 → 分级收件箱 → 用户处理/清零 → 三项指标（处理率、静音率、清零时长）。