定位：语义域（Semantic Domain）组件的语义边界。本文是 Schema-As-Code 证据链的"认知 + 合法性"站（B 列：全景 + 背书），覆盖主题行②的核心设计：语义域模型（覆盖层架构）。回答"凭什么成立"：组件的语义不内生于组件，而由语义域外赋——域是组件的语义边界，边界之内语义唯一，跨边界引用受机器拦截。
阅读结构：调整前的真实反馈 → 背书 → 关键设计（语义域模型全文）→ 架构层概念 → 这些坑怎么被解掉 → 调整后的呈现状态。
快速阅读：
方法论总纲与开源：把设计规范写成代码格式，是所有 AI 工具的上游约束方法论
阶段一结构化诊断：组件语义快照与模式诊断：AI 生成界面的第一道检查
阶段二语义契约化：设计师作为"语义翻译者" 当AI生成界面时我怎么用规则锁住设计意图
角色专题1:设计师与产品经理：AI 界面语义走查指南
角色专题2：前端与AI工程师把语义约束写进AI的生成上下文
机制主题1:① 语义令牌与字典
一、调整前：四个角色的真实反馈
在没有语义域之前，组件的语义归属处于"谁都说得通"的状态。用各角色自己的话说：
设计系统负责人的真实反馈："组件库一升级，语义跟着重写，返工从头来过。"
<Button type="danger">自带"危险"语义——但同一个按钮，在"删除临时草稿"场景里是可逆操作，在"删除生产数据库"场景里是不可逆高危。语义内生于组件，组件库升级时语义跟着重写；同一个<ErrorAlert>在"网络抖动"和"系统崩溃"场景语义不同，分类无法表达。AI 工程师的真实反馈："视觉对了，语义错了——高危操作被画成了普通操作。"
Alert只是圆角、图标位、关闭按钮的容器。AI 不知道这个容器在交易确认场景里是阻断性语义、在信息展示场景里是旁观性语义、在对话中断场景里上下文必须保留——它只能继承视觉惯性。设计师的真实反馈："'错误提示要克制'，十条产品线解读出十种实现。"
"克制"和"醒目"没有边界定义，同一份规范被各自理解，规范越厚，分歧越多。前端的真实反馈："type='error' 一个参数打天下，场景信息全丢了。"
一个参数无法回答：用户在这个界面点是主动操作还是被动接收？上下文要不要保留？数据会不会变更？
汇总成一张表：
| 工具 / 环节 | 界面层呈现状态 | 缺失什么 |
|---|---|---|
| 组件库 | 语义内生于组件，升级即重写 | 语义与组件实现的解耦层 |
| AI 生成工具 | 容器无语义身份，靠视觉惯性猜 | "这个组件在此场景承担什么语义"的边界定义 |
| 规范文档 | 形容词无边界，解读发散 | 可判定、可校验的场景归属规则 |
| 前端 | type 单参数，场景信息丢失 |
覆盖层声明接口（overlay="..."） |
四条反馈指向同一个根因：语义没有自己的边界层。它要么长在组件里、跟着实现走，要么飘在文档里、靠人解读——机器拿到的只是一个 type 字符串。
二、按边界统一定义语义，跨边界设防腐层
2003年，Eric Evans 在《Domain-Driven Design》中提出 Bounded Context（限界上下文）——同一个术语在不同业务边界内有不同含义，域内唯一定义，互不污染。这与我们的语义域是同一逻辑：同一个 Alert 在 transactional 域是"阻断确认"，在 observational 域是"旁观通知条"——域内唯一定义，域间含义不同。
同期，Evans 定义了 Anti-Corruption Layer（防腐层）——边界之间做翻译与隔离，非法引用被拒绝。这与我们的跨层禁止规则对应：status.critical 不可用于 observational 域，非法绑定在编译前置校验时直接阻断。域边界靠机器规则维护。
工业界也在做。Microsoft Azure 将 ACL 作为官方架构模式收录，W3C DTCG 已定义 Semantic Token 层。我们在其之上扩展了行为约束与跨域规则。
但行业也有反面的声音。许多设计系统的"语义令牌"只是换名（color-red-500 改叫 color-danger），没有场景定义；组件分类模型在 AI 生成时代系统性失效，<ErrorAlert> 自带语义导致升级时语义跟着重写。这恰恰反证了我们为什么需要覆盖层模型——语义必须外赋于组件（空容器），由域边界统一定义，可被机器校验。
参考链接
- Eric Evans · DDD Reference 2015
https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf - Microsoft Azure · Anti-Corruption Layer Pattern
https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer - W3C DTCG · Design Tokens Format Module 2025.10
https://www.designtokens.org/TR/2025.10/format/ - W3C · Design Tokens Community Group
https://www.w3.org/community/design-tokens/
三、关键设计：语义域模型
3.1 语义域是什么
语义域是组件所处的语义场景边界：域内，术语有唯一定义；跨域，同一术语含义不同；越域引用，机器拦截。 同一个组件在不同域下语义完全不同——
| 语义域 | 特征 | 典型组件 | 约束 |
|---|---|---|---|
| observational 观察型 | 用户被动接收信息，不需要操作 | 错误提示、状态通知、告警卡片 | 禁止要求用户输入；必须提供退出路径；文案必须说明后果 |
| transactional 交易型 | 用户主动触发操作，系统必须反馈结果 | 提交按钮、表单、确认弹窗 | 必须提供操作结果反馈；成功/失败必须明确；不可逆操作必须二次确认 |
| conversational 对话型 | 双向对话，上下文持续累积 | 聊天界面、问答系统、AI 助手 | 必须保留对话上下文；边界动作必须说明会话状态；拒绝时必须提供替代建议 |
| navigational 导航型 | 用户需要方向指引，无数据变更 | 面包屑、步骤指示、返回跳转 | 必须显示当前位置；必须支持回退；禁止附加数据操作 |
3.2 完整示例：Alert 在三域下的语义外赋
同一个空容器 <Alert>，被不同覆盖层引用时获得完全不同的语义与约束：
| 声明 | 覆盖层注入的语义 | 强制约束 |
|---|---|---|
<Alert overlay="transactional" binding="status.critical"> |
阻断器：用户必须立即处理，否则系统状态恶化 | 红色脉冲 + 八边形图标 + 二次确认 + 文案必须说明后果 |
<Alert overlay="observational" binding="status.info"> |
信息条：用户可选择性关注，不影响系统状态 | 蓝色静态 + 信息图标 + 可自动消失 + 禁止附加操作说明 |
<Alert overlay="navigational" binding="action.primary"> |
路径提示：用户需要方向确认，无状态风险 | 品牌色 + 箭头图标 + 显示下一步预览 |
前端不传 type="error"，而是声明覆盖层与绑定，语义由覆盖层强制注入。
3.3 层级与互斥规则（字典 v1.0.0 注册口径）
| 覆盖层 | 层级 | 定义 | 禁止场景 |
|---|---|---|---|
| universal | L0 | 所有界面点的基础属性（可访问性、响应式） | — |
| transactional | L1 | 用户动作会改变系统状态或数据 | 纯信息展示、状态更新、新手引导 |
| observational | L1 | 用户仅接收信息，无需立即行动 | 需要用户决策、需要二次确认、不可逆操作 |
| navigational | L1 | 用户需要方向指引，无数据变更 | 表单提交、数据操作、支付流程 |
| conversational | L1 | 用户与系统双向交流，上下文持续 | 一次性操作、无上下文的状态提示 |
| financial | L2 | transactional 子层：涉及资金流动 | — |
| data-destructive | L2 | transactional 子层：涉及数据删除 | — |
三条强制规则：
- L1 互斥：每个界面点必须且只能被一个 L1 覆盖层覆盖；
- L2 细化而非替代：L2 是对 L1 的细化，使用时叠加而非替换父层约束；
- 注册前置：覆盖层必须在字典中注册，未注册的覆盖层编译管线拒绝识别——域边界即字典边界。
3.4 跨层禁止：域边界的机器形态
域边界不是文档约定，是可判定的机器规则：
| 绑定 | 所属域 | 跨层禁止 | 违反后果 |
|---|---|---|---|
| status.critical | transactional | observational / navigational / conversational | 编译阻断（block） |
| status.warning | transactional | observational / navigational / conversational | 编译阻断（block） |
| status.info | observational | transactional | 编译阻断（block） |
| status.success | observational | transactional | 编译阻断（block） |
| action.destructive | transactional | observational / navigational / conversational | 编译阻断（block） |
| action.primary | navigational | transactional / observational | 编译阻断（block） |
跨层禁止如何被逐层守住（编译期 / Lint 期 / 生成期），验证设计见 D-V5《跨层禁止如何被机器守住》。
四、架构层概念：设计背景
覆盖层（Overlay）不是分类（Taxonomy）。分类模型语义内生于组件——<ErrorAlert> 自带"错误"语义，组件库升级时语义跟随重写；覆盖层模型语义外赋于组件——组件是空容器（<Alert> 只负责渲染），语义由覆盖层强制注入。组件库是底层（Underlay），语义覆盖层在组件之上加盖业务语义，把空容器翻译为业务语义组件。覆盖层不是分类的替代，是分类之上的场景语义层。
域即边界，边界即契约的锚点。YAML 契约的 semantic_domain 字段引用字典已注册的覆盖层——契约不是自由写作，是"在某个语义域的边界内"定义实例。引用而非自创：字典没有的域，先走字典变更流程注册，非法引用在编译前置校验时直接阻断。
在全景中的位置。语义域是字典第一层（覆盖层目录），位于元规则层最上游：语义域（边界）→ 语义绑定（域内定义）→ 场景映射（域内实例）→ YAML 契约（引用域）→ 编译管线（校验域）。域不确定，其后的绑定、场景、契约全部失去锚点。
术语双轨。语义域 ≈ 覆盖层目录；两套术语指向同一份注册表，面向不同读者群使用。
五、这些坑怎么被解掉：四条反馈的闭环
踩过的坑 1："删除草稿和删除生产库，按钮长得一模一样"
- 症状：同一个
<Button type="danger">，"删除临时草稿"（可逆）与"删除生产数据库"（不可逆高危）被画成同一模样。 - 根因：语义内生于组件，
type参数不携带场景信息，可逆与不可逆无从区分。 - 关联机制：②语义域（本篇）+ ①语义令牌（
action.destructive） - 解法路径：声明
overlay="transactional"+action.destructive后，高危场景被强制注入二次确认与不可恢复说明。前端与 AI 工程师不再靠type参数猜语义，声明覆盖层即继承约束。 - 验证方式：同一组件在两场景下产出差异化表达，高危场景的二次确认不可被生成器省略。
踩过的坑 2："组件库升个级，语义资产跟着清零"
- 症状：分类模型下
<ErrorAlert>升级即语义重写，换库等于返工。 - 根因：语义定义绑死在组件实现里，没有独立资产层。
- 关联机制：②语义域（覆盖层架构）
- 解法路径：覆盖层模型下语义定义在字典中，组件库换成 Ant Design / 自研库均可挂载。
- 验证方式：设计系统负责人换库时语义资产零损耗，升级不再返工。
踩过的坑 3："一句'要克制'，十条产品线十种理解"
- 症状："错误提示要克制"被解读成十种实现，规范越写越厚、分歧越来越大。
- 根因：形容词没有边界定义，不可判定、不可校验。
- 关联机制：②语义域（
observational域约束） - 解法路径：
observational域把"克制"翻译为可判定约束：禁止要求输入、必须提供退出路径、文案必须说明后果。 - 验证方式：设计师的验收争议从"够不够克制"变成"违反了哪条域约束"，跨产品线语义天然一致。
踩过的坑 4："AI 把限流提示画成了致命红"
- 症状：AI 生成限流提示时使用
status.critical的致命红，用户以为账户出了问题。 - 根因：AI 不知道场景归属，视觉惯性替代语义判断。
- 关联机制：②语义域 + D-V5（跨层禁止的机器守护）
- 解法路径：限流的域归属
observational，status.critical在该域为非法绑定，CI 阻断。 - 验证方式：AI 工程师的场景误用在生成前即无法成立，不靠走查事后纠正。
六、调整后：工具界面层的呈现状态
| 工具 / 环节 | 调整前 | 调整后 |
|---|---|---|
| 组件库 | 语义内生，升级即重写 | 空容器 + 可注入接口；语义定义在字典，组件库自由替换 |
| AI 生成工具 | 容器无语义身份 | Prompt 前缀携带域约束：observational 域禁止要求输入、transactional 域必须二次确认——同模型同任务，产出按域分级 |
| 契约编辑器 | 手填语义，自由发挥 | 覆盖层下拉自字典，选域即继承该域全部约束，杜绝自创 |
| 验收环节 | "这里不该用这个组件"的直觉争议 | 域归属校验 + 互斥校验 + 跨层禁止校验，结论定位到具体域条款 |
边界声明
语义域不解决域内语义级别的细分（那是语义令牌与绑定的职责，见主题行①），不定义具体场景的约束实例（那是 YAML 契约的职责，见主题行③），也不约束"域被不被正确引用"（机器防线见 D-V5，消费纪律在角色侧）。当前量化收益均为数据模型推演，待生产数据验证。
1920
