Skill: arisefx/flight-requirement-review (version 1.0.0)

--- name: flight-requirement-review description: 机票产品需求评审 Agent。对前端、后端、运营类机票需求文档进行结构化评审打分，含独立的流程图治理评审（去If化、卫语句、决策表、FSM、泳道图、分层建模）。输入需求文档（markdown/图片/HTML），输出分项评分、评语和改进建议。使用场景：用户说"评审需求"、"审需求文档"、"给需求打分"、"需求评审"、"评审流程图"、"检查流程图"、"流程图打分"时触发。 --- # 机票产品需求评审 Agent ## 评审流程 收到需求文档后，按以下步骤执行： 1. **识别需求类型** → 判断属于前端/后端/运营中的哪一类 2. **解析文档内容** → 读取 markdown 文本、查看图片、解析 HTML 页面 3. **通用维度评分** → 按评审标准对每个维度打分（1-5分） 4. **专项维度评分** → 按需求类型对应专项维度打分 5. **流程图与逻辑建模评审** → 独立评审流程图质量（当文档包含流程/逻辑时） 6. **生成评审报告** → 输出结构化评审结果 > **两种模式**： > - **完整评审模式**：通用 + 专项 + 流程图（作为完整评审的一部分自动执行） > - **独立流程图评审模式**：用户说"评审流程图"、"检查流程图"、"流程图打分"时触发，仅评审 P1-P6（满分 30），结论判定：≥24 分(80%)通过 / ≥18 分(60%)有条件通过 / <18 分不通过 ## 需求分类 收到文档后，先判断需求类型： | 大类 | 子类 | 判断依据 | |------|------|----------| | **前端需求** | 客户端（iOS/Android） | 涉及原生控件、SDK调用、设备能力 | | **前端需求** | H5 | 涉及 Web 页面、浏览器兼容、响应式 | | **前端需求** | 支付宝小程序 | 涉及支付宝组件、my. API | | **前端需求** | 微信小程序 | 涉及微信组件、wx. API | | **后端需求** | 航班数据 | 涉及航班查询、运力、时刻表 | | **后端需求** | 价格 | 涉及运价、票价计算、价格日历 | | **后端需求** | 下单 | 涉及订单创建、支付、库存锁定 | | **后端需求** | 出票 | 涉及票号、PNR、出票通知 | | **后端需求** | 退改 | 涉及退票、改签、退款规则 | | **运营需求** | 活动 | 涉及营销活动、促销、拉新 | | **运营需求** | 优惠包装 | 涉及优惠券、套餐、价格包装 | 如果文档跨多个类型，标注**主类型 + 关联类型**。 **跨类型需求的专项维度处理**： - 主类型的专项维度**全部评分** - 关联类型中**实际涉及的专项维度**也纳入评分，标注来源 - 例如：主类型=前端，关联=后端 → F1-F4 全评 + B1(接口设计)纳入（因文档包含接口定义） - 满分 = 通用 + 主类型专项 + 关联类型中实际评分的维度 × 5 ## 评审维度与评分标准 详细评分标准见 [review-standards.md](review-standards.md) ### 通用维度（所有需求类型适用，共 65 分） | 维度 | 分值 | 核心关注点 | |------|------|-----------| | 1. 需求背景与目标 | 1-5 | 问题是否清晰、目标是否可量化 | | 2. 用户场景 | 1-5 | 场景是否完整、用户路径是否清楚 | | 3. 功能范围 | 1-5 | 边界是否明确、MVP 是否合理 | | 4. 业务流程 | 1-5 | 主流程是否完整、异常流程是否覆盖 | | 5. 交互设计 | 1-5 | 交互是否合理、状态是否完整 | | 6. 数据埋点 | 1-5 | 埋点是否覆盖关键路径、字段是否完整 | | 7. 上线方案 | 1-5 | 灰度/回滚/监控是否考虑 | | 8. 安全与合规 | 1-5 | 数据安全、隐私、合规是否考虑 | | 9. 影响面评估 | 1-5 | 对现有**技术模块**的影响是否分析 | | 10. 文档质量 | 1-5 | 结构清晰、无歧义、图文配合 | | 11. 验收标准 | 1-5 | 是否有明确可测试的验收条件 | | 12. 依赖与风险 | 1-5 | 外部依赖、技术风险是否识别 | | 13. 关联逻辑完整性 | 1-5 | 上下游**业务链路**是否同步考虑（财务/客服/运营） | ### 前端专项维度（+20 分） | 维度 | 分值 | 核心关注点 | |------|------|-----------| | F1. 多端一致性 | 1-5 | 各端差异是否标注、降级方案是否有 | | F2. UI/UX 规范 | 1-5 | 视觉稿是否完整、组件复用是否考虑 | | F3. 性能要求 | 1-5 | 加载速度、动画流畅度是否有指标 | | F4. 兼容性说明 | 1-5 | 机型/系统版本/浏览器兼容范围 | ### 后端专项维度（+20 分） | 维度 | 分值 | 核心关注点 | |------|------|-----------| | B1. 接口设计 | 1-5 | 接口定义是否完整、字段是否清晰 | | B2. 数据模型 | 1-5 | 数据结构是否合理、字段含义是否明确 | | B3. 性能与容量 | 1-5 | QPS预估、缓存策略、限流是否考虑 | | B4. 容灾与降级 | 1-5 | 故障场景、降级策略、数据一致性 | ### 运营专项维度（+20 分） | 维度 | 分值 | 核心关注点 | |------|------|-----------| | O1. 活动规则 | 1-5 | 规则是否完整无歧义、边界case是否覆盖 | | O2. 运营配置 | 1-5 | 是否支持运营自助配置、灵活度如何 | | O3. 效果衡量 | 1-5 | 核心指标是否定义、数据看板需求 | | O4. 成本预估 | 1-5 | 优惠成本、补贴预算是否估算 | ### 流程图与逻辑建模维度（独立评审，+30 分） 当需求文档包含流程图、业务逻辑、状态流转时触发。基于「去 If 化」结构化建模方法论评审。 | 维度 | 分值 | 核心关注点 | |------|------|-----------| | P1. 主干线性化 | 1-5 | 卫语句前置、Happy Path 优先、异常不污染主干 | | P2. 规则外置 | 1-5 | 多维条件是否用决策表/DMN 替代菱形判断 | | P3. 状态建模 | 1-5 | 订单/审批类是否用 FSM 状态机、状态可枚举 | | P4. 职责泳道 | 1-5 | 多角色/多系统是否用泳道图、职责边界清晰 | | P5. 分层建模 | 1-5 | 是否按 L1-L5 分层（主干/系统/状态/规则/交互） | | P6. 可工程映射 | 1-5 | 流程图能否直接映射代码结构/FSM/规则引擎/测试用例 | **核心治理原则**（五个分离）： 1. **主干 vs 异常分离** → 异常前置拦截，不嵌套主流程 2. **流程 vs 规则分离** → 多维条件用决策表，不在流程图里画菱形爆炸 3. **状态 vs 步骤分离** → 有状态流转的用 FSM，不画时间线+回退线 4. **角色 vs 系统分离** → 多方参与的用泳道图，不混在一条线上 5. **差异 vs 策略分离** → 多渠道/多版本用策略模式子图，不用 if-else 分支 **流程图质量红线**（任一触发即扣至 1-2 分）： - 连续菱形 ≥ 4 个 - 存在逻辑断头路（分支无 End 节点） - 用户操作与系统异步混在同一时间线 - A/B 实验逻辑画在主流程中 ## 评分等级 | 分数 | 等级 | 含义 | |------|------|------| | 5 | 优秀 | 全面详尽，可直接进入开发 | | 4 | 良好 | 基本完整，少量细节需补充 | | 3 | 及格 | 有明显遗漏，需补充后再评审 | | 2 | 不足 | 关键内容缺失，需大幅修改 | | 1 | 严重不足 | 核心内容缺失，需重写 | ## 评审报告输出格式 ```markdown # 需求评审报告 ## 基本信息 - **需求名称**：{名称} - **需求类型**：{大类} > {子类} - **关联类型**：{如有} - **文档版本**：{版本号} - **评审日期**：{日期} ## 评审总览 | 项目 | 结果 | |------|------| | 通用维度得分 | {X}/65 | | 专项维度得分 | {Y}/20 | | 流程图建模得分 | {Z}/30（如适用） | | 总分 | {总分}/{满分} | | 得分率 | {百分比}% | | 评审结论 | 🟢通过 / 🟡有条件通过 / 🔴不通过 | ### 评审结论判定（按得分率，优先级从上到下） 1. 🔴 **不通过**：任一维度得 1 分，或得分率 < 60% 2. 🟡 **有条件通过**：得分率 ≥ 60% 且 < 80%，或得分率 ≥ 80% 但存在 2 分项 3. 🟢 **通过**：得分率 ≥ 80% 且所有维度 ≥ 3 分 ### 满分计算规则 - 基础分 = 通用维度(适用项 × 5) + 专项维度(适用项 × 5) - 含流程图时追加：流程图维度(适用项 × 5) - 标记为 N/A 的维度不计入满分和得分 - 典型满分：通用(65) + 专项(20) = 85；含流程图(65) + (20) + (30) = 115 ### 维度 N/A 规则 以下情况可标记维度为 N/A（不计分）： - 需求无流程图/逻辑描述 → P1-P6 全部 N/A - 需求不涉及状态流转 → P3 N/A - 需求不涉及多角色/多系统 → P4 N/A - 纯后端需求无页面 → 维度5(交互设计) N/A - 纯前端样式调整 → 维度6(数据埋点) 可 N/A - 标记 N/A 时必须注明理由 ## 分项评分 ### 通用维度 | # | 维度 | 得分 | 评语 | |---|------|------|------| | 1 | 需求背景与目标 | {分}/5 | {具体评语} | | 2 | 用户场景 | {分}/5 | {具体评语} | | ... | ... | ... | ... | ### 专项维度（{前端/后端/运营}） | # | 维度 | 得分 | 评语 | |---|------|------|------| | 1 | {维度名} | {分}/5 | {具体评语} | | ... | ... | ... | ... | ### 流程图与逻辑建模（如适用） | # | 维度 | 得分 | 评语 | |---|------|------|------| | P1 | 主干线性化 | {分}/5 | {评语：卫语句/Happy Path/异常隔离} | | P2 | 规则外置 | {分}/5 | {评语：决策表/规则引擎} | | P3 | 状态建模 | {分}/5 | {评语：FSM/状态可枚举} | | P4 | 职责泳道 | {分}/5 | {评语：泳道划分/职责边界} | | P5 | 分层建模 | {分}/5 | {评语：L1-L5层次} | | P6 | 可工程映射 | {分}/5 | {评语：代码映射/测试覆盖} | #### 流程图结构检查清单 - [ ] 连续菱形 ≤ 3 个 - [ ] 所有分支有 End 节点（无断头路） - [ ] 拦截校验前置（卫语句） - [ ] 颗粒度对齐（同层级节点） - [ ] 泳道职责清晰（≥2 角色时） - [ ] 同步/异步明确标注 - [ ] 状态可枚举（无回滚乱线） - [ ] 规则可外置（无菱形爆炸） - [ ] 可转 FSM / 规则表 / 测试用例 #### 流程图重构建议（当得分 ≤ 3 时输出） 建议将当前流程图重构为以下交付物： 1. 1 张主干图（L1 业务主干，线性化） 2. 1 张泳道图（L2 系统流程，职责清晰） 3. 1 张状态图（L3 FSM，状态可枚举） 4. N 张规则表（L4 决策表，规则外置） 5. 1 张交互流（L5 页面跳转） ## 关键问题（必须修改） 1. {问题描述} → {修改建议} 2. ... ## 改进建议（建议优化） 1. {建议描述} 2. ... ## 亮点 1. {值得肯定的点} 2. ... ``` ## 评语编写规则 每项评语必须包含： 1. **事实陈述**：文档中做了什么 / 缺了什么 2. **影响分析**：这对开发/测试/用户会造成什么影响 3. **改进建议**（3分及以下时必须给出）：具体的修改方向 评语示例： - 5分："异常流程覆盖了用户取消、超时、网络异常、重复添加等 5 种场景，每种都有明确的提示文案和处理逻辑，可直接进入开发。" - 3分："仅描述了主流程，异常流程只提到了'网络异常'一种。缺少用户取消、授权超时、服务端错误等场景的处理。建议补充异常场景表，每种异常明确提示文案和重试策略。" - 1分："完全没有异常流程描述。任何上线功能都必须考虑异常，建议参考异常流程模板补充。" ## 处理图片和 HTML ### 图片处理 - 查看需求文档中的图片（交互稿/流程图/UI 设计） - 评审图片与文字描述的一致性 - 检查交互稿是否覆盖所有状态（空态、加载态、错误态、正常态） ### HTML 处理 - 读取 HTML 文件，分析页面结构和交互逻辑 - 检查 HTML 是否与需求描述一致 - 评估交互原型的完整度 ## 生成技术文档 评审完成后，如果用户要求，可将需求文档转化为 AI 友好的技术文档。格式见 [tech-doc-template.md](tech-doc-template.md)


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)