AI 伴侣如何避免在错误的重要日期发出提醒？

为什么记住日期不等于排期提醒

一段对话可能包含有用的事实，但这并不意味着用户授权了创建提醒。“玛雅的演奏会在 5 月 14 日”可能是用户分享的一条备忘、一个暂定计划，或者是从模棱两可的措辞中推断出的日期。这句话本身并没有指明是否需要提醒、属于哪一年、几点发送，或应使用哪个时区。

因此，可靠的设计会将它们视为独立的记录：

**记住的事实：** 用户所说或提供的内容，附带其来源和任何不确定性。

**已确认的日期：** 经用户核对的对象或事件以及具体日历日期。

**已排期的通知：** 用户明确批准的提醒，包含发送时间、时区和当前状态。

这种分离是针对 AI 伴侣的一项设计建议。Google 日历的帮助页面介绍了如何在日历中创建活动和管理通知；它们并没有描述 AI 伴侣的记忆机制，也没有实现本文提出的工作流程。仅作为一个日历示例，Google 的说明将创建活动视为一项包含活动详细信息和保存步骤的操作（[Google 日历：创建活动](https://support.google.com/calendar/answer/72143?hl=en)）。

在排期前应确认哪些细节？

确认决定提醒含义及触发时间的具体细节。简短的复核界面或对话摘要应展示：

**对象或事件：** 该日期与谁有关，它指的是什么？

**完整日期：** 日、月、年。只有月和日而缺少具体年份可能并不完整，尤其是当它可以指过去或将来的事件时。

**日期来源：** 该日期从何而来——例如，用户的陈述、导入的日历条目还是推理得出的？应明确指出不确定性，而不是将猜测当作定论。

**提醒时机：** 所要求的提前量和本地具体时间，例如“提前一天上午 9:00”。

**时区：** 决定发送时间的时区，特别是当用户出行或该日期涉及异地人员时。

**授权与发送方式：** 用户是否确实需要提醒，以及如果产品提供多种渠道，提醒将出现在哪里。

Google 日历允许用户为活动设置通知并更改通知设置；其账号和活动设置决定了这些日历通知的运作方式（[Google 日历：更改通知](https://support.google.com/calendar/answer/37242?hl=en)）。这是一个很好的示例，说明了应将通知视为一项拥有自身独立控制选项的配置操作，而非知晓日期后的自然结果。但这不应被视为日历具备伴侣式记忆的证据。

一个虚拟示例：从记住的细节到已确认的提醒

假设一位用户说：“玛雅的演奏会在 5 月 14 日。”AI 伴侣可以将其保留为**未确认的记忆事实**：对象、事件和月/日已知，但年份、时区和通知许可未知。它绝不能仅凭这句话就排期提醒。

伴侣可以询问：“我记录了玛雅的演奏会可能在 5 月 14 日。请问是哪一年，我应该使用哪个时区，您需要设置提醒吗？”用户回答：“2027 年 5 月 14 日，America/Los_Angeles。请在太平洋时间前一天上午 9:00 提醒我。”伴侣随后总结：“我将在 2027 年 5 月 13 日上午 9:00（America/Los_Angeles）提醒您关于玛雅的演奏会，即 5 月 14 日演奏会的前一天。是否进行排期？”

只有在用户确认后，系统才应创建通知记录，例如：**玛雅的演奏会 — 2027 年 5 月 14 日 — 提醒时间 2027 年 5 月 13 日上午 9:00 America/Los_Angeles — 生效中**。上述日期和时间为虚拟示例，并非对真实人物或事件的记录。明确指出时区有助于避免将“上午 9:00”当作世界通用时间。Google 日历的时区指南解释了活动时间会以本地时区显示，且时区更改可能会影响日历项的显示方式；这只是日历行为的示例，而非对 AI 提醒的主张（[Google 日历：在不同时区使用日历](https://support.google.com/calendar/answer/37064?hl=en)）。

面向用户的摘要至关重要，因为它提供了最后一次机会来发现日月颠倒、年份错误、对象不符或对“前一天”的错误理解。如果用户修改了摘要，伴侣应重新陈述修改后的细节，并就最终排期获取确认。

当日期未明确或存在冲突时该如何处理？

切勿基于系统无法确切认定的日期发送提醒。例如，如果一条备忘指出玛雅的演奏会是 2027 年 5 月 14 日，而另一条称是 2027 年 5 月 21 日，则日期存在冲突。伴侣可以指出冲突并询问哪个日期正确，但在用户解决冲突并确认排期之前，通知状态应保持为**未排期**。

当缺失关键细节时，同样适用此规则。“在演奏会前提醒我”并未指明演奏会是什么时候、提醒应提前多久，甚至可能没说清楚用户指的是哪场演奏会。此时应进行针对性的追问。如果用户没有回答，请将该项保留为未明确的备忘，不设置生效的通知。这样可以避免将推测转化为用户从未批准过的提醒。

一个实用的状态模型能让这种行为清晰可辨：**未确认**、**需澄清**、**已排期**、**已暂停**、**已取消**或**已完成**。“未确认”和“需澄清”绝不能产生与“已排期”相同的行为。系统可以在适当情况下保留底层记住的事实，但在真正设置好之前，绝不应暗示存在任何提醒。

修改、暂停和取消应该如何运作？

**修改：** 如果用户说演奏会是 5 月 21 日而非 5 月 14 日，请更新日期并重新展示建议的提醒时间。在激活修改后的排期前要求确认。如果提醒已经排期，请明确指出该修改会变动哪项已生效的提醒，并在替换之前确认更改后的日期。保留足够的可见历史记录以解释当前状态，同时不要隐去旧日期而导致用户困惑。

**暂停：** 暂停应暂时停止发送，同时保留日期和提醒详情。显示通知已处于暂停状态，并明确说明它是会自动恢复还是需要用户手动恢复。切勿将暂停的提醒标记为生效中。当用户想稍后解决某个细节、但在此期间不希望触发提醒时，暂停尤其有用。

**取消：** 取消操作应该停用已排期的通知，而不仅仅是删除对话备忘或隐藏该项。当可能有多个匹配项时，确认要取消的是哪一个提醒，然后显示已取消状态。如果记住的日期仍然有用，请将其与已取消的提醒分开，并提供用于编辑或移除该事实的易懂控制选项。日历提供了更改通知设置的控件，包括针对单个活动的控件；这是通知管理的一个简单示例，并非任何 AI 伴侣如何存储或取消提醒的证据（[Google 日历通知帮助](https://support.google.com/calendar/answer/37242?hl=en)）。

在进行任何更改后，展示最终的状态以及关键细节：提醒所指的日期、何时触发、其时区，以及它是处于生效、暂停还是已取消状态。悄无声息的更改让用户难以核实，并可能留下过时的假设。

给用户的简短自检清单

在依赖某个日期提醒之前，请核对该项目本身：

对象或事件的名称是否正确？

包括年份在内的完整日期是否已确认？

我能否看出日期的来源，其中的不确定性是否可见？

我是否明确批准了提醒，而不仅仅是提到了日期？

提醒的提前量、钟表时间和时区是否正确？

该项目显示的是已排期且生效中，还是仍需澄清？

如果我对其进行了修改、暂停或取消，显示的状态是否符合我的要求？

如果任何问题的答案不够明确，请在将其视为已排期通知之前，对该项进行复核或明确。实际的设计原则很简单：将不确定的信息保持为不确定状态，使提议的提醒易于检查，并且仅在用户的意图和相关日期细节明确之后，才创建或更改生效的通知。

继续探索这个主题