设计系统负责人如何低成本建立组件语义评审能力？本文提出只需找到使用频率最高的组件，核对它在2个场景下的语义身份，就能从“管组件长什么样”升级到“管组件承担什么责任”。通过真实案例和结构化域绑定方法，帮你迈出语义治理的第一步。

前一篇《从追问1个Design Token开始》讲了设计系统负责人怎么从1个错误色开始，建立”从色值到语义”的评审能力：追问三个问题，写成结构化定义，贴在规范旁边。

这篇我们接着往下走一步，把镜头对准组件：设计系统负责人最少做多少，就能开始建立”核对组件语义边界”的评审能力？

答案是：找到你们组件库里使用频率最高的那个组件，核对它在2个场景下的语义身份。仅此而已。

一、为什么要从1个组件的2个场景开始

很多设计系统负责人看到”语义域”这个词，第一反应是：”这是不是意味着我要给组件库里每个组件都标上场景标签？”

不是的。

语义域不是给组件贴标签，而是回答一个问题：同一个组件，在不同场景下，承担的语义责任一样吗？

以 <Alert> 组件为例。它在你们的组件库里只有一份代码、一套样式，但它至少活在三种场景里：

组件是空容器，语义由场景定义。同一个 Alert，被不同场景引用时，获得完全不同的语义身份。

为什么只核对1个组件的2个场景？因为组织对抗往往来自”又要给组件库做大手术”的疲惫感。但如果告诉你：”不需要动组件库，只需要挑1个组件，核对它在2个场景下是不是同一样东西”，门槛就低了很多。

二、核对2个场景：从”这个Alert好不好看”到”这个Alert在这里是谁”

打开你们的组件库，找到使用频率最高的那个组件，通常是 Alert、Button、Modal 中的一个。我们以 Alert 为例。

核对动作只有一步：选这个组件最常出现的2个场景，回答同一个问题，它在这个场景下，承担了正确的语义身份吗？

这两个场景的视觉表达可能是同一个 Alert 组件，但用户看到后的行动完全不同。

你的动作：在组件库文档里，把这个组件的2个场景并排写下来，分别标注它们的语义身份（阻断器 / 信息条 / 路径提示）。注意，这不是视觉判断（”这个 Alert 好不好看”），而是语义判断（”这个 Alert 在这个场景下是否承担了正确的语义责任”）。

顺手再核对一次按钮，效果更好：

三、把核对结果写成”机器能查”的格式

核对完2个场景后，你手里有了一份”人懂的”语义判断。下一步是把它翻译成”机器能查”的格式，不是让你写代码，而是写一段结构化的域绑定说明，让下游的语义翻译设计师能直接把它编码成YAML契约。

核对前（人懂的直觉）：

“这个删除账户的确认弹窗，不应该用普通的蓝色主按钮，应该是危险样式，而且要有二次确认。”

核对后（结构化域绑定）：

你的动作：把这份域绑定说明，贴在你们组件库的对应组件旁边。不需要写YAML，只需要写到这个颗粒度，下游的语义翻译设计师会把它编码成契约。机器拿到这份说明后，跨层禁止规则就能自动执行：谁把危险操作绑到导航域，编译时直接拦截。

四、真的发生过吗：一个你可以在自己组织里验证的案例

你们组织里一定有这样的情况：同一个”删除”动作，在不同产品或不同页面里，样式和确认流程都不一样。

你可以做的验证动作：

1. 打开你们的主产品，找到一个”批量删除”或”删除账户”入口
2. 截图，记录：按钮是什么颜色、什么样式、点击后有没有二次确认
3. 再打开你们的另一个产品（或另一个后台页面），找到同样的删除入口
4. 截图，对比：两个产品的删除按钮，视觉权重和确认流程是否一致？

大概率你会发现：

这就是一个真实发生过的漂移类型：某团队把”批量删除用户”按钮声明为 navigational 域，绑定了 action.primary（引导动作），AI生成代码时按导航按钮的标准映射输出蓝色实心样式，没有二次确认，用户误触后批量删除了数据。根因不是设计师没画对，而是开发团队把”删除”理解成了”导航到删除页面”，而不是”执行删除操作”。域声明标错，下游全错。

你的动作：把这几张截图并排放在一起，在团队群里发一句：”我们的删除操作，好像有的有确认、有的没有？”，这就是语义域核对的起点。

五、一直在工作吗：怎么让这份域绑定不被遗忘

核对完2个场景、写成域绑定说明后，最怕的是：新场景出现时，没人再核对，域声明又回到拍脑袋。

最小可行的保鲜机制：

你的动作：先在每次新场景评审会上加一个问题，”这个场景里的 Alert / Button，是谁？”只需要1分钟，就能让域核对成为习惯。机器负责每次提交、每次生成的自动检查，你只在新场景出现、机器没见过时在场。

六、生长路径：从1个组件到组件库的语义边界体系

核对1个组件的2个场景只是起点。设计系统负责人的语义域核对能力，会沿着这条路径自然生长：

关键原则：不是”等组件库全部标完再开始”，而是”从1个组件开始，在核对中建立标准，在标准中完善规则”。

结语

前一篇讲了怎么从1个Design Token开始追问语义。那些是”点”，让你知道一个颜色意味着什么。

这篇讲的是”面”的第一步：不需要给组件库贴上全套标签，只需要找到你们最常用的那个组件，核对它在2个场景下的语义身份，它是阻断器、信息条，还是路径提示？

核对本身就是评审。 当你开始问”这个组件在这个场景下是谁”，你就已经从”管组件长什么样”生长到了”管组件承担什么责任”。

希望能帮到你。如果你在核对过程中发现了有趣的案例（比如同一个 Alert 在你们组织里既当故障警报又当营销横幅），欢迎在评论区分享，这些真实的混乱，正是语义治理最好的起点。

下一篇会针对”约束显化”展开，聊聊设计系统负责人怎么把1条评审会上说了三年的”绝对不能”，翻译成机器能自动拦截的规则。