# Product Naming

产品命名协作流程。当用户想给产品/项目/模块起名字时使用。通过"灵魂挖掘 → 约束提取 → 路线发散 → 方向选择 → 竞品验证 →...

- Repository: https://github.com/yunshu0909/yunshu_skillshub (788 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-10-11
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add yunshu0909/yunshu_skillshub --skill product-naming -g -a claude-code -y`
Codex: `npx skills add yunshu0909/yunshu_skillshub --skill product-naming -g -a codex -y`
Cursor: `npx skills add yunshu0909/yunshu_skillshub --skill product-naming -g -a cursor -y`
Gemini CLI: `npx skills add yunshu0909/yunshu_skillshub --skill product-naming -g -a gemini-cli -y`

## Description

产品命名协作流程。当用户想给产品/项目/模块起名字时使用。通过"灵魂挖掘 → 约束提取 → 路线发散 → 方向选择 → 竞品验证 → 最终确认"的结构化流程，从模糊想法产出有品牌生命力的名字，避免拍脑袋起名。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

用户想给产品、项目或模块起一个名字，但还没想好叫什么。通过结构化的协作流程，从产品本质出发推导名字，而不是直接列一堆候选词让用户挑。

## 核心原则

- **先想清楚再起名**, 没有理解产品灵魂之前，绝不列候选名字
- **名字是推导出来的，不是拼凑出来的**, 从产品定位、用户画像、品牌气质中自然推导
- **给路线，不给列表**, 先让用户选命名方向，再在方向内发散具体名字
- **用数据验证直觉**, 调研同赛道产品的命名规律，避免闭门造车
- **不催不赶**, 名字是品牌的根基，值得花时间想清楚

## 工作流程

### 第 1 步：产品灵魂挖掘（不碰名字）

这一步的目标是理解产品的本质，而不是收集功能列表。

主动了解项目背景（读代码、读文档），然后向用户追问以下问题：

1. **用户是谁？**, 什么人在用？什么场景下用？使用频率？
2. **产品本质**, 用一句话介绍这个产品是什么？（不是功能列表，是角色/定位/比喻）
3. **产品边界**, 做什么、不做什么、未来往哪个方向长？
4. **品牌气质**, 用户看到这个名字时，应该有什么第一反应？（专业/亲切/极客/轻松/...）
5. **硬性约束**, 语言偏好？长度限制？需要避开的词？

**关键**：如果用户给出一个比喻（比如"像 Jarvis"），一定要深挖这个比喻背后的含义, , 它揭示的是用户对产品角色的想象。

**禁止**：
- 读完项目文档就开始列名字
- 问一个问题就觉得够了，必须把以上问题都覆盖到
- 把这些问题当表单一次性丢给用户，应该是自然对话

### 第 2 步：命名约束提取

从第 1 步的回答中提取：

1. **关键词**, 从用户的描述中提炼核心语素（如：编程、助手、伙伴、工具、管理）
2. **识别张力**, 用户的多个诉求之间是否存在矛盾？（如"要像人名一样有温度" vs "一眼看出跟编程有关"）
3. **明确优先级**, 如果有张力，哪个诉求优先？

向用户展示你的分析，确认理解无误。

```
示例：
你的核心诉求：
- ✅ 让人知道跟团队协作有关
- ✅ 轻松不严肃，不像企业软件
- ⚡ 这两个有张力：协作类名字容易显得"企业味重"，轻松的名字又容易看不出用途

我的判断是"轻松感"优先，因为你要跟 Slack/钉钉竞争的是体验而非功能。对吗？
```

**禁止**：跳过分析直接出名字。这一步是从"感觉"到"逻辑"的关键桥梁。

### 第 3 步：路线发散

基于约束分析，推导出 **2-4 条命名路线**，每条路线代表一种不同的命名策略。

每条路线包含：
- **路线名称**, 一句话概括这条路的思路
- **2-3 个示意名字**, 让用户感受这个方向的味道
- **优缺点**, 诚实说明每条路的利弊

```
示例：
路线 A：拟声/动作词
示意：Ping、Holler、Nudge
✅ 轻快、有画面感
❌ 不直接关联"站会"场景

路线 B：时间/节奏隐喻
示意：DayBeat、MorningSync、Cadence
✅ 暗示每日节奏，贴合站会频率
❌ 偏长，组合感强

路线 C：缩写/造词
示意：Stanly（standup + daily）、Asynco（async + co）
✅ 独特好注册
❌ 需要解释含义
```

**禁止**：
- 只给一条路线
- 路线之间差异太小
- 不说缺点，只说好话
- 在这一步列超过 5 个具体名字/路线（让用户选方向，不是选名字）

### 第 4 步：用户选择方向

用户可以：
- 直接选一条路线
- 组合多条路线的元素（"C 的直接 + A 的温度"）
- 全部否掉，补充新方向 → 回到第 3 步

选定方向后，在该方向内深挖 **3-5 个具体候选名字**，每个附带一句话解释。

**禁止**：用户选了方向之后还在其他方向上发散。聚焦。

### 第 5 步：竞品验证 + 命名策略

用户倾向某个名字后，做两件事：

#### 5a. 竞品命名调研

搜索同赛道产品的命名规律：
- 纯英文 / 中英文双品牌 / 纯中文，哪种多？
- 名字长度？音节数？
- 有没有撞名风险？

#### 5b. 命名策略确认

基于调研结果，向用户建议：
- 需要几个名字？（英文名 + 中文名？还是只要一个？）
- 要不要 slogan？
- 理由是什么？

The rest: https://github.com/yunshu0909/yunshu_skillshub/blob/HEAD/brand/product-naming/SKILL.md