② 语义域：组件是空容器，语义由场景定义

框架设计背景本文是 Schema-As-Code 证据链 的框架设计站。在前序章节中 阶段一 Guard 结构化诊断 通过 组件语义快照 与 三层判定模型 发现了 6 个漂移模式 阶段二 Contract 语义契约化 将设计意图写入了 YAML 契约 语义令牌表 把语义概念编码为机器可运算的离散值。但令牌表回答的是有哪些语义值没回答这些值住在哪里是住在组件名称里还是住在场景上下文里本文要建立的正是 Schema-As-Code 的语义地基当 语义规范体系 需要被消费时语义必须由场景外赋于组件而非内生于组件名称。1. 问题语义住在组件名里还是住在场景里行业现状是语义住在组件名里ErrorAlert自带错误语义Button typedanger自带危险语义。这导致三个系统性问题●升级即重写组件库把 ErrorAlert 改成 StatusBanner所有引用处的语义跟着重写业务含义被组件名称绑架●一名多义同一个Alert在交易场景是阻断确认在通知场景是旁观提示分类模型无法表达同一组件在不同场景下的语义差异●换名不换义设计系统把 color-red-500 改叫 color-dangerAI 把 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 / informationalL2 语义绑定叠加于 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在观察/信息场景observationalAlert阻断器红色脉冲 必须处理 阻断操作信息条蓝色静态 可忽略 不阻断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 typedanger自带危险语义——但同一个按钮在删除临时草稿场景里是可逆操作在删除生产数据库场景里是不可逆高危。语义内生于组件组件库升级时语义跟着重写同一个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 overlaytransactional bindingstatus.critical阻断器用户必须立即处理否则系统状态恶化红色脉冲 八边形图标 二次确认 文案必须说明后果Alert overlayobservational bindingstatus.info信息条用户可选择性关注不影响系统状态蓝色静态 信息图标 可自动消失 禁止附加操作说明Alert overlaynavigational bindingaction.primary路径提示用户需要方向确认无状态风险品牌色 箭头图标 显示下一步预览前端不传 type“error”而是声明覆盖层与绑定语义由覆盖层强制注入。【演示环境同一个空容器不同语义外赋】在演示环境中同一个Alert组件在四个不同覆盖层下呈现完全不同的语义表达transactional 域 · 阻断器Alert overlaytransactional bindingstatus.critical 系统级故障对话上下文可能丢失 [刷新页面] [导出历史]● 视觉红色脉冲 八边形图标● 行为必须二次确认 恢复路径● 文案必须说明后果严重性● 覆盖层标签transactional · status.criticalobservational 域 · 信息条Alert overlayobservational bindingstatus.info ℹ️ 新功能上线智能摘要已支持 PDF 文档● 视觉蓝色静态 信息图标● 行为可自动消失● 文案禁止附加操作说明● 覆盖层标签observational · status.infonavigational 域 · 路径提示Alert overlaynavigational bindingaction.primary → 下一步确认订单信息● 视觉品牌色 箭头图标● 行为点击后跳转● 文案显示下一步预览● 覆盖层标签navigational · action.primaryconversational 域 · 对话边界Alert overlayconversational bindingboundary.refusal 我无法回答这个问题。你可以尝试换个问法或开始一个新话题。● 视觉紫色提示 对话图标● 行为保留输入框 提供替代建议● 文案必须说明会话状态● 覆盖层标签conversational · boundary.refusal3.3 层级与互斥规则字典 v1.0.0 注册口径覆盖层层级定义禁止场景universalL0所有界面点的基础属性可访问性、响应式—transactionalL1用户动作会改变系统状态或数据纯信息展示、状态更新、新手引导observationalL1用户仅接收信息无需立即行动需要用户决策、需要二次确认、不可逆操作navigationalL1用户需要方向指引无数据变更表单提交、数据操作、支付流程conversationalL1用户与系统双向交流上下文持续一次性操作、无上下文的状态提示financialL2transactional 子层涉及资金流动—data-destructiveL2transactional 子层涉及数据删除—三条强制规则L1 互斥每个界面点必须且只能被一个 L1 覆盖层覆盖L2 细化而非替代L2 是对 L1 的细化使用时叠加而非替换父层约束注册前置覆盖层必须在字典中注册未注册的覆盖层编译管线拒绝识别——域边界即字典边界。【演示环境互斥规则验证】✓ 合法单一 L1 覆盖Modal overlaytransactional Alert bindingstatus.critical / Form / Button bindingaction.destructive / /Modal● L1 覆盖transactional ✓● L2 叠加status.critical action.destructive ✓● 编译结果通过 ✓✕ 非法双重 L1 覆盖Modal overlaytransactional overlayobservational ← 冲突 Alert bindingstatus.critical / Alert bindingstatus.info / ← 冲突 /Modal● [CI 阻断] overlay-mutual-exclusion● 错误界面点同时声明了 transactional 和 observational 两个 L1 覆盖层● 规则每个界面点必须且只能被一个 L1 覆盖层覆盖● 编译结果阻断 ✕3.4 跨层禁止域边界的机器形态域边界不是文档约定是可判定的机器规则绑定所属域跨层禁止违反后果status.criticaltransactionalobservational / navigational / conversational编译阻断blockstatus.warningtransactionalobservational / navigational / conversational编译阻断blockstatus.infoobservationaltransactional编译阻断blockstatus.successobservationaltransactional编译阻断blockaction.destructivetransactionalobservational / navigational / conversational编译阻断blockaction.primarynavigationaltransactional / observational编译阻断block跨层禁止如何被逐层守住编译期 / Lint 期 / 生成期验证设计见 《跨层禁止如何被机器守住》。【演示环境跨层禁止验证】场景限流提示observational 域AI 生成器输出非法Alert overlayobservational bindingstatus.critical ← 跨层非法 请求过于频繁请稍后再试 /Alert● [CI 阻断] cross-layer-forbidden● 错误status.critical 在 observational 域为非法绑定● 期望status.warning黄色静态 时钟图标● 编译结果阻断 ✕修正后合法Alert overlayobservational bindingstatus.warning ← 合法 请求频率已达上限42 分钟后重试 /Alert● ✓ 跨层校验通过● status.warning 在 observational 域合法● 视觉黄色静态 时钟图标 倒计时● 编译结果通过 ✓四、架构层概念设计背景覆盖层不是分类。 分类模型语义内生于组件ErrorAlert自带错误语义组件库升级时语义跟随重写覆盖层模型语义外赋于组件组件是空容器Alert只负责渲染语义由覆盖层强制注入。组件库是底层语义覆盖层在组件之上加盖业务语义把空容器翻译为业务语义组件。覆盖层不是分类的替代是分类之上的场景语义层。域即边界边界即契约的锚点。 YAML 契约 的 semantic_domain 字段引用字典已注册的覆盖层契约不是自由写作是在某个语义域的边界内定义实例。引用而非自创字典没有的域先走字典变更流程注册非法引用在编译前置校验时直接阻断。在全景中的位置。 语义域是字典第一层覆盖层目录位于元规则层最上游语义域边界→ 语义绑定域内定义→ 场景映射域内实例→ YAML 契约引用域→ 编译管线校验域。域不确定其后的绑定、场景、契约全部失去锚点。术语双轨。 语义域 ≈ 覆盖层目录两套术语指向同一份注册表面向不同读者群使用。五、这些坑怎么被解掉四条反馈的闭环踩过的坑 1“删除草稿和删除生产库按钮长得一模一样”● 症状同一个Button typedanger“删除临时草稿”可逆与删除生产数据库不可逆高危被画成同一模样。● 根因语义内生于组件type 参数不携带场景信息可逆与不可逆无从区分。● 关联机制语义域本篇 语义令牌● 解法路径声明 overlay“transactional” action.destructive 后高危场景被强制注入二次确认与不可恢复说明。前端与 AI 工程师不再靠 type 参数猜语义声明覆盖层即继承约束。● 验证方式同一组件在两场景下产出差异化表达高危场景的二次确认不可被生成器省略。坑 1删除草稿 删除生产库 根因语义绑死在组件实现里 解法overlaytransactional action.destructive → 强制注入二次确认 不可恢复说明 验证同一组件在两场景下产出差异化表达踩过的坑 2“组件库升个级语义资产跟着清零”● 症状分类模型下ErrorAlert升级即语义重写换库等于返工。● 根因语义定义绑死在组件实现里没有独立资产层。● 关联机制语义域覆盖层架构● 解法路径覆盖层模型下语义定义在字典中组件库换成 Ant Design / 自研库均可挂载。● 验证方式设计系统负责人换库时语义资产零损耗升级不再返工。坑 2组件库升级语义资产清零 根因语义定义绑死在组件实现里 解法覆盖层模型下语义定义在字典中 → 组件库换成 Ant Design / 自研库均可挂载 验证换库时语义资产零损耗踩过的坑 3“一句’要克制’十条产品线十种理解”● 症状错误提示要克制被解读成十种实现规范越写越厚、分歧越来越大。● 根因形容词没有边界定义不可判定、不可校验。● 关联机制语义域observational 域约束● 解法路径observational 域把克制翻译为可判定约束禁止要求输入、必须提供退出路径、文案必须说明后果。● 验证方式设计师的验收争议从够不够克制变成违反了哪条域约束跨产品线语义天然一致。坑 3要克制十种理解 根因形容词无边界不可判定 解法observational 域把克制翻译为可判定约束 → 禁止要求输入 / 必须提供退出路径 / 文案必须说明后果 验证验收争议变成违反了哪条域约束踩过的坑 4“AI 把限流提示画成了致命红”● 症状AI 生成限流提示时使用 status.critical 的致命红用户以为账户出了问题。● 根因AI 不知道场景归属视觉惯性替代语义判断。● 关联机制语义域 跨层禁止的机器守护● 解法路径限流的域归属 observationalstatus.critical 在该域为非法绑定CI 阻断。● 验证方式AI 工程师的场景误用在生成前即无法成立不靠走查事后纠正。坑 4AI 把限流画成致命红 根因AI 不知道场景归属靠视觉惯性猜 解法限流归属 observationalstatus.critical 在该域非法 → CI 跨层禁止阻断 验证场景误用在生成前即无法成立六、调整后工具界面层的呈现状态工具 / 环节调整前调整后组件库语义内生升级即重写空容器 可注入接口语义定义在字典组件库自由替换AI 生成工具容器无语义身份Prompt 前缀携带域约束observational 域禁止要求输入、transactional 域必须二次确认——同模型同任务产出按域分级契约编辑器手填语义自由发挥覆盖层下拉自字典选域即继承该域全部约束杜绝自创验收环节这里不该用这个组件的直觉争议域归属校验 互斥校验 跨层禁止校验结论定位到具体域条款七、一句话总结给不同角色给设计师“以前设计系统告诉你’按钮长什么样’现在语义域告诉你’这个按钮在这个场景下意味着什么’。先定场景再定组件样式不会跑偏。”给前端 / AI 工程师“以前给 AI 的指令是’生成红色按钮’AI 不知道什么意思。现在给 AI 的指令是’生成 transactional 场景下的 destructive_action’AI 查字典自动映射红色空心 二次确认。”给 DesignOps“以前组件库只有’视觉分类’按钮、卡片、弹窗现在增加了’语义分类’交易页、信息页、导航页、对话页。规范从’管形态’升级到’管场景’。”给语义翻译设计师 / 体验架构师“语义域是你的’翻译框架’。设计师说’这里要一个删除按钮’你翻译成’transactional 场景 destructive_action 语义绑定’机器就能查字典生成唯一正确的界面。”给管理层 / 决策者“以前 AI 生成界面靠猜样式返工率 30%。现在先定场景再生成语义域作为查表入口AI 生成准确率从 70% 提升到 95%。”边界声明语义域不解决域内语义级别的细分那是语义令牌与绑定的职责不定义具体场景的约束实例那是 YAML 契约的职责也不约束域被不被正确引用机器防线消费纪律在角色侧。当前量化收益均为数据模型推演待生产数据验证。