Imported from yunshu0909/yunshu_skillshub (
product-naming/SKILL.md). Install upstream withnpx skills add yunshu0909/yunshu_skillshub --skill product-naming. Copyright stays with the author.
用户想给产品、项目或模块起一个名字，但还没想好叫什么。通过结构化的协作流程，从产品本质出发推导名字，而不是直接列一堆候选词让用户挑。
核心原则
- 先想清楚再起名 — 没有理解产品灵魂之前，绝不列候选名字
- 名字是推导出来的，不是拼凑出来的 — 从产品定位、用户画像、品牌气质中自然推导
- 给路线，不给列表 — 先让用户选命名方向，再在方向内发散具体名字
- 用数据验证直觉 — 调研同赛道产品的命名规律，避免闭门造车
- 不催不赶 — 名字是品牌的根基，值得花时间想清楚
工作流程
第 1 步：产品灵魂挖掘（不碰名字）
这一步的目标是理解产品的本质，而不是收集功能列表。
主动了解项目背景（读代码、读文档），然后向用户追问以下问题：
- 用户是谁？ — 什么人在用？什么场景下用？使用频率？
- 产品本质 — 用一句话介绍这个产品是什么？（不是功能列表，是角色/定位/比喻）
- 产品边界 — 做什么、不做什么、未来往哪个方向长？
- 品牌气质 — 用户看到这个名字时，应该有什么第一反应？（专业/亲切/极客/轻松/...）
- 硬性约束 — 语言偏好？长度限制？需要避开的词？
关键：如果用户给出一个比喻（比如"像 Jarvis"），一定要深挖这个比喻背后的含义——它揭示的是用户对产品角色的想象。
禁止：
- 读完项目文档就开始列名字
- 问一个问题就觉得够了，必须把以上问题都覆盖到
- 把这些问题当表单一次性丢给用户，应该是自然对话
第 2 步：命名约束提取
从第 1 步的回答中提取：
- 关键词 — 从用户的描述中提炼核心语素（如：编程、助手、伙伴、工具、管理）
- 识别张力 — 用户的多个诉求之间是否存在矛盾？（如"要像人名一样有温度" vs "一眼看出跟编程有关"）
- 明确优先级 — 如果有张力，哪个诉求优先？
向用户展示你的分析，确认理解无误。
示例：
你的核心诉求：
- ✅ 让人知道跟团队协作有关
- ✅ 轻松不严肃，不像企业软件
- ⚡ 这两个有张力：协作类名字容易显得"企业味重"，轻松的名字又容易看不出用途
我的判断是"轻松感"优先，因为你要跟 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？
- 理由是什么？
示例：
调研发现同赛道的 Geekbot、Range、Standuply 都只用一个英文名。
建议：只用 Ping，不另起中文名。
理由：用户是开发团队，日常沟通已经用英文工具；一个音节最好记。
如果需要中文场景，加 slogan："Ping — 轻拍一下，站会搞定"
禁止：不做调研就建议命名策略，所有建议必须有数据支撑。
第 6 步：最终确认
汇总整个过程的决策链路，输出最终结论：
📌 产品名称：Ping
📌 Slogan：轻拍一下，站会搞定
📌 命名策略：纯英文单品牌
📌 决策依据：
- 用户画像：远程开发团队
- 产品定位：替代每日站会的异步同步工具
- 核心约束：轻松不严肃，一看就想用
- 竞品惯例：同赛道主流为纯英文短名称
沟通规范
必须问用户的
| 时机 | 问什么 |
|---|---|
| 第 1 步 | 用户画像、产品本质、产品边界、品牌气质、硬性约束 |
| 第 3 步 | 选哪条路线 |
| 第 4 步 | 倾向哪个具体名字 |
| 第 5 步 | 命名策略是否认同（几个名字、要不要 slogan） |
| 第 6 步 | 最终确认 |
不需要问用户的
| 事项 | 直接做 |
|---|---|
| 读项目文档了解背景 | 直接读，带着理解去问用户 |
| 竞品调研 | 直接搜索，带着数据给建议 |
| 分析诉求之间的张力 | 直接分析，向用户确认判断 |
AI 绝不应该做的
- 读完项目文档就甩一个名字列表
- 没有理解产品本质就开始起名
- 只从"好不好听"角度评价名字，不从品牌策略角度分析
- 用户说"不好"的时候换一批名字再来，而不是反思流程哪里出了问题
- 为了显得专业而列过多选项，造成选择瘫痪
- 催用户赶快做决定
