07 FDE 场景卡与 PoC 范围锁定
章节目标
用 FDE 场景卡把业务需求、数据条件、技术边界、权限风险和验收指标写清楚，形成后续工程和商业沟通的共同语言。
开篇案例：为什么“智能助手”不是场景
“做一个企业知识库智能助手”听起来完整，但它不是一个合格场景。它没有用户、任务、输入、输出、风险和验收指标。换成场景卡语言，应该写成：“客服坐席在处理售后政策工单时，系统根据 FAQ、SOP 和订单状态生成回复草稿，并标注是否需要转人工。”
这句话立刻带出后续问题：谁用？用什么数据？输出给谁看？哪些情况不能自动回复？怎样算成功？这就是场景卡的价值：它把抽象需求压缩成一个可以被工程、业务和合规共同评审的交付单元。
场景卡字段
| 字段 | 填写要点 |
|---|---|
| 场景名称 | 用一句话说明业务任务 |
| 使用人群 | 一线用户、管理用户、审核用户 |
| 当前流程 | 人工现在如何完成任务 |
| 痛点描述 | 耗时、错误、遗漏、沟通、返工或风险 |
| 输入资料 | 文档、表格、系统、图片、日志或外部信息 |
| 输出结果 | 报告、清单、建议、工单、消息或审批摘要 |
| 权限边界 | 谁能看、谁能问、谁能执行、哪些动作必须审批 |
| 验收指标 | 准确率、耗时、采纳率、引用率、工具成功率、人工节省 |
场景档位
场景卡应标明当前验证档位，避免客户把课堂 Demo 当作生产承诺：
| 档位 | 定义 | 典型周期 |
|---|---|---|
| 原型 | 样例数据、单角色、只读或建议型输出 | 1–2 周 |
| 企业 PoC | 多角色、真实权限子集、评估样本 | 3–6 周 |
| 生产 | 网关、审计、回归门禁、运维交接 | 按里程碑 |
FDE 应明确告诉客户：原型、企业 PoC、MVP、生产上线不是一回事。
场景卡样例（简版）
| 字段 | 示例 |
|---|---|
| 场景名称 | 客服售后政策工单回复草稿 |
| 使用人群 | 一线坐席、质检主管、售后专家 |
| 当前流程 | 坐席读工单 → 查 FAQ → 查订单 → 写回复 → 质检抽查 |
| 痛点描述 | 查资料慢、政策版本混乱、赔付边界容易错 |
| 输入资料 | 历史工单、FAQ、SOP、订单状态 API |
| 输出结果 | 分类、知识引用、回复草稿、转人工建议 |
| 权限边界 | 退款、赔付、投诉升级必须人工处理 |
| 验收指标 | 分类准确率、首响时间、坐席采纳率、高风险转人工准确率 |
| 不做什么 | 不自动赔付、不承诺客户最终处理结果 |
样例不需要一开始就完美，但必须让所有人知道这个 PoC 的边界在哪里。
PoC 范围锁定
PoC 要写清做什么，也要写清不做什么。
做什么
- 使用哪些样例数据。
- 支持哪些用户角色。
- 覆盖哪些流程步骤。
- 输出哪些结果。
- 使用哪些工具。
不做什么
- 不直接改核心系统。
- 不自动执行高风险动作。
- 不覆盖全部历史数据。
- 不承诺替代专家判断。
- 不在没有样本的情况下承诺准确率。
场景优先级
高优先级场景通常具备：
- 高频。
- 高耗时。
- 高复用。
- 高改进空间。
- 低风险边界。
- 数据样本可获得。
- 业务负责人愿意试用。
场景卡评审会议
场景卡写完后，建议开一次 30–45 分钟评审会，参会人包括业务负责人、AIBP、一线代表、IT / 数据负责人和 FDE。会议只回答四个问题：
- 这个场景是否值得做？
- 数据和权限是否支持小范围验证？
- 验收指标是否可以在 2–6 周内观察？
- 哪些需求必须进入变更池，而不是本轮 PoC？
如果这四个问题无法达成一致，后面写代码只会更贵。
实操任务
完成一个场景卡，并用一句话回答：
- 为什么现在值得做？
- 为什么这个范围足够小？
- 为什么这个场景可验证？
- 如果失败，最可能失败在哪里？
交付物
- FDE 场景卡。
- PoC 范围说明。
- 初步验收指标。
- 风险假设清单。
常见误区
- 场景名称写成“智能助手”。
- 范围没有写“不做什么”。
- 没有明确谁负责验收。
- 验收指标只写“效果好”。
检查清单
- 场景是否足够具体？
- 是否有真实样例数据？
- 是否明确输入、输出和权限？
- 是否能在小范围内验证价值？