语义字典：设计系统组件的语义覆盖层

本文是Schema-As-Code治理框架“语义契约化”阶段的收尾篇。 “语义契约化”阶段由三部分组成：语义契约、编译管线、语义字典。三者的依赖关系为：语义字典定义覆盖层与语义绑定规则，语义契约引用覆盖层写实例，编译管线校验覆盖层引用并编译为消费格式。 本文回答：当契约和管线分别建成后，组织如何确保同一组件在不同产品、不同角色手中具有一致的语义。核心机制是语义覆盖层 Semantic Overlay ：组件库是底层 Underlay，只负责渲染；语义覆盖层在组件之上加盖业务语义，把空容器翻译为业务语义组件

关键设计详见：《把设计规范写成代码格式是所有AI工具的上游约束方法论》

阶段一“结构化诊断： 《组件语义快照与模式诊断AI生成界面的第一道检查》

阶段二“语义契约化”《设计师作为"语义翻译者"当AI生成界面时，我怎么用规则锁住设计意图》。

1. 语义覆盖层 一个跨领域的技术概念

"语义覆盖层"不是设计领域独创的概念。它在三个技术领域有成熟的应用：

设计系统组件的语义覆盖层，与上述三个领域是同一概念在不同层的应用。

在数据架构中，语义层把amt_usd_fs翻译成"销售额"；在设计系统中，语义覆盖层把空容器Alert翻译成"阻断器"或"信息条"。

两者的核心机制一致：在底层结构之上，加盖一层符合业务逻辑的语义网络，消除不同角色之间的理解偏差。

需要明确的区分：

• 这里的"覆盖"不是CSS的层叠覆盖（z-index）
• 这里的"覆盖"不是网络的路由覆盖（VPN）
• 这里的"覆盖"是语义命名空间 Semantic Namespace 的覆盖，同一个空容器，在不同的命名空间下，被强制解释为不同的业务语义

2. 覆盖层与分类 两种架构的本质区别

在讨论语义字典之前，需要明确一个架构层面的区分：

语义覆盖层 Overlay 不是分类 Taxonomy。

组件语义分类与漂移模式匹配的结构化规范，详见《组件语义分类与漂移模式匹配：从观察到归类的结构化规范》。

2.1 分类模型 语义内生于组件

传统设计系统和组件库采用分类模型：

Alert 组件自带类型属性
  ├── type="error" → 语义 = 错误提示
  ├── type="warning" → 语义 = 警告提示
  ├── type="info" → 语义 = 信息提示
  └── type="success" → 语义 = 成功提示

在这个模型中，语义是内生的 Intrinsic：Alert组件在定义时就携带了类型和对应的语义。设计师选择type="error"，前端实现type="error"的样式，AI生成type="error"的代码。所有人都围绕组件自带的类型工作。

问题：组件库升级会改变语义。当设计团队决定将type="error"从红色改为橙色时，所有引用该类型的产品同时被改变，但各产品的业务场景未必同步调整。

语义与组件实现强耦合，组织无法统一控制。

2.2 覆盖层模型 语义外赋于组件

Schema-As-Code采用覆盖层模型：

Alert 组件本身无语义，是一个空容器（Empty Vessel）
  ├── 在 transactional 覆盖层下 → 语义被外赋为 "阻断器"
  ├── 在 observational 覆盖层下 → 语义被外赋为 "信息条"
  ├── 在 navigational 覆盖层下 → 语义被外赋为 "路径提示"
  └── 在 conversational 覆盖层下 → 语义被外赋为 "对话反馈"

在这个模型中，语义是外赋的 Extrinsic：Alert组件在定义时不携带任何预设语义。它只是一个空容器，等待覆盖层将语义绑定到它上面。

同一个Alert实例，在不同的覆盖层下，被强制解释为完全不同的东西。

关键区别：

2.3 将语义概念编码为离散令牌，构建强制覆盖层

MOSS在《Memory-Orchestrated Semantic System》中提出了 "i归纳本体论"和 "结构化记忆"，将语义概念编码为关系数据库中的稠密向量映射，而非散落于潜在空间。语义概念从语料库中归纳提取，形成可查询的"语义字典"。MOSS的 "Token Codebook" 作为统一字典，将离散索引映射为连续语义表示。

语料库中的任意节点都可以通过任意覆盖层重新解读，没有一个覆盖层是基础性的。这在文学分析中是合理的，同一文本可以有多种解读角度。

但在工程治理中，这种去中心化会导致语义混乱。

Schema-As-Code的修正：语义字典是唯一的、强制的基础覆盖层。

它不提供"多种阅读角度"，它提供唯一的术语坐标系。

所有其他覆盖层必须在字典中注册，不可自创。

所有角色必须在这个坐标系内工作，然后才能发展各自的专业视角。

3. 语义字典的定位 覆盖层注册表

语义字典不是术语表，也不是设计规范文档。它是 Schema-As-Code 治理框架中的覆盖层注册表 Overlay Registry。

语义规范体系的整体设计，YAML里写的不是颜色值是语义令牌，详见《语义规范体系》。

它回答三个问题：

1. 组织内有哪些强制覆盖层？
2. 每个覆盖层如何将空容器重新解释为具体语义？
3. 覆盖层之间的隔离规则和继承规则是什么？

语义字典与下游的边界：

• 语义字典不定义具体颜色值（如 #FF4D4F），那是Design Token的范畴
• 语义字典不定义代码实现（如React组件Props），那是前端组件库的范畴
• 语义字典只定义"在X覆盖层下，空容器Y被外赋为什么语义、什么约束"
• 语义契约、Lint规则、Prompt前缀只消费语义字典的定义，不修改语义字典的内容

4. 语义字典的三层结构

4.1 第一层：覆盖层目录

覆盖层目录定义了组织内有哪些强制覆盖层，以及每个覆盖层的覆盖范围和层级关系。

强制规则：

• 每个界面点必须且只能被一个 L1覆盖层覆盖（互斥）
• L2覆盖层是对L1的细化，不是替代
• 覆盖层必须在字典中注册，未注册的覆盖层编译管线拒绝识别

4.2 第二层：语义重绑定

语义重绑定定义了在每个覆盖层下，通用术语被强制绑定为什么具体语义。

绑定是强制的，不是建议。

强制规则：

• 语义重绑定是强制的，不是建议。在transactional覆盖层下，"确认"必须被理解为"不可逆操作确认"
• 前端实现时，不是传type="error"参数，而是声明 overlay="transactional"，由覆盖层强制注入语义
• 非法绑定在编译时直接阻断，不可通过

4.3 第三层：约束注入

约束注入定义了在每个覆盖层下，空容器被强制附加什么约束。

这些约束不是组件自带的，而是覆盖层"注入"的。

强制规则：

• 约束注入是覆盖层的责任，不是组件的责任
• 组件库只需实现"可被注入"的接口，具体注入什么由覆盖层决定

5. 完整示例 Alert在覆盖层架构下的语义外赋

界面语料库 Substrate： 一个 Alert 组件，包含：标题、文案、按钮、关闭图标。本身无预设语义。

无覆盖层时 Raw：

• Alert = 一个可复用的消息容器，无特定语义，无强制行为，无强制视觉

在 transactional 覆盖层下（强制语义外赋）：

• Alert 被外赋为：阻断器
• 语义重绑定：标题中的"确认"被强制理解为"不可逆操作确认"
• 约束注入：必须附加二次确认Modal；必须提供"取消"按钮；必须记录操作日志
• 视觉重渲染：强制红色脉冲 + 八边形图标 + 震动动画；关闭图标被强制隐藏（阻断器不可直接关闭）

在 observational 覆盖层下（强制语义外赋）：

• Alert 被外赋为：信息条
• 语义重绑定：标题中的"确认"被强制理解为"已知晓"
• 约束注入：必须附加自动消失计时器；必须提供关闭按钮；不可阻断当前操作
• 视觉重渲染：强制蓝色静态 + 信息图标 + 无动画；红色在该覆盖层下被绑定为非法，即使设计师写了红色，编译管线也阻断

在 navigational 覆盖层下（强制语义外赋）：

• Alert 被外赋为：路径提示
• 语义重绑定：标题中的"确认"被强制理解为"路径确认"
• 约束注入：必须显示下一步预览；必须支持键盘导航（Tab切换，Enter确认，ESC返回）
• 视觉重渲染：强制品牌色空心边框 + 箭头图标 + 呼吸动画

6. 消除分歧的强制机制

语义字典的强制力不依赖"大家自觉遵守"，而是通过三层机制嵌入工作流：

6.1 编译前置校验

在编译管线启动前，先对YAML契约进行字典合规性检查：

YAML契约的写作过程详见《YAML 契约格式》；编译管线的机制设计详见《编译管线是语义一致性的"机器翻译层"》。

6.2 走查红线检查

Checklist的第一组检查项直接引用语义字典：

界面语义观察与走查的记录标准（6字段记录法），详见《组件语义快照：我观察 AI 产品界面时用的 6 字段记录法》。

## 语义字典合规检查（基于字典 v1.0.0）

### 覆盖层检查
- [ ] 该组件是否声明了覆盖层？
- [ ] 声明的覆盖层是否在组织字典中已注册？
- [ ] 该覆盖层是否适用于当前业务场景？

### 语义绑定检查
- [ ] 该组件使用的语义绑定是否在字典中已定义？
- [ ] 语义绑定是否属于声明的覆盖层？（禁止跨层使用）
- [ ] 视觉表达是否与绑定定义一致？（如 `status.critical` 必须是红色脉冲）

### 约束注入检查
- [ ] 该组件是否被注入了覆盖层定义的强制约束？
- [ ] 约束注入是否完整？（如二次确认、后果说明、取消按钮）

6.3 代码静态检查

前端代码提交时，Lint规则检查组件是否引用了未定义的覆盖层或绑定：

// ESLint 规则示例
{
  "rules": {
    "semantic/overlay-registered": "error",
    "semantic/binding-overlay-match": "error",
    "semantic/illegal-binding": "error"
  }
}

检查逻辑：

• 组件文件头部必须声明// overlay: transactional
• 组件使用的绑定必须在字典中存在
• 跨层使用绑定（如在observational覆盖层使用status.critical）触发error

7. 语义字典是上游 YAML/Lint/Prompt是下游

┌─────────────────────────────────────────────┐
│  语义字典（上游·覆盖层注册表）                 │
│  - 定义覆盖层、语义重绑定、约束注入             │
│  - 由语义翻译设计师维护                       │
│  - 版本化管理，变更需审批                     │
│  - 所有下游必须消费，不可绕过                 │
└─────────────────────────────────────────────┘
              ↓ 被引用
┌─────────────────────────────────────────────┐
│  YAML 契约（中游·实例规则）                   │
│  - 引用语义字典中的覆盖层和语义绑定            │
│  - 由设计师编写                               │
│  - 编译时校验：引用是否在字典中？             │
└─────────────────────────────────────────────┘
              ↓ 被编译
┌─────────────────────────────────────────────┐
│  消费格式（下游·执行规则）                    │
│  - Prompt 前缀 / JSON Schema / Checklist / CI│
│  - 由编译管线自动生成                         │
│  - 前端/AI/DesignOps 直接使用                 │
└─────────────────────────────────────────────┘
              ↓ 校验
┌─────────────────────────────────────────────┐
│  Lint / CI / 运行时（末端·强制检查）          │
│  - 检查代码是否遵守语义字典定义               │
│  - 违反则阻断                                 │
└─────────────────────────────────────────────┘

从观察证据到契约规则的完整工作流，详见《从观察到契约：Semantic Pipeline 的三阶段工作流》。

关键边界：

• 语义字典 不定义 具体颜色值（如 #FF4D4F），那是Design Token的范畴
• 语义字典 不定义 代码实现（如React组件 Props），那是前端组件库的范畴
• 语义字典 只定义 "在X覆盖层下，空容器Y被外赋为什么语义、什么约束"
• YAML契约、Lint规则、Prompt前缀只消费语义字典的定义，不修改语义字典的内容

8. 治理机制 版本、审批与兼容

8.1 版本管理

语义字典采用语义化版本管理（SemVer）：

契约与规范的版本化、追踪与同步管理，详见《契约库：让设计规范像代码一样管理》。

8.2 变更审批

8.3 向后兼容

• 旧版本YAML契约可继续引用旧版本字典，编译管线自动匹配
• 废弃的覆盖层或绑定进入 deprecated 状态，保留90天后移除
• 编译管线在编译时，对 deprecated 项发出警告但不阻断

9. 最小可行集 从4个覆盖层开始

语义字典不建议一次性定义完整，而是从最小可行集开始，按需扩展：

第一阶段（v1.0.0）：

• 4个L1覆盖层：transactional/observational/navigational/ conversational
• 6个语义绑定：status.critical/status.warning/status.info/status.success/action.destructive/action.primary
• 6个场景映射：对应6个漂移模式（ERR-001 / PRO-001 / BND-001 / ACT-001 / ALR-001 / FRM-001；诊断机制详见《结构化诊断：三层判定模型与模式匹配机制》，完整证据库详见《6 个漂移模式：AI 生成界面的语义断层证据库》

第二阶段（v1.1.0）：

• 根据实际业务需求，新增覆盖层（如onboarding新手引导覆盖层）
• 根据走查反馈，新增语义绑定（如status.neutral中性状态）
• 根据产品扩展，新增场景映射（如 "批量删除"、"跨设备同步"）

第三阶段（v2.0.0）：

• 重构覆盖层分类，如将transactional拆分为financial和data-operation
• 此为主版本变更，需全组织升级

10. 引出阶段三验证闭环 从覆盖层注册表到角色消费

阶段二“语义契约化 ”的三部分建设完成后，组织具备了以下能力：

• 语义字典：覆盖层注册表与语义绑定规范
• 语义契约：具体场景约束
• 编译管线：自动翻译与校验

但这三部分仍停留在"基础设施建设"层面。阶段三“验证闭环”的核心任务，是让不同角色真正使用这些基础设施，将语义一致性从"技术能力"转化为"组织能力"。

阶段三“验证闭环”将回答五个问题：

• 设计师与产品经理：如何在日常工作中引用覆盖层编写YAML，如何用语义分级器验证AI输出？
• 前端与AI工程师：如何在代码中接入JSON Schema校验，如何确保AI生成内容遵守覆盖层约束？
• DesignOps与设计系统负责人：如何管理字典版本变更，如何确保全组织同步？
• 体验架构师与语义翻译设计师：如何搭建从字典到Lint的全流程工具链？
• 管理层与决策者：如何量化语义治理的投入产出，如何推动组织采纳？

阶段三“验证闭环”不是新增建设，而是阶段二“语义契约化”基础设施的角色级消费。 五个角色专题将分别阐述：在阶段二“语义契约化”的覆盖层注册表之上，每个角色如何执行自己的语义治理职责。

附录：语义字典核心定义

覆盖层定义

transactional（交易与操作）
├── 定义：用户动作会改变系统状态或数据
├── 适用场景：支付、删除、提交、确认、撤销
├── 禁止场景：纯信息展示、状态更新、新手引导
└── 层级：L1

observational（观察与信息）
├── 定义：用户仅接收信息，无需立即行动
├── 适用场景：通知、状态更新、提示、反馈
├── 禁止场景：需要用户决策、需要二次确认、不可逆操作
└── 层级：L1

navigational（导航与引导）
├── 定义：用户需要方向指引，无数据变更
├── 适用场景：面包屑、步骤指示、返回、跳转
├── 禁止场景：表单提交、数据操作、支付流程
└── 层级：L1

conversational（对话与交互）
├── 定义：用户与系统双向交流，上下文持续
├── 适用场景：聊天、问答、建议、澄清
├── 禁止场景：一次性操作、无上下文的状态提示
└── 层级：L1

语义重绑定定义

# 术语 ID：status.critical
所属覆盖层: transactional
状态级别: 系统级故障
语义绑定: 阻断器——用户必须立即处理，否则系统状态恶化
约束注入:
  视觉: 红色脉冲、八边形图标
  行为: 必须二次确认
  文案: 必须说明后果
  适用: 仅用于阻断性错误
跨层禁止: observational / navigational / conversational

# 术语 ID：status.warning
所属覆盖层: transactional
状态级别: 用户可恢复限制
语义绑定: 限制器——用户需要注意，但可以自助恢复
约束注入:
  视觉: 黄色静态、三角图标
  行为: 必须显示恢复时间
  文案: 必须提供操作步骤
  适用: 仅用于可恢复错误
跨层禁止: observational / navigational / conversational

# 术语 ID：status.info
所属覆盖层: observational
状态级别: 一般信息提示
语义绑定: 信息条——用户可选择性关注，不影响系统状态
约束注入:
  视觉: 蓝色静态、信息图标
  行为: 可自动消失
  文案: 禁止附加操作说明
  适用: 仅用于纯信息展示
跨层禁止: transactional

# 术语 ID：status.success
所属覆盖层: observational
状态级别: 操作成功反馈
语义绑定: 成功条——用户操作已完成，系统状态已更新
约束注入:
  视觉: 绿色静态、对勾图标
  行为: 可自动消失
  文案: 禁止附加操作说明
  适用: 仅用于成功状态
跨层禁止: transactional

# 术语 ID：action.destructive
所属覆盖层: transactional
状态级别: 不可逆操作
语义绑定: 危险动作——用户动作将导致数据永久丢失
约束注入:
  视觉: 红色空心描边、危险图标
  行为: 必须二次确认
  文案: 必须说明不可恢复
  适用: 仅用于删除/清空等操作
跨层禁止: observational / navigational / conversational

# 术语 ID：action.primary
所属覆盖层: navigational
状态级别: 主要引导动作
语义绑定: 引导动作——帮助用户进入下一步或完成流程
约束注入:
  视觉: 品牌色实心、箭头图标
  行为: 点击后跳转
  文案: 显示下一步预览
  适用: 仅用于流程推进
跨层禁止: transactional / observational

场景映射定义表

# 场景 ID：SCN-001
场景名称: 删除账户
覆盖层: transactional
语义绑定组合: status.critical + action.destructive
组件组合: Alert + Button + Modal
文案约束:
  - 必须包含"此操作不可恢复"
  - 必须说明数据删除范围
约束注入:
  - 必须输入账户名二次确认
  - 必须提供取消按钮
  - 操作后跳转至登录页

# 场景 ID：SCN-002
场景名称: 网络中断
覆盖层: transactional
语义绑定组合: status.warning
组件组合: Alert + Button
文案约束:
  - 必须显示"网络不稳定"
  - 必须显示自动重试倒计时
约束注入:
  - 提供手动重试按钮
  - 倒计时结束后自动刷新

# 场景 ID：SCN-003
场景名称: 保存成功
覆盖层: observational
语义绑定组合: status.success
组件组合: Toast
文案约束:
  - 仅显示"保存成功"
  - 禁止附加操作说明
约束注入:
  - 3 秒后自动消失
  - 不可手动关闭

# 场景 ID：SCN-004
场景名称: 新功能上线
覆盖层: observational
语义绑定组合: status.info
组件组合: Banner
文案约束:
  - 显示功能名称和一句话说明
  - 提供"了解详情"链接
约束注入:
  - 点击链接跳转帮助中心
  - 不可阻断当前操作

# 场景 ID：SCN-005
场景名称: 支付确认
覆盖层: transactional
语义绑定组合: status.critical
组件组合: Alert + Form + Button
文案约束:
  - 必须显示金额、收款方、支付方式
  - 必须说明支付后不可撤销
约束注入:
  - 必须输入支付密码或指纹
  - 必须提供"取消"按钮

# 场景 ID：SCN-006
场景名称: 步骤引导
覆盖层: navigational
语义绑定组合: action.primary
组件组合: Stepper + Button
文案约束:
  - 显示当前步骤和总步骤
  - 提供上一步/下一步
约束注入:
  - 第一步禁用"上一步"
  - 最后一步变为"完成"

本文是 Schema-As-Code 治理框架阶段二“语义契约化”的收尾篇。阶段二“语义契约化”由三部分组成：语义字典、语义契约、编译管线，三者的依赖关系为语义字典定义覆盖层与语义绑定规则，语义契约引用覆盖层写实例，编译管线校验覆盖层引用并编译为消费格式。本文聚焦语义字典作为设计系统组件语义覆盖层注册表的核心机制。后续将进入阶段三《验证闭环》的五个角色专题。