how-they-built-itlisted
Install: claude install-skill DEOWL-kan/how-they-built-it
# 竞品 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 | 中 | 上榜的都是**真实上线**的站，能打开、能交互。适合找「这一屏的视觉方向」 |
| 截图