如何拆解场景与设计产品流程
大需求最危险的地方在于它听起来很完整，实际上无法执行。PM 的职责之一，就是把“大词”拆成“可设计、可评估、可交付”的场景。
比如“做一个 AI 客服系统”，这不是场景，只是一个方向。场景必须具体到用户在什么时刻、要完成什么任务、系统要如何响应。
从大需求到具体场景
graph TD
A["大需求：做 AI 客服"] --> B["高频任务：查订单"]
A --> C["高频任务：查退货政策"]
A --> D["异常任务：投诉升级"]
A --> E["边界任务：转人工"]
场景拆解的四个维度
| 维度 | 要回答的问题 |
|---|---|
| 主任务 | 用户到底想完成什么 |
| 触发条件 | 在什么情况下会发生 |
| 关键步骤 | 完成任务要经过哪些环节 |
| 异常处理 | 出错或不确定时怎么办 |
产品流程不是只有 UI Flow
AI 产品至少要画两层流程：
- 用户流程：用户看见什么、做什么
- 系统流程：系统如何判断、调用、记录、兜底
如果只画前者，工程与 AI 团队会缺上下文；如果只画后者，设计与业务又很难对齐。
一个最小流程模板
use_case = {
"场景": "查询退货政策",
"用户输入": "这件商品买了 10 天还能退吗？",
"系统步骤": [
"识别商品与订单条件",
"检索退货政策",
"生成回答",
"判断是否需要人工确认",
],
"异常": [
"用户未提供订单信息",
"商品属于特殊品类",
"政策信息已过期",
],
}
for key, value in use_case.items():
print(key, value)
设计流程时必须补的三类点
| 类型 | 为什么重要 |
|---|---|
| 边界条件 | 决定系统什么时候不能直接回答 |
| 异常流程 | 决定失败时用户体验是否崩掉 |
| 日志与反馈 | 决定后续能不能优化 |
案例演练：官网 AI 助手
如果用户进入企业官网，AI 助手可能有五类场景：
- 了解产品功能
- 比较不同方案
- 获取报价入口
- 查询交付周期
- 联系人工顾问
每一类都要单独设计触发条件、信息来源、输出格式和人工接续方式。否则“官网 AI 助手”只是一个空泛名字。
课堂案例：把“官网 AI 助手”拆成 5 个真实场景
案例背景
一家 B2B 官网要上线 AI 助手，老板只给了一句话：“让客户更容易问问题。”
教学拆解
PM 应把它拆成：
- 产品功能问答
- 方案对比导航
- 客户案例查找
- 报价或咨询入口引导
- 转人工销售
然后再继续为每个场景补：
- 触发条件
- 必要知识源
- 输出格式
- 风险边界
教学流程图
graph TD
A["用户进入官网"] --> B["提出问题"]
B --> C{"问题类型"}
C -->|产品问题| D["产品问答"]
C -->|案例问题| E["案例导航"]
C -->|商机问题| F["线索分流/转人工"]
练习题
- 为什么“大需求”不等于“可执行场景”
- 设计流程时为什么必须同时画用户流程和系统流程
- 什么叫边界场景，请举一个例子
标准答案提示
- 关注是否具体到用户任务和系统响应
- 用户流程帮助理解体验，系统流程帮助理解落地与异常
- 可从知识缺失、用户资料不足、高风险动作等方向举例
本章 checklist
- 我是否把大需求拆成了具体高频场景
- 我是否区分了主流程、异常流程和边界流程
- 我是否同时考虑了用户流程与系统流程
- 我是否为每个关键场景明确了信息来源和失败处理
本章小结
- 需求拆解的质量，决定方案设计和交付质量
- AI 产品流程必须覆盖场景、异常、边界与反馈
- 没有流程拆解，后续的 MVP 和 PRD 都会变得含糊
下一节：02-流程图设计与异常分支处理 — 用标准化流程图把 AI 产品的主流程、异常流程与边界条件完整表达。