想象你是一家新餐厅的运营总监,上任第一件事是写一本《服务手册》。手册里要有“客人进门怎么招呼、怎么询问口味、怎么上菜、怎么买单”的完整流程,还要写清楚一堆“如果”:如果招牌菜卖完了怎么办?如果客人说菜太辣怎么办?如果客人情绪激动要找店长怎么办?AI产品的对话流(Bot Flow)设计与异常分支设计,本质上就是给机器人写这样一本“服务手册”。这份手册在AI产品PRD里叫“对话流文档”:它定义机器人在什么状态下说什么话、收集什么信息、遇到听不懂或做不到的情况如何兜底——和餐厅手册挨个定义“如果”是一模一样的思维。本篇文章就带你用这本“服务手册”的视角,一步步看懂对话流的概念、主流程与异常分支的撰写方法、文档规范、可解释性需求设计,以及最后用评估集验收整个流程的方法。

岗位关联

一句话职业价值:对话流与异常分支是AI产品从“想法”走向“可开发、可验收”的施工图。掌握它的PRD撰写方法,是AI产品经理在评审会不被怼、研发不迷路、测试有依据的核心竞争力。

目录
  1. 可视化演示
  2. 1. 对话流的概念:一张服务路线图
  3. 2. 主流程撰写:从迎宾到送客
  4. 3. 异常分支设计:当客人不按剧本走
  5. 4. 文档规范:让手册像手册
  6. 5. 可解释性需求设计:让用户理解机器人
  7. 6. 评估集设计:用“神秘顾客”验收手册
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

动态演示AI产品PRD的核心机制,通过全局/局部/动态/静态四种模式展示关键概念与交互流程。

本节配有交互动效(进入视口后自动加载,约 3KB)。

AI产品PRD:对话流设 对话流设计基础架构 主流程与分支设计 核心机制可视化 AI产品PRD整体架构与关键组件

1. 对话流的概念:一张服务路线图

写《服务手册》的第一步,是画一张“服务路线图”:从客人进门到离店,服务员每一步站在哪里、该做什么、下一步去哪儿。这张图不需要画出每一句台词,但必须标出关键站点和行进方向。对话流(Bot Flow)就是AI产品的“服务路线图”。

在PRD里,对话流被定义为一系列有序的交互节点与状态转移规则。它回答三个问题:机器人现在处于什么状态(状态)、用户此刻的输入是什么意思(意图)、收到这个输入后机器人要做什么并进入什么状态(转移)。这与餐厅路线图中“服务员在门口→看到客人→上前招呼→进入点单状态”是同构的。

常见的节点类型有:开场节点(问候与能力说明)、意图识别节点(判断用户输入)、槽位收集节点(逐项补齐信息)、条件分支节点(按槽位或置信度分流)、回复节点(输出话术)、结束节点(明确收尾)。这些节点串起来形成主流程;从任意节点伸出去的“否则”,就是异常分支的起点。

回到餐厅手册,这张路线图的价值,是让前台、后厨、店长对“服务路径”有一致理解。AI产品经理画对话流图,同样是为了让研发、测试、运营在同一张图上对齐——后面的每一节,都是在为这张图补细节。

St+1=δ(St,At)\displaystyle S_{t+1} = \delta(S_t, A_t)
对话流就是一次状态机旅行:你站在某个状态 $S_t$,用户做了动作 $A_t$,状态机根据规则 $\delta$ 决定你下一步走到 $S_{t+1}$。
  1. 当前状态 $S_t$机器人此刻所在的环节,比如“开场白”或“槽位收集中”,它是决策的起点。
    St∈{s0,s1,…,sn}S_t \in \{s_0, s_1, \dots, s_n\}
  2. 用户动作 $A_t$用户本轮输入的一句话或一个点击,是状态转移的唯一触发器。
    At=用户的自然语言输入A_t = \text{用户的自然语言输入}
  3. 转移规则 $\delta$PRD中定义的“如果…那么…”规则表,把“状态+动作”映射到下一状态。
    δ:S×A→S\delta: S \times A \rightarrow S
  4. 下一状态 $S_{t+1}$机器人完成本轮回复后进入的新环节,也是下一轮决策的起点。
    St+1=δ(St,At)S_{t+1} = \delta(S_t, A_t)

2. 主流程撰写:从迎宾到送客

路线图有了,接下来把主流程的每一站写细。主流程指用户在预期内配合时走过的路径,相当于餐厅的“正常服务线”:迎宾、询问、记录、复述、下单、送客。对话流主流程通常围绕四个环节展开。

开场白设计是第一站。第一句话要说清“我是谁、我能做什么、怎么开始”,就像服务员开口“您好,欢迎光临,今天有新款宫保鸡丁”。开场白要暗示能力边界(避免用户问出机器人答不了的问题),并抛出第一个引导问题,把对话推进到正题。

槽位收集是主流程的核心环节。要完成任务,机器人需要若干必要信息,比如点餐需要“菜品”和“数量”,这些信息项就是槽位(Slot)。撰写要点是每轮只问一项,降低用户负担;用户一次性给出多项时则全部吸收。信息齐了之后进入澄清确认——把理解复述给用户,得到确认后再执行;最后用明确的结束语收尾,告诉用户“订单已下达”。

主流程写得越细,测试越有据可依。餐厅手册绝不会只写“把菜端上去”,而是会写“报菜名、确认桌号、提醒烫口”。对话流PRD对每一环写清触发、动作、回复,就是让开发拿到就可以编码,让测试拿到就可以写用例。

SlotFillRate=∣Ffilled∣∣Frequired∣\displaystyle SlotFillRate = \frac{|F_{\text{filled}}|}{|F_{\text{required}}|}
槽位完成率 = 已收集到的必填信息项 ÷ 全部必填信息项。它等于 1 时,流程才具备进入确认环节的条件。
  1. 必填槽位集合 $F_{\text{required}}$PRD里写死的一组信息项,比如{菜品,数量}。
    Frequired={菜品,数量}F_{\text{required}} = \{\text{菜品}, \text{数量}\}
  2. 已填槽位集合 $F_{\text{filled}}$机器人从用户对话中成功提取到的信息项集合。
    Ffilled⊆FrequiredF_{\text{filled}} \subseteq F_{\text{required}}
  3. 完成率计算两个集合的元素数目之比,取值范围是 0 到 1。
    SlotFillRate=∣Ffilled∣∣Frequired∣∈[0,1]SlotFillRate = \frac{|F_{\text{filled}}|}{|F_{\text{required}}|} \in [0, 1]
  4. 进入条件完成率等于 1 时,对话流才能推进到澄清确认环节。
    SlotFillRate=1⇒进入确认SlotFillRate = 1 \Rightarrow \text{进入确认}

3. 异常分支设计:当客人不按剧本走

再好的服务员也会遇到“不按剧本走”的客人:菜卖完了、客人说太辣、客人突然要求见店长。餐厅手册必须为每个可能翻车的位置准备“否则怎么办”。对话流同理,异常分支是PRD里最见功力的部分。

异常分支从“识别失败”开始。当置信度低于阈值,机器人进入兜底策略——用统一话术表达“没听清/没听懂”,并给出回到主流程的引导,比如“您可以试试说:我要点麻婆豆腐”。注意兜底不是重复同一句话,而是每次都带新的提示,给用户回头的阶梯。

兜底需要计数。连续失败达到上限(如 2 次),就触发拒识处理升级:要么换一种问法,要么直接转人工。转人工机制要有明确的触发条件:连续失败次数、用户明确指出“人工/投诉”、或涉及敏感权限操作。此外,边界约束要写明“绝不承诺的事”,避免机器人为了安抚用户而撒谎,比如承诺“一定退款”。

手册里“客人发火怎么办”这一页,餐厅写的是“先道歉、再倾听、再请店长”。对话流的异常分支规则写得越具体,机器人就越像一个训练有素的员工,而不是一碰就崩的复读机。异常设计本质上是在定义产品的下限体验。

Handoff={转人工,Nfail≥K继续兜底,Nfail<K,Nfail=∑t1[ conft<θ ]\displaystyle Handoff = \begin{cases} \text{转人工}, & N_{\text{fail}} \ge K \\ \text{继续兜底}, & N_{\text{fail}} < K \end{cases}, \quad N_{\text{fail}} = \sum_{t} \mathbb{1}[\, conf_t < \theta \,]
转人工的开关是“失败计数器”:每轮识别置信度低于阈值就记一次失败,失败累计到上限 $K$ 就转人工,否则继续兜底。
  1. 单轮置信度 $conf_t$意图识别模块对第 $t$ 轮输入给出的把握,取各意图概率的最大值。
    conft=max⁡iP(意图i∣At)conf_t = \max_i P(\text{意图}_i | A_t)
  2. 置信阈值 $\theta$PRD定义的及格线,低于它视为“没把握”,建议取值 0.5 到 0.7。
    θ=0.5 (可配置)\theta = 0.5 \ (\text{可配置})
  3. 失败计数 $N_{\text{fail}}$指示函数逐轮累计“低于阈值”的次数。
    Nfail=∑t1[ conft<θ ]N_{\text{fail}} = \sum_{t} \mathbb{1}[\, conf_t < \theta \,]
  4. 转人工判断把累计失败数与上限 $K$ 比较,决定走转人工还是继续兜底。
    Nfail≥K⇒HandoffN_{\text{fail}} \ge K \Rightarrow Handoff

4. 文档规范:让手册像手册

手册写好了,但如果每页格式混乱、编号缺失,服务员现场根本翻不到“客人发火怎么办”在哪一页。PRD的对话流文档同样需要强规范,才能支撑多人协作、评审与追溯。文档规范是对话流PRD的“排版与检索系统”。

PRD结构上,对话流文档一般包含:背景与目标(为什么做)、角色定义(用户与Bot的画像与职责)、主流程(happy path)、异常分支(否则路径)、评估方案(验收口径),以及附录(话术清单、变更记录)。每一部分的职责边界清晰,评审时才能按图索骥。

编号规则是规范的核心。每个节点与分支要有唯一编号,如 BBF-01-03 表示“对话流-主流程-第 3 个节点”,这样评审时可以说“BBF-02-01 的兜底话术要改”,而不是“第二页那个”。状态描述则要求每个节点写清三件事:进入条件、处理逻辑、退出条件(正常出口与异常出口),保证任何人都能照着复现。

餐厅的《服务手册》之所以厚,不是因为话多,而是因为每个流程都有编号、有责任角色、有援引方式。文档规范让PRD从“一篇作文”变成“一张可执行的施工图”,这也是AI产品经理专业度的直接体现。

Sall=Smain∪Sexception,∀s∈Sall: exit(s)≠∅\displaystyle S_{\text{all}} = S_{\text{main}} \cup S_{\text{exception}}, \quad \forall s \in S_{\text{all}}:\, exit(s) \neq \emptyset
状态完备性要求:所有状态 = 主流程状态 ∪ 异常状态,且每个状态都必须有“出口”——没有出口的节点是死路,会让用户卡死。
  1. 主流程状态集 $S_{\text{main}}$用户配合时的路径节点集合,如开场、收集、确认。
    Smain={s0main,s1main,… }S_{\text{main}} = \{s_0^{\text{main}}, s_1^{\text{main}}, \dots\}
  2. 异常状态集 $S_{\text{exception}}$兜底、拒识、转人工等异常路径的节点集合。
    Sexception={s0ex,s1ex,… }S_{\text{exception}} = \{s_0^{\text{ex}}, s_1^{\text{ex}}, \dots\}
  3. 并集完备评审时逐节点检查,两类状态合起来必须覆盖全部对话场景。
    Sall=Smain∪SexceptionS_{\text{all}} = S_{\text{main}} \cup S_{\text{exception}}
  4. 出口非空每个状态至少有一个正常出口或异常出口,不允许死循环。
    exit(s)≠∅, ∀s∈Sallexit(s) \neq \emptyset, \ \forall s \in S_{\text{all}}

5. 可解释性需求设计:让用户理解机器人

客人追问“这道菜怎么还没来”,服务员如果只说“很快就好”而不解释原因,客人只会更不安。AI产品的可解释性需求设计,就是规定机器人“在什么时候、用什么方式解释自己的行为”。这是PRD里经常被漏掉、却决定信任感的部分。

可解释性需求通常写成三条规则。第一,原因说明:当机器人无法完成任务或做得不对时,要主动说明原因,而不是含糊带过。第二,置信度提示:识别不确定时,用“我理解是……对吗?”的方式表达不确定性,而不是假装确定,给用户纠正的机会。

第三,能力边界:在开场或遭遇拒识时,主动告知“我不能做什么”(如“我无法为您转账,转账请前往柜台”),管理用户预期。这些需求都要落到一张“场景→解释话术→触发条件”的表格里,写进PRD的需求条目,而不是留给开发临时发挥。这就是透明机制:让用户始终知道自己面对的是有限能力的AI、当前行为为什么发生。

好的服务员不会假装自己什么都知道,好的机器人也一样。可解释性需求设计,是把“诚实”变成PRD里可开发、可测试的条目。它和餐厅手册里“主动告知今日售罄菜品”是同一件事——先说明,再引导,用户才会放心把事交给机器人。

Response={直接回答,conf≥θ解释+澄清,conf<θ\displaystyle Response = \begin{cases} \text{直接回答}, & conf \ge \theta \\ \text{解释+澄清}, & conf < \theta \end{cases}
可解释性不是做错了才道歉,而是“没把握时先说明再确认”:置信度及格就直接答,不及格就解释并澄清,把不确定性画给用户看。
  1. 置信度变量 $conf$意图识别给出的把握值,范围是 0 到 1。
    conf∈[0,1]conf \in [0, 1]
  2. 阈值 $\theta$PRD定义的“把握及格线”,建议取 0.5 到 0.7。
    θ 建议 0.5-0.7\theta \ \text{建议 0.5-0.7}
  3. 直接回答分支把握足够,给用户确定的直接答案,提升交互效率。
    conf≥θ⇒直接回答conf \ge \theta \Rightarrow \text{直接回答}
  4. 解释+澄清分支把握不足,先说明不确定性,再引导用户确认。
    conf<θ⇒解释+澄清conf < \theta \Rightarrow \text{解释+澄清}

6. 评估集设计:用“神秘顾客”验收手册

手册写得好不好,不能靠自我感觉。餐厅的做法是请“神秘顾客”按标准剧本上门试菜、挑刺、打分。AI产品的评估集(Evaluation Set)就是这套标准剧本:一批预先设计好的输入对话序列,配上期望输出,用来验收对话流是否达标。

评估集设计从用例分类开始:主流程用例(happy path,如完整点单)、异常分支用例(兜底、拒识、转人工)、边界用例(空输入、超长输入、模糊表达)、合规用例(敏感词、隐私请求)。每个用例的标注规范包含三要素:输入对话序列、期望最终状态、允许的回复范围。

覆盖策略上,要求“每条分支至少一条用例”,优先级从高频路径到低频路径递减。验收标准统一用可量化指标:分支覆盖率不低于设定值(如 80%)、任务成功率、未识别转人工率、用户满意度。PRD里写明这些指标,开发完成后才能照单验收,而不是“感觉差不多能上”。

神秘顾客的剧本写得越刁钻,手册的漏洞暴露得越快。评估集不是开发完之后的玩具,而是PRD阶段就要与对话流同步设计的一份“验收合同”。有了它,“这本手册合格吗”这个问题,才第一次有了可以量化的答案。

Coverage=∣Ecovered∣∣Ebranch∣≥γ\displaystyle Coverage = \frac{|E_{\text{covered}}|}{|E_{\text{branch}}|} \ge \gamma
分支覆盖率 = 评估集覆盖到的分支数 ÷ PRD定义的全部分支数,它必须不低于预设的验收线 $\gamma$(比如 80%)。
  1. PRD分支集合 $E_{\text{branch}}$对话流文档里定义的所有主流程与异常分支。
    Ebranch={e1,e2,…,em}E_{\text{branch}} = \{e_1, e_2, \dots, e_m\}
  2. 已覆盖集合 $E_{\text{covered}}$评估集用例实际走过并断言过的分支。
    Ecovered⊆EbranchE_{\text{covered}} \subseteq E_{\text{branch}}
  3. 覆盖率比值两者元素数目之比,反映验收的全面程度。
    Coverage=∣Ecovered∣∣Ebranch∣Coverage = \frac{|E_{\text{covered}}|}{|E_{\text{branch}}|}
  4. 验收线 $\gamma$PRD写明的覆盖率下限,不达标则不允许上线。
    γ=0.8 (示例)\gamma = 0.8 \ (\text{示例})

AI 应用场景

场景1:银行App智能客服的对话流PRD撰写

阶段:需求分析与规格设计

解决的问题:银行智能客服在PRD阶段经常只写“能查余额、能查流水”,导致开发完成后,用户问“能转账吗”时机器人答非所问,转人工无门槛,客服通道被挤爆。用对话流与异常分支的方法,把每个意图的主流程、槽位(账号、时间段)、异常分支(识别失败、超权限请求、转账引导)写成可评审的文档。

具体案例:某银行AI产品经理在PRD中定义“查流水”流程:开场白→收集账号与时间段→确认→展示摘要→引导下载明细;异常分支定义“查询他人账户”时的边界约束为“无法查询他人账户”并引导走合规渠道。上线后无效转人工率下降 40%。

场景2:电商售后机器人的异常升级与转人工

阶段:交互设计与异常兜底

解决的问题:用户情绪激动(“我要投诉!”)或多次未识别时,机器人继续复读会让投诉升级。用失败计数加转人工触发规则设计异常分支,让机器人知道“什么时候该认输、请人上场”。

具体案例:某电商机器人PRD定义:连续 2 轮未识别→转人工;检测到“投诉/人工/消协”关键词→立即转人工并同步订单上下文。上线后投诉升级率下降,用户满意度提升 12 个百分点。

场景3:智能客服上线前的评估集验收

阶段:评测与验收

解决的问题:缺少客观验收指标,研发说“能用了”,测试说“感觉不行”。用评估集设计方法,在PRD阶段就定好用例与指标,避免上线前的“我觉得”拉锯战。

具体案例:某保险客服项目按“分支覆盖率≥85%”的要求设计 120 条用例(主流程 50、异常 40、边界 30)。验收时发现“转人工”分支 3 条用例仅通过 1 条,定位到阈值配置错误,修复后达标上线。

Python 演示

python112 行
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))
目的:用状态机实现一个点餐机器人,演示对话流主流程(开场→槽位收集→确认→完成)与异常分支(兜底→转人工),并用评估集用例自动验收。
  1. def recognize(self, text):意图识别模块,命中词表返回高置信度,否则返回低置信度,对应PRD中的意图识别节点。
  2. if conf < self.threshold:置信度低于阈值时进入兜底逻辑,对应文章中的阈值 $\theta$。
  3. self.fallback_count += 1失败计数器累加,对应异常分支的拒识处理。
  4. if self.fallback_count >= self.max_fallback:失败次数达到上限触发转人工,对应 $N_{\text{fail}} \ge K$。
  5. need = [s for s in self.required_slots if s not in self.slots]计算缺失槽位,对应槽位完成率。
  6. EvalCase("主流程-完整点单", ...)构造一条评估集用例,声明输入序列与期望最终状态。
  7. rate = run_eval(cases)执行全部评估集用例并计算通过率,对应验收标准。

常见误区

误区很多初学者拿到PRD任务,先画一条“开始→识别→处理→结束”的直线,认为用户都会顺着走,画完主流程就交差。

正解真实对话中用户会乱说、会反问、会不配合。PRD必须同时定义主流程和异常分支:兜底话术怎么写、失败几次转人工、哪些话不能说。异常分支直接决定机器人的下限体验,就像餐厅手册不能只写“正常上菜”不写“客人发火怎么办”。

为何常见:人天然倾向于先描述“顺利的情况”,异常是噪声;而且异常分支写起来琐碎,容易被认为是“开发自己想就行”。

误区为了让机器人“无死角”,把能想到的用户输入全部写成独立分支,结果PRD几百页,评审没人看完,维护也崩溃。

正解穷举不现实,正确做法是“分级兜底”:高频异常单独成分支,低频不可列举的输入用统一兜底话术覆盖,并设置转人工上限。像餐厅不会为“客人说外星话”写专属预案,而是统一“不好意思,没听清,我请店长来”。

为何常见:怕漏掉,做加法容易;做“兜底+分级+转人工”需要设计取舍,难度更高。

误区把可解释性理解为“机器人说对不起”,在回复模板里塞一句“抱歉”就算完成可解释性需求。

正解可解释性是结构性的预期管理:让用户知道自己在和AI对话、当前是否确定、为什么做不了、信息如何使用。它要写成“场景→解释话术→触发条件”的需求表,和道歉文案完全是两回事。

为何常见:把“可解释”误认为“礼貌”,忽略了透明机制的设计,这也是PRD评审中最容易被放过的一环。

误区评估是开发之后的事,PRD阶段先把流程写了,测试用例等代码出来再说。

正解评估集应在PRD阶段与对话流同步设计,作为验收红线。否则开发完成后没有客观标准,只能靠“我觉得差不多”决定是否上线,体验风险极高。

为何常见:把评估等同于“测试”,而测试通常发生在开发后;但对话流评估集本质是需求规格的可执行化,必须在写需求时同步定义。

面试题

Q1. 对话流设计中,“槽位”(Slot)最准确的理解是?

单选题 · easy

  • A.对话历史存储位置
  • B.完成任务所需信息项← 正确答案
  • C.数据库查询缓存区
  • D.用户身份验证凭证

答案:B。槽位是完成任务所需的必要信息项,如点餐需要的“菜品、数量”,对应餐厅记录客人需求的“点单信息栏”。对话历史、缓存、凭证都不是槽位。

Q2. 对话流中“意图识别”节点的核心作用是?

单选题 · easy

  • A.判断用户请求分词
  • B.生成用户回复文本
  • C.理解用户真实意图← 正确答案
  • D.训练语言模型参数

答案:C。意图识别是判断“用户这句话想干什么”,如同服务员判断客人说“有点辣”是要加辣还是想换菜。分词是手段,生成回复是下游任务,训练参数是算法侧工作。

Q3. 机器人连续两次未识别用户意图时,最合理的异常设计是?

单选题 · mid

  • A.循环播放同一提示
  • B.触发兜底并转人工← 正确答案
  • C.静默等待用户输入
  • D.直接返回主菜单

答案:B。连续失败达到上限应触发兜底升级并转人工,如同服务员两次没听懂就请店长。循环同一提示让用户重复,静默超时和直接返回主菜单都没有解决用户的真实问题。

Q4. 当槽位全部收集完成后,对话流下一步应该?

单选题 · mid

  • A.立即执行用户操作
  • B.结束整段对话流程
  • C.转交人工客服处理
  • D.进入确认环节复核← 正确答案

答案:D。槽位齐了不代表可以立刻执行,先进入澄清确认环节,把理解复述给用户,像餐厅下单前报一遍菜名。立即执行可能误解用户,直接结束或转人工都跳过了应有的确认步骤。

Q5. 可解释性需求中,当识别置信度较低时机器人应?

单选题 · mid

  • A.说明不确定的原因← 正确答案
  • B.给出最肯定的答复
  • C.重复用户输入原话
  • D.主动结束当前对话

答案:A。低置信时应表达不确定性并给出澄清引导,如“我理解是……对吗?”,对应服务员“我没太听清,您说的是宫保鸡丁吗”。假装肯定、复读原话、结束对话都会破坏信任。

Q6. PRD中对话流文档应包含的内容有?

多选题 · mid

  • A.主流程节点定义← 正确答案
  • B.异常分支兜底策略← 正确答案
  • C.服务器日志存储格式
  • D.转人工触发的规则← 正确答案

答案:ABD。对话流文档必须定义主流程、异常分支和转人工机制,这是“服务手册”的三大部分。服务器日志格式属于技术架构文档,不属于对话流PRD范畴。

Q7. 某对话流共12条分支路径,评估集已覆盖8条,分支覆盖率约为?

单选题 · hard

  • A.百分之五十八
  • B.百分之五十
  • C.百分之六十七← 正确答案
  • D.百分之七十五

答案:C。分支覆盖率 = 已覆盖分支 ÷ 全部分支 = 8 ÷ 12 ≈ 0.67,即百分之六十七。其余选项分别是错误的估算值。

Q8. 对话流“边界约束”设计应明确哪些内容?

多选题 · hard

  • A.渲染层引擎的版本要求
  • B.机器人不回答的问题范围← 正确答案
  • C.敏感信息的权限边界← 正确答案
  • D.兜底话术的表达边界← 正确答案

答案:BCD。边界约束定义“机器人绝不能做什么”:不回答的问题、敏感信息权限、兜底话术的承诺边界,如同餐厅规定服务员不得承诺免单。渲染层引擎版本属于技术实现细节。

Q9. 开场白设计最重要的目标是?

单选题 · easy

  • A.展示技术实现能力
  • B.收集用户全部需求
  • C.引导用户使用入口
  • D.说明服务范围边界← 正确答案

答案:D。开场白要说明“我是谁、能做什么、怎么做”,重点是把能力边界讲清楚,像服务员进门先报今日菜品。展示技术、收集需求、引导下载都不是第一目标。

Q10. 评估集用例设计应在哪个阶段启动?

单选题 · hard

  • A.需求评审全部通过后
  • B.与PRD撰写同步进行← 正确答案
  • C.开发完成联调测试时
  • D.产品上线灰度发布时

答案:B。评估集是需求规格的可执行化,应在PRD阶段与对话流同步设计,作为验收合同。等到评审后、联调时或上线前才启动,都失去了对需求的约束作用。