同一组组件，有人叫“提示”，有人叫“通知”，研发又使用第三种名称，协作时就容易发生偏差。Vitaly Friedman的新文章汇集了命名资源与案例。兰亭妙微围绕B端界面设计，给出一套可从小范围开始执行的命名建议；下文示例是说明方法，不是通用强制标准。
应用建议：先列出项目里最容易混淆的概念，例如页面级通知、字段错误提示和操作结果反馈。为它们分别写一句用途说明，再选择团队熟悉的名称。如果两个名称描述的是同一件事，就合并；如果同一个名称覆盖了不同用途，就拆开。
图1 原文引用的命名规范示例。来源：Smashing Magazine；原始规范由相关作者维护。
这一步可以从十几个常用组件开始，不必一次整理完所有历史页面。评审时用实际场景检查定义，例如“提交失败”提示是否与“长期系统维护通知”使用了相同组件；只有用途清楚，名称才不会只是字面统一。
应用建议：组件名称保持稳定，尺寸、状态与用途差异使用属性记录。例如订单操作按钮可以在组件中定义大小、是否加载和是否可用，而不是为每一种颜色再建立一个名字不相干的按钮。具体字段应与所用设计工具和代码结构协调。
图2 原文介绍的Component Gallery组件词汇示例。来源：Smashing Magazine / Component Gallery。
对颜色也可以区分原始色值和业务角色：一个绿色是否表示品牌主色、成功反馈或在线状态，应由使用场景决定。示例名称如“反馈/成功/背景”仅用于说明语义层次，不能脱离团队现有规范直接替换。
应用建议：给组件建立简短的别名说明和使用示例，让新成员能够按常用词找到它。交付时保留设计名称与研发名称的对应关系，并记录少数例外的原因，减少临时口头解释。
一次小型验证可以这样进行：请未参与建设的同事找到一个筛选组件、切换到错误状态，再说明它与相近组件的差异。若反复找不到或理解不一致，就回到命名和分类本身修改，而不是继续增加文档篇幅。
设计系统的命名价值，在于帮助团队更快找到、正确理解并持续维护组件。稳定的概念边界，比追求某一种固定的英文词法更值得优先解决。
