前一篇《从追问1个Design Token开始》讲了设计系统负责人怎么从1个错误色开始，建立"从色值到语义"的评审能力：追问三个问题，写成结构化定义，贴在规范旁边。
这篇我们接着往下走一步，把镜头对准组件：设计系统负责人最少做多少，就能开始建立"核对组件语义边界"的评审能力？
答案是：找到你们组件库里使用频率最高的那个组件，核对它在2个场景下的语义身份。仅此而已。
一、为什么要从1个组件的2个场景开始
很多设计系统负责人看到"语义域"这个词，第一反应是："这是不是意味着我要给组件库里每个组件都标上场景标签？"
不是的。
语义域不是给组件贴标签，而是回答一个问题：同一个组件，在不同场景下，承担的语义责任一样吗？
以 <Alert> 组件为例。它在你们的组件库里只有一份代码、一套样式，但它至少活在三种场景里：
| 语义域 | 语义身份 | 用户的处境 |
|---|---|---|
| transactional（交易与操作） | "阻断器" | 必须立即处理，否则系统状态恶化 |
| observational（观察与信息） | "信息条" | 可选择性关注，不影响系统状态 |
| navigational（导航与引导） | "路径提示" | 需要方向确认，无状态风险 |
组件是空容器，语义由场景定义。同一个 Alert，被不同场景引用时，获得完全不同的语义身份。
为什么只核对1个组件的2个场景？因为组织对抗往往来自"又要给组件库做大手术"的疲惫感。但如果告诉你："不需要动组件库，只需要挑1个组件，核对它在2个场景下是不是同一样东西"，门槛就低了很多。
二、核对2个场景：从"这个Alert好不好看"到"这个Alert在这里是谁"
打开你们的组件库，找到使用频率最高的那个组件，通常是 Alert、Button、Modal 中的一个。我们以 Alert 为例。
核对动作只有一步：选这个组件最常出现的2个场景，回答同一个问题，它在这个场景下，承担了正确的语义身份吗？
| 场景 A：系统故障提示 | 场景 B：新功能上线通知 | |
|---|---|---|
| 用户的处境 | 系统状态正在恶化或已经受损，必须立即处理，不能划走就当没事 | 系统没有任何问题，可以选择看一眼，也可以直接关掉 |
| 追问 | 这个 Alert 是"阻断器"还是"信息条"？ | 这个 Alert 是"阻断器"还是"信息条"？ |
| 答案 | "阻断器"，应属于 transactional 域 | "信息条"，应属于 observational 域 |
| 用户的行动 | 立即刷新页面、导出历史、联系客服 | 瞄一眼，或者忽略 |
这两个场景的视觉表达可能是同一个 Alert 组件，但用户看到后的行动完全不同。
你的动作：在组件库文档里，把这个组件的2个场景并排写下来，分别标注它们的语义身份（阻断器 / 信息条 / 路径提示）。注意，这不是视觉判断（"这个 Alert 好不好看"），而是语义判断（"这个 Alert 在这个场景下是否承担了正确的语义责任"）。
顺手再核对一次按钮，效果更好：
| 组件 | 场景 A | 场景 B | 你要核对什么 |
|---|---|---|---|
| Alert | 系统故障提示 | 新功能上线通知 | 场景 A 是否属于 transactional 域？场景 B 是否属于 observational 域？ |
| Button | 删除账户 | 保存设置 | 场景 A 是否绑定 action.destructive？场景 B 是否绑定 action.constructive？ |
三、把核对结果写成"机器能查"的格式
核对完2个场景后，你手里有了一份"人懂的"语义判断。下一步是把它翻译成"机器能查"的格式，不是让你写代码，而是写一段结构化的域绑定说明，让下游的语义翻译设计师能直接把它编码成YAML契约。
核对前（人懂的直觉）：
"这个删除账户的确认弹窗，不应该用普通的蓝色主按钮，应该是危险样式，而且要有二次确认。"
核对后（结构化域绑定）：
【组件】ConfirmDialog（确认弹窗）
【场景】删除账户
【语义域】transactional（交易与操作）
【语义绑定】action.destructive（危险操作）
【域内约束】
- 必须使用危险样式（红色空心，禁止蓝色实心）
- 必须二次确认（禁止一键执行）
- 必须说明后果（"删除后不可恢复"）
【跨层禁止】
- status.critical 禁止用于 observational 域（不能拿致命状态当普通通知）
- action.destructive 禁止用于 navigational 域（不能拿危险操作当导航按钮）
你的动作：把这份域绑定说明，贴在你们组件库的对应组件旁边。不需要写YAML，只需要写到这个颗粒度，下游的语义翻译设计师会把它编码成契约。机器拿到这份说明后，跨层禁止规则就能自动执行：谁把危险操作绑到导航域，编译时直接拦截。
四、真的发生过吗：一个你可以在自己组织里验证的案例
你们组织里一定有这样的情况：同一个"删除"动作，在不同产品或不同页面里，样式和确认流程都不一样。
你可以做的验证动作：
- 打开你们的主产品，找到一个"批量删除"或"删除账户"入口
- 截图，记录：按钮是什么颜色、什么样式、点击后有没有二次确认
- 再打开你们的另一个产品（或另一个后台页面），找到同样的删除入口
- 截图，对比：两个产品的删除按钮，视觉权重和确认流程是否一致？
大概率你会发现：
| 产品 | 删除按钮的样式 | 确认流程 |
|---|---|---|
| 产品 A | 红色空心 | 点击后弹二次确认 |
| 产品 B | 蓝色实心，和普通按钮长得一模一样 | 无 |
| 产品 C | 藏在导航菜单里 | 点一下就执行了 |
这就是一个真实发生过的漂移类型：某团队把"批量删除用户"按钮声明为 navigational 域，绑定了 action.primary（引导动作），AI生成代码时按导航按钮的标准映射输出蓝色实心样式，没有二次确认，用户误触后批量删除了数据。根因不是设计师没画对，而是开发团队把"删除"理解成了"导航到删除页面"，而不是"执行删除操作"。域声明标错，下游全错。
你的动作：把这几张截图并排放在一起，在团队群里发一句："我们的删除操作，好像有的有确认、有的没有？"，这就是语义域核对的起点。
五、一直在工作吗：怎么让这份域绑定不被遗忘
核对完2个场景、写成域绑定说明后，最怕的是：新场景出现时，没人再核对，域声明又回到拍脑袋。
最小可行的保鲜机制：
| 检查项 | 频率 | 谁做 | 怎么做 |
|---|---|---|---|
| 这个组件的域声明是否与内容匹配 | 每次契约提交 | 机器（编译前置校验） | 场景一致性检查自动跑，失败即阻断 |
| 绑定是否触发跨层禁止 | 每次AI生成时 | 机器（语义推演层校验） | 非法绑定生成前被拦截 |
| 新场景是否已注册域 | 每次新场景评审 | 设计系统负责人 | 追问"这个场景的组件语义身份是什么" |
| 域定义是否需要扩展 | 双周 | 设计系统负责人 | 汇总团队扩展申请，判断是否新增域 |
你的动作：先在每次新场景评审会上加一个问题，"这个场景里的 Alert / Button，是谁？"只需要1分钟，就能让域核对成为习惯。机器负责每次提交、每次生成的自动检查，你只在新场景出现、机器没见过时在场。
六、生长路径：从1个组件到组件库的语义边界体系
核对1个组件的2个场景只是起点。设计系统负责人的语义域核对能力，会沿着这条路径自然生长：
| 阶段 | 时间 | 动作 | 产出 |
|---|---|---|---|
| 阶段 0：核对1个组件 | 现在 | 找到 Alert，核对2个场景的语义身份，写成域绑定说明 | 1份域绑定草稿 |
| 阶段 1：核对3个组件 | 1-2周后 | 把核对方法复制到 Button、Modal | 1份核心组件域绑定表 |
| 阶段 2：建立核对模板 | 1个月后 | 把"这个场景下组件是谁"写成团队共享的核对清单 | 1份《语义域核对Checklist》 |
| 阶段 3：参与域注册评审 | 2-3个月后 | 新场景接入时，用这份Checklist评审域声明 | 域声明准确率数据 |
| 阶段 4：主导跨层禁止维护 | 6个月后 | 新域的注册、禁止规则的更新、豁免申请的裁决 | 语义域规则版本管理权 |
关键原则：不是"等组件库全部标完再开始"，而是"从1个组件开始，在核对中建立标准，在标准中完善规则"。
结语
前一篇讲了怎么从1个Design Token开始追问语义。那些是"点"，让你知道一个颜色意味着什么。
这篇讲的是"面"的第一步：不需要给组件库贴上全套标签，只需要找到你们最常用的那个组件，核对它在2个场景下的语义身份，它是阻断器、信息条，还是路径提示？
核对本身就是评审。 当你开始问"这个组件在这个场景下是谁"，你就已经从"管组件长什么样"生长到了"管组件承担什么责任"。
希望能帮到你。如果你在核对过程中发现了有趣的案例（比如同一个 Alert 在你们组织里既当故障警报又当营销横幅），欢迎在评论区分享，这些真实的混乱，正是语义治理最好的起点。
下一篇会针对"约束显化"展开，聊聊设计系统负责人怎么把1条评审会上说了三年的"绝对不能"，翻译成机器能自动拦截的规则。
1200 .png
