注意力与通知交互设计规范

让值得知道的事及时可见，让需要处理的事有清楚的下一步，让用户处理完仍能回到自己的工作。

适用于应用内提示、系统通知、摘要、后台任务介入及多通道提醒。面向设计师、产品与工程：每条规则同时说明需要作出的设计决定、用户能感知的反馈和实现应提供的证据。配套：Design Token 与配置字典 · 来源与论据边界。

1. 范围与读法¶

本规范覆盖“订阅与权限 → 事件判定 → 排队与投递 → 呈现与处理 → 返回原任务 → 负担复盘”的完整过程，不规定唯一组件、推荐算法或消息协议。不适用于医疗警报器、紧急广播、驾驶报警等专用告警系统的可靠性认证；普通产品不得借用这些场景为任意穿透勿扰提供理由。

必须／不得是验收底线：缺少它，会使明确的用户承诺在可预见情境下失效。应当是推荐做法，偏离时记录理由与等效方案。可以是可选实现。判定单位是正文中独立的义务子句；示例与成对反例帮助发现问题，不增加义务或扩大适用范围。

规则是本项目的必要性推导，不是外部文献原文。外部标准说明适用要求，平台文档提供实现参考，研究提供需要检验的方向；三者均不能证明某个提醒频率或等待时长普遍最优。

1.1 必须分开的概念¶

“已处理”针对本次通知所指的事项，不直接复制后台任务状态。例如导出任务完成会产生一个仍有知悉价值的新事件，不能因为导出已完成就把该事件立即判为无需提醒；纯知悉事件按其相关性、有效期与用户选择结束，不强造业务待办。

2. 原则与规则速查¶

3. 完整规则¶

N1-1先证明提醒值得发生¶

适用新增类别、后台触发或主动建议可能产生通知时。

要求必须明确接收人、触发条件、用户收益、不提醒的后果、有效性依据和下一步。纯信息类别可以把下一步写为“知悉，无需操作”，同时解释知悉价值。必须区分仅记录、非侵入知悉和主动打断，选择能够兑现收益的方式；应当优先采用较少打扰的方式。营销不得伪装成任务失败、账户风险或待审批事项。

设计决定：先问“这次提醒能帮助用户知道什么、改变什么”，再选择入口。通知订阅不等于同意系统自动执行通知里提出的新任务；用户未回应不得视为同意。

用户侧验证用户能说明为什么收到、是否需要行动；纯信息通知没有被迫点击的确认按钮。

实现侧验证从样本事件可追溯类别、接收依据与触发条件；轮询无变化不产生新提醒。

成对反例每个后台步骤都推送 ↔ 为追求零打扰把用户订阅的重要结果藏进深层日志。

依据项目必要性推导；NR01、NR02提供分类与打断机制参考。

N1-2用后果与时间决定紧急性¶

适用提醒存在不同强度、截止时间或例外穿透时。

要求必须分别记录不处理的影响、业务截止和最晚有用提醒时点，再决定呈现强度。时间敏感不得仅由业务方的“重要”标签决定。升级必须有允许类别、事实条件、有限轮次、间隔及停止条件；不得因未点击而自动提高紧急性。

例外穿透必须同时满足类别资格、真实平台能力和适用的用户允许；产品标签不产生权限。营销不得使用例外穿透。临近截止不能自行越过用户关闭或暂停的范围。

设计决定：区分“重要但可稍后知道”“现在处理有用”“已来不及处理”。第三种显示当前结果与补救入口，不补响失去意义的催促。

用户侧验证相同任务在不同剩余时间下，用户能理解为何提醒或为何不再催促。

实现侧验证注入截止变化、平台资格缺失与用户禁用，核对升级原因与实际允许范围。

成对反例所有消息都最高级 ↔ 为遵守聚合时长让仍可处理的重要事项错过窗口。

依据NR02；最晚有用时点与升级边界为项目推导。

N2-1普通通知不抢走当前任务¶

适用用户正在编辑、拖动、确认、阅读或进行其他连续操作时。

要求普通通知不得自动转移焦点、覆盖正在操作的关键控件或阻断提交。应当在任务边界、用户指定时段或摘要中提示；情境未知时保留非侵入入口，不把短暂停顿当作空闲证据。若继续当前操作确需用户决定，必须将问题放在相关任务处，说明被阻塞的步骤与可选路径。

设计决定：先选位置与时机，再选横幅等形式。前台已可见的结果应当就地反馈，不再同时发声提醒相同事实；“静默”不隐藏当前提交的失败或待确认状态。

用户侧验证输入中出现普通完成消息，焦点、输入和提交位置保持；有阻塞时能找到原因。

实现侧验证测试焦点、键盘顺序、连续阅读和情境信号缺失，记录实际呈现路径。

成对反例导出完成弹模态窗口 ↔ 所有失败都进摘要，用户以为提交成功。

依据NR03、NR04、NR09。

N2-2关闭与暂缓必须按声明范围生效¶

适用产品提供可选通知或用户调整通知设置时。

要求必须提供按有意义类别关闭、暂缓与进入设置的入口，并展示所影响的事件、账号、设备和通道。必须区分“此设备不推送”与“此类事件不再联系我”。不得通过新建通道、更换类别或改发其他媒介绕过选择；不在关闭范围内的独立订阅也不得被误取消。

设置提交后必须反馈实际生效范围；同步未完成时显示待同步，不宣称所有设备都已生效。关闭必须拦截尚未提交的受影响提醒，并尽力撤回平台允许撤回的在途通知；无法撤回已发出的邮件等内容时如实说明限制。

必要的账户安全告知仅在产品明确列出适用依据、事件、接收人、独立通道、关闭限度和失败处置时单独处理；不得借“安全”扩大普通通知范围。专项告知同样受平台权限与内容保护约束。

用户侧验证从通知关闭一个类别后，能说明哪些会停止、哪些仍保留；无能力时不显示虚假的成功。

实现侧验证分别测试单设备关闭、类别全通道关闭、独立邮件订阅、必要安全告知及离线端设置同步。

成对反例关闭手机推送后偷偷发短信 ↔ 关闭一台设备顺带取消另行订阅的邮件。

依据NR01；范围裁决与生效反馈为项目推导。

N2-3在用户理解用途时请求权限¶

适用需要系统通知权限或重新启用已被拒绝的能力时。

要求应当在用户订阅、创建提醒或使用相关能力时说明通知用途并请求权限。必须区分未决定、允许、拒绝与不可用；关闭说明页或未回应不得记录为允许。拒绝后必须保留不依赖该权限的核心任务和查看结果的入口，不得反复弹窗、阻塞无关流程或用误导文案催促授权。

确实依赖通知的功能，必须在用户设定时说明能力缺口和可行替代；不得显示“会准时通知”却没有可用通道。重新请求应由明确的功能需要或用户主动操作触发，并遵从平台限制。

用户侧验证拒绝通知后仍可完成原任务，并知道去哪里查结果；可从设置主动重开。

实现侧验证测试允许、拒绝、取消请求及系统外修改权限；应用开关与平台实际状态分别记录。

成对反例首次启动先要求全部权限 ↔ 用户已经主动创建提醒，仍不说明为什么无法通知。

依据NR07。

N3-1聚合要保留异常并按时释放¶

适用同一任务或对象连续更新，或以摘要集中处理时。

要求应当按任务聚合，必须保留未解决异常、不同截止与各项详情入口。分组不得混合不同账号或不同可见权限的内容。预览条数只限制预览，不删除原始记录；摘要失败必须退回确定性列表，生成式摘要不得编造已解决结论。

聚合必须有有限释放时点。固定窗口从组内首个有效候选开始，后续到达不续期；若使用尾随窗口，必须另有不可续期的等待上界。窗口到点必须再次核对偏好和有效性；不允许主动投递时转入可回看的静默结果或明确的下一许可时点，不无限延期。

设计决定：摘要标题说明对象与重要变化，条目保留最早待办截止；已解决事项不挤掉仍待处理事项。

用户侧验证长列表中能找出尚未处理的异常；展开后能区分各自后果与期限。

实现侧验证持续注入更新、矛盾状态、撤权、摘要生成失败，检查释放上界与分组权限。

成对反例最后一条成功掩盖前面的失败 ↔ 为避免遗漏逐条响铃，失去聚合价值。

依据NR05提供更新机制参考；完整聚合合同为项目推导。

N3-2释放与操作前重新核对当前事实¶

适用排队、离线补投、过期通知、深链接或快捷动作。

要求必须在释放队列和执行动作前核对账号、业务对象、当前内容、有效性及业务状态。已处理、撤回或失效的事件必须停止主动提醒和升级；历史可留，但必须标明现状。时效性未知时不得补投带有过时行动承诺的提醒。

查看权限与操作权限必须分别核验。通知按钮不得跳过业务本身要求的确认；请求对象或关键内容已改变时，旧决定不得直接用于新行动。双击、多端重复和超时重试不得重复产生副作用；结果未知时先核对，不得显示已完成。通知消失、打开或已读均不得改写业务结果。

用户侧验证点开过期事项看见“已结束”与可用下一步；重复点击只产生一次业务结果。

实现侧验证注入撤权、换账号、撤回、乱序消息、提交后回执丢失及并发操作；检查提交处防重与结果证据。

成对反例断网恢复后补响已结束的预约确认 ↔ 删除所有历史，使用户无法理解错过了什么。

依据NR05；动作校验和防重是项目必要性推导。

N3-3延后应当形成可检查的安排¶

适用提供“稍后提醒”、自定义时间或安静时段。

要求必须反馈候选提醒时点、时区、生效范围及可编辑或取消入口；只有调度机制已接受安排时才称“已设置”，接受不等于保证届时送达。相对时长与本地钟点必须分别解释，跨时区和夏令时冲突必须有确定规则。

用户延后是新的明确请求，不消耗自动催促额度，也不重置该额度；未点击不得视作延后。延后仍受用户关闭、平台权限和业务时效约束。若候选时点晚于最晚有用时点，必须在确认前说明可能错过窗口，提供更早时点、立即查看或取消；用户仍可选择稍后查看，但不得保留已失效动作或承诺届时仍能办理。

用户侧验证延后后知道何时会再次提醒、如何取消；提醒未能安排时不会误以为成功。

实现侧验证重启、离线、改时区、重复确认、取消后旧任务回调，均能追溯唯一安排与现状。

成对反例“稍后”没有时间也无记录 ↔ 自动额度用尽后拒绝用户主动设定的提醒。

依据项目必要性推导；平台调度结果须在目标产品实测。

N4-1信息能读懂、能感知、能回看¶

适用横幅、角标、声音、触觉或通知中心传递信息时。

要求必须以文本或等价方式表达来源、对象、变化和必要下一步；不得只靠颜色、声音、振动或短暂出现。状态和操作必须具有可访问名称、角色与状态；动态状态消息必须能在不移动焦点的情况下被辅助技术感知。应当合并普通连续更新，避免重复朗读；只有确需即时感知的消息使用紧急播报。

瞬时提示消失后必须有可到达的等价内容；关键操作不得只有短暂入口。产品自行设置的处理时限必须提供可关闭、调整或延长的机制，或记录适用的实时／必要例外。普通回看入口不能替代对限时业务本身的检查。系统控制横幅时长时，不承诺自定义时长已生效。

角标必须定义计数对象及清除条件；未读数、待处理数和未同步数不得混用。文字放大、窄屏和长文本时必须保留关键信息与操作的可达性；通知动效应当支持减少动态效果的偏好。

用户侧验证静音、读屏、键盘操作、放大文字和错过横幅后仍能理解与处理；打开不把待办计数错误清零。

实现侧验证检查无障碍树、焦点顺序、连续播报、隐藏内容及时间限制；分别记录平台承担与应用承担的部分。

成对反例只亮红点，无文字与记录 ↔ 每个进度百分点都紧急朗读一次。

依据NR04、NR08、NR09、NR10。

N4-2处理通知后能够回到原任务¶

适用通知打开详情、跳到其他页面或启动处理流程时。

要求必须保护允许保存的输入、原任务入口与恢复位置，并提供可理解的返回路径。不得为恢复而擅自持久保存凭据等不允许保留的输入。无法恢复时，必须在离开前说明会丢失什么，提供留在原处、先保存或原位查看等可行选择。

处理后必须反馈业务真实结果；未知结果提供核实入口。返回前应当核对权限与对象现状，保护用户已作的新修改，不自动重放产生外部影响的动作。跳到站内页面同样需要这些保护。

用户侧验证编辑半途处理通知再返回，输入、阅读位置和焦点可恢复；失败与待核实能够区分。

实现侧验证测试页面卸载、会话过期、原对象被修改或删除及敏感字段无法保存时的路径。

成对反例点击通知使草稿清空 ↔ 为恢复任务强制重播完整操作历史。

依据NR03；具体恢复机制为项目推导。

N4-3呈现范围与当前受众匹配¶

适用锁屏、投屏、外放、共享设备或包含敏感内容的通知。

要求必须按内容敏感性、账号权限、当前受众和平台设置裁决标题、正文、缩略图、摘要及播报内容。受众未知不得默认公开；应当使用有意义的脱敏提示，并提供经核验后查看详情的入口。通知摘要不得扩大原始事件的可见范围。

退出账号或撤权后，必须停止后续敏感呈现并清理应用可控制的预览；已投递至不可撤回媒介的内容不得宣称已删除。锁屏快捷操作仍须满足动作所需身份核验。

用户侧验证共享屏幕只显示“有一项待确认事项”等必要信息；获授权查看后能理解具体内容。

实现侧验证在锁屏、投屏、读屏外放、账号切换和受众未知下检查所有呈现表面及缓存。

成对反例正文脱敏但标题暴露客户姓名 ↔ 所有低敏提醒都强认证，用户无法快速了解状态。

依据NR05；受众与完整呈现面约束为项目推导。

N5-1同一事件共享提醒计划与停止条件¶

适用站内、推送、邮件、声音或多设备共同参与提醒时。

要求必须以账号、事件和轮次协调主通道、主动提醒目标、回退条件和停止条件。同一轮不得由多个通道或设备各自抢先打断；回执未知不得当作未送达并全面补发。跨端去重与升级共享同一事件身份与同一停止依据；未读本身不使事件变得更紧急。没有可靠协调能力时，必须采用预定单一主动目标或静默回退，不承诺“保证只响一次”。

内容刷新与传输重试不得增加提醒额度；重复提交须共用可防重标识。已处理、过期和关闭优先阻止新轮次。明确失败后可按已获允许的计划有限改投；跨设备已读与业务已处理必须分别同步。用户关闭当前通知后的自动再次提醒条件必须事先明确，未声明时停止该事件自动打断。本条管理的是通用通知策略的声明范围；工业报警、车辆警示等专门功能的可关闭范围与后援由各自领域的合同决定，不得以消费级静默默认覆盖已经承担的专门义务。

用户侧验证在一处处理后其他端不再新发催促；可回看记录仍在，未知状态如实表达。

实现侧验证测试并发调度、回执丢失、离线恢复、已关闭后的内容更新及多端先后处理；核对轮次账目和防重机制。

成对反例手机、电脑和邮件同时催同一事项 ↔ 为避免重复删除所有端的历史入口。

依据项目必要性推导；平台接受与实际呈现能力须分别验证。

N5-2用任务收益与长期负担评估通知¶

适用持续使用的通知类别。

要求必须按类别记录可观测请求、呈现、延后、关闭、失效及有效处理，并声明单位、统计主体、窗口、去重键、分母与缺失处理。不得把已读、已关闭或发送成功当作有效处理，不得仅以点击率证明价值；不可观测部分必须标为未知并报告覆盖率，不按零计入。

应当结合任务结果、错过截止、恢复成本与主观负担，检查同一用户的跨类别总负担。采集必须限制在目的所需的最小信息，规定保留范围与访问者；不得为了度量打扰持续收集屏幕内容。产品必须有负责人可停用无益类别或调整策略。

用户侧验证调整后用户更容易处理有用事项，并能表达打扰感；低点击的知悉类单独评价。

实现侧验证检查分母、观测覆盖、样本差异和缺失值；对比必须同时报告任务效果，不能只报告发送量下降。

成对反例点击率上升就加频率 ↔ 为减少通知量而隐去关键失败，让用户自行反复检查。

依据NR03；指标合同为项目推导。

N5-3突发事件不能突破总负担控制¶

适用批量事件、多个类别或多个生产者可能同时提醒时。

要求必须定义同一接收主体的突发处理策略，限制主动提醒的累计请求，明确统计范围、窗口、额度、排队上界及溢出处置。不得仅限制单事件轮次而放任大量不同事件同时打断；额度必须覆盖并发竞争，分拆类别或重试不得规避。

超出额度应当合并、静默或延后，保留重要待办入口；安静时段结束或断网恢复不得一次性释放所有过往提醒。关键例外必须列明独立依据与有限计划，不得成为无限额出口。用户明确安排的提醒应独立识别，多项同刻发生时仍须有事先说明的合并或排序方式，不应无声丢弃。

用户侧验证批量失败时能看见影响范围、最重要待办和完整列表，未经历连续横幅或铃声。

实现侧验证同时注入多个类别、大量独立事件和并发发送，检查总额预留、释放上界及重要事项是否仍可发现。

成对反例每条只提醒一次，却在一分钟内响百次 ↔ 全部丢弃，用户不知道批量任务失败。

依据项目必要性推导；不存在由引用资料证明的通用每日上限。

4. 从事件到处理的决策方法¶

4.1 先选行为，再选组件¶

非侵入、普通提醒与例外穿透是呈现强度；立即和延后是时间安排。两者分别决定。对通知的权限不自动授予业务动作权限。

4.2 生命周期与裁决顺序¶

通知候选可进入静默记录、排队或请求投递。请求后按可取得的证据分别记录服务接受、设备接收、呈现；已读、关闭、延后是独立用户行为。业务对象单独维护待处理、已处理、失效等状态。某一阶段未知不抹去已知阶段，也不推断后续阶段。

每次候选释放依次核对：业务事实与账号权限 → 用户选择与平台门控 → 最晚有用时点 → 类别与聚合策略 → 跨类别预算及轮次 → 通道协调 → 当前受众与呈现。在提交处再次检查可能并发改变的停止条件。无可行投递时，返回静默、失效或能力不足的明确结果，不无限重试。

聚合窗、延后时点、业务截止、横幅停留、传输重试和负担统计窗口是不同的时间对象，必须分别管理。

4.3 一条完整旅程¶

用户在编辑报告时，后台导出需要重新选择保存位置：

1. 事件登记为“导出待处理”，说明尚未生成文件；编辑中的用户不被抢焦点，任务入口出现可访问状态。
2. 用户许可摘要，系统把同一导出的重复失败聚合；新失败不重置等待上界，预览保留“需要选择位置”。
3. 用户延后，界面显示候选时间与原任务状态；若临时文件即将清除，确认前说明时间冲突。
4. 用户点击通知，先核对当前账号、临时文件及权限，再打开处理界面；草稿与返回位置被保护。
5. 保存位置提交后回执丢失，界面显示“正在核实导出结果”；先查真实结果，不盲目重复写入。
6. 业务确认完成后停止其他端新提醒；用户返回报告，草稿保持；通知历史记录“已完成”，不由已读推断完成。

5. 验收矩阵¶

每项保留输入事实、用户设置、解析后的配置、预期、用户观察、实现证据与限制。判定为通过／失败／不适用并写理由；必须项失败不能用平均分抵消。

文档检查只能证明规则、字段和引用的一致性。平台实际送达、辅助技术表现和用户净收益必须另做目标场景验证；少量通过样本不能证明通知必达或永不重复。

---

实施验收场景¶

以下场景把已有条款转成可复核的验收输入，不另设通用性能阈值。按产品适用能力选取，补充真实设备、用户、输入序列和证据；不适用记录原因，未执行不得记为通过。

每个场景分别核对配置的有效值、执行记录与用户可理解的结果。保留版本、目标、事件时点、失败范围和恢复结果；外部结果未知不填作成功或失败。