2.2.1.1 大数据方法论与实践指南-公司产品功能命名管理

1. 公司产品&功能命名管理

产品 & 功能命名规范的核心目标是统一跨团队语言（产品 / 开发 / 数据 / 运营）、降低协作成本、支撑数据治理与业务复用，需适配互联网产品 “快迭代、多模块、强关联” 的特点，覆盖 “产品命名” 与 “功能命名” 两大核心场景，兼顾 “用户认知友好” 与 “技术 / 数据落地高效”。

一、核心原则：所有命名需满足 4 个基础要求

1. 语义化：名称本身可解释，无需额外说明（用户 / 团队能快速理解 “是什么、做什么”）；

2. 一致性：同类型命名用统一词汇（如 “新增” 不混用 “添加”“增加”，“删除” 不混用 “移除”“删掉”）；

3. 可扩展：预留迭代空间（避免过细的版本号，如 “会员 V1” 可优化为 “基础会员”，后续可扩展 “高级会员”）；

4. 关联数据：功能命名需与后续数据字段、元数据关联（如功能名→数据字段名保持前缀一致，支撑数据采集与治理）。

二、产品命名规范（含独立产品、子产品、产品线）

产品命名直接影响用户认知与品牌联想，需兼顾 “业务属性”“品牌一致性” 与 “传播性”，避免生僻字、同质化或歧义。

1. 命名结构（3 种主流结构，按产品类型选择）

产品类型	推荐结构	示例（互联网场景）	说明
独立主产品	品牌名 + 核心业务（可选）	抖音（无业务后缀，品牌强认知）、小红书（强品牌）、美团外卖（品牌 + 业务）	适合用户高频使用、品牌辨识度高的产品；业务后缀避免过长（不超过 4 字）
子产品 / 功能产品	主产品名 + 子业务 / 场景	抖音电商、小红书市集、微信支付、淘宝直播	明确归属主产品，同时区分核心场景；子业务名需与主产品定位匹配（如 “小红书市集” 贴合 “社区 + 电商” 属性）
垂类产品线	核心业务 + 用户 / 场景	支付宝商家版、钉钉企业版、B 站青少年模式	针对特定用户群体（商家 / 企业 / 青少年），后缀清晰区分目标场景；避免模糊词汇（如 “专业版” 需补充 “专业在哪”，可优化为 “XX 商家专业版”）

1. 禁用 / 避坑规则

• 禁用生僻字 / 谐音歧义（如 “犇犇”“靐”，用户输入难、记忆成本高；“食色” 易引发负面联想）；

• 避坑同质化（如竞品叫 “XX 优选”，自家不建议直接叫 “XX 精选”，可加场景区分，如 “XX 生鲜优选”）；

• 不包含临时属性（如 “双 11 特惠产品”，活动结束后需更名，可优化为 “XX 特惠频道”，支持长期迭代）。

三、功能命名规范（核心，直接关联开发与数据）

功能是产品的最小操作单元（如 “用户注册”“商品收藏”“订单支付”），命名需结构化、无歧义、强关联模块，直接支撑开发字段定义、数据采集与业务协作。

1. 功能命名通用结构（按 “模块 + 动作 + 属性” 分层，自解释性最强）

基础结构：模块名 + 核心动作 + 补充属性（可选）

• 模块名：按产品核心业务域划分（如 “用户”“订单”“商品”“内容”“支付”“会员”），需与数据域（如用户域、交易域）对齐；

• 核心动作：用统一动词描述操作（见下文 “动作词汇表”）；

• 补充属性：区分细分场景（如渠道、方式、范围，非必要不添加，避免冗余）。

动作词汇表（统一动词，禁止混用）

动作类型	统一动词	禁用替代词	示例
新增 / 创建	新增、创建	添加、增加、新建、生成	用户新增 - 地址、订单创建
删除 / 移除	删除、移除	删掉、取消、清除	商品收藏 - 删除、地址移除
查询 / 查看	查询、查看	搜索（特指 “关键词检索”）、浏览	订单查询 - 历史、会员查看 - 权益
编辑 / 修改	编辑、修改	更改、调整、更新（仅用在数据同步场景）	用户编辑 - 资料、订单修改 - 收货地址
验证 / 校验	验证、校验	检查、核对	用户注册 - 手机验证、订单支付 - 金额校验
提交 / 确认	提交、确认	提交确认（重复，二选一）	表单提交、订单确认
取消 / 撤回	取消	撤销、撤回（仅用在 “未提交” 场景）	订单取消、预约取消

1. 分模块功能命名示例（覆盖互联网产品核心模块）

按 “用户、交易、商品、内容、会员、支付” 六大高频模块，提供结构化命名参考，直接匹配数据字段（如功能名→数据字段名前缀一致）：

业务模块	功能场景	规范命名	禁用命名（问题）	对应数据字段示例（关联数据治理）
用户模块	手机注册验证	用户注册 - 手机验证	注册 - 手机号（缺模块，歧义）	user_register_phone_verify
	密码重置	用户密码 - 重置	改密码（不明确 “重置” 场景）	user_password_reset
	地址管理 - 新增	用户地址 - 新增	添加收货地址（缺模块，不统一）	user_address_add
交易模块	订单创建（未支付）	订单创建 - 待支付	下单（缺状态，歧义）	order_create_pending_pay
	订单退款 - 全额	订单退款 - 全额	退单（不明确 “全额 / 部分”）	order_refund_full
	购物车添加商品	购物车 - 商品新增	加购（简写，团队认知不一致）	cart_goods_add
商品模块	商品收藏	商品收藏 - 新增	收藏商品（顺序反，不统一）	goods_collect_add
	商品搜索（关键词）	商品搜索 - 关键词	搜商品（缺方式，歧义）	goods_search_keyword
	商品库存查询	商品库存 - 查询	查库存（缺模块）	goods_stock_query
内容模块	笔记发布（图文）	笔记发布 - 图文	发笔记（缺类型，不统一）	note_publish_image_text
	视频评论 - 删除	视频评论 - 删除	删评论（缺模块）	video_comment_delete
	直播开播	直播 - 开播	开始直播（冗余，不统一）	live_start
会员模块	会员开通 - 月度	会员开通 - 月度	开会员（缺周期，歧义）	member_activate_monthly
	会员权益 - 查看	会员权益 - 查看	看会员福利（词汇不统一）	member_rights_view
支付模块	订单支付 - 微信支付	订单支付 - 微信支付	微信付钱（口语化，不落地）	order_pay_wechat
	支付结果 - 查询	支付结果 - 查询	查支付状态（词汇不统一）	pay_result_query

1. 功能命名特殊场景处理

• 通用基础功能（跨模块复用）：按 “通用 + 动作” 命名，避免重复模块名，如 “通用搜索”“通用登录”“通用分享”（适用于全局搜索、多模块共用的登录入口）；

• 新功能迭代（兼容旧体系）：新增功能需与现有模块命名规则一致，如现有 “商品收藏 - 新增”，新增 “商品收藏 - 批量删除” 需保持 “商品收藏 + 动作” 结构；

• 第三方集成功能：需标注第三方标识，如 “订单支付 - 支付宝支付”“用户登录 - 微信登录”，避免与自有功能混淆。

四、命名管理与落地流程（确保规范不流于形式）

规范的核心是 “落地执行”，需配套简单的管理流程，避免 “纸上规范，实际混乱”：

1. 命名评审：嵌入需求评审环节

• 所有新产品 / 功能的命名，需在 “需求评审会” 中同步确认（参会方：产品、开发、数据、运营）；

• 评审重点：是否符合语义化、一致性，是否关联数据字段（如开发确认功能名可直接作为字段前缀）。

1. 建立 “命名字典”：统一查询与复用

• 维护在线共享的《产品 & 功能命名字典》（如 Confluence、飞书表格），包含：

  • 产品 / 功能名称、所属模块、命名依据、对应数据字段、负责人、更新时间；

• 字典需定期更新（如每月同步新增功能），并对旧命名标注 “停用原因”（如 “旧功能‘订单提交 - 确认’已优化为‘订单确认 - 提交’”）。

1. 与数据治理结合

• 元数据管理：将命名规范嵌入元数据管理系统（如华为云数据治理中心）。

• 血缘追踪：通过命名规则支持数据血缘分析（如PAYMENT_TRANSACTION_LOG追溯到API_PAY_V1）。

1. 迭代与兼容：旧命名的处理规则

• 存量不兼容命名：若已上线功能命名不符合规范（如 “加购”“改密码”），不强制批量修改（避免开发成本过高），但新增功能必须按规范命名；

• 重大版本迭代：借主版本更新（如 V3.0），逐步将核心模块的旧命名替换为规范命名（如 “加购” 替换为 “购物车 - 商品新增”），同步更新数据字段与元数据。

五、未来趋势：智能化与场景化

1. AI 辅助命名：

   1. 通过 NLP 自动生成功能描述对应的命名（如输入“用户登录功能”，输出auth_service.user_login）。

   2. 使用图计算检测命名冲突（如发现user_login同时用于功能和表名时报警）。

2. 场景化适配：

   1. 针对实时计算、批处理、机器学习等场景定制命名规则（如实时任务命名包含_stream后缀）。

   2. 支持多语言命名（如中英文混合命名需明确转换规则）。

3. 低代码平台集成：

   1. 在低代码开发工具中内置命名规范校验，用户拖拽组件时自动生成合规名称（如创建“用户管理”页面时默认命名为user_management_page）。

总结：命名规范是“小投入、大回报”的治理抓手

• 对业务：确保数据口径一致，支撑精准决策。

• 对技术：降低系统复杂度，提升可维护性。

• 对合规：满足监管要求，规避法律风险。

• 对创新：释放数据价值，加速业务迭代。