给设计规范加一本"字典"：让"alert"在组织里只有一个意思

本文是Schema-As-Code 证据链的"认知 + 合法性"站，覆盖主题行①的第二个关键设计，语义字典（Semantic Dictionary，覆盖层注册表）。回答"凭什么成立"：语义字典是组织内唯一定义覆盖层、语义绑定、场景映射的资产，是全组织同一术语坐标系。

1. 三条真实反馈里的"语义三无"

在没有语义字典之前，组织内的"语义"处于三无状态，每条都有团队里的原话为证。

🧑‍💻 真实反馈 1

"评审会上说'这里用一个alert'，散会后发现三个人理解成三个东西。"

前端理解为模态弹窗，设计师指的是顶部通知条，产品经理以为是可以自动消失的 Toast。三个人用同一个词指三个东西，每个人都对。

因为没有任何注册表裁定"alert在这个场景下是什么"。同名异义，无人仲裁。

🧑‍💻 真实反馈 2

"删除账户按钮该红色实心还是橙色描边？最后谁的职级高听谁的。"

新产品线设计"删除账户"流程，一位设计师主张红色实心按钮、一位主张橙色描边，双方都有道理，最终靠职级裁定。

决策依据是个人经验，不可复用、不可跨产品线继承。决策无据，全靠经验。

🧑‍💻 真实反馈 3

"PRD写'需明显提示风险'，交付后才开始吵什么叫'明显'。"

开发按自己的理解实现，验收按自己的理解走查，争议在交付后才爆发。

需求模糊，无法验收。

三条反馈一个根因：组织里没有一份"唯一定义术语"的资产。字典在的时候，它是文档平台里供人阅读的文字；机器要查的时候它不存在。

2. 用语义注册表统一定义

"用语义注册表统一定义"在工业界已有成熟实践。

2024年起，企业数据领域已大规模实践"语义层"概念。Databricks 在其 Semantic Layer Architecture 中将其定义为"business-friendly abstraction layer"，统一跨部门对"客户""订单"等业务术语的理解。这与我们的语义字典同构，Databricks解决数据领域的语义一致性，我们解决界面领域的语义一致性。

架构相同：元数据仓库 → 业务逻辑层 → 治理框架。

2026年，Kyvos 进一步提出 AI-Ready 语义层：没有语义层，AI无法正确解释数据含义。这个逻辑在界面领域同构。

没有语义字典，AI无法正确解释"红色按钮是致命错误还是普通警告"。

软件工程领域更早。DDD的限界上下文定义术语在特定边界内的唯一含义，防腐层防止外部模型污染内部语义。我们的语义域（覆盖层）即Bounded Context：同一个Alert在transactional域与observational域含义不同，各自域内唯一定义；跨层禁止规则即防腐层，status.critical不可用于observational域，非法绑定在编译时阻断。

但行业也有反面的声音。

Design Systems Collective今年指出，很多所谓"语义令牌"只是换名（color-red-500改叫color-danger），没有场景定义。

这恰恰反证了我们为什么需要真正的语义字典，不是换名而是锁义。

参考链接：Databricks Semantic Layer · Kyvos AI-Ready Semantic Layer · DDD Bounded Context · Design Systems Collective

3. 关键设计：语义字典（三层注册表）

语义字典是覆盖层注册表，三层结构：

覆盖层目录（Overlay Catalog）→ 语义重绑定（Semantic Rebinding）→ 场景映射（Scenario Mapping）

3.1 第 1 层：覆盖层目录（全量）

强制规则：每个界面点必须且只能被一个L1覆盖层覆盖（互斥）；L2是对L1的细化而非替代；未注册的覆盖层编译管线拒绝识别。

3.2 第二层：语义重绑定（全量）

绑定是强制的，不是建议：

通用术语的重绑定示例（同一个词，不同覆盖层下绑定为不同语义）：

前端实现时不传 type="error" 参数，而是声明 overlay="transactional"，由覆盖层强制注入语义。非法绑定在编译时直接阻断。

3.3 第三层：场景映射（全量）

场景映射查询实例：设计师查询 SCN-001（删除账户），字典直接给出完整方案。

覆盖层 transactional；语义绑定 status.critical + action.destructive；组件组合 Alert + Button + Modal；文案必须包含"此操作不可恢复"；交互必须输入账户名二次确认。视觉探索在边界内展开，语义方案无需重新发明。

3.4 注册纪律

字典是组织内唯一定义覆盖层、语义绑定与场景映射的资产。三条纪律：

唯一性：全组织同一术语坐标系，任何团队不得维护平行的"私有字典"。

强制性：所有 YAML 契约必须引用字典中的已定义项，不可自创覆盖层或绑定；semantic_domain 的值必须在字典预定义列表中，非法引用在编译前置校验时直接阻断。

先注册、后引用：字典没有的，先走字典变更流程注册（快照证据 → 诊断归档 → 候选模式 → 评审入典），再引用。不为想象中的需求提前定义语义。

4. 架构层概念：设计背景

覆盖层（Overlay）不是分类（Taxonomy）。

分类模型语义内生于组件（ErrorAlert自带"错误"语义，组件库升级时语义跟随重写）；覆盖层模型语义外赋于组件，组件是空容器（Alert 只负责渲染），语义由覆盖层强制注入。

组件库是底层，语义覆盖层在组件之上加盖业务语义，把空容器翻译为业务语义组件。分类回答"这是什么组件"，覆盖层回答"这个组件在此场景下承担什么语义"。

码本，而非术语表。

术语表供人查阅，码本供机器解码：每个绑定是离散索引，编译管线查表后展开为连续约束。这决定了字典的读者不只是设计师，更是编译管线与AI工具。

在全景中的位置。

语义字典位于建设层的最上游（元规则层）：语义字典（上游·元规则）→ YAML契约（中游·实例）→ 编译管线（下游·执行），契约库提供组织级管理。

术语双轨。面向不同读者群时，三层结构有两套叫法：语义域 ≈ 覆盖层目录；语义令牌 ≈ 语义重绑定；场景映射 ≈ 约束注入。两套术语指向同一份注册表。

5. 这些坑怎么被解掉 三条反馈的闭环

回到开头的三条真实反馈，字典就位后它们各自的解法路径。

🧑‍💻 反馈 1 的解法："alert到底是什么"，歧义在引用条目的瞬间消失

• 症状复盘：评审会上"这里用一个alert"，三个人理解成三个东西。
• 根因：没有可引用的唯一定义注册表，术语含义靠各自脑补。
• 解法路径：查字典，ransactional 域的 alert 是阻断确认，observational 域的 alert 是顶部通知条。设计师与产品经理沟通时，用字典条目编号替代形容词；争议以字典为仲裁依据，不再靠职级裁定。
• 验证方式：同样的评审场景，引用条目编号后，三方理解在当次会议对齐，不再"散会后才发现"。

🧑‍💻 反馈 2 的解法："删除账户按钮之争"。决策依据从职级变成注册表

• 症状复盘：红色实心 vs 橙色描边，双方都有道理，靠职级裁定。
• 根因：没有组织级场景语义方案，决策依据是个人经验，不可复用、不可跨产品线继承。
• 解法路径：查询SCN-001，完整语义方案既定（覆盖层 transactional + status.critical + action.destructive + 二次确认），视觉探索在边界内展开。
• 验证方式：跨产品线语义天然一致——下一个产品线遇到"删除账户"，直接引用同一场景映射，不重新争论。

🧑‍💻 反馈 3 的解法："什么叫明显提示风险"需求从形容词升级为可校验引用

• 症状复盘：PRD写"需明显提示风险"，交付后才吵"什么叫明显"。
• 根因：需求用自然语言形容词描述，没有可校验的语义引用。
• 解法路径：PRD改写为"引用场景映射 SCN-001，语义绑定 action.destructive，必须二次确认"。
• 验证方式：验收标准在需求阶段即已确定，交付后的争议消失，因为"明显"已经被翻译成字典里的具体约束。

6. 扩展路线

• 当前：4个L1覆盖层+6个语义绑定+6个场景映射只覆盖证据最充分的6个漂移模式。
• 规划：按业务需求新增覆盖层（如 onboarding 新手引导）、新增绑定（如 status.neutral 中性状态）、新增场景映射（如"批量删除""跨设备同步"）。
• 远期：重构覆盖层分类（如 transactional 拆分为 financial 和 data-operation），主版本变更，全组织升级。

版本治理：新增覆盖层/绑定/场景 = Minor（设计系统负责人审批）；修改既有定义语义 = Major（设计委员会评审）；措辞澄清不改语义 = Patch（DesignOps 直接合并）。

弃用项标记 deprecated 保留至少90天，编译时对引用方输出 warning 并附迁移指引；旧契约可继续引用旧版本字典（多版本共存，编译时按契约声明的字典版本解析）。

7. 调整后工具界面层的呈现状态

边界声明

语义字典不解决视觉值的一致性，不定义具体场景的约束实例，也约束不了"有没有人查它"。当前量化收益均为数据模型推演，待生产数据验证。