Claude Duet 带来的产品难题：AI 没有提醒，究竟检查过什么？

10 月 21 日发布、今天早报继续关注的 Claude Duet，让小团队看到了一种新的产品承诺：用户离开后，助手继续工作，遇到需要关注的事情再主动提醒。真正难设计的，却是它什么都没说的那段时间。它是检查过后认为没有重要变化，决定稍后汇总，还是已经失去访问权限、没有额度继续检查？

如果你正在做 AI 运营助手，这几种结果不能共用一个让人安心的绿色状态。只有用户知道静默背后的检查范围，静默才有价值。 否则，安静的界面可能让人依赖一项根本没有发生的工作。

本文面向在邮件、日历、客户请求等业务来源上设计后台监测的非技术创始人和小型产品团队。我们把 Duet 的发布转化为一个具体问题：产品至少拿出什么证据，才有资格暗示“你可以不用再自己盯着”？下文提供一个日历与客户沟通场景、一份覆盖检查表，以及同时检查漏报和多余提醒的试点方法。这些是建议采用的设计方法，不是 Duet 实测结果，也不是对其内部实现的描述。

1. 先看清这次发布的承诺边界

Anthropic 的 Duet 官方介绍将产品定位为研究预览，起步阶段向美国 Pro、Max 用户开放候补名单。官方说明，系统每隔数小时检查已连接账户，后台工作与订阅计划共用用量，也承认对紧急程度的判断可能出错。这是厂商的功能说明，不能当作独立测量过的服务水平。

这会直接影响采用决策。创始人可以研究这种交互方式，但不能据此假定自己一定能获得访问资格、监测不会中断，或者事件必定在某个时间内被发现。如果你的下一个产品承诺依赖分钟级升级提醒，这篇发布文章不足以证明该依赖能够满足要求。应取得对应的服务行为证据，或继续让现有渠道承担紧急事件通知。

这次发布清楚展示了一个方向：助手不再等下一条提示，而是判断什么时候来找人。但完成任务和管理人的注意力，是两种能力。有用的草稿可能来得太晚；正确的发现可能打扰了错误的人；没有发现问题，则可能让用户产生错误的安心感。

借鉴这种交互前，先写清自己的业务任务。“帮我跟进所有工作”无法审查。“在每天规划工作之前，检查指定客户项目邮箱和日历中新出现的日程冲突”，则有数据来源、时间边界、使用者和可核对的结果。它也会暴露一个事实：当前定时检查是否慢到无法兑现承诺。

2. 给“没有提醒”一套能解释清楚的状态

检查尝试，是产品试着访问某个来源。覆盖范围，是它真正成功检查了哪些内容，数据覆盖到什么时间，包含哪些对象。新鲜度，是这些证据距离现在有多久。可用决策时间，是用户为了保留有用选择，还剩多少时间可以采取行动。这些词描述产品行为，不是模型对自己回答有多自信。

例如，“日历已于 09:00 检查”仍然没有交代很多问题：查的是不是正确日历？是否读完了所有分页？查询有没有包括刚修改的重复事件？来源返回的数据真的更新到 09:00，还是接口给了较旧的快照？产品不必把每条内部日志都展示出来，但状态不能超过团队实际能够核实的范围。

可以面向用户区分四类结果：已检查、没有符合提醒条件的事件；已检查、有事项留待摘要；仅完成部分检查；尚未检查。邮箱中的一个文件夹可能已更新，另一个却因授权失效无法读取。前者成功，不能让整个账户显示“一切正常”。留待摘要的事项也应仍能找到，即使它没有触发推送。

这与动作账本不同。我们不是在问一封获批邮件有没有发出，而是在问：在提出任何动作之前，观察过程是否已经足以让用户依赖它。这也不同于执行记忆提醒；这里被提醒的是人，产品改变的是人的注意力安排和备用检查习惯。

界面上的实际做法是：允许用户从安静状态展开来源清单。主界面给简短状态，详情页说明具体范围。保持安静和允许核查可以同时做到，无须实时播放每一步内部过程。

3. 从决策截止时间倒推检查节奏

设想一家虚构工作室使用 BriefWatch 助手，读取指定项目邮箱和日历，在创始人开始客户通话前发现冲突。这里是用于设计讨论的假设场景，不是客户案例，也没有实测结果。

09:10，客户把通话改到 10:00。创始人需要二十分钟准备，并可能到 09:40 才结束路途。09:55 才发现变动，与 09:20 就发现，能保留的选择完全不同。只把这条通知评价为“准确”，就漏掉了真正的产品失败：用户有没有足够时间决定和准备。

从这个目标往回推，要给下一次检查、读取全部相关记录、理解内容、送达提醒，以及人的实际响应都留出时间。这些延迟共同消耗可用决策时间。如果允许的最慢检查节奏，已经不足以给用户留下准备时间，再聪明的紧急程度提示词也修不好这个错配。需要缩小承诺、在可行处加快观察，或采用直接事件通知并保留备用渠道。

Google 的 SRE 监测章节区分用户可感知的问题与底层原因，并强调提醒应便于理解。借用到这个场景，“准备窗口正在关闭”是业务层的问题，连接器重试是值得排查的原因。不必把每一次重试都发给创始人；但如果重试已经破坏承诺的覆盖范围，就应明确展示。

因此，BriefWatch 的第一轮试点可以只负责次日规划，而不负责抢救即将开始的会议。这少了一些戏剧性的演示，却让采用决策变得可验证。用户继续依赖原生日历处理临近会议变化；助手先证明自己能完成一个有边界的检查，再承担已有渠道负责的及时性任务。

4. 增加智能之前，先填一张覆盖检查表

下面是供你自己的产品使用的建议模板。先针对一个监测承诺填写，来源或用户预期改变后再重新检查。示例值都是场景中的规划选择，不是 Duet 配置，也不是普遍适用的阈值。

这张表能阻止两种常见的规格偷懒：“监测邮件”不是来源范围，“重要就提醒”也不是决策截止时间。它们都无法帮助审查者判断，助手究竟漏掉了相关事件，还是正确地保持了安静。

让创始人和构建者一起填。如果双方对“明天”怎么算、是否包括共享日历、被静音的文件夹是否继续监测有分歧，应在测试模型质量之前解决。这些是产品规则。留给模型临场推断，即使单条回答看起来合理，也会形成不一致的预期。

试点记录还应保留当时约定的策略版本。否则，审查者可能拿新规则评价旧的静默决定，把策略变化误判成模型退化。这份表要让双方都能说清：本次实际验证的，到底是哪一个产品承诺。

覆盖范围调整也应当作产品变更，并注明生效时间。增加共享日历、移除收件文件夹，或改动每日规划时点，都会改变哪些事件值得关注。记录谁提出变更、影响哪些来源和决定，以及新规则从何时执行。旧观察应保留产生时的策略；需要重评的事项应显示为一次新检查，而不是悄悄改写过去的状态。

团队责任变化也要这样交接。覆盖恢复负责人离职或休假时，接手人需要的不只是连接凭据，还包括尚未解决的覆盖空档：最后一次成功观察是什么时候，哪段时间仍未补查，影响哪项决策期限，以及用户被告知采用什么备用流程。对持续未解决的空档安排复核时点。内部客服工单关闭，不应自动恢复绿色覆盖标识；只有实际检查完相应范围，才有资格恢复。这些是本文建议的运营规则，应与通知逻辑一起用虚构事件演练，再请用户依赖。

5. 决定提醒，不等于提醒真的到达

助手可能正确决定了要通知，用户却完全没看到。设备离线、渠道关闭、摘要延后，或人暂时离开，都可能造成这种情况。“已发送”不能证明用户收到、理解或采取行动。这几步需要分别记录，也需要不同证据。

Apple 的通知设计指南建议通知简洁、有价值，避免围绕同一件事反复打扰，并提醒设计者防止泄露敏感内容。对于 BriefWatch，锁屏通知可以只说有一项规划事项需要查看，不展示客户的保密项目细节；证据留在需要登录的页面中。

Android 的通知渠道文档说明，用户可以控制渠道行为并修改重要程度。因此，应用自己选择“紧急”，并不能保证一定打断用户。引导阶段应说明相关设置入口和备用方案，也应尊重用户主动静音的选择，不要反复催促恢复。

尚未解决的观察结果应保留在容易找到的位置。用户稍后回来时，要能看见发生了什么、为什么重要、何时发现，以及有用的响应窗口是否已经过去。过了期限仍沿用原来的紧急措辞，有时比不提醒更糟：它让人处理一个已经不存在的选择。

后续提醒应对应事先约定的实质变化，例如截止时间进一步提前。用户没有回应，不代表产品可以自动从推送升级到邮件、短信和聊天。每增加一条渠道，都会增加隐私暴露与打扰成本；升级目的地、时机和停止条件，都应让用户明确选择。

6. 用完整事件清单审查静默决定

只审查通知，会留下危险的测量盲区。团队看得见每一条提醒，也能判断它是否烦人，却没有检查那些从未触发通知的事件。提醒越来越少，看起来像是产品进步，实际却可能错过更多期限。

可以用获得同意并妥善保护的示例，或合成测试样例，建立一个小型回放集。审查者先为每个事件确定预期结果，再看助手的选择。集合中应包括相关变更、无关变更、含糊变更、来源故障、迟到事件，以及已在别处解决的事件。除了事件自身的时间戳，也要保留系统当时能够观察到它的时间，避免测试利用未来信息。

每个案例分别记录：是否在范围内、是否成功观察、理解是否正确、是否送往合适位置、是否在有用窗口内到达，以及用户是否理解。这样才能分清模型分类漏判与来源中断。产品根本没有读到的事件，不可能靠修改提示词找回来。

先按时间顺序回放，再进入影子运行：保留原有检查习惯，同时审查助手的判断。审查者既要看提醒，也要抽查静默时段。对于关键事件类别，应检查试点中全部可用案例，不能指望随机抽样恰好包含罕见漏报。小样本可以揭示缺陷，却不足以证明总体失败率已经可靠。

始终保留两个分母：全部应覆盖事件，以及实际成功覆盖的事件。缺失覆盖单独报告。如果准确率只在成功读取的数据里计算，产品可能在来源访问频繁失败时仍显得非常优秀。如果连有边界的试点都无法列清应覆盖事件，就继续缩小范围，直到可以列清。

与现有做法比较时，应使用相同事件集和决策截止时间。分别问：漏掉了什么？发现时还给用户留下哪些有用选择？不要拿真实运行的助手，与一个假想中永远把所有来源都检查得完美的人比较。

7. 第一次演示就加入那些不起眼的故障

接入更多来源之前，先在测试账户里演练以下情况。这是对你自己实现的建议检查，不是已经发现的 Duet 缺陷。

第一，让一个来源失去授权，另一个保持正常。界面应变为部分覆盖，指出缺失范围，停止暗示已经全面检查。重新连接后，还要确认中断期间是否真的补查。一次新的成功检查，不能证明旧空档已恢复。

第二，在一次定时检查刚结束后加入新事件，观察下一次检查是否还留有足够决策时间。如果目标用户涉及夏令时切换、出差时区或周末边界，也应逐一重复。“明天”应是面向用户的业务规则，不能简单等同于服务器日期。

第三，耗尽测试预算，或模拟额度拒绝。产品应通过合适的可见状态和事先约定的渠道披露覆盖中断，不能悄悄从承诺的节奏退化成偶尔有空才检查。支出上限只有在用户也理解服务缩水时，才真正保护业务。

第四，关闭推送。事件仍应留在产品里，不能声称用户已经确认。随后在原始来源中解决事件，再恢复连接。系统不能因为通知队列重新开始发送，就把过期事项重新包装成紧急问题。

最后，对同一事件发送多次更新，其中包括更正。检查用户看到的是一条能理解的历史，还是一叠相互混淆的提醒。较旧消息不能覆盖最新确认状态。要审查最终界面和静默时段，不能只看后台函数是否全部成功返回。

Nielsen Norman Group 的智能家居通知研究讨论了及时性、相关性、强度和频率。这支持我们提出这些设计问题，但不能据此确定业务助手应该多久提醒一次，更不能证明某个 AI 实现会提高留存。

8. 允许用户纠正规则，别替用户猜反馈含义

“没用”是一种含糊反馈：可能来源不对、时间不对、收件人不对，可能事件早已解决，也可能只是内容太多或用户不想看这个类别。把每一次划掉都理解为“以后永远别再提醒”，可能会压掉下一次真正重要的事件。

Google PAIR 的 Feedback + Control 章节讨论隐式反馈、显式反馈与可理解控制之间的关系。试点里可以提供几项可选原因，并允许用户检查产生了什么偏好变化。划掉应先表示关闭当前事项；修改长期监测规则，应是另一个容易理解的明确选择。

例如，BriefWatch 中“放进明天的摘要”只改变当前事项的送达时机；“只在工作日检查这个客户”会改变重复执行的策略；“选错日历了”则是在纠正来源范围。界面不能把三者压成同一个模糊的“不喜欢”。用户应能撤销修改，规则在临近期限制造覆盖空档时，也应得到解释。

安静的体验还必须适用于辅助技术使用者。W3C 状态消息说明解释了如何在不夺走焦点的情况下传达状态变化。应测试覆盖变为不完整、刷新完成等有意义的转换，避免视觉上很安静，屏幕阅读器却播报每一次后台更新。

静默本身也不是人人都想要的结果。原始的关闭通知二十四小时研究记录了三十名志愿者的混合体验：减少分心的同时，也有人担忧不能及时回应。这项研究年代较早、样本较小，更不是对当代智能体的测试。它提醒我们，减少打扰存在取舍；访谈不仅要问产品是否安静，也要问用户害怕漏掉什么。

9. 决定产品目前赢得了哪一份责任

试点结束后，应明确选择产品承担的责任。观察助手可以只整理待审清单；摘要助手可以在指定时点汇总检查过的来源；主动提醒助手则会在约定条件成立时来找人。这是不同的产品承诺，不是所有应用都必须依次升级的阶段。

如果用户觉得整理结果有用，但及时性仍不稳定，就保留摘要定位。覆盖范围解释不清，就限制来源。审查者无法对哪些事值得打断达成一致，就暂缓主动通知。对于漏掉事件的代价超出团队已有证据的场景，应保留人工流程或原始来源的直接提醒。安全关键、医疗、金融和紧急升级，需要领域专门控制，本文的产品设计表不足以覆盖。

评价试点时，要同时看保住了哪些有用决策、产生多少多余打扰、漏掉哪些范围内事件、出现哪些未覆盖时段，以及恢复需要多少工作。算力和支持成本也要放在旁边一起看。通知减少或模型调用增加，本身都不等于成功或失败。核心是：人在可接受的运营负担下，是否能带着更少的隐性不确定性做出承诺中的决定。

扩大使用范围之前，请一位新用户用自己的话解释静默状态：产品检查了什么、排除了什么、证据有多旧、覆盖失效时应该怎么办。如果他把“没有待审事项”理解为“所有已连接来源都在持续监控”，即使底层试点通过，界面仍在过度承诺。

Duet 让主动式助手成为今天值得讨论的产品问题。小团队的机会，是先在用户的一天里赢得一个范围明确、能够信赖的角色。从可核对的承诺开始，让观察空档可见；只有证据和用户理解指向同一项承诺时，才扩大责任。

参考资料

1. Anthropic：Introducing Claude Duet，2026 年 10 月 21 日。
2. Google SRE：Monitoring Distributed Systems。
3. Apple 人机界面指南：Notifications。
4. Android Developers：创建和管理通知渠道。
5. Nielsen Norman Group：Designing Useful Smart Home Notifications。
6. Google PAIR：Feedback + Control。
7. W3C：理解成功准则 4.1.3，状态消息。
8. Pielot、Rello：Productive, Anxious, Lonely — 24 Hours Without Push Notifications。