想象你是一家新餐厅的运营总监,上任第一件事是写一本《服务手册》。手册里要有“客人进门怎么招呼、怎么询问口味、怎么上菜、怎么买单”的完整流程,还要写清楚一堆“如果”:如果招牌菜卖完了怎么办?如果客人说菜太辣怎么办?如果客人情绪激动要找店长怎么办?AI产品的对话流(Bot Flow)设计与异常分支设计,本质上就是给机器人写这样一本“服务手册”。这份手册在AI产品PRD里叫“对话流文档”:它定义机器人在什么状态下说什么话、收集什么信息、遇到听不懂或做不到的情况如何兜底——和餐厅手册挨个定义“如果”是一模一样的思维。本篇文章就带你用这本“服务手册”的视角,一步步看懂对话流的概念、主流程与异常分支的撰写方法、文档规范、可解释性需求设计,以及最后用评估集验收整个流程的方法。
一句话职业价值:对话流与异常分支是AI产品从“想法”走向“可开发、可验收”的施工图。掌握它的PRD撰写方法,是AI产品经理在评审会不被怼、研发不迷路、测试有依据的核心竞争力。
目录
可视化演示
动态演示AI产品PRD的核心机制,通过全局/局部/动态/静态四种模式展示关键概念与交互流程。
本节配有交互动效(进入视口后自动加载,约 3KB)。
AI产品PRD:对话流设 对话流设计基础架构 主流程与分支设计 核心机制可视化 AI产品PRD整体架构与关键组件
1. 对话流的概念:一张服务路线图
写《服务手册》的第一步,是画一张“服务路线图”:从客人进门到离店,服务员每一步站在哪里、该做什么、下一步去哪儿。这张图不需要画出每一句台词,但必须标出关键站点和行进方向。对话流(Bot Flow)就是AI产品的“服务路线图”。
在PRD里,对话流被定义为一系列有序的交互节点与状态转移规则。它回答三个问题:机器人现在处于什么状态(状态)、用户此刻的输入是什么意思(意图)、收到这个输入后机器人要做什么并进入什么状态(转移)。这与餐厅路线图中“服务员在门口→看到客人→上前招呼→进入点单状态”是同构的。
常见的节点类型有:开场节点(问候与能力说明)、意图识别节点(判断用户输入)、槽位收集节点(逐项补齐信息)、条件分支节点(按槽位或置信度分流)、回复节点(输出话术)、结束节点(明确收尾)。这些节点串起来形成主流程;从任意节点伸出去的“否则”,就是异常分支的起点。
回到餐厅手册,这张路线图的价值,是让前台、后厨、店长对“服务路径”有一致理解。AI产品经理画对话流图,同样是为了让研发、测试、运营在同一张图上对齐——后面的每一节,都是在为这张图补细节。
- 当前状态 $S_t$机器人此刻所在的环节,比如“开场白”或“槽位收集中”,它是决策的起点。
- 用户动作 $A_t$用户本轮输入的一句话或一个点击,是状态转移的唯一触发器。
- 转移规则 $\delta$PRD中定义的“如果…那么…”规则表,把“状态+动作”映射到下一状态。
- 下一状态 $S_{t+1}$机器人完成本轮回复后进入的新环节,也是下一轮决策的起点。
2. 主流程撰写:从迎宾到送客
路线图有了,接下来把主流程的每一站写细。主流程指用户在预期内配合时走过的路径,相当于餐厅的“正常服务线”:迎宾、询问、记录、复述、下单、送客。对话流主流程通常围绕四个环节展开。
开场白设计是第一站。第一句话要说清“我是谁、我能做什么、怎么开始”,就像服务员开口“您好,欢迎光临,今天有新款宫保鸡丁”。开场白要暗示能力边界(避免用户问出机器人答不了的问题),并抛出第一个引导问题,把对话推进到正题。
槽位收集是主流程的核心环节。要完成任务,机器人需要若干必要信息,比如点餐需要“菜品”和“数量”,这些信息项就是槽位(Slot)。撰写要点是每轮只问一项,降低用户负担;用户一次性给出多项时则全部吸收。信息齐了之后进入澄清确认——把理解复述给用户,得到确认后再执行;最后用明确的结束语收尾,告诉用户“订单已下达”。
主流程写得越细,测试越有据可依。餐厅手册绝不会只写“把菜端上去”,而是会写“报菜名、确认桌号、提醒烫口”。对话流PRD对每一环写清触发、动作、回复,就是让开发拿到就可以编码,让测试拿到就可以写用例。
- 必填槽位集合 $F_{\text{required}}$PRD里写死的一组信息项,比如{菜品,数量}。
- 已填槽位集合 $F_{\text{filled}}$机器人从用户对话中成功提取到的信息项集合。
- 完成率计算两个集合的元素数目之比,取值范围是 0 到 1。
- 进入条件完成率等于 1 时,对话流才能推进到澄清确认环节。
3. 异常分支设计:当客人不按剧本走
再好的服务员也会遇到“不按剧本走”的客人:菜卖完了、客人说太辣、客人突然要求见店长。餐厅手册必须为每个可能翻车的位置准备“否则怎么办”。对话流同理,异常分支是PRD里最见功力的部分。
异常分支从“识别失败”开始。当置信度低于阈值,机器人进入兜底策略——用统一话术表达“没听清/没听懂”,并给出回到主流程的引导,比如“您可以试试说:我要点麻婆豆腐”。注意兜底不是重复同一句话,而是每次都带新的提示,给用户回头的阶梯。
兜底需要计数。连续失败达到上限(如 2 次),就触发拒识处理升级:要么换一种问法,要么直接转人工。转人工机制要有明确的触发条件:连续失败次数、用户明确指出“人工/投诉”、或涉及敏感权限操作。此外,边界约束要写明“绝不承诺的事”,避免机器人为了安抚用户而撒谎,比如承诺“一定退款”。
手册里“客人发火怎么办”这一页,餐厅写的是“先道歉、再倾听、再请店长”。对话流的异常分支规则写得越具体,机器人就越像一个训练有素的员工,而不是一碰就崩的复读机。异常设计本质上是在定义产品的下限体验。
- 单轮置信度 $conf_t$意图识别模块对第 $t$ 轮输入给出的把握,取各意图概率的最大值。
- 置信阈值 $\theta$PRD定义的及格线,低于它视为“没把握”,建议取值 0.5 到 0.7。
- 失败计数 $N_{\text{fail}}$指示函数逐轮累计“低于阈值”的次数。
- 转人工判断把累计失败数与上限 $K$ 比较,决定走转人工还是继续兜底。
4. 文档规范:让手册像手册
手册写好了,但如果每页格式混乱、编号缺失,服务员现场根本翻不到“客人发火怎么办”在哪一页。PRD的对话流文档同样需要强规范,才能支撑多人协作、评审与追溯。文档规范是对话流PRD的“排版与检索系统”。
PRD结构上,对话流文档一般包含:背景与目标(为什么做)、角色定义(用户与Bot的画像与职责)、主流程(happy path)、异常分支(否则路径)、评估方案(验收口径),以及附录(话术清单、变更记录)。每一部分的职责边界清晰,评审时才能按图索骥。
编号规则是规范的核心。每个节点与分支要有唯一编号,如 BBF-01-03 表示“对话流-主流程-第 3 个节点”,这样评审时可以说“BBF-02-01 的兜底话术要改”,而不是“第二页那个”。状态描述则要求每个节点写清三件事:进入条件、处理逻辑、退出条件(正常出口与异常出口),保证任何人都能照着复现。
餐厅的《服务手册》之所以厚,不是因为话多,而是因为每个流程都有编号、有责任角色、有援引方式。文档规范让PRD从“一篇作文”变成“一张可执行的施工图”,这也是AI产品经理专业度的直接体现。
- 主流程状态集 $S_{\text{main}}$用户配合时的路径节点集合,如开场、收集、确认。
- 异常状态集 $S_{\text{exception}}$兜底、拒识、转人工等异常路径的节点集合。
- 并集完备评审时逐节点检查,两类状态合起来必须覆盖全部对话场景。
- 出口非空每个状态至少有一个正常出口或异常出口,不允许死循环。
5. 可解释性需求设计:让用户理解机器人
客人追问“这道菜怎么还没来”,服务员如果只说“很快就好”而不解释原因,客人只会更不安。AI产品的可解释性需求设计,就是规定机器人“在什么时候、用什么方式解释自己的行为”。这是PRD里经常被漏掉、却决定信任感的部分。
可解释性需求通常写成三条规则。第一,原因说明:当机器人无法完成任务或做得不对时,要主动说明原因,而不是含糊带过。第二,置信度提示:识别不确定时,用“我理解是……对吗?”的方式表达不确定性,而不是假装确定,给用户纠正的机会。
第三,能力边界:在开场或遭遇拒识时,主动告知“我不能做什么”(如“我无法为您转账,转账请前往柜台”),管理用户预期。这些需求都要落到一张“场景→解释话术→触发条件”的表格里,写进PRD的需求条目,而不是留给开发临时发挥。这就是透明机制:让用户始终知道自己面对的是有限能力的AI、当前行为为什么发生。
好的服务员不会假装自己什么都知道,好的机器人也一样。可解释性需求设计,是把“诚实”变成PRD里可开发、可测试的条目。它和餐厅手册里“主动告知今日售罄菜品”是同一件事——先说明,再引导,用户才会放心把事交给机器人。
- 置信度变量 $conf$意图识别给出的把握值,范围是 0 到 1。
- 阈值 $\theta$PRD定义的“把握及格线”,建议取 0.5 到 0.7。
- 直接回答分支把握足够,给用户确定的直接答案,提升交互效率。
- 解释+澄清分支把握不足,先说明不确定性,再引导用户确认。
6. 评估集设计:用“神秘顾客”验收手册
手册写得好不好,不能靠自我感觉。餐厅的做法是请“神秘顾客”按标准剧本上门试菜、挑刺、打分。AI产品的评估集(Evaluation Set)就是这套标准剧本:一批预先设计好的输入对话序列,配上期望输出,用来验收对话流是否达标。
评估集设计从用例分类开始:主流程用例(happy path,如完整点单)、异常分支用例(兜底、拒识、转人工)、边界用例(空输入、超长输入、模糊表达)、合规用例(敏感词、隐私请求)。每个用例的标注规范包含三要素:输入对话序列、期望最终状态、允许的回复范围。
覆盖策略上,要求“每条分支至少一条用例”,优先级从高频路径到低频路径递减。验收标准统一用可量化指标:分支覆盖率不低于设定值(如 80%)、任务成功率、未识别转人工率、用户满意度。PRD里写明这些指标,开发完成后才能照单验收,而不是“感觉差不多能上”。
神秘顾客的剧本写得越刁钻,手册的漏洞暴露得越快。评估集不是开发完之后的玩具,而是PRD阶段就要与对话流同步设计的一份“验收合同”。有了它,“这本手册合格吗”这个问题,才第一次有了可以量化的答案。
- PRD分支集合 $E_{\text{branch}}$对话流文档里定义的所有主流程与异常分支。
- 已覆盖集合 $E_{\text{covered}}$评估集用例实际走过并断言过的分支。
- 覆盖率比值两者元素数目之比,反映验收的全面程度。
- 验收线 $\gamma$PRD写明的覆盖率下限,不达标则不允许上线。
AI 应用场景
场景1:银行App智能客服的对话流PRD撰写
阶段:需求分析与规格设计
解决的问题:银行智能客服在PRD阶段经常只写“能查余额、能查流水”,导致开发完成后,用户问“能转账吗”时机器人答非所问,转人工无门槛,客服通道被挤爆。用对话流与异常分支的方法,把每个意图的主流程、槽位(账号、时间段)、异常分支(识别失败、超权限请求、转账引导)写成可评审的文档。
具体案例:某银行AI产品经理在PRD中定义“查流水”流程:开场白→收集账号与时间段→确认→展示摘要→引导下载明细;异常分支定义“查询他人账户”时的边界约束为“无法查询他人账户”并引导走合规渠道。上线后无效转人工率下降 40%。
场景2:电商售后机器人的异常升级与转人工
阶段:交互设计与异常兜底
解决的问题:用户情绪激动(“我要投诉!”)或多次未识别时,机器人继续复读会让投诉升级。用失败计数加转人工触发规则设计异常分支,让机器人知道“什么时候该认输、请人上场”。
具体案例:某电商机器人PRD定义:连续 2 轮未识别→转人工;检测到“投诉/人工/消协”关键词→立即转人工并同步订单上下文。上线后投诉升级率下降,用户满意度提升 12 个百分点。
场景3:智能客服上线前的评估集验收
阶段:评测与验收
解决的问题:缺少客观验收指标,研发说“能用了”,测试说“感觉不行”。用评估集设计方法,在PRD阶段就定好用例与指标,避免上线前的“我觉得”拉锯战。
具体案例:某保险客服项目按“分支覆盖率≥85%”的要求设计 120 条用例(主流程 50、异常 40、边界 30)。验收时发现“转人工”分支 3 条用例仅通过 1 条,定位到阈值配置错误,修复后达标上线。
Python 演示
class EvalCase: """评估集用例:输入对话序列 + 期望最终状态""" def __init__(self, name, inputs, expected_state): self.name = name self.inputs = inputs self.expected_state = expected_state class OrderBot: """点餐机器人:对话流主流程与异常分支的状态机实现""" DISHES = ["麻婆豆腐", "宫保鸡丁", "酸辣汤"] COUNT_MAP = {"一": 1, "两": 2, "三": 3} def __init__(self, threshold=0.5, max_fallback=2): self.state = "opening" self.slots = {} self.fallback_count = 0 self.threshold = threshold self.max_fallback = max_fallback self.required_slots = ["菜品", "数量"] def recognize(self, text): """意图识别:命中词表返回高置信度,否则返回低置信度""" for dish in self.DISHES: if dish in text: return "dish", 0.85 for word in self.COUNT_MAP: if word in text: return "count", 0.85 for kw in ["人工", "客服", "投诉"]: if kw in text: return "human", 0.85 return "unknown", 0.2 def extract(self, text): """槽位抽取:从一句话中抓取菜品与数量""" for dish in self.DISHES: if dish in text: self.slots["菜品"] = dish for word, num in self.COUNT_MAP.items(): if word in text: self.slots["数量"] = num def collect(self, text): """槽位收集:补全必填槽位,齐了则进入确认""" self.fallback_count = 0 self.extract(text) need = [s for s in self.required_slots if s not in self.slots] if not need: self.state = "confirm" return "您确认点%s%s份吗?" % (self.slots["菜品"], self.slots["数量"]) return "还需要告诉我%s。" % "、".join(need) def step(self, text): """状态转移:一个用户输入对应一次状态流转""" intent, conf = self.recognize(text) if intent == "human": self.state = "human" return "已为您转接人工客服,请稍候。" if self.state == "opening": self.state = "collect_slot" if intent in ("dish", "count"): return self.collect(text) return "您好,请问您要点什么?" if self.state == "collect_slot": if conf < self.threshold: self.fallback_count += 1 if self.fallback_count >= self.max_fallback: self.state = "human" return "多次未识别,转接人工客服。" return "没听清,请再说一次。" return self.collect(text) if self.state == "confirm": if "确认" in text or "对" in text: self.state = "done" return "好的,订单已下达,感谢惠顾。" self.state = "collect_slot" return "请重新告诉我需求,我来重新下单。" return "您的订单已完成,还有别的需要吗?" def run(self, inputs): """跑一段对话,返回每一步后的状态与回复""" logs = [] for text in inputs: reply = self.step(text) logs.append((self.state, reply)) return logs def run_eval(cases): """用评估集验收:逐条断言最终状态是否符合预期""" passed = 0 for case in cases: bot = OrderBot() logs = bot.run(case.inputs) final_state = logs[-1][0] if logs else "opening" ok = final_state == case.expected_state passed += 1 if ok else 0 mark = "通过" if ok else "失败" print("[%s] %s -> %s (期望 %s)" % (mark, case.name, final_state, case.expected_state)) return passed / len(cases) if __name__ == "__main__": cases = [ EvalCase("主流程-完整点单", ["我要点麻婆豆腐", "两", "确认"], "done"), EvalCase("异常-两次未识别转人工", ["你好", "嗯", "人工"], "human"), EvalCase("异常-直接要求转人工", ["转人工"], "human"), EvalCase("边界-分批补齐槽位", ["宫保鸡丁", "三", "确认"], "done"), ] rate = run_eval(cases) print("评估集通过率: %.0f%%" % (rate * 100))
def recognize(self, text):意图识别模块,命中词表返回高置信度,否则返回低置信度,对应PRD中的意图识别节点。if conf < self.threshold:置信度低于阈值时进入兜底逻辑,对应文章中的阈值 $\theta$。self.fallback_count += 1失败计数器累加,对应异常分支的拒识处理。if self.fallback_count >= self.max_fallback:失败次数达到上限触发转人工,对应 $N_{\text{fail}} \ge K$。need = [s for s in self.required_slots if s not in self.slots]计算缺失槽位,对应槽位完成率。EvalCase("主流程-完整点单", ...)构造一条评估集用例,声明输入序列与期望最终状态。rate = run_eval(cases)执行全部评估集用例并计算通过率,对应验收标准。
常见误区
误区很多初学者拿到PRD任务,先画一条“开始→识别→处理→结束”的直线,认为用户都会顺着走,画完主流程就交差。
正解真实对话中用户会乱说、会反问、会不配合。PRD必须同时定义主流程和异常分支:兜底话术怎么写、失败几次转人工、哪些话不能说。异常分支直接决定机器人的下限体验,就像餐厅手册不能只写“正常上菜”不写“客人发火怎么办”。
为何常见:人天然倾向于先描述“顺利的情况”,异常是噪声;而且异常分支写起来琐碎,容易被认为是“开发自己想就行”。
误区为了让机器人“无死角”,把能想到的用户输入全部写成独立分支,结果PRD几百页,评审没人看完,维护也崩溃。
正解穷举不现实,正确做法是“分级兜底”:高频异常单独成分支,低频不可列举的输入用统一兜底话术覆盖,并设置转人工上限。像餐厅不会为“客人说外星话”写专属预案,而是统一“不好意思,没听清,我请店长来”。
为何常见:怕漏掉,做加法容易;做“兜底+分级+转人工”需要设计取舍,难度更高。
误区把可解释性理解为“机器人说对不起”,在回复模板里塞一句“抱歉”就算完成可解释性需求。
正解可解释性是结构性的预期管理:让用户知道自己在和AI对话、当前是否确定、为什么做不了、信息如何使用。它要写成“场景→解释话术→触发条件”的需求表,和道歉文案完全是两回事。
为何常见:把“可解释”误认为“礼貌”,忽略了透明机制的设计,这也是PRD评审中最容易被放过的一环。
误区评估是开发之后的事,PRD阶段先把流程写了,测试用例等代码出来再说。
正解评估集应在PRD阶段与对话流同步设计,作为验收红线。否则开发完成后没有客观标准,只能靠“我觉得差不多”决定是否上线,体验风险极高。
为何常见:把评估等同于“测试”,而测试通常发生在开发后;但对话流评估集本质是需求规格的可执行化,必须在写需求时同步定义。
面试题
Q1. 对话流设计中,“槽位”(Slot)最准确的理解是?
- A.对话历史存储位置
- B.完成任务所需信息项← 正确答案
- C.数据库查询缓存区
- D.用户身份验证凭证
答案:B。槽位是完成任务所需的必要信息项,如点餐需要的“菜品、数量”,对应餐厅记录客人需求的“点单信息栏”。对话历史、缓存、凭证都不是槽位。
Q2. 对话流中“意图识别”节点的核心作用是?
- A.判断用户请求分词
- B.生成用户回复文本
- C.理解用户真实意图← 正确答案
- D.训练语言模型参数
答案:C。意图识别是判断“用户这句话想干什么”,如同服务员判断客人说“有点辣”是要加辣还是想换菜。分词是手段,生成回复是下游任务,训练参数是算法侧工作。
Q3. 机器人连续两次未识别用户意图时,最合理的异常设计是?
- A.循环播放同一提示
- B.触发兜底并转人工← 正确答案
- C.静默等待用户输入
- D.直接返回主菜单
答案:B。连续失败达到上限应触发兜底升级并转人工,如同服务员两次没听懂就请店长。循环同一提示让用户重复,静默超时和直接返回主菜单都没有解决用户的真实问题。
Q4. 当槽位全部收集完成后,对话流下一步应该?
- A.立即执行用户操作
- B.结束整段对话流程
- C.转交人工客服处理
- D.进入确认环节复核← 正确答案
答案:D。槽位齐了不代表可以立刻执行,先进入澄清确认环节,把理解复述给用户,像餐厅下单前报一遍菜名。立即执行可能误解用户,直接结束或转人工都跳过了应有的确认步骤。
Q5. 可解释性需求中,当识别置信度较低时机器人应?
- A.说明不确定的原因← 正确答案
- B.给出最肯定的答复
- C.重复用户输入原话
- D.主动结束当前对话
答案:A。低置信时应表达不确定性并给出澄清引导,如“我理解是……对吗?”,对应服务员“我没太听清,您说的是宫保鸡丁吗”。假装肯定、复读原话、结束对话都会破坏信任。
Q6. PRD中对话流文档应包含的内容有?
- A.主流程节点定义← 正确答案
- B.异常分支兜底策略← 正确答案
- C.服务器日志存储格式
- D.转人工触发的规则← 正确答案
答案:ABD。对话流文档必须定义主流程、异常分支和转人工机制,这是“服务手册”的三大部分。服务器日志格式属于技术架构文档,不属于对话流PRD范畴。
Q7. 某对话流共12条分支路径,评估集已覆盖8条,分支覆盖率约为?
- A.百分之五十八
- B.百分之五十
- C.百分之六十七← 正确答案
- D.百分之七十五
答案:C。分支覆盖率 = 已覆盖分支 ÷ 全部分支 = 8 ÷ 12 ≈ 0.67,即百分之六十七。其余选项分别是错误的估算值。
Q8. 对话流“边界约束”设计应明确哪些内容?
- A.渲染层引擎的版本要求
- B.机器人不回答的问题范围← 正确答案
- C.敏感信息的权限边界← 正确答案
- D.兜底话术的表达边界← 正确答案
答案:BCD。边界约束定义“机器人绝不能做什么”:不回答的问题、敏感信息权限、兜底话术的承诺边界,如同餐厅规定服务员不得承诺免单。渲染层引擎版本属于技术实现细节。
Q9. 开场白设计最重要的目标是?
- A.展示技术实现能力
- B.收集用户全部需求
- C.引导用户使用入口
- D.说明服务范围边界← 正确答案
答案:D。开场白要说明“我是谁、能做什么、怎么做”,重点是把能力边界讲清楚,像服务员进门先报今日菜品。展示技术、收集需求、引导下载都不是第一目标。
Q10. 评估集用例设计应在哪个阶段启动?
- A.需求评审全部通过后
- B.与PRD撰写同步进行← 正确答案
- C.开发完成联调测试时
- D.产品上线灰度发布时
答案:B。评估集是需求规格的可执行化,应在PRD阶段与对话流同步设计,作为验收合同。等到评审后、联调时或上线前才启动,都失去了对需求的约束作用。