# Feature Teardown

> 功能级竞品拆解：这个功能别人家怎么做的、用户路径几步、他们为什么做、 我们现在是不是其实已经有了只是用户找不到、有没有别的解法。 触发词：竞品怎么做的、别人家怎么做的、有竞品吗、这个功能谁做过、拆一下竞品、 我们是不是已经有了、feature-teardown。 轻量前置动作，不出完整竞品简报；不查开源代码实现（那个用本套件的 prior-art）。

- Skill: `timi-fish/feature-teardown` (Agent Skill)
- Install (CLI): `npx skillmds@latest add timi-fish/feature-teardown`
- Raw SKILL.md: https://api.skillmd.com/api/skills/timi-fish/feature-teardown/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Timi-Fish (https://skillmd.com/u/timi-fish)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/timi-fish/feature-teardown

---


# Feature Teardown

一个功能想法或一句用户抱怨进来，五步之内给出结论：**抄谁 / 我们已经有了改入口就行 / 换个解法 / 真得做。**

## 边界

**管**：单个功能级别的对比。别人怎么做、为什么做、我们有没有、还能怎么做。

**不管**：

- 完整竞品简报（公司定位、pricing、win/loss、battle cards、market trend）→ 装有 product-management 插件时用其 competitive-brief，否则不在本 skill 范围
- 这个需求值不值得做的 KANO/RICE 结论 → [requirement-eval](../requirement-eval/SKILL.md)（本套件内）
- 方向还没定、要发散多个方向 → 推荐上游 [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills) 的 idea-refine
- 开源库/能抄的代码 → [prior-art](../prior-art/SKILL.md)（本套件内）

## 当前产品从上下文解析，不预设

第 4 步要盘点"我们现有能力"，"我们"指哪个产品**每次都要确认**：用户当场说的、项目文档、
项目根配置、对话上文。**没有默认产品，也不要沿用其它会话或其它任务里出现过的产品。** 缺就问一句，不猜。

如果这轮压根没有"我们"（纯个人新项目，还没有存量产品），第 4 步跳过并说明跳过了。

## 五步

### 1. 谁做过

分三层，别只看直接竞品：

- **直接** —— 同类产品的同一功能
- **间接** —— 用完全不同的形态解决同一个问题
- **替代** —— 不用软件怎么解决：Excel、手工流程、雇个人、**或者干脆啥也不做**

"啥也不做"是最容易漏的一个选项，也经常是真实答案。

### 2. 用户路径几步

不要停在"他们有这个功能"。写出从**触发**到**拿到结果**的完整步骤：

- 入口在哪（用户怎么发现的）
- 中间几步、每步要用户做什么决定
- 什么时候能看到结果、失败了怎么办

**步数和入口位置本身就是结论。** 同一个功能藏在三级菜单里和挂在首屏，是两个产品决策。

### 3. 为什么做（反推，不是事实）

从可查的东西倒推动机：改版记录 / 发布说明 / 帮助中心措辞 / 应用商店更新日志 /
社区和评论区吐槽 / 招聘 JD。

回答两个问题：**他们在服务哪类人**、**解决这类人的什么问题**。

**这一步的产出全部标成推断，不能当事实用。** 写「推测：…，依据：…」，
依据拿不出来就写「动机不明」，不要编一个合理的故事。

### 4. 自查：我们是不是已经有了 ⟵ 早退出闸门

先把需求升维：**这个功能在第一性原理上解决的是什么问题**（"要收藏功能" → "高频内容会被历史清理冲掉"）。
拿这个问题、而不是功能名，去核当前产品——同一个问题常常已经被另一个形态的功能解决了，按功能名查永远查不到。

核对必须有证据来源，按优先级：

1. **产品知识库**：按 [PRODUCT-CONTEXT 协议](../prd-writing/PRODUCT-CONTEXT.md)登记过知识库的，
   先去知识库里查现有能力和历史方案，再下结论
2. **拿升维后的问题反问用户**："现在用户遇到这个问题时是怎么解决的？有没有部分解决它的功能？"
3. 两者都没有 → 明确写「现状能力未核实」，不许凭空回答下面三问

有了证据再对着第 2 步的用户路径逐步核：

- 这条路径**我们能不能走通**？
- 能走通的话，是**能力问题**还是**发现路径问题**——用户不知道有、找不到、还是用了但不认为解决了？
- 不能走通的话，缺的是哪一步？

**结论是「已经有了，是入口/认知问题」就到此为止，不要往下走第 5 步、不要交给
[requirement-eval](../requirement-eval/SKILL.md)、更不要写 PRD。**
直接给改入口/改文案/加引导的建议，这轮就结束了。

这一步是整个 skill 最值钱的地方。跳过它的代价是白做一个功能。

### 5. 别的解法

只有第 4 步没早退时才做。不做这个功能，同一个问题还能怎么解决——
改现有功能、换交互形态、改默认值、加引导、或者判定这个问题不值得解。

## 输出

只写最终态。**不写调研过程，不列否掉的候选**，除非否掉的理由本身是结论。

```markdown
## 结论

<一句话，四选一：抄 X 的做法 / 我们已经有了，改的是入口 / 换 Y 解法 / 真得做，做 Z>

## 别人怎么做的

| 产品 | 类型（直接/间接/替代） | 用户路径 | 入口位置 | 访问日期 |
|---|---|---|---|---|

## 动机推断

- <产品>：推测服务 <人群> 的 <问题>；依据：<可查来源>

## 我们现在的状态

- 路径能否走通：
- 缺的是能力还是发现路径：
- 证据：

## 建议

<具体到做什么，不是"建议进一步调研">
```

## 反模式

- 只写"竞品 A 有这个功能"，不写路径几步、入口在哪
- 动机推断没标成推断，写得像事实
- **跳过第 4 步直接说"该做"** —— 这是这个 skill 存在的唯一理由
- 漏掉"替代方案"层，尤其是"啥也不做"
- 结论写成"各有优劣，供参考"，不给推荐
- 表里没有访问日期 —— 产品一改版整张表就过期了
- 越界去做 pricing、市场规模、win/loss