product-naminglisted

用户想给产品、项目或模块起一个名字，但还没想好叫什么。通过结构化的协作流程，从产品本质出发推导名字，而不是直接列一堆候选词让用户挑。 ## 核心原则 - **先想清楚再起名** — 没有理解产品灵魂之前，绝不列候选名字 - **名字是推导出来的，不是拼凑出来的** — 从产品定位、用户画像、品牌气质中自然推导 - **给路线，不给列表** — 先让用户选命名方向，再在方向内发散具体名字 - **用数据验证直觉** — 调研同赛道产品的命名规律，避免闭门造车 - **不催不赶** — 名字是品牌的根基，值得花时间想清楚 ## 工作流程 ### 第 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 个具体名字/路线（让用户选方向，不是选名字）