The user wants to give a product, project, or module a name, but hasn't figured out what to call it yet. Through a structured collaborative process, derive the name from the essence of the product, rather than directly listing a bunch of candidate words for the user to choose from.
Core Principles
- Think it through before naming — Before understanding the soul of the product, never list candidate names
- Names are derived, not pieced together — Naturally derived from product positioning, user persona, and brand temperament
- Give routes, not lists — First let the user choose a naming direction, then diverge into specific names within that direction
- Validate intuition with data — Research the naming patterns of products in the same track, avoiding building in isolation
- Don't rush, don't push — A name is the foundation of a brand and is worth taking the time to think through clearly
Workflow
Step 1: Product Soul Mining (Don't touch names)
The goal of this step is to understand the essence of the product, not to collect a feature list.
Proactively learn the project background (read the code, read the docs), then ask the user the following questions:
- Who are the users? — Who uses it? In what scenarios? How often?
- Product essence — Describe what this product is in one sentence? (Not a feature list, but a role/positioning/metaphor)
- Product boundaries — What it does, what it doesn't do, and in which direction it will grow in the future?
- Brand temperament — When users see this name, what should their first reaction be? (Professional/friendly/geeky/relaxed/...)
- Hard constraints — Language preference? Length limit? Words to avoid?
Key: If the user gives a metaphor (for example, "like Jarvis"), be sure to dig deep into the meaning behind this metaphor—what it reveals is the user's imagination of the product's role.
Prohibited：
- Start listing names right after reading the project docs
- Feel that one question is enough; you must cover all the above questions
- Throw these questions at the user all at once like a form; it should be a natural conversation
Step 2: Naming Constraint Extraction
Extract from the answers in Step 1:
- Keywords — Distill the core morphemes from the user's description (such as: programming, assistant, partner, tool, management)
- Identify tensions — Are there contradictions among the user's multiple demands? (Such as "should be as warm as a person's name" vs "should be obvious at a glance that it's related to programming")
- Clarify priorities — If there is tension, which demand takes priority?
Show the user your analysis and confirm that your understanding is correct.
示例：
你的核心诉求：
- ✅ 让人知道跟团队协作有关
- ✅ 轻松不严肃，不像企业软件
- ⚡ 这两个有张力：协作类名字容易显得"企业味重"，轻松的名字又容易看不出用途
我的判断是"轻松感"优先，因为你要跟 Slack/钉钉竞争的是体验而非功能。对吗？
Prohibited: Skip the analysis and directly produce names. This step is the key bridge from "feeling" to "logic".
Step 3: Route Divergence
Based on the constraint analysis, derive 2-4 naming routes, each route representing a different naming strategy.
Each route includes:
- Route name — a one-sentence summary of the approach of this route
- 2-3 illustrative names — let the user feel the flavor of this direction
- Pros and cons — honestly explain the advantages and disadvantages of each route
示例：
路线 A：拟声/动作词
示意：Ping、Holler、Nudge
✅ 轻快、有画面感
❌ 不直接关联"站会"场景
路线 B：时间/节奏隐喻
示意：DayBeat、MorningSync、Cadence
✅ 暗示每日节奏，贴合站会频率
❌ 偏长，组合感强
路线 C：缩写/造词
示意：Stanly（standup + daily）、Asynco（async + co）
✅ 独特好注册
❌ 需要解释含义
Forbidden：
- Only give one route
- The differences between routes are too small
- Do not mention drawbacks, only say good things
- List more than 5 specific names/routes in this step (let the user choose a direction, not a name)
Step 4: The user chooses a direction
The user can:
- Directly choose one route
- Combine elements from multiple routes ("C's directness + A's warmth")
- Reject everything and add a new direction → return to Step 3
After the direction is chosen, dig deeper within that direction into 3-5 specific candidate names, each with a one-sentence explanation.
Forbidden: after the user has chosen a direction, still diverging into other directions. Focus.
Step 5: Competitor validation + naming strategy
After the user leans toward a certain name, do two things:
5a. Competitor naming research
Search for the naming patterns of products in the same track:
- English only / bilingual Chinese-English branding / Chinese only, which type is more common?
- Name length? Number of syllables?
- Is there any risk of name collision?
5b. Naming strategy confirmation
Based on the research results, suggest to the user:
- How many names are needed? (English name + Chinese name? Or only one?)
- Do you want a slogan?
- What is the reasoning?
示例：
调研发现同赛道的 Geekbot、Range、Standuply 都只用一个英文名。
建议：只用 Ping，不另起中文名。
理由：用户是开发团队，日常沟通已经用英文工具；一个音节最好记。
如果需要中文场景，加 slogan："Ping — 轻拍一下，站会搞定"
Forbidden: suggesting a naming strategy without doing research; all suggestions must be supported by data.
Step 6: Final confirmation
Summarize the decision chain of the entire process and output the final conclusion:
📌 产品名称：Ping
📌 Slogan：轻拍一下，站会搞定
📌 命名策略：纯英文单品牌
📌 决策依据：
- 用户画像：远程开发团队
- 产品定位：替代每日站会的异步同步工具
- 核心约束：轻松不严肃，一看就想用
- 竞品惯例：同赛道主流为纯英文短名称
Communication guidelines
Must ask the user
| Timing | What to ask |
|---|---|
| Step 1 | User profile, product essence, product boundaries, brand temperament, hard constraints |
| Step 3 | Which route to choose |
| Step 4 | Which specific name do you lean toward |
| Step 5 | Whether you agree with the naming strategy (how many names, whether a slogan is needed) |
| Step 6 | Final confirmation |
No need to ask the user
| Item | Do directly |
|---|---|
| Read project documents to understand the background | Read directly, then ask the user with understanding |
| Competitor research | Search directly, then give suggestions with data |
| Analyze the tension between demands | Analyze directly, then confirm the judgment with the user |
What AI should never do
- Dump a list of names right after reading the project documents
- Start naming without understanding the essence of the product
- Evaluate names only from the perspective of "whether they sound good," not from the perspective of brand strategy
- When the user says "not good," switch to another batch of names instead of reflecting on where the process went wrong
- List too many options just to appear professional, causing choice paralysis
- Rush the user to make a decision