组件命名，
其实是在统一语言

这是各家说法最一致的一条。颜色、尺寸、圆角迟早会改，名字一旦绑定了这些属性，改版那天就失效了。

Figma 会把斜杠自动变成资产面板里的文件夹。常见的几种写法：

注意：现在 Figma 有 variants 和 component properties，State、Size 这类信息更适合放进属性。斜杠层级主要用来表达“组件属于哪一类”。

开发在 Dev Mode 里看到的就是组件名和属性名。设计稿里叫 Button、代码里是 <Button>，交接就顺；一边叫 CTA、一边叫 <Action>，每次交接都可能翻译出错。

Brad Frost 举过一个例子：同一个顶栏，开发叫 utility bar，设计叫 admin bar，产品叫“顶上那条灰的”。

Figma 官方列了五项要在组件库变大之前决定的规则：

• 大小写：Title Case、小写，还是 camelCase
• 缩写：哪些词允许缩写
• 术语：Modal 还是 Dialog，Notification 还是 Toast
• 布尔属性的说法：Has Icon、Show Icon，还是 Icon Visible
• 取值写法：SM / MD / LG 还是 Small / Medium / Large，Hover 还是 Hovered

属性名也要统一，不能同一个概念有的叫 Size、有的叫 Scale、有的叫 Dimensions。官方原话：没有唯一正确的规范，团队一起遵守的那套就是对的。

这是 Nathan Curtis 在 2026 年提出的新一层说法。以前的“命名难”，难在起名：Pill、Tag、Chip、Badge 到底叫哪个。现在难在另一件事：Figma 只有“组件”这一种资产类型，名字要额外说明这是什么类型的东西、属于谁。

• 图标不算组件，而是内容：加统一前缀，比如 DE Icon asset / heart，下游脚本才能把图标和组件分开处理
• 子组件写成“父 / 子”：Action list / Item、Action list / Group heading。这层从属关系 Figma 本身不记录，只能靠名字表达
• 图片走统一的属性名：比如 imageSource，让 Image、Avatar 等组件都用同一个入口

他把这些规范写成配置文件，交给 linter、代码生成和 AI 工具去读。Figma 官方也提到，命名清楚能让 AI 更准确地理解文件结构。这说明命名的读者，正在从“人”扩展到“人和工具”。

Brad Frost 提醒，团队很容易在命名和分类上想得太巧、陷得太深。Into Design Systems 的做法是：新组件的名字放到有工程师参与的小会上一起定；定下来之后，日常开会也只用这个名字，不再冒出近义词。

别名问题有多普遍？看 Component Gallery 收录的一个例子，同一个组件就有这么多叫法：

Smashing 的结尾说得好：大量时间浪费在用不同“方言”谈论同一件东西上，包括设计、开发、产品和用户各自的方言。功能采用率低，有时仅仅是因为名字没起好。