你手机每天替你做的那个决定——1999 年这篇论文早就写好了代码
- 关联论文：1301.6707
想象一下这个场景：
下午三点，你正在写一份季度汇报，写到第二段。手机在桌上震了一下，屏幕亮起一个微信红点。你瞄了一眼——是某个同事在群里问"今晚吃啥"，还有一条快递通知、一条微博推送、一封老板的邮件。
你大概率会：忽略微信、看一眼微博、不动快递、把老板的邮件标记为稍后处理——然后继续写汇报。
但你有没有想过——iOS 通知摘要、macOS 专注模式、安卓自适应通知，这些你习以为常的"系统替你做决定"的功能，是怎么诞生的？
答案藏在 1999 年的一篇论文里：Horvitz 的《Attention-Sensitive Alerting》（arXiv 1301.6707，原 UAI 1999 论文，2013 年才上 arXiv）。这篇被工程圈引用 390 次的奠基论文，提出了一个现在看来理所当然、当时却极其反直觉的问题：
"通知该不该打断你"——这不该是规则问题，而该是一个期望效用最大化决策问题。每条消息到达时，系统要在毫秒级算清楚：打断你值多少钱？延迟这条消息值多少钱？
换句话说：当所有 app 还在"消息来了 = 立即推送"时，最聪明的那个人选择——把每条通知都当一道数学题做。
一、为什么这件事对今天的你和产品经理都很关键
你可能不写论文，但你一定被这些画面刷到过——
- 「iOS 15 通知摘要功能上线，每天帮你合并 5 次通知轰炸」
- 「macOS 专注模式：在深度工作时间自动屏蔽所有打扰」
- 「Slack / 钉钉的免打扰时段：下班后消息自动延迟到次日早晨」
这些功能每天都在替你工作——但它们的"哲学源头"全在 26 年前的这篇论文里。
- Horvitz 1999 = "通知是决策问题，不是事件总线问题"——整套 Attention-Sensitive Computing 范式的奠基论文
- 微软 Outlook Priorities = 这套框架的第一个产品化形态，跑在 MSR 内部 + 后扩展到企业市场
- iOS Notification Summary (2021) = 把效用决策 + bundle（合并）推到 OS 层，是 1999 框架的直系后代
- macOS Focus Mode / Android Adaptive Notifications = 同样继承这套决策框架
更重要的是：今天所有做 RAG Agent、做 AI 助手、做 AI Coding 工具的团队，都在重新面对 Horvitz 26 年前提出的同一道题——"AI 何时该打断用户？"
当你让一个 AI agent 帮你做 30 分钟的代码重构，它在第 5 分钟跳出提示"需要确认一个 API 选型"——该不该打断你？这是 Horvitz 框架的现代翻版。
二、Horvitz 到底干了什么——期望效用最大化
1. 决策框架：把每条通知当一道数学题
每条通知 m 到达时，系统算三件事：
EU(立即推送) = P_critical(m) × U_now − (1 − P_critical) × C_interrupt
EU(延迟到 t) = P_critical(m) × U_late(t) − (1 − P_critical) × 0
EU(忽略) = 0
选择动作 = argmax{ EU(立即), EU(延迟), EU(忽略) }
其中： - P_critical(m) = 消息 m 在当前上下文下"关键"的概率（0~1 之间） - C_interrupt = 中断成本——注意，这个值不是常数——如果你在写代码、做深度会议，C_interrupt 比刷网页时大一个数量级 - U_now / U_late = 立即送达 / 延迟送达的效用
核心创新：C_interrupt 不是固定数字，而是用户当前 activity 的函数。这是 1999 年的超前洞察——今天的 iOS 专注模式、Android Adaptive Notifications 都还在沿用这个建模思路。
2. 关键性推理（Priorities）
消息的关键性 P_critical(m) 通过一组"信号源"估计：
| 信号源 | 怎么算 |
|---|---|
| 发件人身份 | VIP list / 组织树 / 历史协作密度 |
| 关键词 | "urgent"、"ASAP"、"production" 等词典 |
| 邮件线程 | 线程中过往消息的响应速度 |
| 时间上下文 | 周末、深夜、工作时间窗 |
| 用户当前 activity | 编码 / 会议 / 离线状态（这是 1999 年最大的创新） |
这些信号进入贝叶斯网络/决策树，输出 P_critical(m) ∈ [0,1]。
3. 决策空间不止"推/不推"
论文最有远见的部分是——决策不止 binary，而是三维笛卡尔积：
ALERT_DECISION:
action ∈ {IMMEDIATE, DEFER(t), BUNDLE, SUPPRESS, PREVIEW_ONLY}
channel ∈ {POPUP, SOFT_TONE, TASKBAR_BADGE, VIBRATION}
intensity ∈ {FULL, SUMMARY, SUBJECT_LINE_ONLY}
什么时候推、用哪个通道、推多详细——这是现代通知系统设计语言的起点。iOS 把这条思路推到极致：通知可以是"全屏弹窗 / 横幅 / 仅通知中心 / 仅摘要"四种 intensity，对应不同打扰等级。
4. 伪代码骨架（核心逻辑）
on new_notification(m):
user_state = sense_user_activity() # 键盘/鼠标/日历
p_crit = PrioritiesClassifier.predict(m, user_state)
cost_interrupt = lookup_C_interrupt(user_state.activity_type)
EU_immediate = p_crit * U_now - (1 - p_crit) * cost_interrupt
EU_defer = p_crit * U_late(defer_window) - (1 - p_crit) * 0
if EU_immediate > EU_defer + threshold:
deliver(m, channel=chosen_channel, intensity=chosen_intensity)
else:
schedule(m, at=next_attention_window)
三、为什么这件事 26 年后还值得读
1. 你每天都在用它的"后代"
iOS Notification Summary、macOS Focus Mode、Android Adaptive Notifications、Slack 免打扰时段——这些是当代人每天接触的功能，但没有人问"这套决策逻辑最早是谁写的"。
Horvitz 1999 = "通知是决策问题"的奠基论文 = 26 年后所有 OS 通知系统的共同祖先。
2. 它定义了"中断成本"这个概念
1999 年之前，"通知该不该发"是个工程经验问题；1999 年之后，"中断成本 C_interrupt"成了一个可建模、可调参、可 A/B test 的工程变量。这是从"凭感觉做 UX"升级为"用效用推理做 UX"的关键转折。
3. 它是 AI Agent 时代的"前置论文"
今天所有做 RAG Agent、AI Coding 助手、智能客服的团队，都在重新面对 Horvitz 26 年前提出的同一道题——"agent 何时该打断用户？"
P_critical → 重新理解为：这条 agent 输出对用户来说"关键"的概率
C_interrupt → 重新理解为：打断用户当前任务（写代码/做报表/写邮件）的成本
U_now / U_late → 重新理解为：立即给答案 vs 延迟给答案的效用差
直接套用 Horvitz 框架：每个 AI agent 的"主动提示"功能，都应该走 sense → infer → decide → modulate 四步，而不是"模型想说就说"。
4. 它示范了"AI 落地跑在学术发表前面"
原 UAI 1999 论文 + Priorities 系统已经运行多年才在 2013 年正式公开——这间接说明，工业落地跑在学术发表前面。这种"先做产品再写论文"的范式，今天做 AI Agent 的团队应该熟悉。
四、对工程落地的硬约束（Jay 核查）
核查：事实与存疑点
- 数据集未发布：优先级分类器训练数据 + 用户 activity ground truth 未开源，后续研究者难以复现。
- 缺乏现代 benchmark 对照：论文没有与今天习以为常的"transformer 通知分类器"或"LLM 通知摘要"做对比；其性能只能从 UX 调查间接推断。
- 成本函数主观性强：C_interrupt 的具体数值来自用户自报告，存在 social desirability bias。
- 未覆盖团队协作多用户场景：现代工作流中"通知该不该打断我"还取决于"队友是否在等我响应"——论文以单用户为主，对协作场景的"social cost" 建模薄弱。
- 2013 年才上 arXiv 的历史原因：原 UAI 1999 论文 + Priorities 系统已运行多年才公开，引用时需注意时效性。
现实路径
- 不要从零造这套系统：直接用 OS 自带的 Focus Mode + iOS Summary + Outlook Focused Inbox——这些是 1999 框架的工业实现版本。
- 做 AI Agent 时：把"agent 主动提示"功能套用
P_useful × U_now − P_notuseful × C_interrupt公式，C_interrupt 参数按用户 activity 做 tunable table，供 A/B test 调参。 - 数据飞轮：用户对通知的反应（点开/忽略/屏蔽）应作为标签回流到关键性分类器，形成 online learning 闭环。
- 隐私合规：键盘监控/鼠标跟踪属于敏感数据，GDPR/CCPA/Android 14+ 政策要求明确授权 + 最小化。建议采集聚合特征而非原始行为，设备端推理不上报原始数据。
五、给 AI 产品经理的 3 个具体启示
- 不要把通知系统当事件总线：每条通知都该走
sense → infer → decide → modulate四步，不要只做"消息来了 → 推送"。 - 显式建模 interruption cost：任何"智能通知"系统的设计要点，必须先回答"被打断值多少钱"——这是 Horvitz 框架最大的工程遗产。
- 延迟不是失败，bundle 是高级形态：把多条同类通知合并为 digest，降低单条打断频率，是直接可学的工程动作。iOS Summary 每天给你合并 5 次就是这个原理。
六、一句话总结
Horvitz 1999 年的这篇论文把"通知该不该打断你"从 UX 工程问题重构为期望效用最大化决策问题，发明了"中断成本"这个概念、贝叶斯推理 + 效用决策的完整框架、三维决策空间（action × channel × intensity），直接催生了今天 iOS Notification Summary、macOS Focus Mode、Android Adaptive Notifications 共同的设计语言——这是 26 年来最被低估的一篇 AI 论文，也是今天所有做 AI Agent 主动提示功能的团队应该抄的"前置论文"。
论文 arXiv：https://arxiv.org/abs/1301.6707
三个标题变体
反直觉版：你手机每天替你做的那个决定——1999 年这篇论文早就写好了代码 数字钩子版：26 年前的效用推理公式，至今还在你的 iOS 通知摘要里跑着 类比版：AI 通知系统的"宪法"：Horvitz 1999 用期望效用最大化，重新定义了"打扰"
📱 小红书风格卡片文案（可直接发布）
🤖 你手机每天替你做的那个决定，是 26 年前这篇论文写好的
为什么 iOS 通知摘要、macOS 专注模式能替你合并通知、屏蔽打扰？
背后站着一篇 1999 年的奠基论文。
🔍 它干了什么反常识的事？ - 把"通知该不该打断你"从 UX 工程问题重构为期望效用最大化决策问题 - 每条消息到达时，系统要算：打断值多少钱？延迟值多少钱？ - 发明了"中断成本 C_interrupt"这个概念——它不是常数，而是用户当前 activity 的函数
💡 3 个让工程圈沉默的洞察： 1️⃣ 决策空间不止"推 / 不推"：是 action × channel × intensity 三维笛卡尔积 2️⃣ 多通道调制优于单通道开关：iOS 把这条推到极致——通知可以是全屏弹窗/横幅/仅中心/仅摘要四种 intensity 3️⃣ 延迟不是失败，bundle 是高级形态：iOS 每天合并 5 次通知轰炸 = Horvitz 框架的现代实现
📌 对今天的硬约束：
- 做 AI Agent 主动提示功能？直接套用 P_useful × U_now − P_notuseful × C_interrupt 公式
- 不要把通知系统当事件总线——每条通知都该走 sense → infer → decide → modulate 四步
- 显式建模"打断值多少钱"——这是 26 年前的论文里就写好的工程遗产
🔗 arXiv：https://arxiv.org/abs/1301.6707
📊 Semantic Scholar 被引 390 次