本文是 Schema-As-Code 治理框架“语义契约化”阶段的收尾篇。

“语义契约化”阶段由三部分组成：语义契约、编译管线、语义字典。三者的依赖关系为：语义字典定义覆盖层与语义绑定规则，语义契约引用覆盖层写实例，编译管线校验覆盖层引用并编译为消费格式。

本文回答：当契约和管线分别建成后，组织如何确保同一组件在不同产品、不同角色手中具有一致的语义。核心机制是语义覆盖层（Semantic Overlay）：组件库是底层（Underlay），只负责渲染；语义覆盖层在组件之上加盖业务语义，把空容器翻译为业务语义组件。

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

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

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

一、语义覆盖层：一个跨领域的技术概念

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

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

在数据架构中，语义层把amt_usd_fs翻译成"销售额"；在设计系统中，语义覆盖层把空容器Alert翻译成"阻断器"或"信息条"。两者的核心机制一致：在底层结构之上，加盖一层符合业务逻辑的语义网络，消除不同角色之间的理解偏差。

需要明确的区分：

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

二、覆盖层与分类：两种架构的本质区别

在讨论语义字典之前，需要明确一个架构层面的区分：语义覆盖层（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》中提出了 “inductive ontology”（归纳本体论）和 “structured memory”（结构化记忆），将语义概念编码为关系数据库中的稠密向量映射，而非散落于潜在空间。语义概念从语料库中归纳提取，形成可查询的"语义字典"。MOSS 的 “Token Codebook” 作为统一字典，将离散索引映射为连续语义表示。
语料库中的任意节点都可以通过任意覆盖层重新解读，没有一个覆盖层是基础性的。这在文学分析中是合理的——同一文本可以有多种解读角度。

但在工程治理中，这种去中心化会导致语义混乱。Schema-As-Code 的修正：语义字典是唯一的、强制的基础覆盖层。它不提供"多种阅读角度"，它提供唯一的术语坐标系。所有其他覆盖层必须在字典中注册，不可自创。所有角色必须在这个坐标系内工作，然后才能发展各自的专业视角。

三、语义字典的定位：覆盖层注册表

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

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

它回答三个问题：

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

语义字典与下游的边界：

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

四、语义字典的三层结构

4.1 第一层：覆盖层目录（Overlay Catalog）

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

强制规则：

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

4.2 第二层：语义重绑定（Semantic Rebinding）

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

强制规则：

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

4.3 第三层：约束注入（Constraint Injection）

约束注入定义了在每个覆盖层下，空容器被强制附加什么约束。这些约束不是组件自带的，而是覆盖层"注入"的。

强制规则：

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

五、完整示例：Alert 在覆盖层架构下的语义外赋

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

无覆盖层时（Raw）：

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

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

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

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

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

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

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

六、消除分歧的强制机制

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

6.1 编译前置校验

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

YAML 契约的写作过程详见《YAML 契约格式》；编译管线的机制设计详见[《编译管线是语义一致性的"机器翻译层"》](https://blog.csdn.net/2401_88754349/article/details/162895069?spm=1011.2415.3001.10575&sharefrom=mp_manage_link。

6.2 走查红线检查

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

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

## 语义字典合规检查（基于字典 v1.0.0） ### 覆盖层检查 - [ ] 该组件是否声明了覆盖层？ - [ ] 声明的覆盖层是否在组织字典中已注册？ - [ ] 该覆盖层是否适用于当前业务场景？ ### 语义绑定检查 - [ ] 该组件使用的语义绑定是否在字典中已定义？ - [ ] 语义绑定是否属于声明的覆盖层？（禁止跨层使用） - [ ] 视觉表达是否与绑定定义一致？（如 `status.critical` 必须是红色脉冲） ### 约束注入检查 - [ ] 该组件是否被注入了覆盖层定义的强制约束？ - [ ] 约束注入是否完整？（如二次确认、后果说明、取消按钮）

6.3 代码静态检查（Lint）

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

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

检查逻辑：

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

七、语义字典是上游，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.1 版本管理

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

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

8.2 变更审批

8.3 向后兼容

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

九、最小可行集：从 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）
• 此为主版本变更，需全组织升级

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

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

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

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

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

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

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

附录：语义字典核心定义表

覆盖层（Overlay）定义表

语义重绑定（Semantic Rebinding）定义表

场景映射（Scenario Mapping）定义表

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