本文是 Schema-As-Code 治理框架“语义契约化”阶段的收尾篇。“语义契约化”阶段由三部分组成语义契约、编译管线、语义字典。三者的依赖关系为语义字典定义覆盖层与语义绑定规则语义契约引用覆盖层写实例编译管线校验覆盖层引用并编译为消费格式。本文回答当契约和管线分别建成后组织如何确保同一组件在不同产品、不同角色手中具有一致的语义。核心机制是语义覆盖层Semantic Overlay组件库是底层Underlay只负责渲染语义覆盖层在组件之上加盖业务语义把空容器翻译为业务语义组件。关键设计详见《把设计规范写成代码格式是所有 AI 工具的上游约束方法论》阶段一结构化诊断 《组件语义快照与模式诊断AI 生成界面的第一道检查》阶段二“语义契约化”《设计师作为语义翻译者当 AI 生成界面时我怎么用规则锁住设计意图》。一、语义覆盖层一个跨领域的技术概念语义覆盖层不是设计领域独创的概念。它在三个技术领域有成熟的应用技术领域底层Underlay覆盖层Overlay解决的问题数据架构 / BI数据仓库物理表、字段如user_dim_v2统一语义层业务术语如客户“销售额”消除口径冲突让业务人员不用懂 SQL也能用统一语言分析数据AI / LLM基础模型概率分布Prompt运行时语义约束如你是一位资深教师防止幻觉在模型输出上覆盖一层结构化约束引导生成行为计算机网络物理网络IP 传输覆盖网络逻辑连接如 P2P 内容检索逻辑组网节点按内容关联而非物理距离连接设计系统本文组件库空容器如 Alert、Button语义覆盖层业务语义如阻断器“信息条”消除语义分歧让设计师、前端、AI 用同一套语言解释同一组件设计系统组件的语义覆盖层与上述三个领域是同一概念在不同层的应用。在数据架构中语义层把amt_usd_fs翻译成销售额在设计系统中语义覆盖层把空容器Alert翻译成阻断器或信息条。两者的核心机制一致在底层结构之上加盖一层符合业务逻辑的语义网络消除不同角色之间的理解偏差。需要明确的区分这里的覆盖不是 CSS 的层叠覆盖z-index这里的覆盖不是网络的路由覆盖VPN这里的覆盖是**语义命名空间Semantic Namespace**的覆盖——同一个空容器在不同的命名空间下被强制解释为不同的业务语义二、覆盖层与分类两种架构的本质区别在讨论语义字典之前需要明确一个架构层面的区分语义覆盖层Overlay不是分类Taxonomy。组件语义分类与漂移模式匹配的结构化规范详见《组件语义分类与漂移模式匹配从观察到归类的结构化规范》。2.1 分类模型语义内生于组件传统设计系统和组件库采用分类模型Alert 组件自带类型属性 ├── typeerror → 语义 错误提示 ├── typewarning → 语义 警告提示 ├── typeinfo → 语义 信息提示 └── typesuccess → 语义 成功提示在这个模型中语义是内生的IntrinsicAlert 组件在定义时就携带了类型和对应的语义。设计师选择typeerror前端实现typeerror的样式AI 生成typeerror的代码。所有人都围绕组件自带的类型工作。问题组件库升级会改变语义。当设计团队决定将typeerror从红色改为橙色时所有引用该类型的产品同时被改变但各产品的业务场景未必同步调整。语义与组件实现强耦合组织无法统一控制。2.2 覆盖层模型语义外赋于组件Schema-As-Code 采用覆盖层模型Alert 组件本身无语义是一个空容器Empty Vessel ├── 在 transactional 覆盖层下 → 语义被外赋为 阻断器 ├── 在 observational 覆盖层下 → 语义被外赋为 信息条 ├── 在 navigational 覆盖层下 → 语义被外赋为 路径提示 └── 在 conversational 覆盖层下 → 语义被外赋为 对话反馈在这个模型中语义是外赋的ExtrinsicAlert 组件在定义时不携带任何预设语义。它只是一个空容器等待覆盖层将语义绑定到它上面。同一个 Alert 实例在不同的覆盖层下被强制解释为完全不同的东西。关键区别维度分类模型覆盖层模型语义来源组件自带覆盖层外赋Alert 的本质一种消息组件有预设类型一个空容器无预设语义红色的含义Alert 的 variant“error”transactional 覆盖层对 “status.critical” 的强制绑定二次确认Alert 组件的可选配置transactional 覆盖层向 Alert 注入的强制行为跨产品一致性依赖组件库版本统一依赖覆盖层注册表统一2.3 将语义概念编码为离散令牌构建强制覆盖层MOSS 在《Memory-Orchestrated Semantic System》中提出了 “inductive ontology”归纳本体论和 “structured memory”结构化记忆将语义概念编码为关系数据库中的稠密向量映射而非散落于潜在空间。语义概念从语料库中归纳提取形成可查询的语义字典。MOSS 的 “Token Codebook” 作为统一字典将离散索引映射为连续语义表示。语料库中的任意节点都可以通过任意覆盖层重新解读没有一个覆盖层是基础性的。这在文学分析中是合理的——同一文本可以有多种解读角度。但在工程治理中这种去中心化会导致语义混乱。Schema-As-Code 的修正语义字典是唯一的、强制的基础覆盖层。它不提供多种阅读角度它提供唯一的术语坐标系。所有其他覆盖层必须在字典中注册不可自创。所有角色必须在这个坐标系内工作然后才能发展各自的专业视角。三、语义字典的定位覆盖层注册表语义字典不是术语表也不是设计规范文档。它是 Schema-As-Code 治理框架中的覆盖层注册表Overlay Registry。语义规范体系的整体设计YAML 里写的不是颜色值是语义令牌详见《语义规范体系》。它回答三个问题组织内有哪些强制覆盖层Mandatory Overlays每个覆盖层如何将**空容器Empty Vessel**重新解释为具体语义覆盖层之间的**隔离规则Isolation Rules和继承规则Inheritance Rules**是什么属性定义与下游的区别唯一性组织内每个覆盖层、每个语义绑定、每个场景映射有且只有一个定义语义契约可引用多个绑定组合但引用的绑定必须在字典中已定义强制性所有 YAML 契约、前端代码、AI Prompt 必须引用字典中的已定义项不可自创覆盖层或绑定否则编译管线阻断版本化语义字典以语义版本号管理如 v1.0.0变更需审批语义契约引用特定版本的字典确保向后兼容跨角色设计师、前端、AI、DesignOps 使用同一本字典消除理解偏差角色专题只讲怎么使用字典不讲字典内容是什么语义字典与下游的边界语义字典不定义具体颜色值如#FF4D4F那是 Design Token 的范畴语义字典不定义代码实现如 React 组件 Props那是前端组件库的范畴语义字典只定义“在 X 覆盖层下空容器 Y 被外赋为什么语义、什么约束”语义契约、Lint 规则、Prompt 前缀只消费语义字典的定义不修改语义字典的内容四、语义字典的三层结构4.1 第一层覆盖层目录Overlay Catalog覆盖层目录定义了组织内有哪些强制覆盖层以及每个覆盖层的覆盖范围和层级关系。覆盖层 ID覆盖层名称覆盖范围覆盖哪些界面点层级关系L0universal所有界面点的基础属性如可访问性、响应式最底层被所有其他层覆盖L1transactional会改变系统状态或数据的界面点覆盖 L0可被 L2 细化L1observational仅接收信息、无数据变更的界面点覆盖 L0与 transactional 互斥L1navigational提供方向指引、无数据变更的界面点覆盖 L0与 transactional 互斥L1conversational双向交流、上下文累积的界面点覆盖 L0与 transactional 互斥L2financialtransactional 的子层涉及资金流动覆盖 L1 transactionalL2data-destructivetransactional 的子层涉及数据删除覆盖 L1 transactional强制规则每个界面点必须且只能被一个 L1 覆盖层覆盖互斥L2 覆盖层是对 L1 的细化不是替代覆盖层必须在字典中注册未注册的覆盖层编译管线拒绝识别4.2 第二层语义重绑定Semantic Rebinding语义重绑定定义了在每个覆盖层下通用术语被强制绑定为什么具体语义。绑定是强制的不是建议。通用术语在transactional覆盖层下被绑定为在observational覆盖层下被绑定为在navigational覆盖层下被绑定为Alert阻断器用户必须立即处理否则系统状态恶化信息条用户可选择性关注不影响系统状态路径提示用户需要方向确认无状态风险确认不可逆操作确认用户理解后果并承担风险已知晓确认用户收到信息无需承担风险路径确认用户确认前往下一节点取消操作撤销系统回滚到操作前状态关闭提示信息消失系统无变化返回上一步导航状态回退红色危险信号阻断、不可逆、需立即响应非法绑定observational 覆盖层下红色被绑定为非法非法绑定navigational 覆盖层下红色被绑定为非法强制规则语义重绑定是强制的不是建议。在 transactional 覆盖层下“确认必须被理解为不可逆操作确认”前端实现时不是传typeerror参数而是声明overlaytransactional由覆盖层强制注入语义非法绑定在编译时直接阻断不可通过4.3 第三层约束注入Constraint Injection约束注入定义了在每个覆盖层下空容器被强制附加什么约束。这些约束不是组件自带的而是覆盖层注入的。覆盖层空容器注入约束注入来源transactionalAlert二次确认弹窗 后果说明文案覆盖层强制注入不是组件可选配置transactionalButton如果是action.destructive强制空心描边 禁用快速双击覆盖层强制注入observationalAlert自动消失计时器 关闭按钮覆盖层强制注入observationalBanner不可阻断当前操作点击外部不关闭但可继续操作覆盖层强制注入navigationalButton如果是action.primary强制显示下一步箭头 支持键盘导航覆盖层强制注入强制规则约束注入是覆盖层的责任不是组件的责任组件库只需实现可被注入的接口具体注入什么由覆盖层决定五、完整示例Alert 在覆盖层架构下的语义外赋界面语料库Substrate一个 Alert 组件包含标题、文案、按钮、关闭图标。本身无预设语义。无覆盖层时RawAlert 一个可复用的消息容器无特定语义无强制行为无强制视觉在 transactional 覆盖层下强制语义外赋Alert 被外赋为阻断器语义重绑定标题中的确认被强制理解为不可逆操作确认约束注入必须附加二次确认 Modal必须提供取消按钮必须记录操作日志视觉重渲染强制红色脉冲 八边形图标 震动动画关闭图标被强制隐藏阻断器不可直接关闭在 observational 覆盖层下强制语义外赋Alert 被外赋为信息条语义重绑定标题中的确认被强制理解为已知晓约束注入必须附加自动消失计时器必须提供关闭按钮不可阻断当前操作视觉重渲染强制蓝色静态 信息图标 无动画红色在该覆盖层下被绑定为非法即使设计师写了红色编译管线也阻断在 navigational 覆盖层下强制语义外赋Alert 被外赋为路径提示语义重绑定标题中的确认被强制理解为路径确认约束注入必须显示下一步预览必须支持键盘导航Tab 切换Enter 确认ESC 返回视觉重渲染强制品牌色空心边框 箭头图标 呼吸动画六、消除分歧的强制机制语义字典的强制力不依赖大家自觉遵守而是通过三层机制嵌入工作流6.1 编译前置校验在编译管线启动前先对 YAML 契约进行字典合规性检查YAML 契约的写作过程详见《YAML 契约格式》编译管线的机制设计详见[《编译管线是语义一致性的机器翻译层》](https://blog.csdn.net/2401_88754349/article/details/162895069?spm1011.2415.3001.10575sharefrommp_manage_link。检查项校验逻辑阻断行为覆盖层存在性semantic_domain的值是否在字典预定义列表中不存在则编译失败返回未注册覆盖层语义绑定存在性semantic_tokens中引用的每个绑定是否在字典中已定义不存在则编译失败返回未定义语义绑定覆盖层-绑定匹配性引用的绑定是否属于声明的覆盖层跨层引用则编译失败返回绑定与覆盖层不匹配非法绑定检查在声明的覆盖层下该绑定是否被标记为非法非法则编译失败返回该绑定在当前覆盖层下非法场景 ID 存在性scenario_id是否在字典的场景注册表中已注册不存在则编译失败返回未注册场景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契约与规范的版本化、追踪与同步管理详见《契约库让设计规范像代码一样管理》。版本变更示例影响范围主版本Majorv1.0.0 → v2.0.0破坏性变更删除覆盖层、重命名绑定、修改约束。所有下游 YAML 必须升级次版本Minorv1.0.0 → v1.1.0新增功能新增覆盖层、新增绑定、新增场景。旧 YAML 不受影响修订版本Patchv1.0.0 → v1.0.1修正错误修正描述文案、补充示例、修复歧义。旧 YAML 不受影响8.2 变更审批变更类型提议人审批人通知范围过渡期新增覆盖层任何角色语义翻译设计师 架构师全组织无新增语义绑定任何角色语义翻译设计师全组织无新增场景映射设计师语义翻译设计师相关产品线无修改覆盖层定义语义翻译设计师架构师 管理层全组织30 天删除覆盖层语义翻译设计师架构师 管理层全组织90 天修改约束注入规则语义翻译设计师架构师全组织30 天8.3 向后兼容旧版本 YAML 契约可继续引用旧版本字典编译管线自动匹配废弃的覆盖层或绑定进入deprecated状态保留 90 天后移除编译管线在编译时对deprecated项发出警告但不阻断九、最小可行集从 4 个覆盖层开始语义字典不建议一次性定义完整而是从最小可行集开始按需扩展第一阶段v1.0.04 个 L1 覆盖层transactional/observational/navigational/conversational6 个语义绑定status.critical/status.warning/status.info/status.success/action.destructive/action.primary6 个场景映射对应 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定义表覆盖层 ID中文名称定义适用场景示例禁止场景层级transactional交易与操作用户动作会改变系统状态或数据支付、删除、提交、确认、撤销纯信息展示、状态更新、新手引导L1observational观察与信息用户仅接收信息无需立即行动通知、状态更新、提示、反馈需要用户决策、需要二次确认、不可逆操作L1navigational导航与引导用户需要方向指引无数据变更面包屑、步骤指示、返回、跳转表单提交、数据操作、支付流程L1conversational对话与交互用户与系统双向交流上下文持续聊天、问答、建议、澄清一次性操作、无上下文的状态提示L1语义重绑定Semantic Rebinding定义表术语 ID所属覆盖层状态级别语义绑定约束注入跨层禁止status.criticaltransactional系统级故障阻断器用户必须立即处理否则系统状态恶化视觉红色脉冲、八边形图标行为必须二次确认文案必须说明后果适用仅用于阻断性错误observational / navigational / conversationalstatus.warningtransactional用户可恢复限制限制器用户需要注意但可以自助恢复视觉黄色静态、三角图标行为必须显示恢复时间文案必须提供操作步骤适用仅用于可恢复错误observational / navigational / conversationalstatus.infoobservational一般信息提示信息条用户可选择性关注不影响系统状态视觉蓝色静态、信息图标行为可自动消失文案禁止附加操作说明适用仅用于纯信息展示transactionalstatus.successobservational操作成功反馈成功条用户操作已完成系统状态已更新视觉绿色静态、对勾图标行为可自动消失文案禁止附加操作说明适用仅用于成功状态transactionalaction.destructivetransactional不可逆操作危险动作用户动作将导致数据永久丢失视觉红色空心描边、危险图标行为必须二次确认文案必须说明不可恢复适用仅用于删除/清空等操作observational / navigational / conversationalaction.primarynavigational主要引导动作引导动作帮助用户进入下一步或完成流程视觉品牌色实心、箭头图标行为点击后跳转文案显示下一步预览适用仅用于流程推进transactional / observational场景映射Scenario Mapping定义表场景 ID场景名称覆盖层语义绑定组合组件组合文案约束约束注入SCN-001删除账户transactionalstatus.criticalaction.destructiveAlert Button Modal必须包含此操作不可恢复必须说明数据删除范围必须输入账户名二次确认必须提供取消按钮操作后跳转至登录页SCN-002网络中断transactionalstatus.warningAlert Button必须显示网络不稳定必须显示自动重试倒计时提供手动重试按钮倒计时结束后自动刷新SCN-003保存成功observationalstatus.successToast仅显示保存成功禁止附加操作说明3 秒后自动消失不可手动关闭SCN-004新功能上线observationalstatus.infoBanner显示功能名称和一句话说明提供了解详情链接点击链接跳转帮助中心不可阻断当前操作SCN-005支付确认transactionalstatus.criticalAlert Form Button必须显示金额、收款方、支付方式必须说明支付后不可撤销必须输入支付密码或指纹必须提供取消按钮SCN-006步骤引导navigationalaction.primaryStepper Button显示当前步骤和总步骤提供上一步/下一步第一步禁用上一步最后一步变为完成本文是 Schema-As-Code 治理框架阶段二“语义契约化”的收尾篇。阶段二“语义契约化”由三部分组成语义字典、语义契约、编译管线三者的依赖关系为语义字典定义覆盖层与语义绑定规则语义契约引用覆盖层写实例编译管线校验覆盖层引用并编译为消费格式。本文聚焦语义字典作为设计系统组件语义覆盖层注册表的核心机制。后续将进入阶段三《验证闭环》的五个角色专题。