别让用户重复说三遍：对话式产品的多轮会话设计实战

先说判断：对话不是一问一答，是两个人一起把一件事办完

做对话式产品的团队，很容易掉进一个陷阱：把每一轮对话当成独立的一次问答。用户问一句，模型答一句，看起来挺流畅，数据也挺好看——直到用户说出那句要命的话：“不对，我刚才说的不是这个意思。”这时候产品往往当场露馅：它不记得刚才说了什么，分不清“那个”指的是哪个，甚至直接把用户的新要求叠加到旧要求上，做出一个谁也没要的东西。

我的判断先摆出来：多轮会话设计的核心不是“让模型记住聊天记录”，而是“让产品和用户一起，把一件事从模糊推进到办完”。聊天记录只是原材料，真正要设计的是状态、澄清、打断、回指和修复这五件事。状态不清，对话就会越聊越乱；澄清不讲究，用户会被问烦；打断处理不好，用户改一句主意就得从头再来；回指对不上，用户会觉得产品根本没在听；修复没有章法，一次听错就能毁掉整段信任。

以下例子里出现的产品“云杉食谱”与人物、数字均为虚构，仅用于说明设计方法；方法本身是通用的，放在客服助手、旅行规划、记账工具、学习陪练里都一样成立。

第一步：先把会话画成状态机，再写一句提示词

很多团队是先写提示词、再补逻辑，顺序反了。多轮对话的第一步，是在纸上画出会话的状态机。一个做饭助手“云杉食谱”的状态机只有五种状态：收集信息、等待确认、执行中、等待用户补充、已完成或已放弃。用户说“今晚想吃点清淡的”，会话进入收集信息；产品问清人数和忌口之后，给出三道菜的方案，进入等待确认；用户点头，开始生成菜谱和购物清单，进入执行中；执行时发现缺一个关键信息，比如“家里有没有烤箱”，就回到等待用户补充；用户说“就这样吧”，会话进入已完成。

状态机要画出来，有三个实际好处。第一，产品在任何时刻都知道自己在等什么，就不会出现“用户明明已经确认了，产品还在追问”的低级错误。第二，打断有了落点：用户在执行中突然说“等等，换成素的”，产品知道当前在执行中，应该先停下手头的活，再回到收集信息补一个条件，而不是把“素的”当成一道新菜追加进去。第三，测试有了清单：每个状态的每条转移都能测到，上线前按图走一遍，就能发现那些“正常流程永远碰不到、真实用户三天就碰到”的死角。

状态里该存什么、不该存什么，也值得定一条规矩。存的是“决定”，不是“原话”：用户确认了 2 个人、清淡、微辣，就存这三条结论；至于用户原话是怎么说的、模型中间生成过几版废弃的菜谱，都不必进状态。状态越小，恢复越快，也越不容易在恢复时把旧的废弃方案又翻出来。反过来，凡是会影响下一步的决定——比如用户明确说过“不要香菜”——必须进状态，不能只留在聊天记录里等模型自己去翻。判断标准只有一条：下一次打开会话时，产品要继续推进，必须知道哪些事？那些事就是状态，别的都不是。

还有一条硬规矩：状态必须能活过一次意外。用户杀掉进程、断网重连、切到别的 App 回来，会话应该能续上，而不是从头寒暄。做法不复杂：每次状态变化就把“当前状态 + 已确认的条件 + 待确认的问题”写进本地或服务端，一次写三样，恢复时一次读出来。很多产品的问题不是没有存状态，而是只存了聊天记录，没存“进行到哪一步了”——恢复时把几十条记录全塞给模型，让它自己猜现在该干什么，猜错的概率一点也不低。

第二步：澄清只问“不问就办错”的问题，一次只问一个

澄清是多轮对话里最容易做过头的地方。新手团队怕办错事，于是把能问的全问了：人数、口味、预算、时间、忌口、厨具、购物渠道，一口气七个问题砸过去。用户本来只是想随口问一句今晚吃什么，现在感觉自己在填表，填到第三个就关掉了。这不是用户的错，是产品把自己的焦虑转嫁给了用户。

我的做法是给澄清立三条规矩。第一，只问“不问就办错”的问题。做一顿饭，人数和忌口不问会办错，必须问；至于用户喜欢中餐还是西餐，如果产品能从历史记录里看出来，就不要再问。判断标准很简单：这个问题如果不问，产品给出的答案有大概率是错的，才值得开口。第二，一次只问一个问题，并且给选项不给填空。“几个人吃？”下面直接摆 1 人、2 人、3–4 人、5 人以上四个选项，用户点一下就行；“有什么忌口吗？”给“无 / 素食 / 不吃辣 / 海鲜过敏”四个选项加一个“其他”输入框。点选比打字轻松十倍，转化率的差距就藏在这里。第三，澄清要有上限：连续澄清超过三次，用户就烦了。第三次问完还没问清，产品应该直接按最稳妥的假设给一个默认方案，并且明说“我是按 2 人、无忌口给你排的，不对你随时改”，把选择权还给用户，而不是继续追问。

这里还有一个常见的误区：把澄清当成“收集用户画像”的机会。会话进行中顺手问一句“你平时喜欢什么菜系”，看起来是为用户好，实际上是在用用户的耐心给产品攒数据。画像要攒，等事情办完再问；事情办到一半，用户只关心自己的晚饭。

第三步：允许用户随时改主意，而且改一句就够了

真实对话里，用户改主意是常态，不是异常。今天想吃清淡的，看到菜单又想吃辣的；刚说完 2 个人，又想起今晚朋友要来。产品如果要求用户“重新说一遍完整需求”，就是在惩罚用户说话。好的多轮设计应该做到：用户改一句，产品只改这一句，其他已经确认的条件原样保留。

实现这条并不难，难的是团队要先承认“改主意”是正常路径，而不是异常分支。做法是：每确认一个条件，就把它写进一张“已确认清单”里，清单对用户可见。云杉食谱的界面上一直挂着一行小字：“2 人 · 清淡 · 不吃辣”，用户说“改成微辣”，产品只改“不吃辣”这一项，改完把新清单念一遍：“现在是 2 人 · 清淡 · 微辣，对吗？”用户点一下头，继续往下走。这一句复述很关键：它让用户确信产品改对了地方，而不是悄悄改了别的东西。

执行中的打断要另外处理。用户在产品生成菜谱的过程中说“停，我要换菜”，正确的做法是先停下生成，再确认新需求，而不是等生成完了再说“你刚才说换菜，我已经生成完了”。停得越快，浪费的算力越少，用户的信任损失也越小。如果生成已经花了钱（比如调用了图片模型），也不要紧：停下之后告诉用户“刚才那版已经停了，不会再往下做”，用户要的是掌控感，不是退款。

第四步：把“那个”“刚才”“换一个”翻译成产品听得懂的指代

多轮对话里有一半的句子是指代：“刚才那个换成辣的”“那个菜不要了”“换一个”。用户说这些话的时候，心里指的东西是明确的；产品能不能接住，决定了对话像不像“真的在听”。接不住的表现也很典型：用户说“那个不要了”，产品反问“哪个不要了？”——用户刚说完的话，转头就要再说一遍，体验立刻打折。

我的做法是给回指准备三张表。第一张是“最近提到的东西”：产品刚才推荐的三道菜，分别记成 1 号、2 号、3 号，用户说“那个”的时候，默认指最后提到的那一个；如果最后提到的有两个以上的候选，产品应该主动收窄：“你说的是刚说的糖醋排骨，还是前面的番茄炒蛋？”第二张是“已确认的条件”：人数、口味、忌口这些已经定下来的东西，用户说“把辣度改一下”，产品直接去改辣度这一项，不要反问“改什么”。第三张是“当前话题”：会话同时只能有一个主话题，用户说“对了，顺便帮我列个购物清单”，产品应该先把当前话题收个尾——“菜谱先按这个定下来，购物清单我接着列”——再切过去，而不是两个话题混在一起各说各的。

这里要特别小心一种情况：用户说“换一个”，产品换了一个，用户又说“还是换回刚才那个”。这时候产品必须能找回“刚才那个”是什么。做法是保留最近两到三个被换掉的候选，不要换一次就扔一次。被换掉的东西不是垃圾，是用户随时可能反悔的选项，留着它们的成本很低，丢了再找回来的成本很高。

第五步：听错了不可怕，可怕的是没有修复的章法

再好的产品也会听错：把“不吃辣”听成“吃辣”，把“两个人”听成“十二个人”。听错本身不可怕，用户对一次听错的容忍度其实很高；可怕的是产品没有修复的章法，要么硬着头皮把错的做完，要么让用户从头再说一遍。修复要分级，不同风险用不同力度的确认。

低风险的动作，做了再说，错了能撤销就行。比如给菜谱换一道菜，用户一点就能换回来，这种操作不需要事先确认，做了之后明示一句“已换成麻婆豆腐，不喜欢点一下换回来”，就够了。高风险的动作，必须先复述再执行。比如用户说“把购物清单直接下单”，这句话一旦执行就要花钱，产品应该先复述一遍：“清单上一共 12 样，总共约 86 元，确认下单吗？”等用户点头再动手。中间风险的动作，比如改掉已经确认的人数，复述一句新的清单就行，不必单独弹窗确认。

纠错的入口也要好找。用户发现产品理解错了，应该一句话就能改掉，而不是先点“反馈”、再选“理解错误”、再打字描述。最好的纠错入口就是对话本身：用户说“不对，是三个人”，产品改掉人数、复述新清单、继续往下走，全程不超过两轮。道歉也一样，一次就够了。“抱歉，我记错了，现在改成 3 个人”——说完就继续干活，不要连着道歉三句，用户要的是改对，不是听产品检讨。

第六步：沉默、超时和结束，同样要设计

多轮对话的另一半是“用户不说话的时候”。用户问了一句，产品回了一句，然后用户半天没动静——这时候产品该干什么？很多团队的选择是连环追问：“还在吗？”“还需要我帮你吗？”“要不要看看别的菜？”三条消息发过去，用户直接把通知关了。沉默不是求助信号，大多数时候只是用户在忙。我的做法是：只追问一次，而且追问要带价值。半小时没回，发一条就够了：“刚才的菜谱和购物清单都在这儿，想改随时说。”既提醒了用户东西还在，也给了对方一个不回也不会尴尬的台阶。

超时也要有说法。如果会话隔了一天再回来，产品不应该假装中间什么都没发生，直接接着问“然后呢”。正确的做法是先给一句摘要：“昨天我们定的是 2 人清淡菜谱，购物清单列好了，还没下单。要继续吗？”一句话帮用户找回上下文，再把选择权交回去。摘要的另一个好处是：它就是下一轮的开场白，用户不用翻几十条记录就能接上。

会话的结束同样值得设计。事情办完了，产品应该给一份能带走的东西：最终的菜谱、购物清单、以及“下次想吃类似的，直接说‘按上次的来’就行”。这份摘要既是对本次会话的收尾，也是下一次会话的起点。一个连摘要都没有的对话，用户下次只能从头再说一遍——那多轮设计的意义就少了一半。

落地清单：上线前先过这十条

最后给一份可以直接拿去对照的清单。上线前逐条打勾，缺哪条补哪条。第一，会话状态机画在纸上，五个状态的转移都能测到。第二，状态变化就持久化，杀进程、断网回来都能续上。第三，澄清只问“不问就办错”的问题，一次一个，给选项不给填空。第四，连续澄清不超过三次，第三次问不清就给默认方案加一句可改的说明。第五，用户改一句只改一句，已确认清单对用户可见，改完复述一遍。第六，执行中的打断先停再确认，不要等做完了再说。第七，“那个”“刚才”“换一个”有明确的指代规则，被换掉的候选保留最近两到三个。第八，确认分级：低风险做了再说，高风险先复述再执行，中间风险复述一句清单。第九，沉默只追问一次且带价值，隔天回来先给摘要再问要不要继续。第十，会话结束给一份能带走的摘要，下次一句“按上次的来”就能接上。

还有四个反模式，见到就改。第一，无限追问：把澄清当填表，用户填到第三个就走。第二，假装听懂：没把握的指代不问清楚，硬着头皮往下做，做错了再让用户擦屁股。第三，悄悄改决定：用户改了一句，产品顺手改了三句，改完还不告诉用户。第四，没有退出：用户想结束会话，却找不到结束的办法，只能把 App 关掉。这些反模式的共同点是：它们都在消耗用户对产品的信任，而信任是多轮对话里唯一真正的货币。

多轮会话设计没有银弹，只有一条简单的标准：用户说完一句话之后，产品知不知道现在进行到哪一步、接下来该干什么、万一理解错了怎么修。把这三件事做到位，对话就会越聊越顺；做不到，模型再强，也只是一个会接话的复读机。