对话重置按钮：在不丢失 Artifacts 的情况下重新开始的 UX 模式

现代 AI 产品中最反用户的按钮，偏偏也是最不可或缺的那一个。在对话进行到第 40 轮左右时，智能体（agent）已经陷入了错误的假设，语气开始跑偏，每一次新的交互都在让答案变得更糟而不是更好。用户知道该怎么做：清空重来。他们点击“新对话（New Chat）”——眼睁睁看着进行到一半的计划、草拟的四份文档，以及花了 20 分钟调优的提示词，随着那些被污染的历史记录一同烟消云散。

于是，他们不再使用重置按钮。他们打开第二个标签页，手动复制粘贴产出物，同时维持着那个已经崩坏的对话，把它当成一个不敢关闭的墓地。这种仪式——用手动复制粘贴来绕过本应发挥作用的按钮——是一个聊天产品对其数据模型有误所发出的最清晰信号。

产品的失败并非因为重置功能在工程上难以实现，而是因为数据模型混淆了两类生命周期完全不同的事物：对话，它是短期的，且运行时间越长越容易自我污染；产出物（Artifacts），它是用户出现的唯一原因。将它们混为一谈，结果就是每一个长对话最终都会以用户手动将工作成果迁移到新标签页而告终。

为什么重置按钮必不可少

长篇的大语言模型（LLM）对话并不会优雅地降级。它们的性能退化有一种特定的称呼：上下文窗口污染（context window poisoning）。一个错误的事实进入历史记录，模型开始将其视为真理，后续的每一轮对话都在强化它，细小的补丁累积成了巨大的问题。当用户察觉时，“再澄清一次”已经不起作用了——那个错误的假设已经固化在上下文记忆中，影响着接下来的每一次响应。

还有一种并行的、更缓慢的失效，被称为上下文腐烂（context rot）：即使没有明显的错误事实，较长的历史记录也会降低输出质量。模型开始忽略部分输入，过度索引其他部分，产出的答案比第三轮对话时的表现略逊一筹。研究人员对此早有记录，而大多数聊天 UI 将其掩盖得天衣无缝——没有进度条显示上下文有多满，或者模型已经变得多么困惑。

面对这两种失效，有一个屡试不爽的解决方法：硬重置（hard reset）。新的上下文窗口，新的后验概率，全新的模型行为。重度使用 AI 的从业者会条件反射地点击新对话，就像重启一个不稳定的服务一样。问题不在于他们想要重置，而在于这种重置具有破坏性，不像重启服务那样：服务重启会丢弃内存状态但保留磁盘数据；而“新对话”则会把两者全部丢弃。

这种混淆带来的痛苦

大多数聊天产品将对话及其输出存储在同一个逻辑容器中。系统提示词、往复的历史记录、生成的代码、起草的文档、搜索结果、配置好的计划——所有这些都属于同一个对话 ID，拥有相同的生命周期。删除对话，就删除了一切。开启新对话，就失去了一切。

这是一个范畴错误。对话轮次是模型的输入——它们生命周期短，容易损坏，有时甚至值得被丢弃。产出物（Artifacts）是用户的产出——也是他们付费的原因。它们共用一个界面（都在聊天面板中呈现），但此外别无共同点。它们的更新频率相差几个数量级。它们的失败模式呈负相关：冗长的对话历史是负担，而冗长的产出物列表则是财富。

Claude 的 Artifacts 面板是解决这一问题最常被引用的例子，其架构变动非常简单：实质性的工作进入 Artifacts，对话则用于导航和讨论。当用户在同一个项目中开启新对话时，产出物依然存在。重置按钮不再是用“失忆”来换取“去毒”。这种简单的拆分——将输入通道与输出通道分离——让一个具有破坏性的按钮变得安全。

不惩罚用户的重置模式

一旦产出物实现解耦，关于“重置”的设计空间就会大幅拓宽。单一的“核弹级”按钮可以演变为一系列定义明确的功能，每一个都针对特定的失败场景。

保留产出物的硬重置。 这是基础方案。新的对话，全新的上下文窗口，同一个项目——你生成的所有产出物依然列在侧边栏，依然可以编辑，依然可以作为输入附加到新对话中。你对重置按钮的心理模型（“清空对话”）保持不变，但由于工作成果得以保留，成本降至几乎为零。

局部重置（Scoped reset）。 高级用户希望丢弃对话历史，但保留特定的过程上下文：比如调优过的系统提示词、必须重复三次的关键事实、一小时前上传的文件。局部重置是一个“哪些内容能留存”的清单，而不是非黑即白的按钮。Cursor、Cline 和 Claude Code 都通过压缩命令向这个方向靠拢——你可以引导哪些内容留在上下文中。

软重置（总结并截断）。 系统不再擦除历史记录，而是要求模型将旧的对话轮次压缩成结构化的总结，并以该总结作为新的起点。最近的对话轮次会原样保留，因为它们包含活跃的工作记忆；而较旧的轮次则变成几段“已决定的事项”。这就是编程智能体在窗口填满时自动执行的上下文压缩，对于追求连贯性而非彻底清空的客户来说，这是正确的默认选项。正确配置后，单次会话的长度可以延长一个数量级。

追溯性对话修复。 当你能指出事情开始变糟的具体轮次时，正确的工具不是向前重置，而是向后重置。将包含错误假设的那段对话替换为经过验证的事实，保留两端的有效轮次并恢复。Cline 社区记录了这种模式；其逻辑是 working_history = seed_context + verified_facts + final_artifacts，而不是 working_history = full_chat_log。这种 UX 较难落地——你需要一种查看和编辑历史记录的方式——但在节省 Token 和建立信任方面的收益是巨大的。

撤销重置窗口。 硬重置经常被误触发。一个简短的撤销窗口——哪怕只有 30 秒且只有一个显眼的“恢复”按钮——就能将失败模式从“我点错了导致工作丢失”转变为“我点错了，但我撤销了”。这种模式在设计良好的软件中随处可见，但在聊天 UI 中却几乎绝迹。

揭示问题的指标

开发聊天产品的团队往往意识不到他们的重置体验是糟糕的，因为这种失败会导致用户默默离开，而不是大声投诉。用户学会了规避方法，不再报告 bug。几个指标可以揭示这种痛苦。

每会话长度的重置率（Reset rate per session length）是领先指标。如果用户在头十轮对话内重置的频率明显高于平均水平，这表明模型在早期就变得混乱，且用户已经找到了应对方法。如果重置率在 30 到 50 轮之间激增，那就是典型的上下文中毒（context poisoning）在起作用。

重置后的再参与度（Post-reset re-engagement）能告诉你重置是一种修复工具还是告别。重置后立即发送新消息的用户正在尝试恢复。而重置后关闭标签页的用户则正在离开——重置并不是一个有效的选项，而是一块墓碑。请分别绘制这两条路径。

按分群统计的重置后流失率（Abandonment-after-reset by cohort）是数据模型失败真正显现的地方。如果长会话用户在重置后的流失率高于短会话用户，那是因为长会话用户有更多的制品（artifacts）面临丢失风险，而“新聊天”感觉像是一种更沉重的惩罚。解决办法是将制品与对话解耦，当你发布这个功能时，该指标就会发生变化。

跨标签页会话数（Cross-tab session count）是手动复制粘贴这种规避方法的代理指标。如果你的核心用户倾向于在每个工作区同时打开 3 到 5 个对话，这就是数据模型强加给他们的仪式。每个标签页都是他们不忍丢失的制品。

架构解读

对话重置按钮是检验聊天产品是否考虑过生命周期最清晰的标准。设计良好的产品将对话视为流（stream）——可丢弃的、有时会损坏、易于重新开始；而将制品视为具有自身标识、版本历史和引用的持久对象。重置意味着“丢弃流”；它不意味着“丢弃流所产生的对象”。

做错这些的产品往往有几个共同特征。对话 ID 同时也是制品 ID。“删除聊天”按钮不会询问要保留什么。如果不进行复制，就无法将旧制品附加到新对话中。导出功能是用户唯一的逃生通道，而且它生成的是静态文件，而不是用户可以持续迭代的东西。产品路线图上把“记忆（memory）”列为即将推出的功能，仿佛正确的答案是在下个会话中重新阅读所有内容，而不是从一开始就停止混淆这两件事。

做法正确的产品看起来略有不同。制品拥有稳定的 URI，可以在任何对话生命周期中幸存。对话列表和制品列表是分开的视图。重置是一个快速、可逆的操作，而不是一个确认对话框。新聊天只需点击一下即可引入制品作为起始上下文。长期运行的项目累积制品的方式就像真实工作区累积文件一样，而对话只是编辑这些文件的协作会话。

对于开发者来说，结论虽然平实但非常重要：在添加另一个记忆功能或另一个总结模式之前，请审视数据模型，并询问对话和制品是否共享了不该共享的生命周期。如果是这样，重置按钮将继续是产品中最具惩罚性的按钮，而你最活跃的用户——那些拥有最多上下文、最多制品和最多理由继续使用你的产品的用户——将是受惩罚最重的人。将生命周期解耦，重置就会变成它本应有的样子：一个微小、安全的操作，让用户能够继续前进。