陪伴式聊天产品应如何识别用户何时想要停止？
陪伴式聊天产品应将明确的停止信息视为指令，识别所请求的活动何时完成，并允许用户暂停而无需解释原因。当交流结束时，它应当简短收尾，并将下一步的主动权留给用户。设计这一机制的实用方法是按清晰度对信号进行排序，优先处理明确的请求，并避免去猜测用户的心情或沉默。
从用户的话语出发，而非对其情绪的揣测
诸如“停止”、“我说完了”、“够了”、“再见”或“先到这里吧”等信息，是用户希望结束交流的直接证据。将这些短语以及自然的变体纳入产品的停止处理逻辑中。在整个对话过程中将其视为控制指令，包括在进行创意活动期间或系统正在提问时。
这遵循了既定的对话设计指南。Google 建议尊重诸如“我说完了”和“算了”等表达，并指出当几乎不会丢失什么进度时，不要去质疑那些想要离开未完成任务的人。Amazon Lex 类似地为表明用户想要结束交互的短语定义了停止意图（stop intent）。（Google 关于对话结尾的指南；Amazon Lex 内置的停止意图）
产品的响应应确认一次指令，然后结束该轮对话。例如：“明白了。我们先停在这里。”不要在确认之后又提出另一个问题、邀请继续交谈或要求解释做此决定的原因。停止命令不应演变成一场需要用户不断重复自己的拉锯谈判。
将任务完成视为自然的结束节点
用户可能在不说“停止”的情况下结束对话。他们可能会要求写一个短篇故事并收到故事，挑选一个周末活动的想法，或者完成修改一条消息。一旦交付了所请求的产出，并且该任务没有遗留未解决的部分，系统就可以用简短的陈述来收尾，例如“这是最终版本”或“这样周六的计划就有了”。它不必自动附加“你还想做点别的什么吗？”
这是根据“保持对话响应简明、相关并专注于任务”这一指南得出的设计推论。Amazon 的对话设计核对清单建议尽量减少步骤并保持消息相关性，并建议不要用无关的提议来打断体验。应用于陪伴式聊天，这意味着将后续提问建立在存在真实下一步的基础之上，而不是在每个已完成的回答后都硬加一个。（Amazon Alexa 对话设计原则）
也有例外情况。如果请求包含多个部分，产品应完成所承诺的部分或明确说明剩余内容。如果用户要求提供草稿和修改版，那么仅返回草稿并不是一个完成的任务。但一旦约定的范围得到了满足，开放式提示可能会让一个本已结束的交互显得未完成。简明的收尾可以防止系统悄悄扩大用户的任务量。
让暂停易于表达且易于恢复
暂停与结束不同。“我们先暂停一下”、“我待会儿再来看这个”、“稍等一下”或“留着以后看”可能表明用户想要休息一下，同时保留工作成果。在产品支持对话历史记录或保存草稿的情况下，它可以用通俗易懂的语言确认哪些内容仍可访问。如果无法保存当前状态，并且这种限制很关键，它应在用户离开前明确说明。
保持暂停由用户控制。不要要求解释或猜测休息的原因。如果产品有可见的暂停或关闭控件，请清晰标记并赋予其可预测的结果。W3C 关于用户控制的指南指出，上下文的改变应由用户发起，或者具有关闭它们的机制；该原则支持清晰的控件以及转换周围的可预测行为。（W3C 关于按请求更改的指南）
产品还应利用界面中提供的文字和操作，将暂停与明确的停止区分开来。如果功能支持，暂停可以保留草稿或任务进度。停止则应结束当前的交互。除非确实保存了对话，否则不要谎称已保存；也不要将离开应用或保持沉默视为发送更多消息的请求。
对模糊信号和明确信号使用清晰的优先级顺序
用于实现的一个实用信号层级如下：
明确停止或道别：及时结束交流。
明确暂停或保存请求：如果支持，则暂停或保存，然后简要确认结果。
已完成请求：提供请求的结果并收尾，无需再进行下一轮交互。
不明确的消息：仅当歧义阻碍任务推进时，才提出一个简短的澄清问题。
沉默：根据产品的正常行为等待或结束活动会话；不要推断情绪状态。
这种排序是一个实用的设计建议，而不是已发表的度量标准或通用的分类器。其目的是防止直接指令被较软性的假设所取代。例如，“够了”应该优先于系统预测“相关建议可能会受欢迎”。只有当用户的措辞确实让结果含糊不清时，像“你的意思是停在这里，还是留着以后看？”这样的问题才合适。
如果产品支持可能产生重大后果的操作，或者存在丢失大量工作成果的风险，为了保护这些成果，进行确认可能是合适的。确保确认提示具体且易于回答：“现在停止并放弃此草稿吗？”对于几乎不会丢失进度的日常对话，重复确认会造成不必要的摩擦。Google 的指南也做出了相同的区分：除非会丢失大量进度，否则不要反复确认退出。（Google 关于对话结尾的指南）
保持收尾响应简短且完整
收尾消息只应承担一项任务：明确系统已理解用户，且交互已结束或已暂停。合适的例子包括：
停止：“好的。我们先停在这里。”
已完成的创意任务：“这是修改后的诗歌。”
已保存工作的暂停：“已暂停。您的草稿已保存在此聊天中。”
无保存功能的暂停：“好的。您可以稍后返回此聊天，但我无法单独保存草稿。”
仅使用符合产品实际行为的陈述。避免情感牌、带有负罪感的语句或新的提问。收尾可以在温暖的同时，无需请求用户来安抚系统或继续交互。设计的目的是提供一个值得用户信赖的明确收尾。
测试边界情况，而不仅仅是显而易见的命令
审查日常使用中的简短对话示例：讲故事过程中的直接停止、推荐后的“够了”、已完成的写作任务、中途暂停的请求，以及模棱两可的“也许晚点吧”。检查每种情况是否都能导向预期行为，并确保在明确停止或任务完成后不会出现后续提问。
还要检查误报情况。“别用那个短语了，换一个”虽然包含“别”（stop）字，但它是任务内的指令，并不一定是结束聊天的请求。结合上下文解释词语，同时在系统理解错误时保留专用的停止控件。Amazon 的文档描述了用于常见停止短语的内置停止意图；陪伴式聊天产品可以使用相同的基本思路，同时根据其文本或语音界面定制识别能力。（Amazon Lex 内置的停止意图）
追踪实际的失败案例，例如停止请求后跟着另一个问题、已完成的任务触发了无关的提示，或者暂停暗示已保存但实际上丢失了工作进度。这些都是可观察到的行为核查，而不是对用户感受的臆断。它们有助于团队改进交互，而无需试图从用户的措辞中去诊断其心理状态。
尊重式收尾的简单规则
当用户明确结束交流时，停止。当约定的任务完成时，简短收尾。当用户要求暂停时，维护他们的控制权并解释可用的保存机制。仅在完成请求或解决真实歧义所必需时才追问。这为陪伴式聊天产品提供了一种识别结束的具象方式，同时将日常选择、时机把握和继续对话的自主权留给用户。