---
title: 场景分支（Scenarios）
---

本页用于阐释：基于 [abstraction.md](file:///Users/stephenwang/Documents/trae_projects/my_skills/docs/zh-CN/theory/abstraction.md) 的分析方法，可以系统化地抽取出“场景集合”，并把这些场景对应的边界与约束沉淀为可复用的信息资产，支撑后续的需求详细分析、原型生成与验收测试用例设计。

同时，这种以“主链路 + 场景分支 + 角色泳道”的方式去沟通需求，对业务方更友好：业务更习惯用“发生了什么场景/谁在做/会出现什么例外”来理解系统，而不是从接口、表结构或实现细节出发。

![企业用车场景（示例）](../../assets/zh-CN/visual-spec-scenarios.svg)

## 从抽象到场景

抽象（flows）解决的是“必须表达哪些维度”；场景分支（scenarios）解决的是“这些维度在业务里具体长什么样”。

- 把业务映射到 flows 后，会得到稳定的主链路节点、控制路径（取消/拒绝/撤回/回滚）与约束路径（校验/约束/失败策略）。
- 在每个节点上，按角色拆分“能做什么 / 不能做什么 / 什么时候能做”，自然会产生一组可枚举的场景（变更、取消、撤销、紧急停止、紧急变更、冲突处理等）。
- 把场景落到泳道里，是在明确责任边界：谁触发、谁处理、谁确认、谁承担失败后的补偿或回滚。

## 场景要沉淀哪些信息

每个场景不仅是“一个名字”，还应携带可落地、可验证的信息：

- 触发条件：由谁触发、在什么状态下触发、是否允许并发触发。
- 前置与约束：必须满足的校验项、约束项、资源可用性与可达性（例如位置、路程、工时规则）。
- 状态变化：会改哪些状态、会写哪些字段、是否需要生成/撤销占用（例如资源日历 booking）。
- 失败与补偿：失败如何提示、是否支持重试、是否需要回滚/补偿、幂等如何保证。
- 权限边界：角色与权限如何约束该场景（谁能撤销、谁能紧急停止、谁能紧急变更）。

## 对后续工作的作用

- 需求详细分析：场景是“补齐差异点”的清单，驱动状态机、字段、权限、规则、异常处理与日志策略落到 PRD 细节中。
- 原型生成：场景决定原型的分支页面/状态（正常、不可用、冲突、撤销、变更中、已回滚等），减少只画主流程导致的漏项。
- 验收测试用例：以场景为骨架组织用例，覆盖主链路 + 所有控制路径与关键约束，并能明确每条用例的前置状态与期望结果。

## 用场景做开发范围划定

场景分支不仅用于“补全”，也用于“取舍”。在资源有限时，可以把每个场景按发生概率与业务价值进行分层，用于划定本期开发与验收范围：

- 发生概率：高频主流程、常见异常（例如撤销、变更）优先；低频极端场景可延后，但要明确风险与兜底策略。
- 业务价值：直接影响收入/成本/合规/体验的场景优先；价值较低但实现代价高的场景可暂缓或简化。
- 组合决策：用“概率 × 价值 × 风险（合规/资损/口碑）”做优先级排序，把 P0/P1/P2 的边界写进 scope 与验收口径。

这样做的好处是：评审时可明确“这次要覆盖哪些场景、哪些不做但需要留接口/降级/手工处理”，并减少实现后才发现范围不一致的返工。
