功能与特性命名策略
核心发现：Apple 的功能命名看似混乱，实则遵循”前缀即品类”的隐性规则（Air=无线、i=互联网/个人、Pro=专业级）；AI 行业的功能命名已陷入”诗意 vs 清晰”的系统性困境——Anthropic 的 Haiku/Sonnet/Opus 虽然优雅但用户无法直觉判断层级。
信息源：Medium（Paul Welsh）、Solveo、Artsy Engineering、Sourcegraph Naming Guide、New Kind
一、Apple 的功能命名体系
Apple 是功能命名最有体系但也最受争议的公司。分析其命名可以提炼出通用的功能命名原则。
前缀系统：语义标签
| 前缀/后缀 | 语义 | 应用 | 问题 |
|---|
| i- | 互联网/个人化（源自 iMac 1998） | iPhone、iPad、iCloud | 已过时——Apple Watch 后不再使用 |
| Air- | 无线/轻量 | AirDrop、AirPlay、AirPods、MacBook Air | 双重含义混淆：Air = 轻（MacBook Air）还是无线（AirDrop）？ |
| -Pro | 专业级/高性能 | MacBook Pro、iPhone Pro、AirPods Pro | 在不同产品线中含义不同：iPhone Pro = 摄像头升级，Mac Pro = 极致性能 |
| -Max | 最大/最高级 | iPhone Pro Max、M1 Max | iPhone Max = 屏幕大，芯片 Max = 性能高 |
| -Ultra | 超越 Pro 的级别 | Apple Watch Ultra、M1 Ultra | 目前最清晰的层级标签 |
Apple 命名的优势
- 情感先行：名称传递”氛围”而非技术参数——AirDrop 让人联想到轻盈流畅，而非”蓝牙+Wi-Fi 近场传输”
- 动词化倾向：“FaceTime 一下”、“AirDrop 给我”——名称成为动作本身
- 前缀创造品类感：所有 Air- 产品自动归入”无线/轻量”心智品类
Apple 命名的问题
- 层级不一致：Pro、Max、Ultra 在不同产品线中含义不同
- 大小写混乱：AirPods（驼峰）、iPad（i 小写）、Mac mini（全小写 mini）、MacBook（驼峰）——无统一规则
- 遗留命名：i- 前缀已过时但因惯性保留（iOS、iCloud）
从 Apple 提炼的功能命名原则
| 原则 | 说明 | Apple 案例 |
|---|
| 前缀即品类 | 统一前缀创造产品族归属感 | Air- = 无线族 |
| 名称可动词化 | 好的功能名能变成用户口语 | ”FaceTime me”、“AirDrop it” |
| 氛围 > 技术 | 名称传递使用体验而非实现方式 | AirDrop（非 NearFieldShare） |
| 层级需一致 | 修饰词在整个产品体系中含义稳定 | ❌ Apple 的 Pro/Max 不一致是反面教材 |
二、AI 行业的功能命名困境
当前各公司命名策略对比
| 公司 | 模型命名 | 层级命名 | 功能命名 | 评价 |
|---|
| OpenAI | GPT-4、GPT-4o | o1、o3-mini-high | ChatGPT、DALL-E、Sora | 从简洁走向混乱——用户无法直觉判断 o3-mini-high vs GPT-4o 谁更强 |
| Anthropic | Claude 3.5、3.7 | Haiku/Sonnet/Opus | Artifacts、Claude Code | 诗意但无直觉层级——Sonnet 比 Haiku 大多少？ |
| Google | Gemini | Nano/Flash/Pro/Ultra | Bard→Gemini | 最清晰的层级命名（小→快→专→极） |
| Meta | Llama 3.1 | 8B/70B/405B | — | 参数量直接作层级——技术用户友好，普通用户困惑 |
| Apple | — | — | Apple Intelligence | 唯一完全回避模型命名的做法——用户只看到品牌 |
AI 命名的核心问题（Solveo 分析）
- 技术术语过载：o3-mini-high 是给工程师看的内部代号，不是用户界面名称
- 虚假进度幻觉：3.5 → 3.7 → 4.0 的版本号制造了线性进步的假象，实际能力跳跃远非均匀
- 隐藏竞争优势：诗意命名（Sonnet）牺牲了用户对性能层级的直觉理解
- 模型 vs 产品混淆：Claude 既是”模型”又是”助手”——技术讨论和产品讨论经常错位
AI 功能命名的标杆与反面
| 名称 | 类型 | 评价 |
|---|
| Copilot（GitHub/Microsoft） | 隐喻型 | 精准隐喻——AI 不是驾驶员而是副驾。但 Microsoft 过度使用导致”Copilot 疲劳” |
| Artifacts（Anthropic） | 隐喻型 | ”产出物”——AI 生成的可交互内容，名称清晰且不限定格式 |
| Canvas（OpenAI） | 隐喻型 | ”画布”——暗示创作空间，但和 Artifacts 功能高度重叠时造成行业混淆 |
| Claude Code | 描述型 | 直接说明”Claude + 编程”——简洁但限制想象空间 |
| o3-mini-high | 技术型 | 完全面向内部，用户不知道 o 代表什么、mini 比谁 mini、high 相对什么 |
三、内部代号 vs 对外名称
为什么需要内部代号
- 保密需要：产品未发布前用代号防止泄露
- 范围灵活：代号不绑定功能——产品方向变化时不需要改名
- 团队文化：趣味代号创造归属感（Apple 用加州地名、Google 用甜品）
代号管理的关键原则（Sourcegraph Naming Guide + Artsy Engineering）
| 原则 | 说明 | 反面案例 |
|---|
| 代号是临时的 | 代号应在产品发布时被公开名称替代 | ❌ 代号泄露后成为用户口中的产品名（如 Android 甜品名） |
| 不要让代号逃逸 | 如果不主动命名产品层级，用户会用内部代号 | ❌ Slack 内部称呼变成客户词汇 |
| 建立命名单源文档 | 平台名、控制面板名、模块名、“禁用词”统一管理 | ❌ 团队各自创造称呼导致用户困惑 |
| 代号风格统一 | 同一系列用同一主题（地名/动物/天体） | Apple: 加州地名（Sierra、Ventura、Sonoma） |
经典代号体系
| 公司 | 代号主题 | 案例 | 对外名称 |
|---|
| Apple macOS | 加州地名 | Monterey、Ventura、Sonoma | macOS + 地名（代号即公开名） |
| Apple 芯片 | 天体（早期） | — | M1、M2（放弃代号直接用代号） |
| Google Android | 甜品（已弃用） | KitKat、Oreo、Pie | Android 10+（改用版本号） |
| Microsoft Windows | 代号+版本混用 | Longhorn → Vista | Windows + 版本/品牌名 |
| Intel 处理器 | 湖泊 | Raptor Lake、Meteor Lake | Core i5/i7/i9（对外）+ 代号（技术文档） |
代号→公开名的过渡策略
最佳实践：
- 代号仅在团队内使用，不出现在任何外部文档
- 产品发布前 2-4 周确定公开名称
- 发布当天同步更新所有文档、API、UI 中的名称
- 保留代号→公开名的映射表，方便内部搜索历史讨论
最差实践：
- 代号出现在 API 端点中（
/api/longhorn/v2）——一旦公开就永远无法改名
- 代号和公开名混用——用户不知道 Sonoma 和 macOS 14 是同一个东西
- 每个子功能都有独立代号——认知成本指数增长
四、功能命名的通用 Checklist
命名前评估
| 问题 | 说明 |
|---|
| 这个功能是否足够大到需要独立名称？ | 不是每个功能都需要品牌名——大部分功能用描述性标签即可 |
| 名称是否需要跨产品复用？ | AirDrop 跨 iPhone/Mac——需要独立名称；一个设置页面不需要 |
| 用户是否需要口头提及？ | 需要口头传播的功能（“帮我 AirDrop 一下”）比后台功能更需要好名称 |
命名原则
| 原则 | 正面案例 | 反面案例 |
|---|
| 可动词化 | ”FaceTime me" | "Windows Defender me”（无法自然使用） |
| 暗示功能但不限定 | Artifacts（产出物） | “Code Generator”（限定了代码生成） |
| 层级一致 | Google: Nano < Flash < Pro < Ultra | Apple: Pro 含义因产品而异 |
| 避免缩写 | AirDrop | NFST（Near-Field Share Technology） |
| 全球化安全 | 先检查目标市场语言含义 | ”Siri” 在日语中 = 屁股 |
信息源
核心参考
补充参考