当AI生成界面时，组件名称已无法承载语义。本文提出语义域模型：组件是空容器，语义由场景外赋。通过L1覆盖层与L2语义绑定，实现域内唯一定义、跨域防腐，解决升级重写、一名多义等漂移问题。

本文是 Schema-As-Code 证据链 的”框架设计”站。在前序章节中， 阶段一 Guard 结构化诊断 通过 组件语义快照 与 三层判定模型 发现了 6 个漂移模式； 阶段二 Contract 语义契约化 将设计意图写入了 YAML 契约； 语义令牌表 把语义概念编码为机器可运算的离散值。但令牌表回答的是”有哪些语义值”，没回答”这些值住在哪里”，是住在组件名称里，还是住在场景上下文里？本文要建立的正是 Schema-As-Code 的语义地基：当 语义规范体系 需要被消费时，语义必须由场景外赋于组件，而非内生于组件名称。

1. 问题：语义住在组件名里，还是住在场景里？

行业现状是”语义住在组件名里“：<ErrorAlert> 自带”错误”语义，<Button type=”danger”> 自带”危险”语义。这导致三个系统性问题：

1. 升级即重写：组件库把 ErrorAlert 改成 StatusBanner，所有引用处的语义跟着重写，业务含义被组件名称绑架；
2. 一名多义：同一个 <Alert> 在交易场景是”阻断确认”，在通知场景是”旁观提示”，分类模型无法表达同一组件在不同场景下的语义差异；
3. 换名不换义：设计系统把 color-red-500 改叫 color-danger，AI 把 color-danger 用在成功状态的对勾旁边——名字变了，结构没变，语义仍然漂移。

组件语义快照 的 6 字段记录法 已经证明：观察界面时，”这是什么组件”（分类）与”这个组件在此场景承担什么语义”（语义域）是两个独立维度。 6 个漂移模式 中的 ERR-001错误状态后果差异未分级、BND-001边界动作权利差异未区分等，根因都是”分类正确，但语义域归属错误”。

2. 为什么分类模型守不住：语义内生于名称

分类模型（Taxonomy）的假设是：组件名称决定了它的语义。这在人工设计时代勉强可行，设计师画 <ErrorAlert> 时心里知道它是”错误”。但在 AI 生成时代，这个假设系统性失效：

• AI 看到的是 Alert 组件和 red 色值，它不知道“红色在此场景代表什么”；
• 语义令牌表 中的 error_severity 有四级，但分类模型只有”错误/成功/警告”三种组件类型；
• 边界动作诊断 已经证明：拒绝和终止在分类上都是“对话结束”，但在语义域上是“权利还在”与“权利已清空”的根本差异。

分类模型回答”这是什么”，语义域回答”在此场景下它意味着什么”。AI 生成时代，”是什么”已经由组件库回答了，”意味着什么”却无人定义。

3. 设计思路：空容器 + 语义外赋 + 域边界

本文的设计思路是三个递进命题：

1. 组件是空容器：<Alert>、<Button>、<Modal> 只是视觉形态的空壳，不携带任何语义。语义由场景外赋，而非内生于名称；
2. 语义外赋于覆盖层：每个界面点必须且只能被一个 L1 覆盖层声明（transactional / observational / navigational / informational），L2 语义绑定叠加于 L1 之上。语义是”层”的属性，不是”组件”的属性；
3. 域内唯一定义，域间含义不同：同一个 status.critical 在 transactional 域是”阻断确认的红色”，在 observational 域是非法绑定（ 跨层禁止）。域边界不是评审约定，是机器规则。

这与 DDD 限界上下文同构：同一个术语在不同业务边界内有不同含义，各自自洽，互不污染。我们在界面语义层做了同样的建模—— 语义字典 是域内唯一信源， 契约库 中的 YAML 契约 只是字典的引用。

3.1 按钮本身没有”意思”，放对场景才有”意思”

一个 <Button> 组件，代码层面只是”一个可点击的矩形”。它是”保存”还是”删除”，是”提交”还是”取消”，完全取决于它出现在什么场景里。

同一个按钮，四个场景，四种语义：

为什么这样做：以前设计系统只定义”按钮长什么样”（圆角、padding、字体），不定义”按钮在这个场景下意味着什么”。结果 AI 生成界面时，把”删除”按钮做成了”保存”的样式，用户误触。

3.2 先定场景，再定组件，最后定样式

传统设计流程是”先画组件，再填内容”。语义域的做法是反过来——先问”这是什么类型的页面？”，再问”这个页面里需要什么组件？”，最后才问”这个组件用什么样式？”

三层决策：

为什么这样做：防止”样式先行，语义后置”。AI 生成界面时，如果先选颜色再定场景，很容易”蓝色删除按钮”或”红色保存按钮”。先定场景，语义就不会跑偏。

3.3 同一个组件，跨场景必须换语义

设计系统里的”Alert”组件，在 A 页面是”系统故障警告”，在 B 页面是”新功能提示”。如果两个页面都用同一个 Alert 样式，用户会混淆——到底哪个需要我立刻处理？

演示里的例子：

为什么这样做：防止”组件复用”变成”语义复用”。组件可以复用，但语义不能复用。同一个 Alert 在不同场景下，必须是不同的语义表达。

3.4 AI 生成界面时，先问场景，再问组件

以前给 AI 的指令是”生成一个红色按钮”。AI 不知道这个按钮是干什么的，只能猜。现在给 AI 的指令是”生成一个交易场景下的删除操作按钮”——AI 先查语义域字典，发现 transactional + destructive = 红色空心 + 二次确认 + 不可恢复文案。

Prompt 对比

为什么这样做：把”样式描述”变成”场景描述”。AI 不擅长理解”红色”，但擅长查表”transactional + destructive = 什么样式”。

3.5 语义域是”查表”的第一把钥匙

你的语义字典里有几千个词，AI 怎么知道用哪个？第一步不是查词，而是查场景——先确定”这是什么语义域”，再在这个域下查具体的语义令牌。

查表路径：

为什么这样做：没有语义域，字典就是一本乱序的词典。有了语义域，字典变成”分类目录”——先翻到”交易页”这一章，再查”删除操作”这一节。

3.6 五条思路的依赖关系

4. 本文的核心命题

“组件是空容器，语义由场景定义”必须翻译成可验证的框架设计。本文回答三个命题：

4.1 调整前：四个角色的真实反馈

在没有语义域之前，组件的语义归属处于”谁都说得通”的状态。用各角色自己的话说：

设计系统负责人的真实反馈：“组件库一升级，语义跟着重写，返工从头来过。”

<Button type=”danger”> 自带”危险”语义——但同一个按钮，在”删除临时草稿”场景里是可逆操作，在”删除生产数据库”场景里是不可逆高危。语义内生于组件，组件库升级时语义跟着重写；同一个 <ErrorAlert> 在”网络抖动”和”系统崩溃”场景语义不同，分类无法表达。

AI 工程师的真实反馈：“视觉对了，语义错了——高危操作被画成了普通操作。”

Alert 只是圆角、图标位、关闭按钮的容器。AI 不知道这个容器在交易确认场景里是阻断性语义、在信息展示场景里是旁观性语义、在对话中断场景里上下文必须保留——它只能继承视觉惯性。

设计师的真实反馈：“‘错误提示要克制’，十条产品线解读出十种实现。”

“克制”和”醒目”没有边界定义，同一份规范被各自理解，规范越厚，分歧越多。

前端的真实反馈：“type=’error’ 一个参数打天下，场景信息全丢了。”

一个参数无法回答：用户在这个界面点是主动操作还是被动接收？上下文要不要保留？数据会不会变更？

汇总成一张表：

四条反馈指向同一个根因：语义没有自己的边界层。它要么长在组件里、跟着实现走，要么飘在文档里、靠人解读——机器拿到的只是一个 type 字符串。

4.2 按边界统一定义语义，跨边界设防腐层

按边界统一定义语义、跨边界设防腐层——这不是新理论，是软件工程验证过的老方法。

语义域 = DDD 限界上下文

Eric Evans 2003 年提出的核心概念：同一个术语在不同业务边界内含义不同，域内必须唯一定义。我们的语义域直接对应这个逻辑——同一个 Alert，在交易域是”阻断确认”，在观察域是”旁观通知”，在导航域是”路径提示”。组件只是空容器，语义由域边界外赋。

跨层禁止 = DDD 防腐层

ACL 的核心是：跨边界的引用必须经过显式转换，非法引用被拒绝。我们的跨层禁止规则就是这个逻辑的实例化，status.critical 不可用于观察域，非法绑定在编译前置校验时直接阻断。域边界不靠评审纪律，靠机器规则维护。

反证：为什么分类模型（Taxonomy）在 AI 时代失效

传统设计系统靠组件分类自带语义（如 <ErrorAlert>），但 AI 生成时组件名称不代表真实语义，升级时语义跟着重写，同一组件在不同场景语义也不同。这反证了覆盖层模型的必要性——语义必须外赋于组件，由域边界统一定义，可被机器校验。

4.3 关键设计：语义域模型

4.3.1 语义域是什么

语义域是组件所处的语义场景边界：域内，术语有唯一定义；跨域，同一术语含义不同；越域引用，机器拦截。 同一个组件在不同域下语义完全不同

4.3.2 完整示例：Alert 在三域下的语义外赋

同一个空容器 <Alert>，被不同覆盖层引用时获得完全不同的语义与约束：

前端不传 type=”error”，而是声明覆盖层与绑定，语义由覆盖层强制注入。

【演示环境：同一个空容器，不同语义外赋】

在演示环境中，同一个 <Alert> 组件在四个不同覆盖层下呈现完全不同的语义表达：

transactional 域 · 阻断器

视觉：红色脉冲 + 八边形图标

行为：必须二次确认 + 恢复路径

文案：必须说明后果严重性

覆盖层标签：transactional · status.critical

observational 域 · 信息条

视觉：蓝色静态 + 信息图标

行为：可自动消失

文案：禁止附加操作说明

覆盖层标签：observational · status.info

navigational 域 · 路径提示

视觉：品牌色 + 箭头图标

行为：点击后跳转

文案：显示下一步预览

覆盖层标签：navigational · action.primary

conversational 域 · 对话边界

视觉：紫色提示 + 对话图标

行为：保留输入框 + 提供替代建议

文案：必须说明会话状态

覆盖层标签：conversational · boundary.refusal

4.3.3 层级与互斥规则（字典 v1.0.0 注册口径）

三条强制规则：

1. L1 互斥：每个界面点必须且只能被一个 L1 覆盖层覆盖；
2. L2 细化而非替代：L2 是对 L1 的细化，使用时叠加而非替换父层约束；
3. 注册前置：覆盖层必须在字典中注册，未注册的覆盖层编译管线拒绝识别——域边界即字典边界。

【演示环境：互斥规则验证】

✓ 合法：单一 L1 覆盖

L1 覆盖：transactional ✓

L2 叠加：status.critical + action.destructive ✓

编译结果：通过 ✓

✕ 非法：双重 L1 覆盖

[CI 阻断] overlay-mutual-exclusion

错误：界面点同时声明了 transactional 和 observational 两个 L1 覆盖层

规则：每个界面点必须且只能被一个 L1 覆盖层覆盖

编译结果：阻断 ✕

4.3.4 跨层禁止：域边界的机器形态

域边界不是文档约定，是可判定的机器规则：

跨层禁止如何被逐层守住（编译期 / Lint 期 / 生成期），验证设计见 《跨层禁止如何被机器守住》。

【演示环境：跨层禁止验证】

场景：限流提示（observational 域）

AI 生成器输出（非法）：

[CI 阻断] cross-layer-forbidden

错误：status.critical 在 observational 域为非法绑定

期望：status.warning（黄色静态 + 时钟图标）

编译结果：阻断 ✕

修正后（合法）：

✓ 跨层校验通过

status.warning 在 observational 域合法

视觉：黄色静态 + 时钟图标 + 倒计时

编译结果：通过 ✓

4.4 架构层概念：设计背景

覆盖层不是分类。 分类模型语义内生于组件，<ErrorAlert> 自带”错误”语义，组件库升级时语义跟随重写；覆盖层模型语义外赋于组件，组件是空容器（<Alert> 只负责渲染），语义由覆盖层强制注入。组件库是底层，语义覆盖层在组件之上加盖业务语义，把空容器翻译为业务语义组件。覆盖层不是分类的替代，是分类之上的场景语义层。

域即边界，边界即契约的锚点。 YAML 契约 的 semantic_domain 字段引用字典已注册的覆盖层，契约不是自由写作，是”在某个语义域的边界内”定义实例。引用而非自创：字典没有的域，先走字典变更流程注册，非法引用在编译前置校验时直接阻断。

在全景中的位置。 语义域是字典第一层（覆盖层目录），位于元规则层最上游：语义域（边界）→ 语义绑定（域内定义）→ 场景映射（域内实例）→ YAML 契约（引用域）→ 编译管线（校验域）。域不确定，其后的绑定、场景、契约全部失去锚点。

术语双轨。 语义域 ≈ 覆盖层目录；两套术语指向同一份注册表，面向不同读者群使用。

4.5 这些坑怎么被解掉：四条反馈的闭环

踩过的坑 1：“删除草稿和删除生产库，按钮长得一模一样”

症状：同一个 <Button type=”danger”>，”删除临时草稿”（可逆）与”删除生产数据库”（不可逆高危）被画成同一模样。

根因：语义内生于组件，type 参数不携带场景信息，可逆与不可逆无从区分。

关联机制：语义域（本篇）+ 语义令牌

解法路径：声明 overlay=”transactional” + action.destructive 后，高危场景被强制注入二次确认与不可恢复说明。前端与 AI 工程师不再靠 type 参数猜语义，声明覆盖层即继承约束。

验证方式：同一组件在两场景下产出差异化表达，高危场景的二次确认不可被生成器省略。

踩过的坑 2：“组件库升个级，语义资产跟着清零”

症状：分类模型下 <ErrorAlert> 升级即语义重写，换库等于返工。

根因：语义定义绑死在组件实现里，没有独立资产层。

关联机制：语义域（覆盖层架构）

解法路径：覆盖层模型下语义定义在字典中，组件库换成 Ant Design / 自研库均可挂载。

验证方式：设计系统负责人换库时语义资产零损耗，升级不再返工。

踩过的坑 3：“一句‘要克制’，十条产品线十种理解”

症状：”错误提示要克制”被解读成十种实现，规范越写越厚、分歧越来越大。

根因：形容词没有边界定义，不可判定、不可校验。

关联机制：语义域（observational 域约束）

解法路径：observational 域把”克制”翻译为可判定约束：禁止要求输入、必须提供退出路径、文案必须说明后果。

验证方式：设计师的验收争议从”够不够克制”变成”违反了哪条域约束”，跨产品线语义天然一致。

踩过的坑 4：“AI 把限流提示画成了致命红”

症状：AI 生成限流提示时使用 status.critical 的致命红，用户以为账户出了问题。

根因：AI 不知道场景归属，视觉惯性替代语义判断。

关联机制：语义域 + 跨层禁止的机器守护

解法路径：限流的域归属 observational，status.critical 在该域为非法绑定，CI 阻断。

验证方式：AI 工程师的场景误用在生成前即无法成立，不靠走查事后纠正。

4.6 调整后：工具界面层的呈现状态

4.7 一句话总结（给不同角色）

给设计师：

“以前设计系统告诉你’按钮长什么样’，现在语义域告诉你’这个按钮在这个场景下意味着什么’。先定场景，再定组件，样式不会跑偏。”

给前端 / AI 工程师：

“以前给 AI 的指令是’生成红色按钮’，AI 不知道什么意思。现在给 AI 的指令是’生成 transactional 场景下的 destructive_action’，AI 查字典自动映射红色空心 + 二次确认。”

给 DesignOps：

“以前组件库只有’视觉分类’（按钮、卡片、弹窗），现在增加了’语义分类’（交易页、信息页、导航页、对话页）。规范从’管形态’升级到’管场景’。”

给语义翻译设计师 / 体验架构师：

“语义域是你的’翻译框架’。设计师说’这里要一个删除按钮’，你翻译成’transactional 场景 + destructive_action 语义绑定’，机器就能查字典生成唯一正确的界面。”

给管理层 / 决策者：

“以前 AI 生成界面靠猜样式，返工率 30%。现在先定场景再生成，语义域作为查表入口，AI 生成准确率从 70% 提升到 95%。”

边界声明

语义域不解决域内语义级别的细分（那是语义令牌与绑定的职责，见主题行），不定义具体场景的约束实例（那是 YAML 契约的职责），也不约束”域被不被正确引用”（机器防线，消费纪律在角色侧）。当前量化收益均为数据模型推演，待生产数据验证。

附录

演示环境

语义域交互演示：组件是空容器，语义由场景定义

https://2436041978-ops.github.io/semantic-pipeline/mechanism/02-semantic-domain/semantic-domain.html

框架与方法论

阶段一 Guard 结构化诊断（Structured Diagnosis）

https://www.yuque.com/u222739/why7ts/lzwfwmg2iwde0qfw

组件语义快照：我观察 AI 产品界面时用的 6 字段记录法

https://www.yuque.com/u222739/why7ts/eh9r40xm1wwku0os

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

https://www.yuque.com/u222739/why7ts/zz4f1sg57gwnw4ff

结构化诊断：三层判定模型与模式匹配机制

https://www.yuque.com/u222739/why7ts/rdyspgtkuky50zie

从语义快照到结构化诊断：三层判定模型与模式匹配机制

https://www.yuque.com/u222739/why7ts/pvon1gu9c9gc4blh

6 个漂移模式：AI 生成界面的语义断层证据库

https://www.yuque.com/u222739/why7ts/rwlzmucm3lgxzm10

从观察到契约：Semantic Pipeline 的三阶段工作流

https://www.yuque.com/u222739/why7ts/pfaoq6xsftme601m

语义规范与契约

语义规范体系：YAML 里写的不是颜色值，是语义令牌

https://www.yuque.com/u222739/why7ts/ugxdg4go2t7tlf9l

YAML 契约格式：理解了语义规范体系后，怎么写语义规则

https://www.yuque.com/u222739/why7ts/orfwe0f15ga79wdg

契约库：让设计规范像代码一样管理

https://www.yuque.com/u222739/why7ts/cn0l4ewmwvzeqsdo

阶段二 Contract 语义契约化（Semantic Contractualization）：设计师作为”语义翻译者”——当 AI 生成界面时，我怎么用规则锁住设计意图

https://www.yuque.com/u222739/why7ts/xqcb55ikrtpyeqih

编译与验证

编译管线是语义一致性的”机器翻译层”

https://www.yuque.com/u222739/why7ts/yvrpvhwawyb9b54u

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

https://www.yuque.com/u222739/why7ts/kw7qgel1uio0nk2g

跨层禁止：机器如何拦截非法语义绑定

https://www.yuque.com/u222739/why7ts/eh9r40xm1wwku0os

字典引用的机器防线

https://www.yuque.com/u222739/why7ts/pvon1gu9c9gc4blh

前端与 AI 工程师

前端与 AI 工程师

https://www.yuque.com/u222739/why7ts/fa6warny9tu65mpb

Token 层与本文

① Token 层差异：从颜色值到语义状态的三层跃迁（语义令牌表）

https://www.yuque.com/u222739/why7ts/to224eewapfpigp9

① 语义字典引用的机器防线：三层验证，证明语义可被机器执行（本文自身）

https://www.yuque.com/u222739/why7ts/dxsrr7dt1b32clzq