你随口告诉过 AI 助手一件事，之后几天它反复提起。事情早已过去，或者早已与你后来的生活无关，提醒却停不下来。这不是记性太好，而是系统分不清三件事：哪些只是需要记住的信息，哪些是正在进行的目标，哪些是做完就该结束的任务。
一条记忆，一个目标，一件任务
生活里的事至少分三类。一类是记忆：住在哪里、孩子在读几年级、对什么过敏，这些信息长期稳定，不随周次过期，也谈不上“完成”。一类是目标：正在推进、有终点的事，比如准备一次搬迁、把一个慢性问题弄清楚，需要的是被持续追踪。还有一类是任务：明天交保险、下个月续签，一次行动，做完即结束。
这三类需要的对待方式不同，但把它们一起说给一个聊天框听时，系统往往只有一种处理办法：全部记下来。记忆被存住了，目标被存住了，任务也被存住了，而“这件事什么时候算完”没有存进去。一次产品讨论中提到的例子很典型：告诉助手一件事之后，它“天天跟你磨叨这事儿”，而磨叨的内容早已和用户后来做的事无关。信息没有错，错在它没有一个终止方式。
打勾是在告诉系统：这件事结束了
待办清单上的打勾，表面上是个动作，实际上是一条状态信号：这条关注可以关闭了。一项录制时的产品体验里，Muse 的页面把长期目标拆成列表，事情做完就打勾，打勾之后系统不再惦记这件事。
这个设计的价值不在多了一个清单，而在给记忆装了一个出口：相关的信息可以沉淀下来，但“关于这件事的提醒”应当有办法结束。没有这个出口，用户只剩下一种工具——反复用嘴澄清“这事不用再提了”，而每一次澄清本身又是新的上下文。
反过来说，很多被抱怨“记性太好”的助手，缺的不是更强的记忆模型，而是一个简单到几乎不值得设计的界面元素：一个能让事情从“正在关心”变成“已经结束”的按钮。
纯聊天为什么管不住待办
一次被记录下来的尝试是：放下滴答清单，完全用对话管理待办。一年之后的结论是什么都没管理好，又把清单软件用了回来。
失败的原因不在模型，在聊天的形态。对话是一条向前流动的流，说过的话沉进历史，翻找和确认都要费劲。做完没有地方打勾，没做没有地方排期，隔一天就想不起来昨天让助手做了什么。交互之后，人需要一份可以回看、可以复查的结果——这份结果必须待在聊天流之外的某个地方。最近笔记软件和待办软件反而重新活跃，与这个缺口有关：人们与 AI 交互得越多，越需要一个交互之外可以核对结果的界面。
便签的简单，泛化的难题
待办需求本身非常大众。一位 Google 日历前产品经理在交流中转述过团队的调研：美国普通用户最常用的工具不是任何日历软件，而是贴在冰箱上的便签。把日程排满日历是少数人的需要，大多数人的待办是“明天该交水费”这个级别，用不着方法论，也用不着复杂界面。
难点在于纯程序应付不了泛化。什么算“完成”、什么时候过期、事情改期了怎么跟进、一句话里哪些是任务哪些只是抱怨，规则很难写全；写全了的规则，遇到下一句稍微不同的话就失效。这恰好是模型可以补上的位置：把一句自然的话变成一条有状态、有终点、有出口的记录，再让简单界面负责展示和打勾。程序负责形态，模型负责理解，各做各的擅长部分。这是基于现有产品的方向推断，各产品实际能力以发布为准。
结束，不是遗忘
一个完成按钮解决的不是效率问题，是知情问题：系统终于知道这件事对用户来说已经结束。由此推导出的分层也清楚——信息沉淀为记忆，不设截止；目标挂着进度，随推进更新；任务打勾关闭，提醒随之停止。三者混在一个“记忆”里，助手就只能在所有事情上永远在线。
仍然待回答的问题是边界由谁划：用户打勾之前，系统能否先判断一件事真的做完了；有没有一些事，结束的方式不是打勾而是过期作废。完成按钮只是第一步，任务状态的管理才是它背后真正的产品问题。