机票产品需求评审

v1.0.0

机票产品需求评审 Agent。对前端、后端、运营类机票需求文档进行结构化评审打分,含独立的流程图治理评审(去If化、卫语句、决策表、FSM、泳道图、分层建模)。输入需求文档(markdown/图片/HTML),输出分项评分、评语和改进建议。使用场景:用户说"评审需求"、"审需求文档"、"给需求打分"、"需求评审"...

0· 112·0 current·0 all-time

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for arisefx/flight-requirement-review.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "机票产品需求评审" (arisefx/flight-requirement-review) from ClawHub.
Skill page: https://clawhub.ai/arisefx/flight-requirement-review
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install flight-requirement-review

ClawHub CLI

Package manager switcher

npx clawhub@latest install flight-requirement-review
Security Scan
VirusTotalVirusTotal
Pending
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
Name/description match the provided SKILL.md, example outputs, and templates. All included files are documentation and review templates that are appropriate for a requirements-review agent. There are no declared binaries, env vars, or config paths that would be out-of-scope for a document-review tool.
Instruction Scope
Runtime instructions ask the agent to read Markdown, view images, and parse HTML to produce structured scores/reports, which is consistent with the stated purpose. Note: the SKILL.md assumes the agent environment can process images/HTML (OCR/HTML parsing); this is an operational dependency (not a security misalignment). The instructions do not ask to read unrelated system files, access credentials, or transmit data to unexpected external endpoints.
Install Mechanism
No install spec or code is present (instruction-only). This is low-risk: nothing will be downloaded or written by the skill itself.
Credentials
No environment variables, credentials, or config paths are requested. The skill does not require any secret or external-service tokens, matching its stated function of offline document evaluation.
Persistence & Privilege
always:false and normal autonomous invocation settings. The skill does not request permanent presence or modify other skills' configuration. No elevated privileges are requested.
Assessment
This skill appears internally consistent and low-risk from a technical footprint perspective, but consider these points before installing: 1) It will process any document, image, or HTML you give it — do not upload sensitive PII, credentials, or confidential business secrets unless you trust the agent logging/retention policy. 2) The SKILL.md assumes the platform/agent can parse images (OCR) and HTML; test with non-sensitive examples to confirm expected behavior in your environment. 3) Because the skill is instruction-only, there is no hidden code download, but outputs and user-provided inputs may be stored in conversation logs — check your platform's data retention and privacy settings. 4) If you need stricter data handling, avoid sending regulated data or sanitize documents before use. Overall, the skill is coherent with its stated purpose.

Like a lobster shell, security has layers — review code before you run it.

latestvk97a9ya2tgy1t2fgmqj0bs50vn83pszt
112downloads
0stars
1versions
Updated 1mo ago
v1.0.0
MIT-0

机票产品需求评审 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

通用维度(所有需求类型适用,共 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-5QPS预估、缓存策略、限流是否考虑
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严重不足核心内容缺失,需重写

评审报告输出格式

# 需求评审报告

## 基本信息
- **需求名称**:{名称}
- **需求类型**:{大类} > {子类}
- **关联类型**:{如有}
- **文档版本**:{版本号}
- **评审日期**:{日期}

## 评审总览

| 项目 | 结果 |
|------|------|
| 通用维度得分 | {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

Comments

Loading comments...