每一条自动发出的消息，都是你替用户做的一次决定。
一、三十八条消息，没有人说得清为什么要发
陈默的排班工具做了三年，后台的自动消息列表有四行屏。注册欢迎、邮箱验证码、付款成功、班次变更提醒、每周摘要、功能上新、节日问候、问卷邀请，还有几条他自己都想不起来源的。
某天一位客户在工单里写：「你们为什么一天给我发三封邮件？我只想收到班次变更。」他打开发送记录，翻了半小时，发现自己也说不清哪条在发、发给谁、能不能关。那些消息不是设计出来的，是三年里一个个「顺手加上去」的。
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
他花了一个周末做清点：把每条消息的触发条件、收件人、渠道、紧急度、能否关闭、模板位置和负责人写进一张表。写完发现 38 条里有 12 条没有明确触发条件，属于历史遗留的群发；另有 9 条在三个地方重复发送同一件事，因为「班次已变更」在排班页、通知中心和邮件各写了一遍。
清点后保留 26 条：事务 12 条、生命周期 9 条、公告 5 条。月发送量从 7600 封降到 5000 封，名单 1200 人的人均消息从 6.33 条降到 4.17 条。
砍掉的三分之一，没有一条是用户要求的。 它们是被「多做一点总没错」加进来的。
二、四类消息：只有一类不能关
消息看起来五花八门，按用途只有四类。分类的意义在于：它直接决定这条消息能不能被关掉。
| 类型 | 典型例子 | 能否关闭 | 默认渠道 | 延迟容忍 |
|---|---|---|---|---|
| 事务 | 验证码、密码重置、收据、支付失败 | 不能 | 邮件或短信 | 秒级 |
| 生命周期 | 欢迎、激活引导、召回 | 能 | 邮件或站内信 | 小时级 |
| 公告 | 维护、破坏性变更、事故 | 部分（安全类不能） | 站内信、邮件、状态页 | 分钟到天 |
| 一次性 | 节日问候、问卷、活动推广 | 能 | 任意 | 天级 |
事务消息不能给关闭入口。 用户关掉收据，账单出问题时就找不到凭证；关掉验证码，账号就登不进去。
生命周期消息必须能关，而且要能按类别关。 只能「全部退订」的产品，最后会同时失去召回信和产品更新。
公告要按紧急度分开。 数据泄露与服务中断是必须送达的；「我们换了图标」不是。两类混在一个开关里，用户只能整类关掉。
一次性消息默认不发。 每一条都要单独回答「用户此刻需要它吗」，答不上来就不发。
分类会随产品变化。 同一条消息在不同产品里可能属于不同类别：登录提醒对普通工具是事务，对高安全要求的产品还带公告性质。判断依据是「关掉它会不会造成损失」，不是名字。
三、七个字段：缺一个就别发
清点时不需要文采，只需要把七件事写清楚。任何一格空白，都会在半年后变成一条没人敢删的消息。
| 字段 | 要写什么 | 缺失后的典型后果 |
|---|---|---|
| 触发 | 哪个事件、满足什么条件 | 最后变成手动群发 |
| 收件人 | 谁收、明确排除谁 | 发给已退订或已付费的人 |
| 渠道 | 站内信、邮件、推送或短信 | 同一件事在三个渠道重复 |
| 紧急度 | 阻断、即时、摘要或静默 | 全部标成「重要」 |
| 可否关闭 | 必要、按类别或按频率 | 用户只能一键全部退订 |
| 模板 | 模板版本与变量清单 | 文案散落在代码与数据库里 |
| 负责人 | 谁维护、多久复审一次 | 上线之后没人删 |
「排除谁」比「发给谁」更容易出事。 已退订、已付费、已完成、已注销，这四类排除条件要在触发时判断，不能等到发送时再过滤。
模板要放在一个能被非工程师修改的地方。 一个人的产品里，改一句话要发版，就意味着这句话永远不会被改。
负责人写自己也要写复审日期。 「我负责」在三个月后等于没人负责，写清「每季度第一周复审」才有约束力。
字段要放在同一张表里。 26 条消息共用一张表，比散落在代码注释、后台配置与文档里更容易发现重复与空白。
四、该砍的十二类与打扰预算
清点的目的不是整理，是删除。下面十二类是最常见的「看着有用、实际只增加打扰」的消息。
- 没有触发条件、只能手动群发的通知。
- 同一事件在页面、通知中心与邮件各发一次的重复消息。
- 用户从未订阅的「功能上新」。
- 节日问候与生日祝福。
- 注册成功当天连发的三封欢迎信。
- 发给已付费用户的激活引导。
- 发给已退订用户的「最后一次提醒」。
- 管理员操作产生、却抄送给普通用户的通知。
- 测试环境漏到生产的消息。
- 没有退出条件的生命周期序列。
- 标题写「重要更新」的常规版本说明。
- 只为汇报数字而发的周报。
判断标准只有一条：删掉它，会不会有人在一周内发现。 不会，就删。
删除要留档。 记录删了哪条、哪天删、谁提的；三个月后有人问「为什么收不到提醒」，这份记录就是答案。
打扰不是感觉，可以算。按四级分层，一个人的产品每天给同一个用户的消息上限大约是这样：
清点前：38 条消息，月发送 7600 封
人均 = 7600 ÷ 1200 = 6.33 条/月
清点后：26 条（事务 12、生命周期 9、公告 5）
月发送 = 5000 封
人均 = 5000 ÷ 1200 = 4.17 条/月
减少 = (7600 − 5000) ÷ 7600 = 34.2%
按 22% 打开率计，减少的无效触达
= 2600 × 22% = 572 次/月
钱不是重点。 2600 封按每封 0.004 美元只省 10.4 美元，真正省下的是用户对「你们又发信了」的耐受度。
打扰预算可以写成一条硬规则：阻断级每天最多 1 条，即时级每天最多 2 条，摘要级每天 1 条，静默级每周最多 1 条。四条加起来的理论上限仍偏高，实际控制在 2 条左右才接近用户能接受的水平。
五、行动清单与复算验收
先导出全部消息，再谈删除。凭记忆清点，一定会漏掉最该删的那几条。
- 从后台或代码里导出全部自动消息，逐条编号。
- 为每条补齐七个字段，空白的先标红。
- 按四类归档，标出哪些属于不可关闭的事务消息。
- 列出每条消息的月发送量与独立收件人数。
- 把十二类该砍的消息逐条对照，给出删、并、留三个结论。
- 为剩下的消息写排除条件：已退订、已付费、已完成、已注销。
- 把模板迁到可在线修改的位置，并记录版本。
- 定下复审日期，写进日历而不是待办清单。
验收标准：你能用一张表说清当前每一条自动消息的触发条件、收件人、排除条件、渠道、紧急度、能否关闭与维护人，并说出这一次删掉了哪几条、为什么。
使用边界与实操验收
本文只做清点与删除，不涉及发信身份、送达率、通知分层与偏好中心，那些在后面几篇。
清点不是一次性项目。 每加一条消息都要过一遍七字段；过不了，就不该上线。否则一年后你会再做一次同样的周末。
砍消息不等于砍沟通。 安全告警、账单失败、服务中断不能因为「打扰」被删掉，它们属于阻断级，要保留并单独走渠道。
一人产品的特殊约束是没有值班的人。 消息发错时没人能在一小时内补救，所以清点时要额外检查「发错对象的后果」：发给全体用户的测试消息，比漏发一条提醒严重得多。
关键参考与核验范围
核验日期：2026-10-25。以下链接仅作为公开文档入口，用于核对邮件传输与发信人规范的基础概念，本文未逐条引用其内容。
- RFC 5321：Simple Mail Transfer Protocol ：用于核对邮件投递的基本流程与失败语义。
- Google 发信人指南 ：用于核对事务邮件与批量邮件在发信身份上的通用要求。
引用口径。 本文只借用两份材料的基础概念：邮件有明确的投递与失败语义，事务与批量发信要分开对待。文中的 38 条、26 条、7600 封、5000 封与 1200 人全部来自教学假设，与上述材料无关。
核验范围。 核验的是「四类消息 + 七字段 + 十二类该砍」这套清点方法是否仍然可操作，不是比对某个发送平台的功能。工具会变，清点原则不变。
如何自行复核。 打开你的发送记录，按收件人取一个月的数据，算人均条数；如果超过 4 条，先别优化文案，先去清点。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。