框架设计背景
本文是 Schema-As-Code 证据链 的"框架设计"站。在前序章节中， 阶段一 Guard 结构化诊断 通过 组件语义快照 与 三层判定模型 发现了 6 个漂移模式； 阶段二 Contract 语义契约化 将设计意图写入了 YAML 契约； 语义令牌表 把语义概念编码为机器可运算的离散值。但令牌表回答的是"有哪些语义值"，没回答"这些值住在哪里"，是住在组件名称里，还是住在场景上下文里？本文要建立的正是 Schema-As-Code 的语义地基：当 语义规范体系 需要被消费时，语义必须由场景外赋于组件，而非内生于组件名称。
1. 问题：语义住在组件名里，还是住在场景里？
行业现状是"语义住在组件名里"：<ErrorAlert> 自带"错误"语义，<Button type="danger"> 自带"危险"语义。这导致三个系统性问题：
●升级即重写：组件库把 ErrorAlert 改成 StatusBanner，所有引用处的语义跟着重写，业务含义被组件名称绑架；
●一名多义：同一个 <Alert> 在交易场景是"阻断确认"，在通知场景是"旁观提示"，分类模型无法表达同一组件在不同场景下的语义差异；
●换名不换义：设计系统把 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. 设计思路：空容器 + 语义外赋 + 域边界
本文的设计思路是三个递进命题：
●组件是空容器：<Alert>、<Button>、<Modal> 只是视觉形态的空壳，不携带任何语义。语义由场景外赋，而非内生于名称；
●语义外赋于覆盖层：每个界面点必须且只能被一个 L1 覆盖层声明（transactional / observational / navigational / informational），L2 语义绑定叠加于 L1 之上。语义是"层"的属性，不是"组件"的属性；
●域内唯一定义，域间含义不同：同一个 status.critical 在 transactional 域是"阻断确认的红色"，在 observational 域是非法绑定（ 跨层禁止）。域边界不是评审约定，是机器规则。
这与 DDD 限界上下文同构：同一个术语在不同业务边界内有不同含义，各自自洽，互不污染。我们在界面语义层做了同样的建模—— 语义字典 是域内唯一信源， 契约库 中的 YAML 契约 只是字典的引用。
3.1 按钮本身没有"意思"，放对场景才有"意思"
一个 <Button> 组件，代码层面只是"一个可点击的矩形"。它是"保存"还是"删除"，是"提交"还是"取消"，完全取决于它出现在什么场景里。
同一个按钮，四个场景，四种语义：
| 场景（语义域） | 按钮文案 | 按钮颜色 | 用户心理 | 后果 |
|---|---|---|---|---|
| 交易/操作页（transactional） | 确认删除 | 红色空心 | 紧张，怕点错 | 数据永久丢失 |
| 观察/信息页（observational） | 查看详情 | 蓝色实心 | 好奇，想了解 | 跳转到详情页 |
| 导航/引导页（navigational） | 下一步 | 灰色描边 | 自然，跟着走 | 进入下一流程 |
| 对话/交互页（conversational） | 发送 | 品牌色 | 随意，随时发 | 消息发出 |
为什么这样做：以前设计系统只定义"按钮长什么样"（圆角、padding、字体），不定义"按钮在这个场景下意味着什么"。结果 AI 生成界面时，把"删除"按钮做成了"保存"的样式，用户误触。
3.2 先定场景，再定组件，最后定样式
传统设计流程是"先画组件，再填内容"。语义域的做法是反过来——先问"这是什么类型的页面？"，再问"这个页面里需要什么组件？"，最后才问"这个组件用什么样式？"
三层决策：
第一层：语义域（Semantic Domain）
↓ 这是什么场景？
交易页？信息页？导航页？对话页？
第二层：语义绑定（Semantic Binding）
↓ 这个场景下，组件承载什么语义？
删除按钮 = 高危操作 = 必须二次确认
第三层：视觉映射（Visual Mapping）
↓ 这个语义用什么视觉表达？
红色空心 + 脉冲动画 + 八边形警告图标
为什么这样做：防止"样式先行，语义后置"。AI 生成界面时，如果先选颜色再定场景，很容易"蓝色删除按钮"或"红色保存按钮"。先定场景，语义就不会跑偏。
3.3 同一个组件，跨场景必须换语义
设计系统里的"Alert"组件，在 A 页面是"系统故障警告"，在 B 页面是"新功能提示"。如果两个页面都用同一个 Alert 样式，用户会混淆——到底哪个需要我立刻处理？
演示里的例子：
| 组件 | 在交易/操作场景（transactional） | 在观察/信息场景（observational） |
|---|---|---|
| Alert | 阻断器：红色脉冲 + 必须处理 + 阻断操作 | 信息条：蓝色静态 + 可忽略 + 不阻断 |
| Button | 确认删除：红色空心 + 二次确认 | 查看详情：蓝色实心 + 直接跳转 |
| Modal | 确认弹窗：红色 + 必须明确选择 | 提示弹窗：灰色 + 可点击外部关闭 |
为什么这样做：防止"组件复用"变成"语义复用"。组件可以复用，但语义不能复用。同一个 Alert 在不同场景下，必须是不同的语义表达。
3.4 AI 生成界面时，先问场景，再问组件
以前给 AI 的指令是"生成一个红色按钮"。AI 不知道这个按钮是干什么的，只能猜。现在给 AI 的指令是"生成一个交易场景下的删除操作按钮"——AI 先查语义域字典，发现 transactional + destructive = 红色空心 + 二次确认 + 不可恢复文案。
Prompt 对比：
| 旧指令（无语义域） | 新指令（有语义域） |
|---|---|
| "生成一个红色按钮，文案写删除" | "生成一个 transactional 场景下的 destructive_action 组件" |
| AI 自由发挥，可能给蓝色实心 | AI 查字典，自动映射红色空心 + 二次确认 + 警告文案 |
为什么这样做：把"样式描述"变成"场景描述"。AI 不擅长理解"红色"，但擅长查表"transactional + destructive = 什么样式"。
3.5 语义域是"查表"的第一把钥匙
你的语义字典里有几千个词，AI 怎么知道用哪个？第一步不是查词，而是查场景——先确定"这是什么语义域"，再在这个域下查具体的语义令牌。
查表路径：
用户说："我要一个删除账户的界面"
↓
第一步：定语义域 → transactional（交易/操作页，会改数据）
↓
第二步：定语义绑定 → destructive_action（不可逆操作）
↓
第三步：查字典 → status.critical + action.destructive + 组件 Alert + Button + Modal
↓
第四步：输出 → 红色空心删除按钮 + 二次确认弹窗 + 不可恢复警告
为什么这样做：没有语义域，字典就是一本乱序的词典。有了语义域，字典变成"分类目录"——先翻到"交易页"这一章，再查"删除操作"这一节。
3.6 五条思路的依赖关系
第1条：组件本身无意义，场景赋予意义（空容器）
↓
第3条：同一个组件跨场景必须换语义（场景绑定）
↓
第2条：先定场景，再定组件，最后定样式（决策顺序）
↓
第5条：语义域是查表的第一把钥匙（检索入口）
↓
第4条：AI 生成时先问场景再问组件（Prompt 改造）
4. 本文的核心命题
"组件是空容器，语义由场景定义"必须翻译成可验证的框架设计。本文回答三个命题：
| 命题 | 验证标准 |
|---|---|
| 组件不携带语义 | 同一 <Alert> 在不同覆盖层下可承载完全不同的语义绑定，且绑定由字典定义而非组件名称决定 |
| 语义外赋于覆盖层 | 每个界面点必须且只能被一个 L1 覆盖；L2 绑定必须叠加于 L1 之上，不可独立声明 |
| 域内唯一、域间隔离 | status.critical 在 transactional 域合法，在 observational 域非法；跨域绑定被 跨层禁止规则 拦截 |
一、调整前：四个角色的真实反馈
在没有语义域之前，组件的语义归属处于"谁都说得通"的状态。用各角色自己的话说：
设计系统负责人的真实反馈："组件库一升级，语义跟着重写，返工从头来过。"
<Button type="danger">自带"危险"语义——但同一个按钮，在"删除临时草稿"场景里是可逆操作，在"删除生产数据库"场景里是不可逆高危。语义内生于组件，组件库升级时语义跟着重写；同一个<ErrorAlert>在"网络抖动"和"系统崩溃"场景语义不同，分类无法表达。
AI 工程师的真实反馈："视觉对了，语义错了——高危操作被画成了普通操作。"
Alert 只是圆角、图标位、关闭按钮的容器。AI 不知道这个容器在交易确认场景里是阻断性语义、在信息展示场景里是旁观性语义、在对话中断场景里上下文必须保留——它只能继承视觉惯性。
设计师的真实反馈："'错误提示要克制'，十条产品线解读出十种实现。"
"克制"和"醒目"没有边界定义，同一份规范被各自理解，规范越厚，分歧越多。
前端的真实反馈："type='error' 一个参数打天下，场景信息全丢了。"
一个参数无法回答：用户在这个界面点是主动操作还是被动接收？上下文要不要保留？数据会不会变更？
汇总成一张表：
| 工具 / 环节 | 界面层呈现状态 | 缺失什么 |
|---|---|---|
| 组件库 | 语义内生于组件，升级即重写 | 语义与组件实现的解耦层 |
| AI 生成工具 | 容器无语义身份，靠视觉惯性猜 | "这个组件在此场景承担什么语义"的边界定义 |
| 规范文档 | 形容词无边界，解读发散 | 可判定、可校验的场景归属规则 |
| 前端 | type 单参数，场景信息丢失 | 覆盖层声明接口（overlay="..."） |
四条反馈指向同一个根因：语义没有自己的边界层。它要么长在组件里、跟着实现走，要么飘在文档里、靠人解读——机器拿到的只是一个 type 字符串。
二、按边界统一定义语义，跨边界设防腐层
按边界统一定义语义、跨边界设防腐层——这不是新理论，是软件工程验证过的老方法。
语义域 = DDD 限界上下文
Eric Evans 2003 年提出的核心概念：同一个术语在不同业务边界内含义不同，域内必须唯一定义。我们的语义域直接对应这个逻辑——同一个 Alert，在交易域是"阻断确认"，在观察域是"旁观通知"，在导航域是"路径提示"。组件只是空容器，语义由域边界外赋。
跨层禁止 = DDD 防腐层
ACL 的核心是：跨边界的引用必须经过显式转换，非法引用被拒绝。我们的跨层禁止规则就是这个逻辑的实例化，status.critical 不可用于观察域，非法绑定在编译前置校验时直接阻断。域边界不靠评审纪律，靠机器规则维护。
反证：为什么分类模型（Taxonomy）在 AI 时代失效
传统设计系统靠组件分类自带语义（如 ），但 AI 生成时组件名称不代表真实语义，升级时语义跟着重写，同一组件在不同场景语义也不同。这反证了覆盖层模型的必要性——语义必须外赋于组件，由域边界统一定义，可被机器校验。
参考链接
● 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"，而是声明覆盖层与绑定，语义由覆盖层强制注入。
在演示环境中，同一个 <Alert> 组件在四个不同覆盖层下呈现完全不同的语义表达：
transactional 域 · 阻断器
<Alert overlay="transactional" binding="status.critical">
🚨 系统级故障，对话上下文可能丢失
[刷新页面] [导出历史]
● 视觉：红色脉冲 + 八边形图标
● 行为：必须二次确认 + 恢复路径
● 文案：必须说明后果严重性
● 覆盖层标签：transactional · status.critical
observational 域 · 信息条
<Alert overlay="observational" binding="status.info">
ℹ️ 新功能上线：智能摘要已支持 PDF 文档
● 视觉：蓝色静态 + 信息图标
● 行为：可自动消失
● 文案：禁止附加操作说明
● 覆盖层标签：observational · status.info
navigational 域 · 路径提示
<Alert overlay="navigational" binding="action.primary">
→ 下一步：确认订单信息
● 视觉：品牌色 + 箭头图标
● 行为：点击后跳转
● 文案：显示下一步预览
● 覆盖层标签：navigational · action.primary
conversational 域 · 对话边界
<Alert overlay="conversational" binding="boundary.refusal">
💬 我无法回答这个问题。你可以尝试换个问法，或开始一个新话题。
● 视觉：紫色提示 + 对话图标
● 行为：保留输入框 + 提供替代建议
● 文案：必须说明会话状态
● 覆盖层标签：conversational · boundary.refusal
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 的细化，使用时叠加而非替换父层约束；
- 注册前置：覆盖层必须在字典中注册，未注册的覆盖层编译管线拒绝识别——域边界即字典边界。
✓ 合法：单一 L1 覆盖
<Modal overlay="transactional">
<Alert binding="status.critical" />
<Form />
<Button binding="action.destructive" />
</Modal>
● L1 覆盖：transactional ✓
● L2 叠加：status.critical + action.destructive ✓
● 编译结果：通过 ✓
✕ 非法：双重 L1 覆盖
<Modal overlay="transactional"
overlay="observational"> ← 冲突
<Alert binding="status.critical" />
<Alert binding="status.info" /> ← 冲突
</Modal>
● [CI 阻断] overlay-mutual-exclusion
● 错误：界面点同时声明了 transactional 和 observational 两个 L1 覆盖层
● 规则：每个界面点必须且只能被一个 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 期 / 生成期），验证设计见 《跨层禁止如何被机器守住》。
场景：限流提示（observational 域）
AI 生成器输出（非法）：
<Alert overlay="observational"
binding="status.critical"> ← 跨层非法
请求过于频繁，请稍后再试
</Alert>
● [CI 阻断] cross-layer-forbidden
● 错误：status.critical 在 observational 域为非法绑定
● 期望：status.warning（黄色静态 + 时钟图标）
● 编译结果：阻断 ✕
修正后（合法）：
<Alert overlay="observational"
binding="status.warning"> ← 合法
请求频率已达上限，42 分钟后重试
</Alert>
● ✓ 跨层校验通过
● status.warning 在 observational 域合法
● 视觉：黄色静态 + 时钟图标 + 倒计时
● 编译结果：通过 ✓
四、架构层概念：设计背景
覆盖层不是分类。 分类模型语义内生于组件，<ErrorAlert> 自带"错误"语义，组件库升级时语义跟随重写；覆盖层模型语义外赋于组件，组件是空容器（<Alert> 只负责渲染），语义由覆盖层强制注入。组件库是底层，语义覆盖层在组件之上加盖业务语义，把空容器翻译为业务语义组件。覆盖层不是分类的替代，是分类之上的场景语义层。
域即边界，边界即契约的锚点。 YAML 契约 的 semantic_domain 字段引用字典已注册的覆盖层，契约不是自由写作，是"在某个语义域的边界内"定义实例。引用而非自创：字典没有的域，先走字典变更流程注册，非法引用在编译前置校验时直接阻断。
在全景中的位置。 语义域是字典第一层（覆盖层目录），位于元规则层最上游：语义域（边界）→ 语义绑定（域内定义）→ 场景映射（域内实例）→ YAML 契约（引用域）→ 编译管线（校验域）。域不确定，其后的绑定、场景、契约全部失去锚点。
术语双轨。 语义域 ≈ 覆盖层目录；两套术语指向同一份注册表，面向不同读者群使用。
五、这些坑怎么被解掉：四条反馈的闭环
踩过的坑 1："删除草稿和删除生产库，按钮长得一模一样"
● 症状：同一个 <Button type="danger">，"删除临时草稿"（可逆）与"删除生产数据库"（不可逆高危）被画成同一模样。
● 根因：语义内生于组件，type 参数不携带场景信息，可逆与不可逆无从区分。
● 解法路径：声明 overlay="transactional" + action.destructive 后，高危场景被强制注入二次确认与不可恢复说明。前端与 AI 工程师不再靠 type 参数猜语义，声明覆盖层即继承约束。
● 验证方式：同一组件在两场景下产出差异化表达，高危场景的二次确认不可被生成器省略。
坑 1：删除草稿 = 删除生产库
根因：语义绑死在组件实现里
解法：overlay="transactional" + action.destructive
→ 强制注入二次确认 + 不可恢复说明
验证：同一组件在两场景下产出差异化表达
踩过的坑 2："组件库升个级，语义资产跟着清零"
● 症状：分类模型下 <ErrorAlert> 升级即语义重写，换库等于返工。
● 根因：语义定义绑死在组件实现里，没有独立资产层。
● 关联机制：语义域（覆盖层架构）
● 解法路径：覆盖层模型下语义定义在字典中，组件库换成 Ant Design / 自研库均可挂载。
● 验证方式：设计系统负责人换库时语义资产零损耗，升级不再返工。
坑 2：组件库升级，语义资产清零
根因：语义定义绑死在组件实现里
解法：覆盖层模型下语义定义在字典中
→ 组件库换成 Ant Design / 自研库均可挂载
验证：换库时语义资产零损耗
踩过的坑 3："一句'要克制'，十条产品线十种理解"
● 症状："错误提示要克制"被解读成十种实现，规范越写越厚、分歧越来越大。
● 根因：形容词没有边界定义，不可判定、不可校验。
● 关联机制：语义域（observational 域约束）
● 解法路径：observational 域把"克制"翻译为可判定约束：禁止要求输入、必须提供退出路径、文案必须说明后果。
● 验证方式：设计师的验收争议从"够不够克制"变成"违反了哪条域约束"，跨产品线语义天然一致。
坑 3："要克制"十种理解
根因：形容词无边界，不可判定
解法：observational 域把"克制"翻译为可判定约束
→ 禁止要求输入 / 必须提供退出路径 / 文案必须说明后果
验证：验收争议变成"违反了哪条域约束"
踩过的坑 4："AI 把限流提示画成了致命红"
● 症状：AI 生成限流提示时使用 status.critical 的致命红，用户以为账户出了问题。
● 根因：AI 不知道场景归属，视觉惯性替代语义判断。
● 解法路径：限流的域归属 observational，status.critical 在该域为非法绑定，CI 阻断。
● 验证方式：AI 工程师的场景误用在生成前即无法成立，不靠走查事后纠正。
坑 4：AI 把限流画成致命红
根因：AI 不知道场景归属，靠视觉惯性猜
解法：限流归属 observational，status.critical 在该域非法
→ CI 跨层禁止阻断
验证：场景误用在生成前即无法成立
六、调整后：工具界面层的呈现状态
| 工具 / 环节 | 调整前 | 调整后 |
|---|---|---|
| 组件库 | 语义内生，升级即重写 | 空容器 + 可注入接口；语义定义在字典，组件库自由替换 |
| AI 生成工具 | 容器无语义身份 | Prompt 前缀携带域约束：observational 域禁止要求输入、transactional 域必须二次确认——同模型同任务，产出按域分级 |
| 契约编辑器 | 手填语义，自由发挥 | 覆盖层下拉自字典，选域即继承该域全部约束，杜绝自创 |
| 验收环节 | "这里不该用这个组件"的直觉争议 | 域归属校验 + 互斥校验 + 跨层禁止校验，结论定位到具体域条款 |
七、一句话总结（给不同角色）
给设计师：
"以前设计系统告诉你'按钮长什么样'，现在语义域告诉你'这个按钮在这个场景下意味着什么'。先定场景，再定组件，样式不会跑偏。"
给前端 / AI 工程师：
"以前给 AI 的指令是'生成红色按钮'，AI 不知道什么意思。现在给 AI 的指令是'生成 transactional 场景下的 destructive_action'，AI 查字典自动映射红色空心 + 二次确认。"
给 DesignOps：
"以前组件库只有'视觉分类'（按钮、卡片、弹窗），现在增加了'语义分类'（交易页、信息页、导航页、对话页）。规范从'管形态'升级到'管场景'。"
给语义翻译设计师 / 体验架构师：
"语义域是你的'翻译框架'。设计师说'这里要一个删除按钮'，你翻译成'transactional 场景 + destructive_action 语义绑定'，机器就能查字典生成唯一正确的界面。"
给管理层 / 决策者：
"以前 AI 生成界面靠猜样式，返工率 30%。现在先定场景再生成，语义域作为查表入口，AI 生成准确率从 70% 提升到 95%。"
边界声明
语义域不解决域内语义级别的细分（那是语义令牌与绑定的职责），不定义具体场景的约束实例（那是 YAML 契约的职责），也不约束"域被不被正确引用"（机器防线，消费纪律在角色侧）。当前量化收益均为数据模型推演，待生产数据验证。
1920
