消息通知映射表把业务事件、接收角色、通知渠道和消息模板放在同一张表里，让每条通知都有明确的触发条件和投递规则。本文提供一张可直接复制的空白映射表，并逐字段说明填写方法、必填与选填的划分标准，再用“代码合并请求待评审”演示完整填写过程，最后给出长期维护办法。
要点总览（TL;DR）
- 空白映射表包含12列：事件名称、触发条件、接收对象、通知渠道、消息模板、模板变量、优先级、去重规则、静默规则、责任人、最后更新和序号，可直接粘贴到文档或表格工具使用。
- 必填字段按“缺少后无法执行或无法追溯”判定，事件名称、触发条件、接收对象、通知渠道、消息模板、责任人必填；优先级、去重、静默、变量、更新日期可按集成阶段逐步补齐。
- 填写顺序从事件名称和触发条件开始，再确定接收对象与渠道，最后补模板、变量和规则类字段，每行先回答“什么情况下通知谁”，再回答“通知长什么样、发几次”。
- 示例以“合并请求待评审”演示完整一行，并用一条真实请求走通触发、变量替换、去重和静默的链路，链路走通才算配置完成。
- 维护上固化新增登记、渠道与模板同步、季度复核、失效行先停用后移除、表外变更记录五项动作，保证每行都有责任人和更新日期。
可复制空白映射表模板
下表可直接粘贴到文档或表格工具中使用。表头下方保留一行空白行，复制该行即可扩展新事件。括号内标注了每列的填写单位或取值格式，正式使用时可以删除括号说明。
| 序号 | 事件名称 | 触发条件 | 接收对象 | 通知渠道 | 消息模板 | 模板变量 | 优先级 | 去重规则 | 静默规则 | 责任人 | 最后更新 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| （整数，如 01） | （业务事件简称，如“合并请求待评审”） | （状态变化或条件表达式，如“MR 状态变为待评审”） | （角色或群组，如“仓库评审人”） | （渠道名，如“即时消息”“邮件”） | （消息正文，含变量占位符） | （变量名及来源字段，如 ${title}=MR标题） | （P0–P3 或 高/中/低） | （同一事件在时间窗内的合并或抑制规则） | （免打扰时段或静默条件） | （岗位或姓名，负责本行维护） | （日期，如 2025-06-01） |
填写顺序建议从事件名称和触发条件开始，再确定接收对象与渠道，最后补模板、变量和规则类字段。这样每一行先回答“什么情况下通知谁”，再回答“通知长什么样、发几次”。
每个字段记录什么
字段的含义决定取值来源。下表逐列说明每个字段记录什么、从哪里取值、常见写法是什么，填写时按同一口径执行，避免同一张表里出现两种写法。
| 字段 | 含义 | 取值来源 | 写法提示 |
|---|---|---|---|
| 序号 | 行的唯一编号，便于引用和变更记录 | 建表人按顺序分配 | 两位数字，新增行顺延，不复用已删除编号 |
| 事件名称 | 触发通知的业务事件 | 业务流程或工作项状态定义 | 用动宾短语，如“合并请求待评审”“工单超时未响应” |
| 触发条件 | 事件成立的具体判断条件 | 工作项状态机、业务规则或系统事件定义 | 写成可判断的表达式，如“状态由‘开发中’变为‘待评审’”，避免“有人提交时”这类模糊描述 |
| 接收对象 | 通知送达的人或群组 | 组织角色、项目成员或值班表 | 优先写角色而非个人，如“仓库评审人”“当班运维”，人员变动时无需改表 |
| 通知渠道 | 消息投递的通道 | 团队已接入的渠道清单 | 写渠道名称，如“即时消息”“邮件”“短信”；多渠道并列时注明主次 |
| 消息模板 | 通知正文的固定文案 | 通知配置中的模板内容 | 正文只保留必要信息，变量用占位符表示，如“${title} 等待你评审” |
| 模板变量 | 模板中占位符对应的数据来源 | 工作项字段、事件属性 | 逐项列出“变量名=来源字段”，如 ${title}=合并请求标题、${url}=详情链接 |
| 优先级 | 通知的紧急程度，影响发送方式和提醒强度 | 事件对业务的影响程度 | 统一用 P0–P3 或高/中/低，全表只选一种分级 |
| 去重规则 | 同一事件重复触发时的合并或抑制方式 | 事件频率与接收人承受度 | 写时间窗和合并方式，如“10 分钟内同一 MR 只发一次，后续变更合并为摘要” |
| 静默规则 | 不发送或延迟发送的条件 | 团队作息、免打扰时段 | 写时段或条件，如“22:00–08:00 仅 P0 即时发送，其余次日汇总” |
| 责任人 | 负责本行配置与维护的人 | 团队分工 | 写岗位或姓名，与变更记录中的修改人对应 |
| 最后更新 | 本行最近一次修改日期 | 修改时填写 | 统一格式，如 2025-06-01 |
事件与触发条件是一行的起点，两者要能对应到系统里可观测的状态变化；接收对象与渠道决定消息去向；模板与变量决定消息内容；优先级、去重与静默规则控制发送节奏；责任人与更新日期保证这行长期有人负责。
必填项与选填项怎么划分
判定标准可以归纳为一句话：缺少该字段，这一行就无法被正确执行或无法被追溯，就设为必填；只影响体验优化或仅在特定阶段需要，就设为选填。按此标准，事件名称、触发条件、接收对象、通知渠道、消息模板、责任人属于必填，优先级、去重规则、静默规则、模板变量、最后更新可按阶段取舍。
| 字段 | 建议 | 理由或适用条件 |
|---|---|---|
| 事件名称 | 必填 | 没有名称无法登记和引用 |
| 触发条件 | 必填 | 缺少条件则通知无法判断何时发送 |
| 接收对象 | 必填 | 没有接收人，通知没有去向 |
| 通知渠道 | 必填 | 渠道决定投递方式，缺失则无法配置 |
| 消息模板 | 必填 | 正文缺失时接收人无法理解通知内容 |
| 责任人 | 必填 | 保证每行有人维护，避免失效无人处理 |
| 模板变量 | 选填 | 模板不含变量时可不填；含变量时必须与模板同步填写 |
| 优先级 | 选填 | 事件量少、渠道单一时可先统一默认值，事件增多后再细分 |
| 去重规则 | 选填 | 高频事件必须填；低频事件可暂用渠道默认策略 |
| 静默规则 | 选填 | 涉及夜间或非工作时段发送时填写 |
| 最后更新 | 选填 | 建议填写；若团队已有独立变更记录，可只在该记录中维护 |
必填范围可以随团队规模和集成阶段调整。事件数量在十几条以内、只接入一个渠道的小团队，可先保留六个必填字段，规则类字段留空；事件超过数十条、接入多个渠道后，再补齐优先级和去重规则，否则接收人会被重复消息淹没。集成初期可把模板变量列为选填，等模板开始使用变量后再转为必填。
一条完整填写示例：代码合并请求待评审
以下为演示情景，用于说明填写方式，不代表真实企业案例。假设团队使用研发管理平台管理代码合并请求，希望评审人及时收到待评审提醒。
| 字段 | 填写内容 |
|---|---|
| 序号 | 01 |
| 事件名称 | 合并请求待评审 |
| 触发条件 | 合并请求状态由“开发中”变为“待评审” |
| 接收对象 | 该仓库的评审人角色 |
| 通知渠道 | 即时消息（主）、邮件（每日汇总） |
| 消息模板 | 【待评审】${title} 已提交，请评审。提交人：${author}，链接：${url} |
| 模板变量 | ${title}=合并请求标题；${author}=提交人；${url}=详情链接 |
| 优先级 | P1 |
| 去重规则 | 同一合并请求 30 分钟内多次状态变化只发一次，后续变更合并为一条摘要 |
| 静默规则 | 22:00–08:00 不即时发送，次日 09:00 汇总 |
| 责任人 | 研发效能负责人 |
| 最后更新 | 2025-06-01 |
逐项对应字段说明来看：触发条件写成状态变化，系统可以据此判断；接收对象用角色而非具体人名，评审人调整时无需改表；模板只保留标题、提交人和链接三个关键信息，变量与模板一一对应；P1 表示需要当天处理但不必打断夜间休息，因此静默规则允许夜间延迟；去重规则针对评审过程中反复修改状态的情况，避免同一请求多次打扰。
填写完成后，用一条真实的合并请求走通链路：提交评审，确认接收人收到消息，检查变量是否正确替换，再模拟一次状态反复变化，验证去重是否生效。链路走通，这一行才算配置完成。
模板的调整与长期维护
映射表的价值在于持续可用。事件和渠道会变化，表如果长期不更新，就会出现通知发了没人看、事件改了表没改的情况。维护工作可以固化为以下流程。
- 新增事件登记：由提出方按空白行填写事件名称、触发条件、接收对象和渠道，提交给表责任人审核；审核通过后分配序号并记录更新日期。
- 渠道或模板变更同步：渠道调整、模板文案修改或变量增删时，先改映射表对应行，再改通知配置，确保表与配置一致；涉及接收对象的变更需通知相关角色。
- 定期复核：建议每季度复核一次，逐行确认事件是否仍在发生、接收人是否仍在岗、渠道是否仍在使用；连续两个周期无人响应的行标记为待清理。
- 失效行清理：确认失效的行不直接删除，先标记“停用”并注明原因和日期，保留一个周期后再移除，便于追溯历史通知。
- 版本与变更记录：在表外维护变更记录，记录修改日期、修改人、修改行号和变更说明；表内“最后更新”与变更记录保持同步。
变更记录可使用以下字段：变更日期、修改人、涉及序号、变更类型（新增/修改/停用）、变更说明、审核人。事件较多时，可把映射表作为配置清单，在研发管理平台中按工作项状态流转登记事件，并将通知规则与状态变化关联。ONES 支持工作项状态流转与通知配置，可承载事件登记和规则维护，让映射表中的每一行在系统中找到对应配置，减少表与系统脱节的情况。具体配置方式以团队实际使用的平台为准。
维护节奏不必统一。事件少、变更慢的团队可按季度复核；集成渠道多、事件频繁调整的团队可改为月度检查，并在每次渠道上线前强制更新映射表。关键是让每一行都有责任人和更新日期，表才能随业务一起演进。
常见问题
映射表里的触发条件写成“有人提交时”可以吗？
不建议这样写。“有人提交时”无法对应到系统里可观测的状态变化，配置时难以判断何时发送，事后也难以核对。更可执行的写法是描述状态变化或条件表达式，例如“合并请求状态由‘开发中’变为‘待评审’”“工单创建后超过 4 小时未响应”。如果事件本身由多个条件组合触发，把条件逐项列出并注明是同时满足还是任一满足。
团队刚接入通知渠道，映射表可以先只填必填字段吗？
可以。集成初期事件数量少、渠道单一时，先保留事件名称、触发条件、接收对象、通知渠道、消息模板、责任人六个必填字段，规则类字段留空，能保证通知正常发出。等事件数量增加或接入多个渠道后，再补齐优先级和去重规则，否则接收人容易被重复消息打扰。模板变量在模板开始使用变量时转为必填。
同一事件在多个渠道发送时，映射表怎么记录？
在“通知渠道”一列并列写出渠道名称并注明主次，例如“即时消息（主）、邮件（每日汇总）”。如果不同渠道使用不同模板或不同接收对象，建议拆成两行分别登记，各自写清触发条件、模板和去重规则，避免一行内混用两套配置导致维护时难以判断哪条规则对应哪个渠道。
映射表和系统里的通知配置不一致时以哪个为准？
以映射表为配置清单，先改表再改系统配置，两边保持一致。渠道调整、模板文案修改或变量增删时，按这个顺序执行，并在变更记录中登记修改日期、修改人、涉及序号和变更说明。定期复核时逐行比对表与系统配置，发现差异及时修正，避免出现通知发了没人看、事件改了表没改的情况。
失效的事件行可以直接删掉吗？
建议先标记“停用”并注明原因和日期，保留一个周期后再移除。直接删除会丢失历史通知的追溯依据，后续排查“这条通知为什么没发”时缺少对照。停用期间如果事件恢复，可以重新启用该行并更新最后更新日期，不必从头登记。
