Agent skill · product strategy · aiskillstore
product-naming
产品命名协作流程。当用户想给产品/项目/模块起名字时使用。通过"灵魂挖掘 → 约束提取 → 路线发散 → 方向选择 → 竞品验证 → 最终确认"的结构化流程，从模糊想法产出有品牌生命力的名字，避免拍脑袋起名。
Why this skill is useful
Provides a structured naming process that incorporates brand strategy and competitor analysis, which the AI wouldn't reliably generate on its own.
What it needs
About 1k tokens when loaded. Last updated 2026-08-07. 405 stars on the source repository.
What this skill does
用户想给产品、项目或模块起一个名字，但还没想好叫什么。通过结构化的协作流程，从产品本质出发推导名字，而不是直接列一堆候选词让用户挑。 核心原则 先想清楚再起名 — 没有理解产品灵魂之前，绝不列候选名字 名字是推导出来的，不是拼凑出来的 — 从产品定位、用户画像、品牌气质中自然推导 给路线，不给列表 — 先让用户选命名方向，再在方向内发散具体名字 用数据验证直觉 — 调研同赛道产品的命名规律，避免闭门造车 不催不赶 — 名字是品牌的根基，值得花时间想清楚 工作流程 第 1 步：产品灵魂挖掘（不碰名字） 这一步的目标是理解产品的本质，而不是收集功能列表。 主动了解项目背景（读代码、读文档），然后向用户追问以下问题： 1. 用户是谁？ — 什么人在用？什么场景下用？使用频率？ 2. 产品本质 — 用一句话介绍这个产品是什么？（不是功能列表，是角色/定位/比喻） 3. 产品边界 — 做什么、不做什么、未来往哪个方向长？ 4. 品牌气质 — 用户看到这个名字时，应该有什么第一反应？（专业/亲切/极客/轻松/...） 5. 硬性约束 — 语言偏好？长度限制？需要避开的词？ 关键：如果用户给出一个比喻（比如"像 Jarvis"），一定要深挖这个比喻背后的含义——它揭示的是用户对产品角色的想象。 禁止： 读完项目文档就开始列名字 问一个问题就觉得够了，必须把以上问题都覆盖到 把这些问题当表单一次性丢给用户，应该是自然对话 第 2 步：命名约束提取 从第 1 步的回答中提取： 1. 关键词 — 从用户的描述中提炼核心语素（如：编程、助手、伙伴、工具、管理） 2. 识别张力 — 用户的多个诉求之间是否存在矛盾？（如"要像人名一样有温度" vs "一眼看出跟编程有关"） 3. 明确优先级 — 如果有张力，哪个诉求优先？ 向用户展示你的分析，确认理解无误。 禁止：跳过分析直接出名字。这一步是从"感觉"到"逻辑"的关键桥梁。 第 3 步：路线发散 基于约束分析，推导出 2-4 条命名路线，每条路线代表一种不同的命名策略。 每条路线包含： 路线名称 — 一句话概括这条路的思路 2-3 个示意名字 — 让用户感受这个方向的味道 优缺点 — 诚实说明每条路的利弊 禁止： 只给一条路线 路线之间差异太小 不说缺点，只说好话 在这一步列超过 5 个具体名字/路线（让用户选方向，不是选名字） 第 4 步：用户选择方向 用户可以： 直接选一条路线 组合多条路线的元素（"C 的直接 + A 的温度"） 全部否掉，补充新方向 → 回到第 3 步 选定方向后，在该方向内深挖 3-5 个具体候选名字，每个附带一句话解释。 禁止：用户选了方向之后还在其他方向上发散。聚焦。 第 5 步：竞品验证 + 命名策略 用户倾向某个名字后，做两件事： 5a. 竞品命名调研 搜索同赛道产品的命名规律： 纯英文 / 中英文双品牌 / 纯中文，哪种多？ 名字长度？音节数？ 有没有撞名风险？ 5b. 命名策略确认 基于调研结果，向用户建议： 需要几个名字？（英文名 + 中文名？还是只要一个？） 要不要 slogan？ 理由是什么？ 禁止：不做调研就建议命名策略，所有建议必须有数据支撑。 第 6 步：最终确认 汇总整个过程的决策链路，输出最终结论： 沟通规范 必须问用户的 时机 问什么 ------ -------- 第 1 步 用户画像、产品本质、产品边界、品牌气质、硬性约束 第 3 步 选哪条路线 第 4 步 倾向哪个具体名字 第 5 步 命名策略是否认同（几个名字、要不要 slogan） 第 6 步 最终确认 不需要问用户的 事项 直接做 ------ -------- 读项目文档了解背景 直接读，带着理解去问用户 竞品调研 直接搜索，带着数据给建议 分析诉求之间的张力 直接分析，向用户确认判断 AI 绝不应该做的 读完项目文档就甩一个名字列表 没有理解产品本质就开始起名 只从"好不好听"角度评价名字，不从品牌策略角度分析 用户说"不好"的时候换一批名字再来，而不是反思流程哪里出了问题 为了显得专业而列过多选项，造成选择瘫痪 催用户赶快做决定
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aiskillstore/product-naming