# 机票需求评审详细评分标准

## 一、通用维度评分细则

### 1. 需求背景与目标（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 清晰描述业务痛点 + 量化现状数据 + SMART 目标 + 预期 ROI |
| 4 | 痛点清晰 + 目标可量化，缺少现状数据或 ROI |
| 3 | 有背景描述但目标模糊（如"提升用户体验"无量化指标） |
| 2 | 只有一句话背景，无目标定义 |
| 1 | 无背景描述，直接写功能 |

**检查项**：
- 是否回答了"为什么做"
- 是否有现状数据（转化率/客诉量/操作耗时等）
- 目标是否有数字（"转化率提升 X%"而非"提升转化"）
- 是否说明做了之后预期的业务收益

### 2. 用户场景（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 多场景覆盖 + 用户画像 + 完整用户故事 + 场景优先级 |
| 4 | 主要场景覆盖 + 用户路径清晰，缺少用户画像或优先级 |
| 3 | 只描述了 1-2 个主场景，缺少边缘场景 |
| 2 | 场景描述笼统（如"用户购买机票"无细节） |
| 1 | 无场景描述 |

**机票业务必须覆盖的场景维度**：
- 国内 vs 国际
- 单程 vs 往返 vs 多程
- 成人 vs 儿童 vs 婴儿
- 新用户 vs 老用户
- 首次使用 vs 重复使用

### 3. 功能范围（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 功能边界明确 + In/Out scope清晰 + MVP 分期合理 + 迭代计划 |
| 4 | 功能清单完整 + 有 scope 定义，缺少分期或迭代计划 |
| 3 | 有功能列表但边界模糊（不清楚什么不做） |
| 2 | 功能描述不完整，容易产生歧义 |
| 1 | 功能范围严重不清，无法判断工作量 |

**检查项**：
- 是否明确列出"本期做什么"和"本期不做什么"
- 功能颗粒度是否合适（不过粗也不过细）
- 是否考虑了与现有功能的关系

### 4. 业务流程（1-5分）

> **与 P1-P6（流程图建模）的边界**：本维度评审的是"业务逻辑是否完整"——主流程有没有漏步骤、异常有没有覆盖、逻辑是否通顺。P1-P6 评审的是"流程图画法是否结构化"——图的画法是否线性、是否用了泳道/FSM/决策表。简言之：**维度 4 = 内容完整性，P1-P6 = 表达结构化程度**。

| 分数 | 标准 |
|------|------|
| 5 | 主流程步骤完整 + 异常分支全覆盖 + 并发/竞态处理 + 逻辑无矛盾 |
| 4 | 主流程完整 + 主要异常覆盖（≥5种），逻辑通顺 |
| 3 | 主流程完整但异常覆盖不全（≤3种异常） |
| 2 | 主流程有遗漏或逻辑不通 |
| 1 | 无流程描述或流程严重残缺 |

**机票业务常见异常流程检查清单**：
- [ ] 网络超时/失败
- [ ] 库存不足/售罄
- [ ] 价格变动
- [ ] 支付失败
- [ ] 用户中途退出
- [ ] 并发抢购/重复提交
- [ ] 第三方接口异常（航司/GDS）
- [ ] 证件校验失败
- [ ] 黑名单/风控拦截

### 5. 交互设计（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 完整交互稿 + 所有状态（空/加载/错误/成功）+ 动效说明 + 文案定稿 |
| 4 | 有交互稿 + 主要状态覆盖，缺少部分边缘状态或文案 |
| 3 | 有交互描述但无完整稿件，或缺少关键状态 |
| 2 | 交互描述简略，仅文字无图 |
| 1 | 无交互设计 |

**页面状态检查清单**：
- [ ] 空态（无数据时）
- [ ] 加载态（骨架屏/Loading）
- [ ] 正常态
- [ ] 错误态（网络错误/服务错误）
- [ ] 缺省态（部分数据缺失）
- [ ] 边界态（超长文本/极端数据）

### 6. 数据埋点（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 全链路埋点 + 事件/参数定义完整 + 埋点与业务指标对应 + 数据看板需求 |
| 4 | 关键路径有埋点 + 事件参数基本完整 |
| 3 | 有部分埋点但不完整，缺少关键节点或参数 |
| 2 | 只提到"需要埋点"但无具体定义 |
| 1 | 完全没有埋点设计 |

**机票业务必备埋点**：
- 页面曝光/进入
- 关键按钮点击
- 搜索请求/结果
- 方案选择
- 下单/支付节点
- 异常/错误发生

### 7. 上线方案（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 灰度计划 + 回滚方案 + 监控告警 + AB 实验设计 + 应急预案 |
| 4 | 有灰度 + 回滚方案，缺少监控或 AB 实验 |
| 3 | 提到了分阶段上线但无灰度细节 |
| 2 | 只有时间排期，无发布策略 |
| 1 | 无上线计划 |

### 8. 安全与合规（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 数据安全方案 + 隐私合规 + 传输加密 + 存储加密 + 审计日志 |
| 4 | 主要安全措施覆盖，缺少部分合规考虑 |
| 3 | 提到了安全但措施不具体 |
| 2 | 安全措施明显不足（如证件号明文传输） |
| 1 | 完全没有安全考虑 |

**机票业务敏感数据**：
- 身份证/护照号码
- 手机号
- 支付信息
- 行程信息（GDPR 等法规关注）

### 9. 影响面评估（1-5分）

> **本维度聚焦技术模块影响**。业务上下游的连锁反应（财务/客服/运营）由维度 13（关联逻辑完整性）评审。

| 分数 | 标准 |
|------|------|
| 5 | 完整影响面分析 + 受影响技术模块清单 + 接口兼容方案 + 数据迁移计划 |
| 4 | 主要技术影响分析到位，有兼容方案 |
| 3 | 提到了影响但分析不够深入 |
| 2 | 未分析对现有功能模块的技术影响 |
| 1 | 涉及核心模块改动却完全无影响分析 |

### 10. 文档质量（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 结构清晰 + 术语一致 + 图文配合 + 无歧义 + 版本管理 |
| 4 | 结构合理 + 基本清晰，少量模糊之处 |
| 3 | 结构基本有但部分章节逻辑混乱 |
| 2 | 缺少关键章节，或大段纯文字无结构 |
| 1 | 无结构、表述混乱、读不懂 |

### 11. 验收标准（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 可测试的验收条件 + 测试用例维度 + 性能指标 + 兼容性要求 |
| 4 | 有验收条件 + 基本可测试 |
| 3 | 验收标准模糊（如"功能正常"） |
| 2 | 只有笼统的验收描述 |
| 1 | 无验收标准 |

### 12. 依赖与风险（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 依赖方清单 + 技术风险 + 排期风险 + 应对预案 + 风险等级评定 |
| 4 | 主要依赖和风险识别到位 |
| 3 | 提到了部分依赖但风险分析不足 |
| 2 | 有明显的外部依赖但未说明 |
| 1 | 完全未考虑依赖和风险 |

### 13. 关联逻辑完整性（1-5分）

> **与维度 9（影响面评估）的边界**：维度 9 评审的是对技术模块的影响（接口改动、字段兼容、数据迁移）。维度 13 评审的是**业务链路的上下游连锁反应**——你改了一个业务节点，上下游的财务、客服、运营、合规等业务流程是否同步考虑了。简言之：**维度 9 = 技术影响，维度 13 = 业务连锁**。

| 分数 | 标准 |
|------|------|
| 5 | 完整识别所有关联业务链路 + 每条链路明确说明处理方案 + 关联方已确认 |
| 4 | 主要关联链路已识别并有处理方案，少量次要链路未覆盖 |
| 3 | 识别了部分关联但不完整，或只提到了"需要同步"但无具体方案 |
| 2 | 存在明显的关联业务链路未被考虑 |
| 1 | 完全没有关联逻辑分析，改了核心业务节点却不考虑上下游 |

**评审方法**：针对需求中的每一项变更，逐一追问以下 6 条关联链路是否被覆盖。

#### 关联链路 1：金额/优惠变更 → 财务链路

当需求涉及**价格、金额、优惠、折扣、补贴**的修改时，必须检查：

| 检查项 | 具体问题 |
|--------|---------|
| 财务报表 | 收入确认口径是否变化？报表字段是否需要新增/调整？ |
| 退改金额 | 新的优惠/折扣参与退款时如何计算？是按原价退还是折后退？ |
| 报销凭证 | 行程单/发票金额是否受影响？增值税率计算是否正确？ |
| 对账 | 与航司/供应商的结算对账逻辑是否需要同步调整？ |
| 佣金 | 代理佣金/返点计算基数是否因价格变更而改变？ |
| 预算 | 补贴/优惠是否有预算上限？超支预警机制是否考虑？ |

#### 关联链路 2：新增功能/流程变更 → 客服链路

当需求涉及**新增功能、修改用户流程、新增状态**时，必须检查：

| 检查项 | 具体问题 |
|--------|---------|
| 客服 SOP | 客服的操作手册/知识库是否需要更新？ |
| 客服工具 | 客服后台是否需要新增功能（查看新字段/执行新操作）？ |
| 话术更新 | 新功能的常见问题和标准话术是否已准备？ |
| 投诉预案 | 新功能可能产生的投诉场景是否有应对方案？ |
| 工单分类 | 工单系统是否需要新增分类/标签？ |
| 培训计划 | 客服团队是否需要上线前培训？ |

#### 关联链路 3：规则/政策变更 → 运营链路

当需求涉及**业务规则、活动规则、退改政策**变更时，必须检查：

| 检查项 | 具体问题 |
|--------|---------|
| 现有活动 | 当前进行中的活动是否受新规则影响？ |
| 文案/说明 | App/页面中的规则说明文案是否需要同步更新？ |
| 协议/条款 | 用户协议/购买须知是否需要修改？ |
| 运营通知 | 是否需要给存量用户发通知说明变更？ |
| 新老兼容 | 变更前后的订单分别按什么规则处理？过渡期方案？ |

#### 关联链路 4：数据结构变更 → 数据/BI 链路

当需求涉及**新增字段、修改数据结构、改变状态枚举**时，必须检查：

| 检查项 | 具体问题 |
|--------|---------|
| 数据看板 | 现有 BI 看板/数据报表是否需要调整？ |
| 数据口径 | 核心指标（转化率/客单价/退改率）的计算口径是否受影响？ |
| 数据同步 | 下游数据仓库/数据湖的 ETL 流程是否需要同步修改？ |
| 历史数据 | 新旧数据结构的兼容性？历史数据是否需要回刷？ |

#### 关联链路 5：用户可见变更 → 合规/法务链路

当需求涉及**用户可见的规则变更、信息收集变更**时，必须检查：

| 检查项 | 具体问题 |
|--------|---------|
| 隐私政策 | 新增/变更的数据收集是否需要更新隐私政策？ |
| 用户告知 | 规则变更是否需要提前告知用户（法律要求）？ |
| 电子合同 | 购买协议/退改条款是否需要法务审核？ |
| 备案 | 新功能是否涉及需要向监管报备的内容？ |

#### 关联链路 6：上下游系统 → 外部协同链路

当需求涉及**与外部系统交互的逻辑变更**时，必须检查：

| 检查项 | 具体问题 |
|--------|---------|
| 航司通知 | 涉及航司政策的变更，航司侧是否已确认/同步？ |
| 供应商 | 供应商的对接接口/对账规则是否需要调整？ |
| 支付渠道 | 支付金额/退款逻辑的变更是否已与支付渠道确认？ |
| 合作方 | 分销/联运合作方是否需要同步？ |

#### 机票业务高频关联速查表

| 你改了什么 | 必须同步检查 |
|-----------|------------|
| 票价/运价计算 | 财务报表、行程单金额、航司对账、代理佣金、退款金额 |
| 优惠/折扣规则 | 退款时优惠退回逻辑、财务成本核算、预算告警 |
| 退改签政策 | 客服 SOP、App 规则展示文案、财务退款流程、协议条款 |
| 新增预订流程 | 客服知识库、客服后台工具、投诉预案、话术准备 |
| 新增乘机人字段 | 出票接口、航司 API 对接、身份校验规则、隐私政策 |
| 支付方式变更 | 退款通道、对账规则、财务入账口径 |
| 新增订单状态 | 客服后台展示、数据看板、BI 口径、客服 SOP |
| 航班数据源切换 | 价格一致性、库存准确性、历史数据兼容 |
| 国际航线新规则 | 签证提示、行李政策、汇率结算、海关合规 |

---

## 二、前端专项维度评分细则

### F1. 多端一致性（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 各端差异明确标注 + 降级方案 + 特性矩阵 + 统一设计语言 |
| 4 | 主要端差异标注 + 有降级策略 |
| 3 | 只考虑了主要端，未标注差异 |
| 2 | 只考虑单端，其他端一句带过 |
| 1 | 未考虑多端适配 |

**检查项**：
- iOS / Android 差异是否标注
- 小程序与 App 功能差异是否说明
- 不支持的端是否有降级或替代方案
- 各端交互差异是否有对照表

### F2. UI/UX 规范（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 完整视觉稿 + 设计规范引用 + 组件复用说明 + 动效标注 + 文案终稿 |
| 4 | 有视觉稿 + 基本标注完整 |
| 3 | 有线框图但无视觉稿，或标注不完整 |
| 2 | 只有文字描述 UI |
| 1 | 无任何视觉参考 |

### F3. 性能要求（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 有量化指标（首屏 < Xs，FCP/LCP/TTI 等）+ 性能预算 + 优化策略 |
| 4 | 有性能要求 + 基本量化 |
| 3 | 提到性能但无量化指标 |
| 2 | 涉及列表/搜索等性能敏感场景但未提性能 |
| 1 | 完全未考虑性能 |

### F4. 兼容性说明（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 最低系统版本 + 机型覆盖 + 浏览器兼容 + 屏幕适配 + 弱网处理 |
| 4 | 有兼容范围定义 + 主要场景覆盖 |
| 3 | 有部分兼容考虑但不全 |
| 2 | 未明确兼容范围 |
| 1 | 完全未考虑兼容性 |

---

## 三、后端专项维度评分细则

### B1. 接口设计（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 完整接口文档 + 请求/响应示例 + 错误码定义 + 版本管理 + 幂等性 |
| 4 | 接口定义完整 + 有示例 + 基本错误码 |
| 3 | 有接口定义但缺少部分字段说明或错误码 |
| 2 | 接口设计不完整，字段含义不清 |
| 1 | 无接口设计 |

**机票接口必检项**：
- 请求/响应字段是否有类型和说明
- 是否有分页/排序参数
- 错误码是否区分业务错误和系统错误
- 是否考虑接口幂等性（特别是下单/支付接口）
- 是否有接口版本管理

### B2. 数据模型（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | ER图 + 字段定义 + 索引设计 + 数据生命周期 + 数据迁移方案 |
| 4 | 有数据结构 + 字段完整 + 基本索引 |
| 3 | 有数据结构但字段含义不全 |
| 2 | 数据模型模糊 |
| 1 | 无数据模型设计 |

### B3. 性能与容量（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | QPS 预估 + 缓存策略 + 限流降级 + 数据库容量规划 + 压测计划 |
| 4 | 有性能预估 + 缓存方案 |
| 3 | 提到性能但无量化评估 |
| 2 | 涉及高频场景（搜索/查价）但未考虑性能 |
| 1 | 完全未考虑性能 |

### B4. 容灾与降级（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 故障场景全覆盖 + 降级策略 + 数据一致性保障 + 自动恢复 + 演练计划 |
| 4 | 主要故障有降级策略 + 一致性考虑 |
| 3 | 部分容灾考虑但不完整 |
| 2 | 涉及核心链路但未考虑容灾 |
| 1 | 完全未考虑容灾 |

**机票后端必检容灾场景**：
- 航司/GDS 接口超时或不可用
- 价格缓存失效
- 库存数据不一致
- 支付回调延迟或丢失
- 出票失败

---

## 四、运营专项维度评分细则

### O1. 活动规则（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 规则完整无歧义 + 边界case全覆盖 + 防刷策略 + 法律合规审查 |
| 4 | 规则清晰 + 主要边界覆盖 |
| 3 | 规则基本有但边界case不全 |
| 2 | 规则模糊，容易产生歧义或纠纷 |
| 1 | 规则严重缺失 |

**活动规则检查清单**：
- [ ] 活动时间范围
- [ ] 参与条件（新/老用户、航线限制等）
- [ ] 优惠计算规则（叠加/互斥）
- [ ] 单用户参与上限
- [ ] 库存/预算上限
- [ ] 异常退款规则
- [ ] 防刷/风控策略

### O2. 运营配置（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 运营后台配置项清晰 + 配置生效机制 + 权限控制 + 操作日志 |
| 4 | 有配置方案 + 基本灵活 |
| 3 | 部分可配置，部分硬编码 |
| 2 | 需要开发改代码才能调整规则 |
| 1 | 完全没考虑运营配置灵活性 |

### O3. 效果衡量（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 核心指标定义 + 对照组设计 + 数据看板需求 + 复盘计划 |
| 4 | 有核心指标 + 基本衡量方案 |
| 3 | 提到了指标但定义不明确 |
| 2 | 没有明确的效果衡量方案 |
| 1 | 完全没有效果指标 |

### O4. 成本预估（1-5分）

| 分数 | 标准 |
|------|------|
| 5 | 详细成本测算 + 补贴预算 + ROI 预估 + 熔断机制 + 预算告警 |
| 4 | 有成本预估 + 预算控制 |
| 3 | 有大概预算但测算不够详细 |
| 2 | 涉及补贴/优惠但未估算成本 |
| 1 | 完全未考虑成本 |

---

## 五、流程图与逻辑建模评分细则（独立评审）

> 基于「去 If 化」结构化建模方法论。当需求文档包含流程图、业务逻辑、状态流转时触发本维度评审。
>
> **核心理念**：流程图不是"操作说明书"，而是"系统架构蓝图"。治理本质是把混在一起的东西强制拆开。

### 流程图复杂的 6 个根源（评审时逐一排查）

1. **角色混杂** — 用户、前端、后端、三方系统画在一起
2. **规则混杂** — 计算规则被画成路径分支
3. **状态混杂** — 订单状态被画成步骤流
4. **异常混杂** — 所有异常都画在主路径上
5. **版本混杂** — A/B、灰度、新老逻辑同时存在
6. **层级混杂** — 战略动作和按钮点击画在同一张图

---

### P1. 主干线性化（1-5分）

评审流程图是否做到「卫语句前置 + Happy Path 优先 + 异常不污染主干」。

| 分数 | 标准 |
|------|------|
| 5 | 拦截校验全部前置 + 主干完全线性（无嵌套 if）+ 异常统一出口 + Happy Path 单独可读 |
| 4 | 主要拦截前置 + 主干基本线性，少量异常混在中间 |
| 3 | 部分前置但仍有嵌套判断，主干右移明显 |
| 2 | 异常与主干严重交织，主路径被嵌套包裹 |
| 1 | 完全嵌套式画法，主干不可识别 |

**检查项**：
- [ ] 拦截型条件（登录校验、黑名单、风控、库存等）是否全部在流程最前端？
- [ ] 主流程是否可以从上到下一条线读完，不需要反复横跳？
- [ ] 异常出口是否统一（如统一指向"异常处理中心"节点）？
- [ ] 是否先画了 Happy Path 再单独处理异常子图？

**错误示例**（嵌套式）：
```
是否登录？
 └─ 是
     └─ 是否黑名单？
         └─ 否
             └─ 是否库存充足？
                 └─ 是 → 创建订单
```

**正确示例**（卫语句前置）：
```
登录校验 → 不通过 → 结束
风控校验 → 不通过 → 结束
库存校验 → 不通过 → 结束
————————————
进入核心主流程
————————————
创建订单 → 计算优惠 → 发起支付
```

---

### P2. 规则外置（1-5分）

评审多维条件组合是否用决策表/DMN/规则引擎替代了流程图中的菱形爆炸。

| 分数 | 标准 |
|------|------|
| 5 | 多维条件全部外置为决策表 + 规则版本化 + 规则与流程解耦 + 规则可独立迭代 |
| 4 | 主要规则外置 + 有决策表，少量简单判断仍在图中 |
| 3 | 意识到需要外置但执行不彻底，仍有 ≥3 维交叉判断在图中 |
| 2 | 大量多维条件画成连续菱形，没有外置意识 |
| 1 | 所有条件都画在流程图中，菱形 ≥ 6 个且有交叉组合 |

**触发外置的信号**：
- 同时判断 ≥ 3 个维度（如：会员等级 × 金额 × 渠道 × 航线类型）
- 条件存在交叉组合
- 条件未来会频繁变化（运营调整优惠、风控调整阈值）

**检查项**：
- [ ] 流程图中连续菱形是否 ≤ 3 个？
- [ ] 优惠/折扣计算是否用决策表而非分支？
- [ ] 风控规则是否标注为"调用规则引擎"黑盒节点？
- [ ] 决策表是否标注版本号（如"优惠规则 V3.2"）？
- [ ] A/B 实验是否用"调用实验系统"替代"是否灰度用户？"

**机票业务常见应外置的规则**：

| 规则类型 | 应外置为 | 流程图中仅保留 |
|---------|---------|-------------|
| 优惠计算 | 优惠决策表（等级×金额×渠道×航线→折扣） | `调用优惠规则引擎` |
| 风控判断 | 风控规则表（评分×支付方式×航线→动作） | `调用风控引擎` |
| 退改规则 | 退改政策矩阵（航司×舱位×时间→费用） | `查询退改政策` |
| 行李规则 | 行李策略表（航司×舱位×航线→额度） | `获取行李政策` |
| 灰度/AB | 实验配置 | `获取实验分组` |

---

### P3. 状态建模（1-5分）

评审涉及状态流转的逻辑（订单、审批、退款等）是否用 FSM 状态机建模而非步骤流。

| 分数 | 标准 |
|------|------|
| 5 | 完整 FSM 状态矩阵 + 所有状态可枚举 + 无断头路 + 可直接映射数据库字段 + 含异常状态 |
| 4 | 有状态图 + 主要状态转移完整，缺少部分异常状态 |
| 3 | 用了状态概念但仍以步骤流画法为主，有回退线交叉 |
| 2 | 步骤流 + 回退线 + 超时线混杂，状态不可枚举 |
| 1 | 完全按时间线画，状态混乱，存在回滚乱线和断头路 |

**FSM 标准公式**：`当前状态 + 事件 → 下一状态`

**检查项**：
- [ ] 是否有明确的状态枚举表？
- [ ] 每个状态转移是否有对应的触发事件？
- [ ] 是否每条路径都有终态（无断头路）？
- [ ] 状态名是否可直接映射数据库字段？
- [ ] 是否考虑了超时、失败等异常状态？

**机票业务典型 FSM 检查**：

| 业务场景 | 必须包含的状态 | 必须包含的事件 |
|---------|-------------|-------------|
| 下单 | INIT→WAIT_PAY→PAID→ISSUED→COMPLETED | 创建/支付/超时/出票/出票失败 |
| 退款 | PAID→REFUND_APPLY→REFUND_REVIEW→REFUNDED | 申请/审核通过/审核拒绝/退款完成 |
| 改签 | ISSUED→CHANGE_APPLY→CHANGE_REVIEW→CHANGED | 申请/审核/改签成功/改签失败 |

---

### P4. 职责泳道（1-5分）

评审多角色/多系统流程是否用泳道图明确职责边界。

| 分数 | 标准 |
|------|------|
| 5 | 泳道划分合理（≤5 条）+ 职责单一 + 同步/异步标注清晰 + 系统边界明确 |
| 4 | 有泳道 + 主要职责清晰，缺少异步标注或边界说明 |
| 3 | 有泳道但划分不合理（太粗或太细），部分职责混淆 |
| 2 | 涉及 ≥2 个角色/系统但未使用泳道，职责不清 |
| 1 | 多角色/多系统全部混在一条线上，完全无法区分谁做什么 |

**泳道使用规范**：
- ≥2 个角色或系统参与时**必须**使用泳道
- 泳道数量 ≤ 5 条（太多横向爆炸）
- 泳道内保持单向流（禁止跨越多条泳道跳跃）
- 异步行为必须标注 `【异步回调】` `【定时任务】` `【MQ消息】`
- 如果画不清楚泳道 → 说明职责划分不清，需先厘清架构

**机票 OTA 标准泳道划分**：

| 泳道 | 包含内容 |
|------|---------|
| 用户 | 选择、点击、确认等操作 |
| 前端系统 | 页面渲染、请求发起、展示结果 |
| OTA 后端 | 业务逻辑、订单管理、缓存 |
| GDS/航司 | 锁舱、出票、退改签处理 |
| 支付平台 | 支付处理、回调通知 |

**检查项**：
- [ ] 是否能一眼看出"谁做了什么"？
- [ ] 前端行为和后端行为是否分开？
- [ ] 第三方系统调用是否在独立泳道？
- [ ] 异步回调/定时任务是否有明确标注？
- [ ] 泳道是否 ≤ 5 条？

---

### P5. 分层建模（1-5分）

评审需求文档是否按层级拆分流程图，而非全部塞进一张图。

| 分数 | 标准 |
|------|------|
| 5 | 完整 L1-L5 分层 + 各层独立可读 + 层间引用清晰 + 适合不同受众 |
| 4 | 有 2-3 层拆分（如主干图+详细图）+ 基本可读 |
| 3 | 有拆分意识但层次不清（如部分细节仍在主干中） |
| 2 | 所有内容塞在一张图中，但尚可读 |
| 1 | 一张超大图（≥3 页）+ 混合所有层级 + 不可读 |

**L1-L5 分层标准**：

| 层级 | 名称 | 受众 | 内容 | 特征 |
|------|------|------|------|------|
| L1 | 业务主干 | 管理层/业务方 | 核心步骤，无判断 | 5-8 个节点，线性 |
| L2 | 系统流程 | 技术团队 | 泳道图，明确职责 | 含同步/异步标注 |
| L3 | 状态图 | 开发/测试 | FSM 状态矩阵 | 状态+事件→新状态 |
| L4 | 规则文档 | 运营/风控 | 决策表/DMN | 可独立版本化 |
| L5 | 交互流 | 设计/前端 | 页面跳转+弹窗 | 含各种状态 |

**检查项**：
- [ ] 是否有面向管理层的"一眼看完"主干图？
- [ ] 技术细节是否下沉到 L2/L3 而非塞进 L1？
- [ ] 状态流转类逻辑是否独立为状态图（L3）？
- [ ] 业务规则是否独立为决策表（L4）？
- [ ] 交互流程是否独立为交互图（L5）？

**机票 OTA 下单的分层交付示例**：
- L1 主干图：选航班 → 确认订单 → 支付 → 出票 → 完成
- L2 泳道图：用户|前端|OTA后端|GDS|支付平台
- L3 状态图：INIT → WAIT_PAY → PAID → ISSUED → COMPLETED
- L4 规则表：优惠决策表 + 风控规则表 + 退改政策矩阵
- L5 交互图：搜索页 → 航班列表 → 订单确认 → 支付页 → 出票结果

---

### P6. 可工程映射（1-5分）

评审流程图是否可以直接被研发用于代码实现、测试用例生成、系统架构设计。

| 分数 | 标准 |
|------|------|
| 5 | 可直接映射：代码结构 + FSM 实现 + 规则引擎配置 + 测试用例 + API 设计 |
| 4 | 大部分可映射，少量需研发二次解读 |
| 3 | 需要研发大量补充和猜测才能转为实现 |
| 2 | 流程图与实际工程实现差距大，仅作示意 |
| 1 | 流程图无法指导任何工程实现 |

**可工程映射检查清单**：
- [ ] 流程图可转为代码中的函数/方法调用链？
- [ ] 状态图可直接转为数据库状态字段 + 状态机代码？
- [ ] 决策表可直接配置进规则引擎？
- [ ] 每条路径（含异常）可生成一条测试用例？
- [ ] 泳道可映射为服务/模块边界？

**评语模板**：
- 5分："流程图完全可工程映射：主干图→Controller 调用链，状态图→OrderStatus 枚举 + 状态机，优惠表→规则引擎配置，泳道→微服务边界。测试可直接从状态矩阵枚举 12 条用例。"
- 3分："主干流程基本可映射代码，但优惠规则仍画在流程图中，研发需自行抽取为决策表。状态流转用步骤线画法，需研发自行整理为 FSM。建议：将优惠逻辑外置为决策表 V1，订单流程改为状态矩阵。"
- 1分："流程图仅为示意，无法指导工程实现。存在断头路、未定义状态、多维判断嵌套。研发看了等于没看，需要重新跟产品对齐所有逻辑。"

---

### 流程图综合质量检查表

评审时逐项打勾，未通过项需在评语中说明：

**结构检查**：
- [ ] 职责单一：每张图只讲一件事
- [ ] 菱形去重：连续菱形 ≤ 3 个
- [ ] 卫语句检查：拦截校验全部在流程最前端
- [ ] 闭环验证：每个分支都有 End 节点
- [ ] 颗粒度对齐：不混合"点击按钮"和"系统异步扣款"

**泳道检查**：
- [ ] ≥2 角色/系统时使用了泳道
- [ ] 同步/异步区分清晰
- [ ] 跨系统调用逻辑清晰
- [ ] 泳道数量 ≤ 5

**状态检查**：
- [ ] 涉及状态的场景用了 FSM
- [ ] 不存在回滚乱线
- [ ] 状态可枚举

**可工程映射**：
- [ ] 可转 FSM 代码
- [ ] 可转规则表配置
- [ ] 可生成测试用例