题目重点：让不同应用生成并展示通知，设计 app 身份、用户偏好、展示队列和过期；面试另考察提示词迭代与 AI 输出评估。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版系统边界是本机 OS 通知路由服务，app 以已验证 appId/进程身份调用 publish；用户可按 app 控制许可与勿扰。
- 通知有 notificationId、appId、content、createdAt、expiresAt、priority；这些是训练 API 契约，非题目字段。
- 展示至少一次可接受，但同 notificationId 的重试不重复弹出；历史中心可持久化最近通知，具体保留期须问。
- AI 工具用于生成方案和边界测试建议，所有权限/并发/过期代码要人工审查与实测。
解题路线
- 先定义生产者、路由器、用户展示组件、历史存储的边界。app 发起 publish 时核对其身份与权限，校验内容长度/动作 URL，防一应用冒用另一应用。
- 路由按用户许可、勿扰、优先级、过期与 rate limit 决定入展示队列；受抑制通知若仍需进入历史中心，产品合同应明确。
- notificationId 作幂等键，持久化状态机 CREATED→QUEUED→SHOWN/EXPIRED/DISMISSED；重复 delivery 与用户点击通过版本状态避免二次动作。
- 高峰时按 app 和用户设队列配额，通知合并/折叠以免某 app 淹没界面；展示线程与持久写分离，但崩溃恢复时不能错误重弹已读通知。
- AI 面试环节可先向 AI 提供明确需求/威胁模型，请其列架构选项；第二轮 prompt 针对权限绕过、崩溃恢复和通知风暴；最后用不变量、状态测试、日志和性能量测评估答案，而不是‘AI 说可以’。
手动走一遍
App A 以 notificationId=7 发两次同一请求，路由只接受一次。用户禁用 A 时不展示；若 B 同时发大量通知，B 的限额不能阻塞 A 的重要消息。通知过期后被从待展示队列清掉；是否保留历史需产品确认。
规模与取舍
按 notificationId 的去重与状态查询预期 O(1)，队列入出 O(log Q) 若按优先级堆；存储量约通知写入率×保留期。多 app 通知峰值、UI 展示速率和 OS 重启恢复是容量关键；题目未明确具体 QPS，不能代填。
易错点与追问
容易失分的边界
- 只设计可视 UI，不认证发通知的 app 身份。
- 重复重试产生多次弹窗或按钮动作。
- 勿扰/过期与展示队列状态不一致。
- 把 Windows 内部具体系统 API 当题目要求。
- AI 辅助后没验证边界和代码，却声称 prompt 很好就足够。
继续深挖
- 跨设备同步已读/撤销时如何避免旧设备重弹？
- 紧急通知可否绕过勿扰，授权边界是什么？
- 如何度量 AI 建议的质量与回归风险？
- 多应用通知风暴怎样公平排队？
