# App Competitor Analysis

> 对波咯咯（BOLOLO）APP 做功能切片竞品分析：公开资料与用户评论挖功能，再结合登录态截图校准， 输出人群需求、体验优化点、可创新/可差异化点与行动建议。 Use when the user mentions 竞品分析、竞品对比、功能对标、宝宝树、亲宝宝、美的美居、米家、小佩, or asks to analyze competitor APP features against 波咯咯/bololo.

- Skill: `lareina0011/app-competitor-analysis` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add lareina0011/app-competitor-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lareina0011/app-competitor-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lareina0011 (https://skillmd.com/u/lareina0011)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/lareina0011/app-competitor-analysis

---


# APP 竞品分析（波咯咯）

面向 **波咯咯 APP 产品经理** 的功能级竞品分析。默认我方锚点见下方；不要一上来做整 App 漫游式审计。

## 我方默认锚点

| 项 | 默认 |
|----|------|
| 产品 | 波咯咯（BOLOLO / 喂养家）APP，已上架各大应用市场 |
| 用户 | 购买我司母婴小家电的用户；宝妈为主、宝爸为辅；iOS 占比较大 |
| 能力 | 设备控制 + 数据记录库；商城为后续能力 |
| 视角 | 宝妈场景压力（一手/碎片/低负担）+ 兼顾 iOS 习惯 |

用户当次另有说明时，以当次为准。

## 何时启用

用户提到竞品分析、功能对标，或点名默认竞品 / 新竞品，并要对照波咯咯某功能时启用。

输入不足时先问清：

1. **本次功能点**（必填，如配网绑定、远程控制、喂养记录、场景自动化、商城…）
2. **赛道范围**：母婴 / 家电 / 两边都要（默认两边）
3. **竞品名单**：未指定则用 [reference.md](reference.md) 默认名单
4. **材料**：有无登录态截图、规格说明、我方现状简述

## 双赛道角色（评价滤镜）

| 赛道 | 默认竞品 | 主要对照什么 |
|------|----------|--------------|
| 母婴类 | 宝宝树、亲宝宝 | 育儿记录、内容/社区、宝妈任务与心智 |
| 家电类 | 美的美居、米家、小佩 | 配网控制、设备状态、场景/生态、硬件耦合 |

- 同一功能在两赛道用**不同评价标准**，禁止「谁功能多谁赢」。
- 交叉属性竞品标「双属性」，分别用两套滤镜各看一眼。
- 定位不可比时写「仅作参考」，仍可摘体验/差异化线索。

与 `app-interaction-review` 分工：本 skill 出需求/功能/体验方向与差异化；单屏方案对错 + Demo 交给交互评审。

## 工作流

复制并跟踪：

```
进度:
- [ ] 0 锁定范围（功能点 / 赛道 / 竞品 / 我方现状）
- [ ] 1 公开采集（商店/官网/更新说明）
- [ ] 2 评论筛功能与痛点
- [ ] 3 功能假设清单（带来源与置信度）
- [ ] 4 截图校准（有则执行；无则标「待校准」）
- [ ] 5 按输出结构写分析
```

### 阶段 0：锁定范围

以**我方功能点**为锚，列出要对齐的用户任务（用任务语言，不用菜单名），例如「半夜远程开调奶」「补记一次喂奶量」。

### 阶段 1：公开信息采集

对每个竞品用联网搜索/公开页收集：应用商店简介与截图说明、近期更新日志、官网/帮助中心卖点。只记与**本次功能点**相关的内容。

### 阶段 2：用户评论筛功能

从商店评论、公开讨论中筛选**功能相关**句，忽略纯刷分/物流/客服无关抱怨（除非指向 App 能力）。关注：

- 有什么 / 没有什么
- 好用或难用的具体步骤
- 使用场景（谁、何时、为何）
- 反复提到的缺口或竞品对比句

评论 = 线索，不是最终事实。

### 阶段 3：功能假设清单

每条写：`能力描述 | 来源（链接或「评论摘要」） | 置信度（高/中/低）`。  
无截图时输出可先停在「假设 + 待截图确认项」，并明确告知用户。

### 阶段 4：截图校准（用户提供登录态截图后）

对每个功能点截图：

1. 先用一两句还原「当前交互/能力」（便于用户纠偏）
2. 确认入口、路径步数、文案、状态反馈、能力边界
3. 修正假设：标 **确认 / 部分确认 / 推翻 / 截图未见但评论提及**

多图按任务流串联，不割裂成纯画面审美。

### 阶段 5：分析与输出

严格按「输出结构」。有涉及的维度都写；没有证据的不硬凑。

## 分析维度

| 维度 | 写什么 |
|------|--------|
| 用户人群与需求 | 谁、什么场景、核心任务；未被满足的需求；与波咯咯用户（购机宝妈/宝爸）的重合与错位 |
| 体验优化点 | 路径、反馈、容错、可发现性、一手/碎片/中断、iOS 习惯冲突等 |
| 可创新 / 可差异化点 | 竞品弱或空白、育儿×设备交叉缝、我们能做深且对方难抄的点 |
| 功能现状对照 | 有 / 弱 / 强 / 无 + 证据（评论句或截图） |
| 定位滤镜 | 是否直接可比；不可比处标明 |
| 行动建议 | **可借鉴 / 可差异化 / 可忽略**，尽量带优先级（P0/P1/P2） |

可选（有材料再写）：信任与安全（账号/隐私/误操作）、生态耦合与迁移成本、内容 vs 工具 vs 控制 的类型判断。

## 输出结构（必须按此顺序）

### 1. 结论摘要

短句直接给：

- **人群需求**：1–3 条
- **体验优化**：1–3 条
- **创新 / 差异化**：1–3 条
- **证据状态**：仅公开+评论（待截图） / 已截图校准

### 2. 证据与校准

- 公开与评论发现了什么
- 截图确认 / 推翻了什么（无截图则列「待确认清单」）

### 3. 分竞品深剖（按本次功能点）

每个竞品一小节：定位与人群 → 该功能怎么做 → 需求/体验/差异化线索 → 与波咯咯关系（直接竞品 / 间接 / 参考）。

### 4. 对照表

| 用户任务 | 波咯咯 | 竞品A | 竞品B | … |
|----------|--------|-------|-------|---|
| … | 有/弱/强/无 + 一句说明 | … | … | … |

### 5. 行动建议

| 类型 | 项 | 优先级 | 理由 |
|------|----|--------|------|
| 可借鉴 | … | P0/P1/P2 | … |
| 可差异化 | … | … | … |
| 可忽略 | … | — | … |

## 证据与表述纪律

- 区分 **已证实（截图/官方）**、**评论提及**、**推断**；推断须标明。
- 禁止假装装机实测；无登录态证据不得写死「当前版本一定有/无」。
- 默认竞品名单与评论筛选细则见 [reference.md](reference.md)。
- 用户新增竞品时并入当次分析；不擅自删改默认名单，除非用户要求更新 skill。

## 边界

- 不替代完整可用性测试或市场调研报告。
- 不做整 App 功能大全，除非用户明确要求扩大范围。
- 不在此 skill 内交付交互 Demo（交给 `app-interaction-review`）。
- 商城等未上线能力：可对标竞品并标「我方规划中」，避免写成已有能力。