product-naming

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

核心原则

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

工作流程

第 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？
• 理由是什么？

示例：
调研发现同赛道的 Geekbot、Range、Standuply 都只用一个英文名。
建议：只用 Ping，不另起中文名。
理由：用户是开发团队，日常沟通已经用英文工具；一个音节最好记。
如果需要中文场景，加 slogan："Ping — 轻拍一下，站会搞定"