第34章 AI产品原型设计：对话流、状态机、异常处理

34.1 AI产品的原型设计和传统产品有什么不同？

传统产品的原型设计已经有成熟的方法论——页面流程图、线框图、交互原型。但AI产品的原型设计有很大不同，如果用传统方法设计AI产品原型，开发出来的产品往往体验很差。

34.1.1 传统产品原型设计的核心假设

传统产品的原型设计建立在几个假设上：

• 交互确定性：用户点击按钮A，就跳转到页面B；用户提交表单，就保存数据。交互路径是确定的，原型可以穷举所有页面和跳转。
• 输出可预期：系统的输出是确定的——搜索"iPhone"就返回iPhone的商品列表，点击"加入购物车"就把商品加入购物车。原型可以精确展示每个页面的内容。
• 状态有限：系统状态是有限的、可枚举的——未登录/已登录、未支付/已支付/已发货/已完成。原型可以覆盖所有状态。
• 异常可枚举：异常情况是有限的——网络错误、参数错误、权限不足。原型可以为每种异常设计错误提示。
• 页面为中心：传统产品以页面为中心，原型设计就是设计页面和页面之间的跳转关系。

34.1.2 AI产品原型设计的特殊挑战

AI产品打破了传统原型设计的所有假设：

1. 交互不确定性——用户输入千变万化，AI输出不可预测
传统产品用户只能点击预设的按钮、输入预设的表单，交互路径是确定的。但AI产品用户可以输入任何内容——"帮我写个假条"、"我心情不好"、"1+1等于几"、"你是傻逼吗"。AI的输出也是不可预测的——同样的问题，不同时间回答可能不一样。
这意味着：你无法穷举所有用户输入和AI输出，原型不能只画几个页面，必须设计对话流和状态机，覆盖各种可能的交互路径。

2. 对话式交互——不是页面跳转，而是连续对话
传统产品以页面为中心，用户在页面之间跳转。但AI产品以对话为中心，用户和AI在一个对话窗口中连续交互——用户说一句话，AI回答，用户再追问，AI再回答，可能持续很多轮。
这意味着：原型设计的核心不是页面流程图，而是对话流——对话怎么开始、怎么推进、怎么结束、上下文怎么管理、多轮对话怎么衔接。

3. 状态复杂——对话状态、任务状态、用户状态交织
传统产品的状态相对简单（登录状态、订单状态）。但AI产品的状态非常复杂：

• 对话状态：刚开始/进行中/等待用户回复/AI思考中/已结束
• 任务状态：未开始/信息收集中/处理中/待确认/已完成/已失败
• 用户状态：新用户/老用户、免费用户/付费用户、情绪正常/情绪激动
• 系统状态：正常/模型调用中/工具调用中/网络异常/系统故障

4. 异常情况多且不可预测——AI会出错、会幻觉、会理解错
传统产品的异常是有限的、可枚举的（网络错误、参数错误）。但AI产品的异常非常多且不可预测：

• 用户输入异常：用户说脏话、说无关的话、输入乱码、输入超长文本
• AI输出异常：AI幻觉（编造信息）、答非所问、输出格式错误、输出敏感内容
• 工具调用异常：工具调用失败、参数错误、返回结果异常、超时
• 系统异常：模型API超时、限流、网络中断、服务不可用
• 安全异常：用户试图注入Prompt、用户询问敏感内容、用户试图越权操作

5. 渐进式输出——AI不是一次性给出完整回答，而是流式输出
传统产品的输出是一次性的——点击搜索，等加载完成，一次性显示完整结果。但AI产品的输出是渐进式的——AI一个字一个字地生成回答（流式输出），用户可以看到AI的思考过程（如Agent的工具调用过程）。
这意味着：原型必须设计流式输出的交互——Loading状态、打字机效果、思考过程展示、生成中断、重新生成。这些是AI产品特有的交互，传统原型设计方法不覆盖。

6. 反馈与学习——用户可以给AI反馈，AI会持续学习
传统产品用户使用完就完了，很少有反馈环节。但AI产品需要用户反馈来持续优化——"有帮助/没帮助"、"重新生成"、"编辑AI的回答"、"转人工"。这些反馈数据是AI持续优化的基础。
这意味着：原型必须设计反馈机制——什么时候展示反馈按钮、反馈后给用户什么响应、反馈数据怎么收集和使用。

34.2 对话流设计：AI产品交互的核心

对话流（Conversation Flow）是AI产品原型设计的核心，它描述了用户和AI之间的对话如何开始、推进、结束。

34.2.1 对话的基本结构

一个完整的AI对话通常包含以下阶段：

1. 对话开始（Opening）
   - 用户进入对话界面
   - AI展示欢迎语/引导语/推荐问题
   - 用户输入第一个问题

2. 意图识别（Intent Recognition）
   - AI理解用户的意图
   - 判断是常见问题/复杂问题/闲聊/异常输入
   - 决定处理策略（直接回答/收集信息/转人工/拒绝回答）

3. 信息收集（Information Gathering）
   - 如果需要更多信息才能回答，AI主动询问
   - 用户提供信息
   - AI确认信息是否完整

4. 处理与回答（Processing & Response）
   - AI处理用户请求（检索知识库/调用工具/推理）
   - AI生成回答
   - 流式输出回答

5. 确认与反馈（Confirmation & Feedback）
   - AI询问是否解决了用户问题
   - 用户给出反馈（有帮助/没帮助/继续追问）
   - 如果没解决，AI尝试其他方式或转人工

6. 对话结束（Closing）
   - 用户问题解决，对话结束
   - AI展示结束语/推荐后续操作/邀请评价
   - 用户离开或开始新对话

34.2.2 单轮对话 vs 多轮对话

单轮对话（Single-turn）：
用户问一个问题，AI回答，对话结束。不需要上下文记忆。
示例："退换货政策是什么？" → AI回答退换货政策 → 用户得到答案，对话结束。
设计要点：

• 回答要完整、准确，一次解决用户问题
• 回答末尾可以推荐相关问题（"您可能还想了解：物流查询、发票申请"）
• 提供反馈按钮（"有帮助/没帮助"）
• 如果回答不完整，提供"查看更多"或"转人工"选项

多轮对话（Multi-turn）：
用户和AI连续交互多轮，需要上下文记忆和状态管理。
示例：
用户："我想订机票"
AI："好的，请问您从哪里出发，去哪里？"
用户："从北京到上海"
AI："好的，北京到上海。请问您想哪天出发？"
用户："下周三"
AI："好的，下周三（10月16日）北京到上海。为您查询到以下航班..."
设计要点：

• 上下文记忆：AI要记住之前对话的信息（出发地、目的地、日期），不要重复询问
• 信息收集策略：一次问一个问题还是一次问多个？（一次问一个体验好但轮次多，一次问多个效率高但用户可能不回答全部）
• 确认机制：关键信息收集完后，要向用户确认（"您是要订10月16日北京到上海的机票，对吗？"）
• 修改机制：用户可以修改之前提供的信息（"不对，是周四不是周三"），AI要能正确更新信息
• 上下文丢失处理：如果对话太长上下文丢失，AI要能识别并重新询问关键信息，而不是胡乱回答
• 任务状态展示：让用户知道当前任务进展到哪一步（"已收集：出发地、目的地、日期，还需要：乘客信息"）

34.2.3 对话引导设计

AI产品的用户往往不知道该怎么和AI对话，需要设计引导机制。

新用户引导：

• 欢迎语：友好的欢迎语，介绍AI能做什么（"您好，我是智能客服小助手，可以帮您查询物流、退换货、发票等问题"）
• 推荐问题：展示几个常见问题按钮，用户点击即可提问（"查询物流 · 退换货政策 · 发票申请 · 联系人工"）
• 使用提示：告诉用户怎么使用（"您可以直接输入问题，或点击上方推荐问题"）
• 示例对话：展示一个示例对话，让用户知道AI能做到什么程度

对话中引导：

• AI回答后推荐相关问题（"您可能还想了解：如何申请退款？退款多久到账？"）
• 用户问题模糊时，AI主动澄清（"您是想查询已下单的物流，还是想了解配送时效？"）
• 任务完成后推荐下一步操作（"机票已预订成功，您还需要：预订酒店？预约接机？查看行程？"）
• 用户卡住时提供帮助（"您可以输入'人工'转人工客服，或输入'菜单'查看功能列表"）

引导设计的原则：

• 不要过度引导，不要每句话都推荐一堆问题，会干扰用户
• 引导要和上下文相关，不要推荐无关的问题
• 引导选项不要太多（3-5个为宜），太多用户选择困难
• 引导是辅助，不要强制，用户可以忽略引导自由输入

34.2.4 对话终止与重新开始

对话终止的情况：

• 用户问题解决，用户主动结束（"谢谢，搞定了"）
• AI判断问题已解决，主动结束（"您的问题已解决，还有其他需要帮助的吗？"）
• 用户长时间无响应（超时，如5分钟无消息，对话自动结束）
• 用户要求转人工，AI对话结束，转接人工
• 用户输入"结束"、"再见"、"退出"等结束指令

对话结束的交互：

• 结束语：友好的结束语（"感谢您的咨询，祝您生活愉快！"）
• 评价邀请：邀请用户评价本次服务（"请对本次服务评分：⭐⭐⭐⭐⭐"）
• 后续推荐：推荐相关功能或内容（"您可能还需要：查看订单 · 关注公众号 · 下载APP"）
• 新对话入口：提供"开始新对话"按钮，用户可以开始新的话题
• 历史记录：保存对话历史，用户可以查看之前的对话

重新开始对话：

• 用户点击"新对话"按钮，清空当前对话，开始新对话
• 新对话不继承之前的上下文（避免上下文混乱）
• 如果用户在同一个对话中切换话题，AI要能识别并切换（"好的，我们来聊下一个问题"），必要时提醒用户"开始新对话"以获得更好的体验

34.3 状态机设计：管理复杂的对话状态

AI产品的状态非常复杂，如果不设计状态机，开发出来的产品会状态混乱。状态机（State Machine）是管理复杂状态的有效工具。

34.3.1 为什么需要状态机

没有状态机的AI产品会出现这些问题：

• AI还在思考/生成回答时，用户又发了一条消息，导致两条消息冲突
• 任务还在信息收集中，AI就开始处理，导致信息不全结果错误
• 用户已经转人工了，AI还在自动回答，和人工客服"抢话"
• 网络异常后恢复，AI不知道之前进行到哪一步，重复询问用户
• 对话已经结束了，用户发消息AI还在回答，或者AI不回答了

34.3.2 AI产品的核心状态

对话状态（Conversation State）：

• IDLE（空闲）：对话已开始，等待用户输入。AI可以接收用户消息。
• THINKING（思考中）：AI正在理解用户意图、检索信息、生成回答。此时不接收新的用户消息（或排队等待）。
• TOOL_CALLING（工具调用中）：AI正在调用外部工具（查询数据库、调用API）。展示工具调用过程。
• WAITING_USER（等待用户回复）：AI已经回答，等待用户反馈或继续输入。可以接收用户消息。
• COLLECTING_INFO（信息收集中）：多轮对话中，AI正在收集完成任务所需的信息。每收集一个信息更新状态。
• CONFIRMING（待确认）：AI收集完信息，等待用户确认关键信息。用户可以确认或修改。
• PROCESSING（处理中）：信息确认完毕，AI正在执行任务（如下单、预订）。展示处理进度。
• HUMAN_TRANSFER（转人工中）：正在转接人工客服。AI停止自动回答，展示排队信息。
• HUMAN_CHATTING（人工服务中）：人工客服正在服务。AI不自动回答，但可以辅助人工（推荐答案）。
• COMPLETED（已完成）：任务/对话已完成。展示完成信息，用户可以开始新对话。
• ERROR（异常）：系统异常（模型调用失败、网络中断、工具调用失败）。展示错误信息，提供重试/转人工选项。

任务状态（Task State）（对于需要完成具体任务的对话）：

• NOT_STARTED（未开始）
• INFORMATION_COLLECTING（信息收集中）
• INFORMATION_CONFIRMED（信息已确认）
• PROCESSING（处理中）
• PARTIALLY_COMPLETED（部分完成）
• COMPLETED（已完成）
• FAILED（已失败）
• CANCELLED（已取消）

用户状态（User State）：

• NEW_USER（新用户）/ EXISTING_USER（老用户）
• FREE_USER（免费用户）/ PAID_USER（付费用户）/ VIP_USER（VIP用户）
• NORMAL（情绪正常）/ FRUSTRATED（情绪烦躁）/ ANGRY（愤怒）
• VERIFIED（已认证）/ UNVERIFIED（未认证）

34.3.3 状态转换设计

状态机的核心是状态转换——什么事件触发什么状态转换，转换时执行什么动作。

示例：AI客服的状态转换

状态：IDLE（空闲，等待用户输入）
  ↓ 用户发送消息
  动作：接收消息，显示用户消息
  ↓
状态：THINKING（思考中）
  ↓ 意图识别完成
  ├─ 是常见问题且信息完整 → 检索知识库 → 生成回答
  ├─ 需要更多信息 → 进入COLLECTING_INFO
  ├─ 是复杂问题/投诉 → 进入HUMAN_TRANSFER
  └─ 是异常输入/敏感问题 → 进入ERROR或拒绝回答
  ↓
状态：COLLECTING_INFO（信息收集中）
  ↓ AI询问缺失的信息
  ↓ 用户回复信息
  动作：更新已收集的信息
  ↓ 信息收集完整
  ↓
状态：CONFIRMING（待确认）
  ↓ AI向用户确认关键信息
  ↓ 用户确认 → 进入PROCESSING
  ↓ 用户修改 → 回到COLLECTING_INFO（更新信息）
  ↓ 用户取消 → 进入CANCELLED
  ↓
状态：PROCESSING（处理中）
  ↓ AI执行任务（调用工具/API）
  ↓ 处理成功 → 进入COMPLETED
  ↓ 处理失败 → 进入ERROR（提供重试/转人工）
  ↓
状态：COMPLETED（已完成）
  ↓ 展示完成信息，邀请评价，推荐后续操作
  ↓ 用户开始新对话 → 回到IDLE（清空上下文）
  ↓
状态：HUMAN_TRANSFER（转人工中）
  ↓ 展示排队信息，预计等待时间
  ↓ 人工接入 → 进入HUMAN_CHATTING
  ↓ 排队超时/用户取消 → 回到IDLE或留言
  ↓
状态：HUMAN_CHATTING（人工服务中）
  ↓ 人工客服服务，AI辅助（推荐答案、自动填写）
  ↓ 人工结束服务 → 进入COMPLETED
  ↓
状态：ERROR（异常）
  ↓ 展示错误信息，提供重试/转人工/返回菜单选项
  ↓ 用户重试 → 回到之前的状态
  ↓ 用户转人工 → 进入HUMAN_TRANSFER
  ↓ 用户返回菜单 → 回到IDLE

34.3.4 状态机设计的原则

• 状态不要太多也不要太少：太多太复杂难以维护，太少不够精确。通常核心状态10-15个比较合适。
• 每个状态有明确的进入条件和退出条件：什么情况下进入这个状态？在这个状态下能做什么？什么情况下退出？
• 每个状态转换有明确的触发事件和动作：什么事件触发转换？转换时执行什么动作（如展示什么界面、调用什么接口）？
• 覆盖所有状态和转换：不要遗漏状态，不要遗漏转换路径，尤其是异常路径。
• 状态要可观测：用户能看到当前状态（如"AI正在思考..."、"正在为您转接人工..."），系统能监控状态转换，发现异常。
• 状态要可恢复：系统异常恢复后，能恢复到之前的状态，而不是从头开始。
• 用状态图可视化：画状态图（State Diagram），直观展示状态和转换，方便团队沟通和评审。

34.4 异常处理设计：AI产品体验的关键

异常处理是AI产品原型设计中最容易被忽视、但对用户体验影响最大的部分。AI产品的异常情况远多于传统产品，如果不设计好异常处理，用户体验会很差。

34.4.1 用户输入异常

异常类型与处理：

34.4.2 AI输出异常

异常类型与处理：

34.4.3 工具/系统异常

异常类型与处理：

34.4.4 异常处理设计的原则

• 友好性：错误提示要友好、易懂，不要展示技术错误信息（如"500 Internal Server Error"），要用用户能理解的语言（"系统繁忙，请稍后重试"）
• 可恢复：异常发生后，用户能恢复正常使用，而不是卡死或崩溃。提供重试、返回、转人工等恢复选项。
• 透明性：告诉用户发生了什么、为什么、怎么办。不要让用户蒙在鼓里（如一直Loading没有反馈）。
• 降级策略：核心功能不可用时，提供降级方案（如AI不可用时返回FAQ列表、人工不可用时提供留言）。保证基本可用，而不是完全不可用。
• 不编造：AI不知道就说不知道，工具调用失败就说失败，不要编造信息或假装成功。诚实比虚假的"完美"更能赢得用户信任。
• 可观测：异常要记录日志、监控告警，方便开发团队发现和修复。异常率是AI产品的核心指标之一。
• 覆盖全面：原型设计阶段就要穷举所有可能的异常，为每种异常设计处理方案。不要只设计正常流程，异常处理占AI产品设计工作量的40%以上。
• 用户引导：异常发生后，引导用户下一步怎么做（"您可以重试，或转人工客服"），不要让用户不知所措。

34.5 AI产品特有的原型要素

除了对话流、状态机、异常处理，AI产品还有一些特有的原型要素，在原型设计时必须考虑。

34.5.1 Loading与思考状态

AI生成回答需要时间（通常2-10秒），不能让用户干等。要设计Loading和思考状态。

设计要点：

• 即时反馈：用户发送消息后，立即显示用户消息，并显示AI的Loading状态（"AI正在思考..."），不要让用户以为没发送成功。
• 思考过程展示：对于Agent类产品，可以展示AI的思考过程（"正在检索知识库...正在调用查询工具...正在生成回答..."），让用户知道AI在做什么，减少等待焦虑。
• 打字机效果：AI回答生成时，用打字机效果逐字显示，而不是等全部生成完一次性显示。打字机效果让用户感觉AI在"实时回答"，体验更好，也减少了等待感。
• 生成中断：AI生成回答过程中，用户可以点击"停止"按钮中断生成。中断后显示已生成的部分，用户可以编辑或重新生成。
• 超时处理：如果AI思考时间过长（如超过30秒），提示用户"AI思考时间较长，您可以继续等待，或转人工客服"，不要让用户无限等待。
• 进度展示：对于多步骤任务（如预订机票），展示任务进度（"1/4 已确认出发地和目的地，2/4 正在查询航班..."），让用户知道进展。

34.5.2 反馈机制

AI产品需要用户反馈来持续优化，反馈机制是原型的重要部分。

反馈类型：

• 即时反馈：AI每条回答后，展示"有帮助/没帮助"按钮（👍/👎），用户一键反馈。
• 详细反馈：用户点"没帮助"后，可以选择原因（"回答不准确"、"答非所问"、"回答太简单"、"其他"），并可以输入文字说明。
• 重新生成：用户对AI回答不满意，可以点击"重新生成"，AI换一种方式回答。
• 编辑回答：用户可以编辑AI的回答，修改后使用。编辑后的数据可以用于优化AI。
• 复制/分享：用户可以复制AI的回答，或分享对话。
• 对话评价：对话结束后，邀请用户对本次服务整体评分（1-5星），并可以写评价。

设计要点：

• 反馈按钮要明显但不打扰，放在AI回答下方，不要遮挡内容。
• 反馈后给用户即时响应（"感谢您的反馈，我们会持续优化"），让用户知道反馈被接收了。
• 用户点"没帮助"后，可以主动提供替代方案（"抱歉没有帮到您，您可以：重新生成回答 / 转人工客服 / 查看相关帮助文档"）。
• 反馈数据要收集和分析，定期统计"没帮助"率、反馈原因分布，指导优化方向。
• 不要强制用户反馈，反馈是可选的，不要弹窗打断用户。

34.5.3 置信度与透明性

AI的回答不是100%准确的，要让用户知道AI的置信度和局限性，管理用户预期。

设计要点：

• AI身份明确：明确告诉用户这是AI助手（"我是智能客服小助手"），不要假装是人工。
• 置信度展示：对于高风险或不确定的回答，可以展示置信度（"根据知识库，答案是XXX（置信度：高/中/低）"）。低置信度时提醒用户核实。
• 来源引用：RAG生成的回答，可以引用来源（"根据《退换货政策》第3条..."），用户可以点击查看原文，增加可信度。
• 局限性说明：在合适的地方说明AI的局限性（"AI回答仅供参考，具体以实际政策为准"、"复杂问题建议转人工客服"）。
• 更新时间：知识库内容标注更新时间（"信息更新于2024年10月"），让用户知道信息的时效性。
• 不编造承诺：AI不要编造信息、不要做无法兑现的承诺（如"肯定能退款"），不确定时说"建议您咨询人工客服确认"。

34.5.4 人工介入设计

AI不可能解决所有问题，人工介入是AI产品的重要组成部分。

人工介入的触发方式：

• 用户主动触发：用户输入"人工"、"转人工"、"客服"，或点击"转人工"按钮。
• AI自动触发：AI判断问题复杂/高风险/自己解决不了，主动建议转人工（"这个问题比较复杂，建议您转接人工客服处理，可以吗？"）。
• 反馈触发：用户连续多次点"没帮助"，或用户表达不满，自动建议转人工。
• 规则触发：特定类型的问题（投诉、退款、赔偿、账户安全）直接转人工，AI不处理。

转人工流程设计：

• 确认：转人工前确认用户意愿（"正在为您转接人工客服，预计等待5分钟，请稍候"）。
• 排队展示：展示排队位置、预计等待时间，让用户有预期。可以让用户选择继续等待或留言。
• 信息同步：转接时把AI对话历史、用户信息、问题分类、AI的分析同步给人工客服，人工客服不需要重复询问。
• 人工辅助：人工客服服务时，AI可以辅助（推荐答案、自动填写常用回复、查询信息），提升人工效率。
• 服务结束：人工服务结束后，邀请用户评价，记录人工处理结果，用于优化AI。
• 非工作时间：非工作时间转人工时，提示工作时间，提供留言功能，工作时间后人工回复。

34.5.5 对话历史与上下文管理

AI产品需要管理对话历史和上下文，这是传统产品没有的。

设计要点：

• 历史记录保存：保存用户的对话历史，用户可以查看、搜索、删除之前的对话。
• 新对话机制：用户可以开始新对话，新对话不继承之前的上下文，避免上下文混乱。
• 上下文摘要：对话较长时，对早期对话做摘要，用摘要代替原始对话，节省上下文空间。
• 关键信息提取：从对话中提取关键信息（用户姓名、订单号、需求），结构化保存，跨对话复用。
• 上下文丢失处理：如果上下文丢失（对话太长、新对话），AI要能识别，必要时重新询问关键信息，不要胡乱回答。
• 跨设备同步：用户在手机上开始的对话，在电脑上可以继续，对话历史跨设备同步。
• 隐私保护：用户可以删除对话历史，可以设置对话保存时长，敏感对话可以选择"不保存"。

34.6 实战：设计一个AI旅行助手的对话流和状态机

让我们通过一个AI旅行助手的例子，实战练习对话流和状态机设计。

34.6.1 场景定义

AI旅行助手帮用户预订机票+酒店的自由行套餐。用户说"帮我安排下周去三亚的旅行"，AI需要：

1. 理解用户需求（目的地、时间、人数、预算、偏好）
2. 收集缺失信息（出发地、具体日期、人数、预算、酒店偏好）
3. 查询航班和酒店
4. 推荐方案，用户选择
5. 确认预订信息
6. 执行预订（调用订票API）
7. 完成预订，发送确认信息

34.6.2 对话流设计

【对话开始】
AI："您好，我是旅行助手小助手，可以帮您预订机票和酒店。请问您想去哪里旅行？"
（展示推荐目的地：三亚 · 成都 · 杭州 · 更多）

用户："帮我安排下周去三亚的旅行"

【意图识别】
AI识别：用户要预订旅行，目的地=三亚，时间=下周，出发地未知，人数未知，预算未知，酒店偏好未知
→ 需要收集信息，进入COLLECTING_INFO状态

【信息收集】
AI："好的，下周去三亚。请问您从哪个城市出发？"
用户："从广州出发"
AI："好的，广州出发。请问您具体想哪一天出发，玩几天？"
用户："下周五出发，玩3天"
AI："好的，10月18日（周五）出发，玩3天（10月18-20日）。请问几位出行？"
用户："2个人"
AI："好的，2位出行。请问您的预算大概是多少？对酒店有什么偏好吗？"
用户："预算5000以内，酒店要海景房"

【信息确认】
AI："好的，为您确认一下行程信息：
- 出发地：广州
- 目的地：三亚
- 出发日期：10月18日（周五）
- 行程天数：3天（10月18-20日）
- 出行人数：2人
- 预算：5000元以内
- 酒店偏好：海景房

请问以上信息正确吗？"
（按钮：确认 / 修改信息）

用户："确认"

【查询与推荐】
AI："好的，正在为您查询航班和酒店..."
（展示进度：正在查询航班... 正在查询酒店... 正在为您匹配方案）

AI："为您找到以下3个方案：

方案一（推荐）：¥4280/人
- 航班：南航CZ6743，10月18日 08:00-10:15，经济舱
- 酒店：三亚湾海景酒店，豪华海景房，含双早
- 包含：机票+酒店+接送机

方案二：¥3680/人
- 航班：春秋9C8921，10月18日 12:00-14:20，经济舱
- 酒店：三亚湾假日酒店，侧海景房，含双早
- 包含：机票+酒店

方案三：¥4980/人
- 航班：海航HU7361，10月18日 09:00-11:15，经济舱
- 酒店：亚龙湾海景度假酒店，无敌海景房，含双早+下午茶
- 包含：机票+酒店+接送机+旅行保险

请问您想选择哪个方案？"
（按钮：方案一 / 方案二 / 方案三 / 查看更多方案 / 修改需求）

用户："选方案一"

【预订确认】
AI："好的，您选择了方案一（¥4280/人，2人共¥8560）。
请提供出行人信息：
1. 出行人1姓名、身份证号
2. 出行人2姓名、身份证号
3. 联系人手机号"

用户：（提供信息）

AI："好的，已收到出行人信息。请确认预订信息：
- 行程：广州→三亚，10月18日-20日，3天2晚
- 航班：南航CZ6743，08:00-10:15
- 酒店：三亚湾海景酒店，豪华海景房，含双早
- 出行人：张三（身份证XXX）、李四（身份证XXX）
- 联系人：138XXXX1234
- 总价：¥8560

确认无误后请点击'确认预订'，我们将为您出票。"
（按钮：确认预订 / 修改信息 / 取消）

用户："确认预订"

【执行预订】
AI："正在为您预订，请稍候..."
（展示进度：正在预订机票... 正在预订酒店... 正在生成订单...）

【预订完成】
AI："✅ 预订成功！
订单号：TR20241018001
- 机票：南航CZ6743，10月18日 08:00-10:15，票号：784-XXXXXXX
- 酒店：三亚湾海景酒店，豪华海景房，10月18-20日，2晚
- 接送机：已预约，司机将在出发前1天联系您
- 总价：¥8560，已支付

确认信息已发送至您的手机和邮箱。
祝您旅途愉快！🎉"
（按钮：查看订单 / 预订返程 / 联系客服 / 开始新对话）

【对话结束】

34.6.3 状态机设计

状态：IDLE（空闲）
  ↓ 用户进入对话
  动作：展示欢迎语和推荐目的地
  ↓ 用户发送需求
  ↓
状态：INTENT_RECOGNIZING（意图识别中）
  ↓ AI理解用户意图
  ├─ 信息完整 → 进入INFORMATION_CONFIRMING
  ├─ 信息不完整 → 进入COLLECTING_INFO
  ├─ 非旅行需求 → 回到IDLE，引导用户使用旅行相关功能
  └─ 异常输入 → 进入INPUT_ERROR
  ↓
状态：COLLECTING_INFO（信息收集中）
  ↓ AI询问缺失的信息（出发地/日期/人数/预算/偏好）
  ↓ 用户回复信息
  动作：更新已收集信息，展示已收集/待收集
  ↓ 信息收集完整
  ↓
状态：INFORMATION_CONFIRMING（信息确认中）
  ↓ AI展示完整行程信息，请求用户确认
  ├─ 用户确认 → 进入QUERYING
  ├─ 用户修改 → 回到COLLECTING_INFO（更新对应信息）
  └─ 用户取消 → 进入CANCELLED
  ↓
状态：QUERYING（查询中）
  动作：调用航班查询API、酒店查询API，展示查询进度
  ↓ 查询成功
  ↓
状态：RECOMMENDING（方案推荐中）
  ↓ AI展示推荐方案列表
  ├─ 用户选择方案 → 进入BOOKING_CONFIRMING
  ├─ 用户查看更多 → 继续查询，展示更多方案
  ├─ 用户修改需求 → 回到COLLECTING_INFO
  └─ 用户取消 → 进入CANCELLED
  ↓
状态：BOOKING_CONFIRMING（预订确认中）
  ↓ AI收集出行人信息，展示完整预订信息
  ├─ 用户确认预订 → 进入BOOKING_PROCESSING
  ├─ 用户修改 → 回到对应步骤修改
  └─ 用户取消 → 进入CANCELLED
  ↓
状态：BOOKING_PROCESSING（预订执行中）
  动作：调用机票预订API、酒店预订API、支付API，展示预订进度
  ├─ 预订成功 → 进入COMPLETED
  ├─ 预订失败（机票售罄/支付失败）→ 进入BOOKING_ERROR
  └─ 用户取消 → 进入CANCELLED（取消预订，退款）
  ↓
状态：COMPLETED（已完成）
  动作：展示预订成功信息、订单详情，发送确认通知，邀请评价
  ↓ 用户开始新对话 → 回到IDLE
  ↓
状态：BOOKING_ERROR（预订异常）
  动作：展示错误原因（机票售罄/支付失败/系统异常），提供替代方案
  ├─ 换方案重新预订 → 回到RECOMMENDING
  ├─ 修改需求重新查询 → 回到COLLECTING_INFO
  ├─ 转人工客服 → 进入HUMAN_TRANSFER
  └─ 取消 → 进入CANCELLED
  ↓
状态：INPUT_ERROR（输入异常）
  动作：友好提示无法理解，引导用户重新输入或提供示例
  ↓ 用户重新输入 → 回到INTENT_RECOGNIZING
  ↓
状态：HUMAN_TRANSFER（转人工中）
  动作：展示排队信息，同步对话历史给人工
  ↓ 人工接入 → HUMAN_CHATTING
  ↓
状态：CANCELLED（已取消）
  动作：展示取消信息，退款说明（如已支付），推荐后续操作
  ↓ 用户开始新对话 → 回到IDLE

34.6.4 关键异常处理设计

在这个AI旅行助手中，需要重点设计的异常处理：

1. 用户信息不完整或模糊
用户说"下周去三亚"，但没说出发地、具体日期、人数。AI要主动询问，一次问一个关键信息，不要一次问太多（用户可能不回答全部）。如果用户回答模糊（"玩几天都行"），AI可以给建议（"推荐3天2晚，比较轻松"）。

2. 查询无结果
用户的需求查不到合适的航班或酒店（如日期太近没票、预算太低）。AI要告诉用户"没有找到符合条件的方案"，并提供替代方案（"您可以：调整日期 / 提高预算 / 换个目的地 / 转人工客服帮您找"），不要说"没有"就完事了。

3. 预订失败
预订过程中可能失败（机票售罄、支付失败、酒店满房）。AI要告诉用户失败原因，提供替代方案（换航班/换酒店/换日期），如果已支付要说明退款流程。不要假装预订成功，也不要让用户不知道发生了什么。

4. 用户中途修改需求
用户在信息收集或方案推荐阶段可能修改需求（"等等，我想改成去厦门"、"预算改成3000"）。AI要能正确更新信息，重新查询，不要混乱。修改后要重新确认关键信息。

5. 用户输入无关内容
用户在预订过程中可能说无关的话（"今天天气真好"、"你们机票贵不贵"）。AI要能区分，友好引导回到正题（"是的，今天天气不错。我们继续安排您的三亚行程，请问您从哪里出发？"），不要被带偏。

6. 上下文丢失
对话太长或用户切换设备后，上下文可能丢失。AI要能识别（"抱歉，我没有看到您之前的行程信息，请问您想预订去哪里的旅行？"），不要胡乱回答。关键信息（已选方案、出行人信息）要持久化存储，不依赖上下文。

34.7 原型设计工具与方法

34.7.1 原型设计工具

34.7.2 原型设计方法

1. 从对话脚本开始
不要一上来就画界面，先写对话脚本——把用户和AI的对话逐句写出来，覆盖正常流程和主要异常流程。对话脚本是AI产品原型的核心，界面只是对话的载体。

2. 画对话流程图
用流程图工具画对话流程图，展示对话的分支、循环、异常路径。对话流程图能帮你发现逻辑漏洞和遗漏的分支。

3. 定义状态机
列出所有状态、状态转换条件、转换时的动作。画状态转换图，确保所有状态和转换都覆盖。状态机是开发团队实现的依据，必须清晰完整。

4. 设计界面原型
在对话脚本、流程图、状态机都确定后，再设计界面原型。界面原型要包含：对话界面、各种状态的展示（思考中/工具调用中/等待用户）、异常页面、反馈机制、转人工流程。

5. 做可交互原型
用可交互原型工具或AI原型工具，做可以真实交互的原型。让团队成员和目标用户试用，体验对话流程，发现问题。可交互原型比静态原型更能发现体验问题。

6. 原型评审
组织原型评审，邀请产品、设计、开发、算法、测试、业务团队参加。评审重点：对话流程是否顺畅、状态是否完整、异常是否覆盖、交互是否友好、技术是否可行。评审后修改原型，达成共识。

34.8 原型评审要点

AI产品原型评审时，要重点检查以下内容：

34.8.1 对话流评审

• 对话开始的引导是否清晰？新用户知道怎么用吗？
• 意图识别是否准确？各种用户输入都能正确识别吗？
• 信息收集策略是否合理？一次问几个问题？用户会不会觉得烦？
• 多轮对话的上下文管理是否清晰？AI会记住之前的信息吗？
• 对话结束的机制是否合理？用户知道对话结束了吗？能方便地开始新对话吗？
• 对话引导是否适度？不会过度推荐干扰用户吧？
• 各种对话路径都覆盖了吗？（正常路径、分支路径、循环路径）

34.8.2 状态机评审

• 所有状态都定义了吗？有没有遗漏的状态？
• 每个状态的进入条件、退出条件明确吗？
• 每个状态转换的触发事件、执行动作明确吗？
• 状态转换有没有死循环？有没有无法退出的状态？
• 有没有状态冲突？（如两个状态同时激活）
• 异常状态都覆盖了吗？（网络异常、系统故障、用户取消）
• 状态恢复机制设计了吗？（系统异常恢复后能回到之前的状态吗？）
• 状态对用户可见吗？（用户知道当前在什么状态吗？）

34.8.3 异常处理评审

• 所有可能的异常都列出来了吗？（用户输入异常、AI输出异常、工具调用异常、系统异常、网络异常）
• 每种异常都有处理方案吗？
• 异常提示友好吗？用户能看懂吗？知道下一步怎么做吗？
• 异常后能恢复吗？（重试、返回、转人工）
• 降级方案设计了吗？（核心功能不可用时的替代方案）
• AI会编造信息吗？（不知道时会说不知道吗？）
• 高风险操作有确认机制吗？（支付、预订、修改信息）
• 异常率监控设计了吗？（能统计各种异常的发生率吗？）

34.8.4 交互体验评审

• Loading和思考状态设计了吗？用户等待时有反馈吗？
• 流式输出（打字机效果）设计了吗？
• 反馈机制（有帮助/没帮助、重新生成、编辑）设计了吗？
• 置信度和来源引用设计了吗？
• 人工介入流程设计了吗？（触发方式、排队、信息同步、人工辅助）
• 对话历史和上下文管理设计了吗？
• 移动端体验好吗？（输入方便吗？对话显示清晰吗？）
• 无障碍设计考虑了吗？（视障用户、听障用户）

34.9 常见误区

误区1：只画界面，不设计对话流和状态机
很多产品经理做AI产品原型，就是画几个对话界面的线框图，觉得这就是原型了。但AI产品的核心是对话流和状态机——用户怎么和AI对话、对话怎么推进、状态怎么转换、异常怎么处理。只画界面不设计对话流和状态机，开发出来的产品会逻辑混乱、状态错误、异常崩溃。
正确做法：先写对话脚本、画对话流程图、定义状态机，再画界面。界面是载体，对话流和状态机是灵魂。

误区2：只设计正常流程，不设计异常处理
很多原型只设计了"用户正常使用、AI正常回答"的理想流程，完全没考虑异常情况。但AI产品的异常情况远多于传统产品——用户输入千奇百怪、AI会幻觉会答错、工具会调用失败、网络会中断。如果不设计异常处理，产品一遇到异常就崩，用户体验极差。
正确做法：异常处理占AI产品设计工作量的40%以上，原型阶段就要穷举所有异常，为每种异常设计处理方案。

误区3：对话太机械，像机器人
很多AI对话设计得太机械——"请输入出发地"、"请输入目的地"、"请输入日期"，像填表一样，用户体验很差。好的AI对话应该自然、流畅、有温度，像和真人聊天一样。
正确做法：

• 一次可以收集多个信息（"好的，去三亚。请问您从哪里出发，想哪天去，玩几天？"），不要一句一句问
• 用自然的语言，不要用指令式语言（"请输入XXX"）
• 适当加入人性化表达（"好的"、"没问题"、"为您找到了以下方案"）
• 根据用户的情绪调整语气（用户着急时更简洁高效，用户闲聊时更友好）
• 不要重复用户已经说过的信息（用户说了出发地，不要又问一遍）

误区4：状态管理混乱，用户不知道发生了什么
很多AI产品状态管理混乱——AI还在思考用户就可以输入导致冲突、任务还没完成就显示完成、转人工了AI还在回答、网络异常后状态丢失。用户不知道当前在什么状态、发生了什么、该怎么做。
正确做法：设计完整的状态机，明确定义所有状态和转换；状态对用户可见（"AI正在思考..."、"正在为您转接人工..."、"预订处理中..."）；状态转换有明确的触发和动作；异常状态有恢复机制。

误区5：AI什么都想���，不设边界
很多产品经理希望AI什么都能做——订机票、订酒店、查攻略、写游记、翻译、聊天...结果什么都做不好。AI有能力边界，产品也要有明确定位。
正确做法：明确AI的能力范围和产品定位，聚焦核心场景把体验做好。用户问超出范围的问题时，友好说明并引导回正题，或推荐其他工具。不要为了"显得智能"而什么都接，结果什么都做不好。

误区6：不做可交互原型，直接开发
很多团队写完PRD和静态原型就直接开发，开发完才发现对话流程有问题、状态转换有bug、异常处理缺失，返工成本很高。
正确做法：开发前做可交互原型（可以用AI原型工具接入真实大模型），让团队和目标用户试用，发现对话流程、状态管理、异常处理、交互体验的问题，修改完善后再开发。可交互原型能发现很多静态原型发现不了的问题。

误区7：忽视用户反馈机制设计
很多AI产品没有反馈机制，用户觉得AI回答不好也没办法，产品团队也不知道哪些回答不好。AI效果是持续优化的，没有用户反馈就不知道怎么优化。
正确做法：设计完善的反馈机制——每条回答后有"有帮助/没帮助"按钮，点"没帮助"可以选原因，对话结束后可以评价，用户可以编辑AI的回答。反馈数据收集后定期分析，指导Prompt优化、知识库更新、模型迭代。

34.10 本章小结

AI产品的原型设计和传统产品有本质不同——传统产品设计页面和跳转，AI产品设计对话流、状态机、异常处理。因为AI产品的交互是不确定的、对话式的、状态复杂的、异常多发的、渐进式输出的、需要反馈学习的。

核心内容回顾：

对话流设计：对话的基本结构（开始→意图识别→信息收集→处理回答→确认反馈→结束）、单轮对话vs多轮对话、对话引导设计（新用户引导、对话中引导）、对话终止与重新开始。

状态机设计：为什么需要状态机（避免状态混乱）、AI产品的核心状态（对话状态、任务状态、用户状态）、状态转换设计（触发事件+动作）、状态机设计原则（状态数量适中、转换明确、覆盖全面、可观测、可恢复）。

异常处理设计：用户输入异常（无关/模糊/超长/乱码/情绪激动/Prompt注入/敏感问题）、AI输出异常（幻觉/答非所问/格式错误/不完整/敏感内容/重复/质量差）、工具/系统异常（模型超时/限流/错误、工具调用失败/返回异常、网络中断、系统故障、转人工失败）、异常处理原则（友好性、可恢复、透明性、降级策略、不编造、可观测、覆盖全面、用户引导）。

AI产品特有原型要素：Loading与思考状态（即时反馈、思考过程展示、打字机效果、生成中断、超时处理、进度展示）、反馈机制（即时反馈、详细反馈、重新生成、编辑回答、对话评价）、置信度与透明性（AI身份明确、置信度展示、来源引用、局限性说明、不编造承诺）、人工介入设计（触发方式、转人工流程、人工辅助、非工作时间处理）、对话历史与上下文管理（历史保存、新对话机制、上下文摘要、关键信息提取、上下文丢失处理、跨设备同步、隐私保护）。

实战案例：通过AI旅行助手的完整例子，展示了对话流设计（从用户说"帮我安排下周去三亚的旅行"到预订完成的完整对话）、状态机设计（10+个状态的完整转换图）、关键异常处理设计（信息不完整、查询无结果、预订失败、用户修改需求、输入无关内容、上下文丢失）。

原型设计工具与方法：工具选择（通用UI工具、对话式原型工具、流程图工具、可交互原型工具、AI原型工具）、设计方法（从对话脚本开始→画对话流程图→定义状态机→设计界面原型→做可交互原型→原型评审）。

原型评审要点：对话流评审、状态机评审、异常处理评审、交互体验评审。

常见误区：只画界面不设计对话流和状态机、只设计正常流程不设计异常处理、对话太机械像机器人、状态管理混乱用户不知道发生了什么、AI什么都想做不设边界、不做可交互原型直接开发、忽视用户反馈机制设计。

掌握AI产品原型设计方法，能让你在开发前就把对话流程、状态管理、异常处理、交互体验想清楚，减少开发返工，提升产品体验。这是AI产品经理从"传统产品经理"升级为"AI产品经理"的关键能力之一。

至此，AI产品经理教程的核心模块全部完成——从AI产品经理的角色认知、能力模型，到大模型基础、Prompt工程、RAG知识库、Agent系统，再到需求分析、竞品分析、PRD撰写、原型设计，形成了完整的AI产品经理知识体系。希望这个课程能帮助你系统掌握AI产品经理的核心技能，在AI时代成为优秀的产品经理！

📝 本章练习（5题）

答案与解析请在 互动学习看板 中作答查看。

📚 AI产品经理实战训练营 课程目录（44 章）

1. 第1章 AI产品经理是做什么的？和传统PM有什么区别？
2. 第2章 2026年AI产品经理就业市场：哪些行业在招？薪资多少？
3. 第3章 零经验转行AI产品经理的3条路径
4. 第4章 AI产品全景图：从聊天机器人到Agent，一文搞懂
5. 第5章 AI产品经理能力模型：你需要掌握哪些技能？
6. 第6章 实战：拆解3个你每天在用的AI产品
7. 第7章 大模型是什么？用大白话讲清楚
8. 第8章 主流大模型对比：GPT-4o、Claude、DeepSeek、豆包、Kimi怎么选？
9. 第9章 Prompt入门：写好提示词的5个原则
10. 第10章 Prompt进阶：System Prompt、COT思维链、Few-shot示例
11. 第11章 结构化输出：让大模型返回JSON、表格、代码
12. 第12章 Prompt优化实战：从垃圾Prompt到高质量Prompt
13. 第13章 大模型的"幻觉"问题：产品经理怎么应对？
14. 第14章 实战：为一个智能客服设计完整Prompt体系
15. 第15章 RAG是什么？为什么企业都在做知识库？
16. 第16章 RAG工作原理：文档→分块→向量→检索→生成
17. 第17章 向量数据库选型：Milvus、Pinecone、Chroma、pgvector怎么选？
18. 第18章 Embedding模型选型：OpenAI、BGE、M3E、GTE对比
19. 第19章 Reranker重排序：让检索结果更精准
20. 第20章 查询改写与混合检索：提升召回率的实战技巧
21. 第21章 知识库运营：文档治理、更新机制、效果监控
22. 第22章 实战：从零搭建一个企业知识库（完整流程）
23. 第23章 Agent是什么？和聊天机器人有什么区别？
24. 第24章 Agent核心能力：感知、规划、工具调用、记忆
25. 第25章 主流Agent框架与协议：Agent Harness、MCP、A2A全解析
26. 第26章 工具调用（Function Calling）原理与实战
27. 第27章 Agent记忆系统：短期记忆、长期记忆、向量记忆
28. 第28章 多Agent协作：多个智能体怎么分工配合？
29. 第29章 Agent评估体系：成功率、成本、延迟怎么监控？
30. 第30章 实战：设计一个制造业生产异常处理Agent
31. 第31章 AI产品需求分析：怎么识别真需求还是伪需求？
32. 第32章 AI产品竞品分析：怎么调研和拆解竞品？
33. 第33章 AI产品PRD撰写：技术可行性、数据需求、评估指标
34. 第34章 AI产品原型设计：对话流、状态机、异常处理
35. 第35章 AI产品数据指标体系：从DAU到模型准确率，全面监控
36. 第36章 AI项目管理：从需求到上线的全流程管控
37. 第37章 实战项目1：从零搭建制造业AI智能质检系统
38. 第38章 实战项目2：从零搭建企业级AI知识库（RAG系统）
39. 第39章 AI产品经理简历优化：让HR一眼看中你
40. 第40章 项目经验包装：把普通项目讲成亮眼案例
41. 第41章 AI产品经理面试常见问题：提前准备，从容应对
42. 第42章 案例分析面试：用结构化思维征服面试官
43. 第43章 薪资谈判：拿到你应得的报酬
44. 第44章 入职前3个月：快速站稳脚跟，建立信任