Prd Cross Analyzer

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

PRD 三合一交叉分析 Skill

触发条件

用户请求以下任一：

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

核心方法论

text

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

执行流程

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

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

Phase 2: 加载数据源

2.1 加载PRD框架

text

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

2.2 加载竞品截图/文档

text

竞品数据索引（本地）:

企迈：
  路径: 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

text

开放平台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. 三平台的会员架构都偏简单（单品牌），大师傅的多品牌多层级是壁垒优势