Prd Cross Analyzer

SKILL.md

---
name: prd-cross-analyzer
description: |
  三合一产品需求交叉分析。输入产品框架 → 加载竞品截图/文档 → 加载开放平台API → 输出详细模块PRD。
  适用于大师傅餐饮系统各业务模块的需求详细设计。
---

# PRD 三合一交叉分析 Skill

## 触发条件

用户请求以下任一：
- "梳理 [模块名] 的详细需求"
- "对 [模块名] 做竞品交叉分析"
- "结合竞品和API，完善 [模块名] PRD"
- "三合一分析 [模块名]"
- "用交叉分析法写 [模块名] 需求"

## 核心方法论

```
PRD框架（要做什么）
    ×
竞品截图/文档（别人怎么做）
    ×
开放平台API（系统能接什么）
    ↓
详细模块PRD（我们要怎么做，比竞品好在哪）
```

## 执行流程

### Phase 1: 确认分析范围（1分钟）

1. **明确目标模块**：如 组织架构、账号权限、点餐收银、会员、外卖、订单聚合等
2. **确认PRD框架版本**：默认使用最新 `基础基建模块v2.1`
3. **确认竞品范围**：默认三平台（企迈+客如云+美团POS）
4. **确认开放平台范围**：默认四平台（企迈+美团+客如云+天财商龙）

### Phase 2: 加载数据源

#### 2.1 加载PRD框架

```
来源：飞书文档
- 基础基建模块 PRD v2.1: doc_id=TnHCdKY6jopPAAxGH8ucrxhunTg
- 目标模块的已有框架（如有）
```

#### 2.2 加载竞品截图/文档

```
竞品数据索引（本地）:

企迈：
  路径: catering-saas-prd/competitor-analysis/企迈/
  总报告: 企迈PC端竞品分析总报告.md
  模块文档:
    - 原始素材/模块文档/PC端深度分析_账号与门店管理.md
    - 原始素材/模块文档/PC端深度分析_门店业务.md
    - 原始素材/模块文档/PC端深度分析_支付管理.md
    - 原始素材/模块文档/PC端深度分析_品牌管理.md
    - 原始素材/模块文档/PC端深度分析_鸿图与平台业务.md
    - 原始素材/模块文档/PC端深度分析_财务与数据.md
    - 原始素材/模块文档/PC端深度分析_企迈鸿图.md
  截图: 395张

客如云：
  路径: catering-saas-prd/competitor-analysis/客如云/
  总报告: 客如云PC端竞品分析总报告.md (或 _完整报告.md)
  模块文档:
    - 原始素材/模块文档/PC端深度分析_餐厅管理上.md
    - 原始素材/模块文档/PC端深度分析_餐厅管理下.md
    - 原始素材/模块文档/PC端深度分析_菜品与外卖.md
    - 原始素材/模块文档/PC端深度分析_营销与会员.md
    - 原始素材/模块文档/PC端深度分析_报表.md
    - 原始素材/模块文档/PC端深度分析_供应链与服务市场.md
    - 原始素材/模块文档/PC端深度分析_财务账号与设置.md
  截图: 184张

美团POS：
  路径: competitor-analysis/meituan-pos/
  总报告: 美团POS竞品分析总报告.md
  截图: 546张（17个模块）
```

**按目标模块筛选**：只加载与目标模块相关的文档和截图，不全部加载。

#### 2.3 加载开放平台API

```
开放平台Skill索引:

企迈 (qmai-api-fetcher): 32模块, 307接口
  Skill路径: skills/qmai-api-fetcher/SKILL.md
  数据路径: skills/qmai-api-fetcher/references/

美团 (meituan-api-fetcher): 6大类, 329接口
  Skill路径: skills/meituan-api-fetcher/SKILL.md
  数据路径: skills/meituan-api-fetcher/references/

客如云 (keruyun-api-fetcher): 20模块, 178接口
  Skill路径: skills/keruyun-api-fetcher/SKILL.md
  数据路径: skills/keruyun-api-fetcher/references/

天财商龙 (tcsl-api-fetcher): 9模块, 99接口
  Skill路径: skills/tcsl-api-fetcher/SKILL.md
  数据路径: skills/tcsl-api-fetcher/references/
```

**按目标模块筛选**：只加载相关API模块，例如分析"会员"时只加载各平台的会员相关API。

### Phase 3: 交叉分析

#### 3.1 竞品功能对标

提取每个竞品在目标模块上的功能清单：

```markdown
## 竞品功能对标：[模块名]

| 功能点 | 企迈 | 客如云 | 美团POS |
|--------|------|--------|---------|
| 功能A | ✅ 有 | ✅ 有 | ❌ 无 |
| 功能B | ✅ 有 | ❌ 无 | ✅ 有 |
| ... | | | |
```

**分析原则**：
- 从截图/文档中提取**事实**，不做主观推断
- 三平台都有的功能 = 行业标配，必须做
- 仅一平台有的功能 = 差异化机会，值得评估
- 三平台都没有的 = 蓝海，重点考虑

#### 3.2 API能力对齐

用开放平台API反推竞品的真实数据模型：

```markdown
## API能力对齐：[模块名]

| 能力 | 企迈API | 美团API | 客如云API | 天财商龙API |
|------|---------|---------|-----------|-------------|
| 接口A | /v3/xxx | /api/xxx | /open/xxx | - |
| 接口B | - | /api/yyy | /open/yyy | /yyy |
| ... | | | | |
```

**分析原则**：
- API存在 = 该平台对这个功能的抽象程度
- API参数结构 = 真实数据字段设计
- API调用流程 = 业务流程设计
- 多个平台共有的API = 行业标准接口模式

#### 3.3 需求提炼

结合框架+竞品+API，输出详细需求：

```markdown
## 需求详细设计：[模块名]

### 功能清单

#### P0 必须做（三平台都有的行业标配）
1. 功能A
   - 竞品参考：企迈XX页、客如云XX页
   - API参考：企迈/v3/xxx、美团/api/xxx
   - 设计要点：...

#### P1 建议做（差异化机会）
1. 功能B（仅企迈有）
   - 竞品截图参考
   - 增强设计：...

#### P2 蓝海机会（三平台都没有）
1. 功能C
   - 为什么竞品没做但值得做
   - 设计方向：...

### 数据模型
（从各平台API反推整合）

### 交互流程
（从竞品截图提炼最优路径）

### 与已有模块的关系
（关联耦合点、依赖关系）
```

### Phase 4: 输出交付

#### 4.1 输出格式

保存到 `catering-saas-prd/模块名/PRD-模块名.md`

同时同步到飞书（可选，用户确认）。

#### 4.2 交付清单

1. **完整分析文档**（本地 + 飞书）
2. **竞品功能对标矩阵**
3. **API能力对齐表**
4. **详细需求清单（P0/P1/P2）**
5. **数据模型草案**
6. **未解决问题列表**

## 分析深度要求

### 竞品分析深度
- 不止说"有/无"，要说明**怎么做的**（交互细节、字段设计、流程步骤）
- 标注截图编号或页面位置，方便溯源
- 区分"截图可见"和"推测"两类信息来源

### API分析深度
- 提取**请求参数**（必填/可选、类型、取值范围）
- 提取**响应字段**（字段名、类型、含义）
- 提取**调用流程**（需要先调什么、返回什么id用于后续调用）
- 识别**回调/Webhook**事件

### 需求提炼质量
- 每个P0需求必须至少有一个竞品参考和一个API参考
- 每个P1需求必须说明差异化理由
- 每个数据字段必须标注来源（竞品截图 or API定义）

## 模块映射参考

不同目标模块对应的竞品文档和API模块：

| PRD模块 | 竞品文档（关键字） | 相关API模块 |
|---------|-------------------|-------------|
| 组织架构/账号权限 | 账号与门店管理、餐厅管理、品牌管理 | 门店管理、组织管理、人员管理 |
| 点餐收银 | 门店业务、餐厅管理、菜品与外卖 | 订单服务、交易支付 |
| 会员 | 营销与会员 | 会员服务、会员营销 |
| 外卖/订单聚合 | 菜品与外卖 | 订单服务、配送 |
| 营销 | 营销与会员、企迈鸿图 | 营销服务、券管理、活动管理 |
| 供应链 | 供应链与服务市场 | 进销存、库存管理 |
| 报表/财务 | 财务与数据、报表 | 财务管理、数据报表 |
| 支付 | 支付管理 | 交易支付、支付管理 |

## 注意事项

### 数据加载策略
- **按需加载，不全量加载**：只加载目标模块相关的竞品文档和API
- **优先读本地**：竞品文档和API数据都在本地，使用read工具直接读取
- **API数据优先读索引**：先读各skill的SKILL.md了解接口概览，再按需读具体JSON

### 效率控制
- 单个模块分析控制在 20-30 分钟
- 如模块过大（如"点餐收银"），与用户确认是否拆分
- 竞品文档按"目标模块"筛选阅读，不是全读

### 质量要求
- 竞品功能对标必须标注来源（哪份文档/哪个截图）
- API对齐必须标注具体接口路径
- 数据模型字段必须标注是"竞品可见"还是"API定义"
- 未解决或存疑的点必须明确标注

### 输出风格
- 以产品总监视角，输出可直接评审的需求文档
- 区分"事实陈述"和"设计建议"
- 每个设计建议附竞品对照和API依据

## 示例对话

**用户**：梳理会员模块的详细需求

**助手**：
> 好的，开始三合一交叉分析会员模块。
> 
> **Phase 1-2: 加载数据**
> - PRD框架：基础基建v2.1 第5章会员体系配置
> - 竞品：企迈营销与会员文档、客如云营销与会员文档、美团会员CRM解决方案
> - API：企迈4.x会员服务(4模块84接口)、美团会员营销类、客如云会员、天财商龙会员
> 
> **Phase 3: 交叉分析**
> [输出竞品功能对标矩阵 + API能力对齐表 + 详细需求P0/P1/P2]
> 
> **Phase 4: 输出**
> 详细PRD已保存到 `catering-saas-prd/会员/PRD-会员.md`
> 
> 关键发现：
> 1. 三平台都支持会员积分+等级+权益，是行业标配
> 2. 企迈额外支持"会员标签管理"（12个API），是差异化功能
> 3. 美团API暴露了"会员通存通兑"概念，建议大师傅系统也支持
> 4. 三平台的会员架构都偏简单（单品牌），大师傅的多品牌多层级是壁垒优势