jixiaxue 知识库
evidence · 2026-04-06

工程项目与技术概念命名

/Users/eamanc/Documents/pe/jixiaxuegong/research/命名方法论/evidence/技术命名/工程与概念命名.md

工程项目与技术概念命名

核心发现：好的技术命名本质是「隐喻压缩」——用一个日常词汇承载一整套技术语义，使其成为设计词汇表的一部分；而工程代号的核心价值不在保密，在于团队凝聚力和版本辨识度。 信息源：Pingdom 代号研究、Refactoring.guru 设计模式、Gartner Hype Cycle、9to5Google、Apple Wiki

一、工程项目代号文化

1.1 三大公司的代号体系

Apple：主题系列轮替

Apple 的代号文化是业界最系统化的，维持了三层命名体系：

命名策略的精髓：同一主题系列内的名字自带序列感（用户自然知道 Ventura 在 Monterey 之后），且每个名字都有独立的视觉意象可用于营销（壁纸、发布会视觉）。

Google Android：字母序甜点 → 全球化转型

Android 1.5 起按字母序用甜点命名：Cupcake → Donut → Eclair → Froyo → Gingerbread → Honeycomb → Ice Cream Sandwich → Jellybean → KitKat → Lollipop → Marshmallow → Nougat → Oreo → Pie。

2019 年 Android 10 起放弃甜点名，改为纯数字。核心原因是全球可达性：

教训：主题命名的扩展性受限于主题空间的大小和文化普适性。当产品从硅谷极客圈扩展到全球 30 亿用户时，「有趣」让位于「可理解」。

Microsoft：地理迷恋

Microsoft 的代号偏爱地名，尤其是滑雪度假村和美加地理标志：

这种选择反映了微软西雅图总部的团队文化——Pacific Northwest 的户外运动偏好渗透到了代号里。

1.2 代号的功能分析

功能说明案例
版本辨识比数字更容易记忆和引用「Catalina 的兼容性问题」比「10.15 的兼容性问题」更口语化
团队凝聚代号给项目赋予人格，增强归属感Google 每个 Android 版本在总部放一个甜点雕塑
保密屏障外部听到代号无法推断产品细节Apple 用葡萄酒名做内部代号，泄露也不暴露版本序
营销资产好代号可直接转为产品名macOS Big Sur 的悬崖意象成为发布会视觉核心
情绪锚定将抽象版本号与具体意象关联Daytona 暗示速度目标，团队自然理解性能优先

1.3 代号命名的反模式

二、微服务命名策略

微服务命名是工程领域争议最大的命名问题之一。核心矛盾：描述性（一看就懂）vs 稳定性（业务演化后名字不过时）。

2.1 命名原则

黄金规则：名字应描述业务能力（what it does），而非实现方式（what it is）或组织归属（who owns it）。

原则正例反例原因
描述业务能力payment-processingstripe-integration支付渠道会换，业务能力不变
避免技术栈user-authredis-session-service技术栈是实现细节
避免团队名order-managementplatform-team-orders团队重组比服务下线频繁得多
避免代号inventory-syncproject-phoenix代号仅适用于保密阶段

2.2 命名格式规范

<domain>-<capability>[-<qualifier>]

2.3 治理建议

三、数据库/表/字段命名规范

数据库命名是最成熟的技术命名领域，行业共识度高。

3.1 核心规范

对象规范示例
表名单数名词，snake_casecustomer、order_item
列名单数名词，snake_case，具有描述性start_date、email_address
主键<table>_id 或纯 idcustomer_id
外键与引用表主键同名order.customer_id → customer.customer_id
布尔列is_/has_/can_ 前缀is_active、has_subscription
时间列_at 后缀created_at、updated_at

3.2 争议与取舍

单数 vs 复数表名：行业分裂。Rails/Django 默认复数（users），DBA 社区偏好单数（user）。关键是全库一致，不要混用。

前缀/后缀标注类型：tbl_、vw_、sp_ 等匈牙利式前缀已被现代风格指南否定——它们是元数据，不是命名的一部分。

缩写：除非是行业通用缩写（qty、amt、desc），否则不要缩写。cust_addr 不如 customer_address 清晰。

四、设计模式的命名——为什么这些名字好

4.1 隐喻即压缩

GoF（Gang of Four，Erich Gamma 等四人，1994）定义的 23 个设计模式，每个名字都是一个「隐喻压缩包」——用日常隐喻承载完整的技术语义：

模式隐喻来源为什么好
Factory工厂生产产品一听就知道「这个东西负责创建对象」，且暗示了创建过程的封装
Observer观察者观察目标源自报纸订阅模型——发布者发消息，订阅者接收。名字精确传达了单向监听关系
Strategy军事战略选择指挥官从多个战略中选一个执行，完美映射「运行时选择算法」
Singleton独一无二名字本身就是约束的完整表达——只能有一个实例
Decorator装饰/包装像给礼物层层包装纸——每层添加功能但不改变核心
Facade建筑外立面复杂建筑的简洁外观，完美映射「简化复杂子系统的统一接口」
Bridge桥梁连接两岸将抽象和实现分离，像桥连接两个独立变化的维度

4.2 好命名的设计原则

GoF 模式名之所以成功，是因为它们满足了命名的三个层次：

  1. 即时可懂：用日常词汇，无需解释就能猜到大致含义（Factory = 造东西的）
  2. 精确无歧义：隐喻的映射足够精确，不会产生误导（Observer 不会被理解成「双向通信」）
  3. 设计词汇化：成为团队沟通的简写——说「用 Observer 模式」比解释「搞一个发布-订阅机制，当状态变化时通知所有注册的回调」高效 10 倍

GoF 自己的评价标准：「A good name is vital because it will become part of your design vocabulary.」——模式名的首要功能不是描述，而是成为团队共享词汇表的一部分。

4.3 命名失败的反例

并非所有模式名都同样成功：

五、新概念造词与技术 Buzzword 生命周期

5.1 成功造词的模式

技术领域的新概念命名遵循几种固定模式：

造词模式机制案例
领域嫁接把成熟领域的词移植到新领域Prompt Engineering（工程化思维 → AI 交互）、Harness Engineering（安全带/工具 → 开发者平台）
动词化将名词/形容词变为动词性概念Vibe Coding（氛围 → 编码方式）、Rubber Duck Debugging
隐喻造词用具象事物命名抽象概念Technical Debt（债务隐喻）、Code Smell（代码气味）
缩写/首字母压缩为可发音的缩写SaaS、DevOps、MLOps
旧词新义赋予已有词全新技术含义Cloud（云）、Container（容器）、Pipeline（管线）

5.2 Vibe Coding：一个造词案例分析

Andrej Karpathy 于 2025 年 2 月在 X 上发了一条推文，定义「Vibe Coding」为「完全跟着感觉走，忘掉代码的存在，让 AI 处理一切」。这条推文迅速获得了一个 Wikipedia 页面——大多数技术概念做不到这一点。

成功因素：

5.3 Buzzword 的 Gartner 式生命周期

技术概念从造词到沉淀，遵循与 Gartner Hype Cycle（1995 年由分析师 Jackie Fenn 提出）高度同构的五阶段模型：

影响力
 ^
 |        Peak of
 |       Inflated       
 |      Expectations    Slope of          Plateau of
 |        /\           Enlightenment      Productivity
 |       /  \            /                ___________
 |      /    \          /                /
 |     /      \        /                /
 |    /        \      /                /
 |   /          \    /                /
 |  /            \  /                /
 | /    Trough of \/                /
 |/    Disillusion-                /
 +----ment--------------------------→ 时间
Innovation
 Trigger

以 Prompt Engineering 为例：

  1. 触发期（2022）：ChatGPT 发布，Prompt Engineering 成为「最热门 AI 职位」
  2. 膨胀期（2023）：媒体预测年薪百万，课程和认证泛滥
  3. 幻灭期（2024）：「Prompt Engineering 已死」论调兴起，模型能力提升使精心构造的 prompt 变得不那么必要
  4. 复苏期（2025）：社区开始理性认识——Prompt Engineering 不是独立职业，而是所有 AI 使用者的基础技能
  5. 成熟期（进行中）：与 Vibe Coding 等新概念共存，各有适用场景

Buzzword 存活的关键判据：一个技术词汇能否从 buzzword 沉淀为行业术语，取决于它是否填补了真实的认知空白。Technical Debt 活了 30 年，因为它精确命名了一个所有工程师都经历但此前无法简洁表达的现象。而「Web 3.0」正在幻灭谷，因为它试图命名一个尚不存在的范式。

信息源

核心参考

补充参考