跨场景命名通用 Checklist 与决策树
核心发现：不同命名场景的最优策略差异巨大，但共享一套底层评估维度：可发音性、可记忆性、可搜索性、可注册性、跨文化安全性。本文提供一张决策树 + 分场景 Checklist，供实际命名项目直接使用。 信息源：综合前四篇调研的交叉分析
一、命名决策树
第一步：确定命名对象
你在命名什么？
│
├── 公司/品牌 ──────→ 场景 A
├── 产品/App ──────→ 场景 B
├── 功能/特性 ──────→ 场景 C
├── 插件/扩展/Skill ──→ 场景 D
└── 域名/URL slug ──→ 场景 E第二步：按场景确定策略权重
| 评估维度 | A. 公司品牌 | B. 产品/App | C. 功能 | D. 插件/Skill | E. 域名/URL |
|---|---|---|---|---|---|
| 品牌独特性 | ★★★★★ | ★★★★ | ★★★ | ★★★ | ★★ |
| 功能可读性 | ★★ | ★★★ | ★★★★★ | ★★★★ | ★★★★★ |
| 商标可注册 | ★★★★★ | ★★★★ | ★★ | ★ | ★ |
| 搜索可发现 | ★★ | ★★★★ | ★★ | ★★★★★ | ★★★★★ |
| 跨文化安全 | ★★★★★ | ★★★★ | ★★★ | ★★ | ★ |
| 口头传播性 | ★★★★ | ★★★★ | ★★★★★ | ★★★ | ★★ |
二、场景 A：公司/品牌命名 Checklist
流程
1. 命名简报 → 2. 方法论选择 → 3. 大规模生成（1000+）
→ 4. 筛选（100→20→5）→ 5. 法律审查 → 6. 消费者测试 → 7. 最终确定评估打分卡（每项 1-5 分）
| 维度 | 评估问题 | 分数 |
|---|---|---|
| 含义 | 名称是否传达品牌理念或价值主张？ | /5 |
| 独特性 | 在同行业中是否足够差异化？ | /5 |
| 发音 | 第一次看到就能正确读出来吗？ | /5 |
| 拼写 | 听到后能正确拼出来吗？ | /5 |
| 记忆 | 听一次后第二天还能想起来吗？ | /5 |
| 视觉 | 做成 logo 时视觉效果好吗？ | /5 |
| 延展 | 未来公司扩展业务时名称还适用吗？ | /5 |
| 域名 | .com 或合理替代域名可用吗？ | /5 |
| 商标 | 在目标市场的商标类别中可注册吗？ | /5 |
| 跨文化 | 在所有目标市场语言中无负面含义？ | /5 |
及格线：总分 ≥ 35 分进入候选池，≥ 40 分进入最终名单。
禁忌
- ❌ 不要用团队内部投票决定——这会选出”最不得罪人”而非”最好”的名称
- ❌ 不要以域名可用性为第一筛选标准——先选好名称再想办法获得域名
- ❌ 不要跳过跨文化检查——Mercedes-Benz “奔死”的教训
三、场景 B：产品/App 命名 Checklist
流程
1. 竞品命名分析 → 2. ASO 关键词研究 → 3. 生成候选（200+）
→ 4. 平台规则检查 → 5. 商店搜索测试 → 6. 最终确定命名公式
应用商店：品牌名 [分隔符] 功能关键词
- Calm – Meditation & Sleep
- Duolingo: Language Lessons
SaaS：单词名称（≤ 10 字符），功能由副标题和描述承载
检查清单
- 名称 ≤ 10 字符（高点击率区间）
- 包含品类核心关键词（标题或副标题中）
- 在目标应用商店搜索无直接同名竞品
- 满足平台字符限制（iOS: 30、Google Play: 50）
- 不含 “#1”、“FREE”、emoji 等违规元素
- 域名方案确定（精确 .com / 前缀 .com / 替代 TLD）
- 社交媒体 handle 统一方案确定
当前 SaaS 命名趋势（2024-2026）
| 趋势 | 做法 | 避免 |
|---|---|---|
| 动词/行动词 | Zoom、Notion、Linear | — |
| 单词名 | Slack、Figma、Vercel | 组合长名 |
| 意义优先 | 名称暗示价值 | 纯造词无含义 |
| — | — | -ly/-ify 后缀（已过度饱和） |
| — | — | “AI”/“Smart” 前缀（已泛滥） |
四、场景 C：功能/特性命名 Checklist
决策门槛
先回答这个问题：这个功能是否需要独立名称？
| 条件 | 需要独立名称 | 用描述标签即可 |
|---|---|---|
| 跨产品复用 | ✅ | — |
| 用户口头提及 | ✅ | — |
| 营销重点 | ✅ | — |
| 仅内部使用 | — | ✅ |
| 一次性功能 | — | ✅ |
| 设置/偏好项 | — | ✅ |
功能命名原则
| 原则 | 正面案例 | 反面案例 |
|---|---|---|
| 可动词化 | ”FaceTime me" | "Windows Defender me” |
| 暗示不限定 | Artifacts | Code Generator |
| 前缀建品类 | Air- = 无线族 | 每个功能独立命名无关联 |
| 层级一致 | Nano < Flash < Pro < Ultra | Pro 含义因产品而异 |
检查清单
- 名称是否可以自然地用在句子中？（“帮我 __ 一下”）
- 同一产品内的功能命名风格是否一致？
- 修饰词（Pro/Max/Ultra）含义是否与其他产品线一致？
- 内部代号是否已有替代的公开名称？
- 名称在所有目标市场语言中是否安全？
五、场景 D：插件/扩展/Skill 命名 Checklist
流程
1. 竞品分析 → 2. 搜索词研究 → 3. 生成候选（50+）
→ 4. 平台搜索测试 → 5. 包管理器名称检查 → 6. 最终确定命名公式
[品牌名（可选）] + [功能描述词] + [技术栈修饰（可选）]
案例：
- Prettier - Code Formatter
- uBlock Origin
- bb-browser
- art-of-questioning检查清单
- 名称包含至少一个功能关键词
- 2-4 个词，可口头说出
- 在目标商店/平台搜索无同名冲突
- npm/PyPI/GitHub 等包管理器名称可用
- 描述/README 包含所有功能关键词和触发词
- CLI 友好格式（全小写 + 连字符）
- 分类标签/topics 准确设置
按平台差异
| 平台 | 侧重点 | 名称格式 |
|---|---|---|
| VS Code | 功能清晰度 > 品牌 | PascalCase 或 kebab-case |
| Chrome | 功能关键词前置 | 自然语言 |
| npm/PyPI | 短 + 可记忆 | kebab-case |
| Claude Skill | 记忆度 > 搜索性 | kebab-case，2-3 词 |
六、场景 E：域名与 URL Slug Checklist
域名选择
- .com 可用？→ 优先获取
- .com 不可用？→ 尝试 get/use/go 前缀
- 考虑 .ai/.app/.dev 等替代 TLD
- 域名 ≤ 3 个词
- 无连字符、无数字
- 口头传播测试：说出来后对方能正确输入吗？
URL Slug
- 包含页面核心关键词
- 3-6 个词
- 连字符分隔
- 全小写
- 无停用词（a/the/and）
- 无日期/版本号
七、跨场景通用禁忌
| 禁忌 | 为什么 | 替代方案 |
|---|---|---|
| 团队投票选名 | 投票选出”最不得罪人”的平庸名 | 由简报标准客观评估 |
| 域名优先于名称质量 | 好名称 + 差域名 > 差名称 + 好域名 | 先选名后找域名方案 |
| 跳过跨文化检查 | 一个市场的笑柄可能毁掉全球品牌 | 每个目标市场都做母语者审查 |
| 名称太长 | 记忆成本与名称长度指数相关 | ≤ 3 个词（品牌）、≤ 10 字符（App） |
| 追随命名潮流 | -ly/-ify 从差异化变成噪音只用了 5 年 | 选择不依赖潮流的命名方向 |
| 依赖 AI 生成不验证 | AI 可能生成已注册商标或有负面含义的名称 | AI 辅助生成 + 人工全面验证 |
八、命名评估通用模板
用于任何场景的候选名评估：
## 候选名评估：[名称]
### 基础检查
- [ ] 可发音（首次看到能读对）
- [ ] 可拼写（听到后能写对）
- [ ] 无负面联想（中/英/目标市场语言）
- [ ] 无直接同名竞品
### 战略评估（1-5 分）
- 含义传达：__/5
- 独特性：__/5
- 延展性：__/5
- 目标受众匹配：__/5
### 技术检查
- 域名状态：[ ] 可用 / [ ] 需购买 / [ ] 需替代方案
- 商标状态：[ ] 无冲突 / [ ] 需进一步审查 / [ ] 有冲突
- 社交 handle：[ ] 统一可用 / [ ] 需变体
### 综合评分：__/50信息源
本文综合自前四篇调研文件的交叉分析，原始信息源已在各篇中列出。核心方法论来源：
- How Brands Are Built — Rob Meyerson
- Igor Naming Guide
- Lexicon Branding — David Placek
- VS Code Extension API 文档
- Google/Apple App Store 官方指南