how-they-built-it

---
name: how-they-built-it
description: 拆解竞品 App / 网页是怎么做出来的，产出能直接照着做的规格与分析。三种入口都用本技能——拆这个（觉得某产品或某一屏好，要机制和规格）、帮我找（要做某一屏没思路，要三个参考的对比与建议，web 与 App 一起找）、功能调研（要做某个功能，先去调研竞品怎么做的，产出需求分析 + 功能分析 + 技术剖解）。以下全都应该使用：①点了名的——「分析一下 XX 的登录页」「Notion 的首页信息结构拆一下」；②没点名、要找思路的——「我要做空状态页，没想法」「同类产品的付费墙都怎么设计」；③只问一个机制细节的——「那个背景是视频还是静态图」「这个转场到底多长时间」；④只有感受没有对象的——「我们的界面看起来很廉价，对手看着就贵，差在哪」；⑤要做某个功能先调研的——「我们要做自动分章节，先看看竞品怎么做的」「这个功能帮我出一份需求和功能分析」；⑥⭐口语化追问实现细节的（不带「分析/调研」这类动词、也不点名产品，一样要用）——「他们那个转写是端侧还是云端」「这块是自己做的还是用的现成方案」「那个功能到底做到什么程度」「他们怎么实现的」。英文同理（analyse how X built their sign-in screen / help me find ideas for an onboarding flow / research how competitors implement <feature> / is their transcription on-device or cloud）。核心价值是把「看起来很高级」「他们怎么做到的」拆成可量化、可追溯到证据的机制（动效节奏、渐变结构、资源类型、色彩规格、原生库、第三方 SDK、接口结构），⛔ 而不是停在主观描述或猜测。⛔ 不要用于给我方从零做设计、改我方文案配色、修我方页面 bug、竞品的定价与商业策略调研。涉及下载安装包、在竞品 App 上产生真实数据、或提取竞品资源时会先征求授权。
---

# 竞品 UI 逆向拆解

## 这个技能解决什么问题

你看到竞品某一屏很好看，想知道怎么做的。凭肉眼看只能得出「它用了大图和柔和的光」这种没法落地的结论，
而且**大概率是错的** —— 一个 2.7 秒的缓动交叉溶解，肉眼会读成「每 2.5 秒换一张，淡入淡出 0.6 秒」。

本技能的做法是：**能测的一律测，不能测的标明是推断**。资源类型从安装包读，动效节奏从录屏算，
颜色和渐变结构从像素取。最后产出的是别人能照着做的规格，不是形容词。

## 流程

分五步。**每一步都可以单独停下来交付**，不必每次都走完 —— 用户只想要参考方向时，第 1 步就够了。

### 1. 先分清是哪种活，再找候选

用户来找你，只有两种开头：

| 入口 | 用户的话长什么样 | 产出 |
|---|---|---|
| **A. 拆这个** | 「XX 的付费墙做得真好，拆一下」「他们那个转场怎么做的」 | **一屏的规格**（第 5 步 A 模板） |
| **B. 帮我找** | 「我要做空状态页，没思路」「同类产品的 onboarding 都怎么做的」 | **对比简报**：三个做得好的 + 各自机制 + 建议走哪条（第 5 步 B 模板）；用户选定一个之后再回到 A 深拆 |
| **C. 功能调研** | 「我们要做自动分章节，先去调研一下」「这个功能竞品是怎么做的，帮我出需求和功能分析」 | **需求分析 + 功能分析 +（按需）技术剖解**，见 §C 与 `references/feature-research.md`。⚠️ 这一档**精度要求最高**，每条结论必须挂证据标签 |

⛔ B 模式最常见的错误是**找到一个就开拆**。用户没思路时要的是**方向**，不是某一屏的像素值——
先给三条路和取舍，让人选，选完再拆透。

**A 模式**：用户已经点名 → 直接进第 2 步。

**B 模式**：先问清楚**要做哪一屏**（登录 / 引导 / 付费墙 / 列表 / 空状态 / 设置…）和**在意什么**
（视觉质感 / 动效 / 信息结构 / 转化 / 无障碍），然后**web 和 App 一起找**，不要只找一端——
同一个问题在两端常有不同解法，对比出来的差异本身就是思路。**从最容易拿到一手证据的开始**：

| 来源 | 端 | 价值 | 怎么取 |
|---|---|---|---|
| ⭐ **用户设备上已装的同类 App** | App | 最高 | `adb shell pm list packages -3`。往往已经躺着三五个同品类产品，**不用下载、不用授权** |
| 应用商店同品类榜单 + 截图 | App | 高 | 榜单靠前 ≈ 有预算做设计。`https://itunes.apple.com/search?term=<关键词>&entity=software&limit=25` 直接返回 `screenshotUrls`——**不装 App 就能先看截图筛人** |
| 用户点名的 / 品类头部产品的**官网与 web 端** | Web | 高 | 样式明文，取值零成本（`references/web.md`）。⚠️ 官网 ≠ App，两者常不是一套设计，⛔ 别拿官网结论去描述 App |
| 设计奖项站（awwwards / godly / siteinspire / lapa） | Web | 中 | 上榜的都是**真实上线**的站，能打开、能交互。适合找「这一屏的视觉方向」 |
| 截图库（Mobbin / screenlane / pageflows） | 双端 | 中 | 按屏幕类型归好类的真实产品截图，**找方向快**；但是截图不是实测，动效、资源类型看不出来，⛔ 只用来筛候选 |
| 设计社区（Dribbble / Behance） | — | ⚠️ 低 | **大多是没有工程约束的概念稿**——没有真实文案长度、多语言、加载态、错误态。只当情绪板，⛔ 不当规格来源 |

判断一个参考是否可信，只看一条：**它是不是真的发行了、能不能真的打开用**。
能，它的每个决定都经受过真实约束；不能，它只是一张好看的图。

**筛到三个就停。** 两三个拆透，远胜十个泛泛而谈。三个里最好**有 web 也有 App**。

授权边界在这一步不变：**找**是免费的（列表、商店截图、打开网页都不需要授权）；
要**下安装包 / 解包**才进第 3 步问用户。

### 2. 真机实测（网页产品见下方提示）

这一步不可跳过。资源清单能告诉你「有什么」，只有真机能告诉你「这个资源用在哪一屏」——
两者的差别是本技能最容易翻车的地方（见 `references/pitfalls.md` 第 1 条）。

```bash
python3 scripts/preflight.py        # 先看缺什么：ffmpeg / adb / aapt / 设备，缺的直接给安装命令
adb devices -l                      # 确认设备
adb shell pm list packages -3       # 已装的三方应用
adb shell monkey -p <pkg> -c android.intent.category.LAUNCHER 1
adb exec-out screencap -p > shot.png
adb shell screenrecord --time-limit 12 --bit-rate 12000000 /sdcard/rec.mp4
adb pull /sdcard/rec.mp4 .
```

有动效就**录屏**，别只截图。静态截图看不出节奏，而节奏往往就是质感的来源。

⭐ **入场动效要冷启动才录得到**，而且必须**先起录、后启动**：

```bash
adb shell am force-stop <pkg>
adb shell screenrecord --time-limit 14 /sdcard/rec.mp4 &   # 先起录
sleep 1.5 && adb shell monkey -p <pkg> -c android.intent.category.LAUNCHER 1
```

App 已经停在那一屏的时候录多久都是静止的 —— 实测录满 14 秒、峰值 0.14，
差点判成「纯静态」，冷启动重录才看到 0.55 秒淡入 + 0.10 秒硬切（`pitfalls.md` 第 12 条）。
**两段都要录**：冷启动看入场，停住看有没有循环。

设备是共用的时候先看一眼有没有别的会话在用（`adb shell ps -A | grep <pkg>`），
⛔ 别把别人正在跑的测试挤掉。

> **拆的是 iOS 产品的话，先把话说在前面：第 3 步（资源清单）做不了。**
> 非越狱设备拿不到 IPA，而资源清单正是本流程里最决定性的一步 ——
> 「背景到底是视频还是几张静态图」这个问题在 iOS 上**只能推断，不能实测**。
>
> iOS 上仍然成立的：录屏 → `frame_diff.py`（时长、曲线、节奏），截图 → `image_probe.py`
> （颗粒、渐变结构、色值、对比度）。也就是**「怎么动」和「什么颜色」能量，「用什么做的」不能**。
> 输出报告时这一条必须落在三态里记 `SKIP(未验)`，⛔ 不许写成实测。
>
> ⚠️ `ipatool` 一类的工具需要登录用户自己的 Apple ID 去下载，触及商店账号，
> 本技能**不替用户操作商店账号**（见下方边界表）。要走这条路请用户自己决定并自己执行。

> **拆的是网页的话，第 2–4 步换一条路走：网页的样式是明文的，规格可以直接读出来，
> 不需要从像素反推。** 渐变定义、动效时长与缓动曲线、字阶、design token 全都能一行 JS 取到 ——
> 见 `references/web.md`。⛔ 别对网页录屏算帧差分，那是 App 才需要的迂回手段。

### 3. 取安装包（需要授权）

**这一步必须先问用户。** 下载和解包安装包是有实际影响的动作，且涉及竞品资产：

取包有三档，**按这个顺序试**，⛔ 不要跳过前两档直接下载：

| 档 | 做法 | 授权 |
|---|---|---|
| **1. 设备上已装** | `adb shell pm path <pkg>` 拿路径后 `adb pull` | 不产生新下载，**首选**。版本就是真机正在跑的那个，天然可信 |
| **2. 公开渠道下载** | 应用市场的网页版、APKMirror / APKPure / apkcombo 一类的公开镜像 | ⚠️ **先问用户**。只下**免费**应用。下完**必须核版本**，见下 |
| **3. 驱动用户的商店账号** | 登录用户的 Google / Apple 账号去下 | ⛔ **绝不**。付费应用、绕地区限制、破解，同样 ⛔ |

第 2 档和第 3 档的区别是**动不动用户的账号**：从公开镜像下一个免费 APK 不碰任何人的账号，
和用浏览器打开一个网页没有本质区别；替用户登录商店去下载是另一回事。⛔ 别把两者混成一句
「不许下载」—— 那会让设备上没装的产品**整个 App 端都拆不了**。

询问第 2 档的时候把话说清楚，例如：
> 设备上没装 X。要看它的资源构成得拿到安装包——**我从公开镜像下一个免费版本**，
> 只读资源的类型和结构，不提取素材、不进仓库。也可以你自己在设备上装好我从设备里拉。哪种都行？

### ⛔ 下载来的包必须核版本，⛔ 不核就别拆

镜像站的包**不等于**商店现在在发的包：可能是几年前的旧版（拆出来的是过期的设计，
结论全错），也可能被二次打包（塞了广告 SDK，资源清单里多出原版没有的东西）。

```bash
aapt dump badging <apk> | head -1     # package name / versionCode / versionName
```

**判据按可信度排**：

1. ⭐ **设备上装着官方版** → 把设备那份也 `adb pull` 下来，两个 `aapt dump badging` 对比。
   版本号一致、资源条目数量级一致，才算同一个东西
2. 版本号对得上商店列表页当前版本 —— 差一两个小版本可以接受，**差一个大版本就重下**
3. `apksigner verify --print-certs <apk>` 比签名指纹。最严格，但**需要真的 JRE**
   （2026-09-20 实测：macOS 自带的 `/usr/bin/java` 是个桩，直接报 "Unable to locate a Java Runtime"），
   而且 v2/v3 签名的包里没有 `META-INF/*.RSA`，⛔ 纯脚本取不到签名

⚠️ 三条都做不到 ⇒ 在报告里记 `PLAUSIBLE(包来源未核)`，⛔ 不许当成实测。

拿到 APK 后：

```bash
python3 scripts/apk_assets.py app.apk                  # 全局清单 + 按屏分组
python3 scripts/apk_assets.py app.apk --screen login   # 只看某一屏
python3 scripts/apk_assets.py app.apk --extract login bg_loop --out ./probe
```

这一步通常能一击命中：**背景到底是视频、帧序列、Lottie，还是几张静态图在交叉溶解**，
清单上一目了然，而这件事在运行的 App 里是看不出来的。

⚠️ 两条实测出来的用法约束：

- **`pm path` 返回多行是常态**（实测 10 个 App 里 9 个是 split APK）。
  **做视觉拆解时拿 `base.apk` 就够** —— 六个 App 实测，资源体积的 99%+ 都在 base 里，
  density/语言 split 只有 0.1MB 级别的零头。
  ⛔ **但做功能 / 技术调研（C 档）必须把 ABI split 一起拉** —— 原生库全在
  `split_config.<abi>.apk`，`base.apk` 里**一个 `.so` 都没有**（实测三个 App 全是如此）。
- **屏幕桶是线索，不是清单。** 它是关键词启发式，召回永远不全。
  先不带 `--screen` 跑一遍看按类型的总量，再用**你自己产品的词汇**去 grep 路径
  （做录音笔就搜 `cable` / `sync` / `charge` / `firmware`）。见 `pitfalls.md` 第 14 条。

### 4. 量化分析

三个脚本对应三类问题。它们只依赖 `ffmpeg`/`ffprobe` 和 Python 标准库。

**动效节奏** —— 它到底多久变一次、怎么变的：
```bash
python3 scripts/frame_diff.py rec.mp4 --crop 1080x1200+0+200
```
`--crop` 很重要：把固定不动的 UI（按钮、状态栏）切掉，否则闪烁的时钟会被算成「动效」。
输出会给出静止段、运动段、周期长度，以及差分曲线的形状 —— 钟形是缓动，平台是线性，尖峰是硬切。

⛔ **脚本开头若打印了采样率告警，先按它给的 `--fps` 重跑再读结论**：采样率不整除源帧率时，
无纹理的渐变背景会被劈出假的静止段，`NOT A LOOP` 可能是假的（`pitfalls.md` 第 30 条）。
⭐ 要报数字优先报 **cycle length**（对边界误差免疫）；**转场时长读数是下界**，真值更长。

**图像是怎么做的** —— 有没有颗粒、光在哪、颜色怎么排：
```bash
python3 scripts/image_probe.py bg.png --grid 9x20 --contrast '#1E2C28,#5C756F'
```
最有价值的两个输出：**颗粒判定**（决定这张图能不能用纯代码画出来，省掉整个素材）
和**降采样网格**（一眼看出光斑贴边还是居中、底部有没有转灰）。

⛔ **`--contrast` 要喂解包出来的背景素材，不要喂截图** —— 截图上的文字本身就是最暗的像素，
脚本会拿文字去和文字比（实测把 `#111111` 标题判成 `FAIL 1.06`）。见 `pitfalls.md` 第 10 条。
另外 `chroma peak` 在**浅色背景**上指的是**最深的那一端，不是光斑** —— 脚本现在会自己说明是哪种。

**资源构成** —— 见第 3 步的 `apk_assets.py`。

⚠️ 每个脚本的结论都要**回到画面上确认一次**。数字告诉你「有 2.7 秒在变化」，
但「是交叉溶解还是镜头移动」得抽帧看：静止点清晰 + 峰值点重影 = 溶解。
### C. 功能调研（需求 / 功能 / 技术）

A、B 两档拆的是**一屏长什么样**；C 档拆的是**一个功能怎么运转**。难点完全不同：
视觉有像素可量，功能行为和技术实现**没有证据就全是猜**，而猜出来的东西看起来和实测一模一样。
所以这一档的核心不是流程，是**证据纪律**。

⛔ **进入这一档先读 `references/feature-research.md`**（C.0–C.4 全流程）。

在读它之前，这三条先生效，⛔ 少了任何一条都不许往下走：

- ⛔ **每条结论必须挂标签**：`[真机]` 亲眼看到（附时间点）／`[包内]` 追溯到具体文件（附文件名）／
  `[推断]` 证据撑不住这句话（附一句话理由）。⛔ 无标签的句子不许进报告。
- ⭐ **`[包内]` ≠ 功能存在**。包里有字符串只证明**这些字节在包里**，不证明功能上线、可见、没被开关关掉。
  「他们有 X 功能」这种话必须有 `[真机]` 兜底。
- ⭐⭐ **架构类结论（端侧/云端、用了什么方案）默认 `[推断]`**，哪怕两个标签都齐 ——
  「没有端侧推理库」+「飞行模式下不可用」推不出「识别在云端」，本地识别一样可能卡在联网校验上。
  三态里一律 `PLAUSIBLE`，⛔ 不许记 PASS。

### 5. 输出设计要点

拆解的价值在于能落地。

**A 模式（拆这个）用这个结构**——单屏规格：

```markdown
# <产品> <屏幕> 拆解

## 实测结论
（每条都带证据：资源清单 / 帧差分数字 / 像素分析。推断要标明是推断）

## 它为什么好看
（拆成机制，不是形容词。「浅景深 + 斜构图 + 产品只占画面 15%」而不是「高级」）

## 我们能抄什么、不能抄什么
（区分开：机制可以借鉴；素材、品牌资产、具体画面⛔ 不能用）

## 落地规格
（具体到数值：时长、曲线、色值、尺寸、角度。别人照着就能做）

## 三态
（PASS 实测 / PLAUSIBLE 推断 / SKIP 未验。⛔ 不许把推断写成实测）
```

**B 模式（帮我找）用这个结构**——它是对比简报，不是单屏规格：

```markdown
# <要做的屏幕> 该怎么做：三个参考的对比

## 你的约束
（用户产品是什么、品牌、平台、这一屏要解决什么问题——⛔ 没问清楚别往下写）

## 三个参考（web + App 混合）
### 1. <产品> <端>
- 它怎么做的：一句话机制（「空状态 = 插画 + 一个主动作，没有次级入口」）
- 实测到的：（资源类型 / 时长 / 色值——有多少写多少，没测的不写）
- 它为什么这样做：（推断，标明）

### 2. …
### 3. …

## 共同点与分歧点
（三个都做的 = 这一屏的基线，别省；做法分叉的地方 = 真正要选的）

## 建议
（结合「你的约束」给一条路 + 为什么；另外两条什么情况下更合适）
⛔ 建议要落到具体：「走 1 的结构、用 3 的动效节奏」，不是「参考以上」

## 三态
（PASS 实测 / PLAUSIBLE 推断 / SKIP 未验——截图库来的全是 SKIP，别装成实测）

## 下一步
（选定之后回到 A 模式深拆哪一屏、要不要授权拿包）
```

**最后一节是必须的。** 拆解里一定会有测不到的东西（对方用什么工具做的、素材怎么来的），
把它们如实标出来，比假装全都知道有用得多。

## 授权与边界

这类工作会接触别家的产品资产，边界要守住，而且要**主动说明**而不是等人问：

| 行为 | 是否可以 |
|---|---|
| 分析实现机制、时长、色值、结构 | ✅ 这是本技能的目的 |
| 把机制写成我方规格并自己重做 | ✅ |
| 截图 / 抽帧用于分析与对照 | ✅ 标注「竞品分析用」 |
| **从公开渠道下载免费安装包** | ⚠️ **先征求用户同意**，下完核版本 |
| 替用户登录 / 操作商店账号 | ⛔ 绝不 |
| 下载付费应用 / 绕地区限制 | ⛔ 绝不 |
| 提取竞品素材用于我方产品 | ⛔ 绝不 |
| 把竞品素材提交进我方仓库 | ⛔ 绝不。归档只留自己做的分析图 |
| 绕过付费墙 / 破解 / 篡改客户端 | ⛔ 绝不。本技能只读公开发行的安装包 |

归档时在目录里放一个 README 写明来源和「仅供分析、禁止用作素材」，
免得几个月后有人翻到这些图当素材用了。

## 关键提醒

- **资源名里的屏幕名是权威的，你的印象不是。** `onboarding_*` 就是引导页的，不是登录页的。
  这一条单独写在 `references/pitfalls.md`，因为它造成的返工最多。
- **别机械套用。** 把竞品的蓝色换成你的绿色，可能同时换掉了对比度和视觉重量 —— 换完要重算。
- **抄机制，不抄形态。** 拆出来的应该是「慢溶解 2.7s」「光斑贴左边缘」这类规则，
  而不是把对方的画面复制一遍。
- **拆得再准，也代替不了自己的判断。** 竞品的方案适配的是竞品的产品、品牌和用户。
  最后一定要回答：**这条放到我们身上还成立吗？**

## 参考文件

- `references/feature-research.md` — **C 档（功能调研）全流程**：证据标签制度、提问清单、真机调研、包内取证、产出模板。⛔ 走 C 档前必读
- `references/pitfalls.md` — 踩坑清单（30 条）。**动手前先读**；绝大多数是真实发生过的事故，个别是设计时识别出的风险，条目里会自己说明
- `references/android.md` — 真机与安装包操作的完整命令、常见报错
- `references/web.md` — 网页产品的拆解方法（**能直接读明文规格，比 App 简单得多**）