iPhone 为什么把通知攒到固定时间再给你？它在管理的不是消息，而是注意力 (2026)

你正在写一段方案，手机亮了一下。你停下来扫一眼，发现只是购物软件的优惠；回到文档时，刚才那句要怎么写，已经要重新想一遍。一天里发生几十次，真正被拿走的往往不是读通知的几秒，而是重新接回原任务的那一步。

iPhone 的 Scheduled Summary 没有把通知关掉，也没有把它们永久藏起来。它做了一个更窄的改变：让你选定的应用先安静地积累，到了你指定的时间，再把它们集中送到锁屏上。Apple 在介绍 iOS 15 时把这项功能描述为按用户设定的时间投递通知摘要，同时让时间敏感的通知、信息和电话立即送达。1

iPhone 锁屏上的通知摘要，显示 9:30 AM 的 Morning Summary 和 11 条通知 — *Apple 在 2021 年介绍 iOS 15 时展示的通知摘要：锁屏上显示 9:30 AM、11 条通知，以及来自多个应用的卡片。它是产品界面截图，不是效果实验。1*

先把 iPhone 的通知分成两条路

这个功能的关键不在「摘要」两个字，而在于它把到达时间从一个统一规则改成了两条路径：

通知类别	什么时候出现	用户或系统做了什么	主要代价
纳入 Scheduled Summary 的应用	到用户设定的时间1	用户选择应用和时间2，系统把多条通知集中投递	当前任务少一次打断，但用户要等到摘要时再看
时间敏感的通知、信息和电话	产生后立即出现1	继续保留一条即时通道	用户仍可能被打断，但紧急联系不会和普通更新一起等待

Apple 的用户指南写得更具体：用户可以在「设置」>「通知」>「Scheduled Summary」中开启摘要，安排一个或多个投递时间，再选择要纳入的应用；摘要会按优先级排列，最相关的通知排在前面。2 3

所以它不是「延迟所有通知」。它延迟的是用户已经判断为可以稍后处理的一部分，并保留了即时例外。这个边界很重要：如果一个设计只会让所有消息安静下来，却没有告诉用户什么必须立即穿透，它提供的是失联风险，不是注意力管理。

通知真正打断的，是接回任务的成本

通知是否造成损失，不能只看用户有没有点开。2022 年的一项实验让 105 名参与者在五种手机条件下完成 Stroop 任务。研究者发现，手机通知会让完成任务所需的时间增加，而且不受手机归谁所有、任务难度高低的影响；单是通知到来，就足以改变任务表现。4

另一项 PLOS One 研究把智能手机通知音和控制声音放进注意力任务。参与者在通知音条件下整体反应更慢，但效应量很小；研究者也把结果限定为对通知影响认知控制的部分支持，而不是「每条通知都会造成严重错误」。5

两项研究合起来，给产品设计一个比「通知很烦」更有用的判断：通知的成本发生在当前任务之外，却由当前任务承担。 用户哪怕只扫了一眼，也要重新找回正在读到哪里、刚才准备比较什么、下一句打算写什么。这个恢复过程未必每次都很长，但它反复发生，就会把连续工作切成许多小段。

Scheduled Summary 的设计推断也因此变得清楚：它不是让用户少获得信息，而是把「什么时候被要求注意」从应用的发送时刻，交还给用户的检查时刻。Apple 的页面说明了功能如何工作，却没有把这项功能当成一项减少错误或提高生产率的对照实验；后面的判断属于基于界面和相关研究的设计分析。

它用三个动作把注意力重新排了一次队

1. 先让用户决定哪些通知可以等

开启摘要时，用户要选应用。这个设置不是单纯的权限开关，它让用户先回答一个现实问题：这个应用发来的东西，错过几分钟会不会造成外部后果？购物更新、游戏奖励和普通资讯，通常可以进入等待队列；值班电话、正在进行的交易或需要及时回应的联系，则需要另一条路径。

这一步把「重要」拆成了两个维度：内容对我有没有价值，以及它是否必须现在打断我。很多通知看起来重要，却不需要在产生的那一秒处理。把这两个维度混在一起，结果通常是所有应用都争夺即时通道。

2. 把多次提醒合并成一次检查

摘要到达时，用户看到的不是一长串按时间滚动的提醒，而是一个带时间标签的集合。Apple 展示的界面里，摘要写着「9:30 AM」，旁边有通知数量，下面再展开来自不同应用的内容。1

这是一种外部认知：用户不必在每条通知出现时都记住「稍后还要去看」，系统把待检查的内容暂时放在一个可回看的容器里。它减少的是检查时机的分散，而不是信息本身。

不过，合并也会制造新的问题。通知如果积得太多，用户只是把多次小打断换成了一次大清单。NotiModes 研究在四周的实地评估中最后保留了 13 名参与者；一些参与者喜欢延迟后成组出现的通知，也有人觉得一个时间段结束后一次涌入的数量太多。研究者还记录到，用户更愿意自己设定延迟，并希望对不同应用、联系人和紧急情况设置例外。6

3. 用排序降低一次检查的搜索成本

Apple 的用户指南称，通知摘要会根据用户当前活动按优先级排列，把更相关的通知放在前面。3

这说明摘要不是一个简单的「按时间堆起来」的收件箱。它还承担了第二层工作：当用户终于愿意打开这个集合时，先把可能更值得看的内容放到前面。对设计师来说，批处理和排序必须一起评估。只做批处理，用户会面对更大的清单；只做排序，却保留每条通知的即时弹出，注意力仍然会被频繁拉走。

这套方案的失败边界在哪里

Scheduled Summary 适合的是「可以晚一点看，但不能永远丢掉」的信息。它至少有四个边界需要在设计评审中单独检查：

紧急程度不能靠应用类别完全代替。 同一个应用里既可能有普通更新，也可能有必须马上处理的消息。系统需要让用户或发送者标出例外，否则「延迟应用」会把真正紧急的内容一起压住。NotiModes 的参与者正是因为担心错过重要消息，才对固定延迟保持谨慎。6
摘要大小要能被一次处理。 如果用户打开时只看到几十条没有分组的卡片，产品只是把打断集中化，却没有减少检查成本。要问的不是「能不能汇总」，而是「用户能否在一眼内判断哪些要点开」。
排序必须允许用户纠正。 系统根据当前活动推断优先级，用户却可能有临时任务、值班安排或个人关系。评审时要确认：用户能否看懂排序依据，能否调整应用范围，重要联系人能否穿透等待队列。
延迟要和可达性一起设计。 延迟模式如果没有即时例外，用户可能为了不漏消息而彻底关闭它。NotiModes 的研究中，最初招募的 35 人有 18 人中途退出，研究者记录的原因之一就是消息服务的受限感太强；这个结果来自小样本原型研究，不能直接当作 iPhone 的使用结论，但足以提醒设计师把「我还能不能被找到」放进评审。6

带回设计评审的五个问题

把这个案例转成方案比较时，可以先不讨论要不要照搬 Apple 的界面，先问下面五件事：

评审问题	要核对的设计事实	如果答案不清楚，可能出现什么
这条通知的截止时间是什么？	几分钟后处理，结果是否仍然相同	所有内容都被当成即时事件
谁能决定它进入等待队列？	用户、应用、发送者是否拥有不同的控制权	用户为了安全只能全部放行或全部关闭
等待期间，用户能否知道自己没有漏掉它？	是否保留可回看的位置、数量和时间线	延迟变成隐形丢失
摘要打开后，第一眼应该先看什么？	是否有可靠的排序、分组和摘要线索	批处理后仍要逐条搜索
紧急情况如何穿透？	时间敏感、联系人、上下文和人工例外是否存在	用户因为害怕漏消息而放弃安静模式

这五个问题也揭出了一个常见误区：设计师很容易把「减少通知」当成目标，却忘了用户真正需要的是在不被每件小事叫走的同时，保留对大事的控制感。iPhone 的做法值得借鉴的不是某个开关名称，而是把通知的到达时间、信息优先级和紧急例外拆成了不同的设计决定。

结尾：让系统替用户守住一个检查时刻

通知摘要没有证明用户从此更专注，也没有消除信息遗漏的风险。它解决的是一个更具体的问题：应用什么时候可以占用注意力，不应该完全由应用发消息的时间决定。

当内容可以等待时，系统把它们收进一个有时间标记的集合；当内容可能造成外部后果时，系统保留即时通道；当用户终于开始检查时，系统再用排序减少搜索。对于任何需要提醒、消息或更新的产品，设计评审都可以从这条因果链开始：先判断截止时间，再安排到达方式；先保留紧急例外，再决定怎样批处理；最后验证用户能否在一次检查中找回真正重要的事。