框架设计背景
本文是 Schema-As-Code 证据链 的"框架设计"站，属于主题行的第一个关键设计——语义令牌表（Semantic Token Table）。在前序章节中，阶段一 Guard 结构化诊断 通过 组件语义快照 与 三层判定模型 发现了 6 个漂移模式；语义域 建立了"组件是空容器，语义由场景定义"的覆盖层模型。但语义要能被机器识别、校验与生成，必须先解决一个编码问题：如何把"语义概念"变成"机器可运算的离散值"？本文要建立的正是 Schema-As-Code 的语义编码层——当 语义规范体系 需要被写入 YAML 契约 时，语义必须以离散令牌的形式存在，而非自然语言描述。
1. 问题：语义是"感觉"，还是"可运算的值"？
行业现状中，语义以自然语言或视觉样式存在：设计师说"这个要用红色"，前端看到 #EF4444，AI 生成工具看到 color: red。但"红色"在不同场景下含义完全不同——在 语义域 的 transactional 域它是"阻断确认"，在 observational 域它可能是非法绑定（跨层禁止）。当语义以颜色值、文案词或"感觉"的形式流动时，机器无法区分"同一个红色在不同场景下是否合法"。
6 个漂移模式 中的 ERR-001（错误状态后果差异未分级）根因正是如此：致命错误、网络抖动、限流、降级四种完全不同的后果，共用同一种红色——因为机器看到的只是 color: #EF4444，而不是 error_severity.fatal 与 error_severity.retryable 的语义区别。没有离散令牌，就没有机器可执行的判定依据。
2. 为什么自然语言守不住：语义不可运算
设计规范文档用自然语言描述语义："致命错误用红色脉冲，限流用黄色时钟"。但自然语言对机器是不可运算的：
●AI 生成工具读不懂"致命错误"与"限流"的区别，它的训练语料里只有 red 和 yellow；
●前端工程师看到的是 Design Token color-danger 和 color-warning，但 danger 与 warning 的语义边界没有机器定义，AI 可以把 color-danger 用在成功状态；
●验收走查依赖人的主观判断，"感觉不对"无法转化为可复现的校验规则。
组件语义快照 的 6 字段记录法已经证明：观察界面时需要记录 component_type、visual、copy、interaction、context 等维度。但这些字段的值如果是自由文本（如 color: "red"），仍然不可运算。语义令牌表的作用，就是把"红色"编码为 status.critical，把"限流"编码为 error_severity.retryable——让语义成为机器可查询、可校验、可拦截的离散值。
3. 设计思路：把语义概念编码成离散枚举
本文的设计思路是三个递进命题：
●语义概念 → 离散令牌：error_severity 不是文档里的段落，而是包含 fatal、transient、retryable、degraded 四个枚举值的令牌表；每个枚举值绑定唯一的视觉映射（status.critical → 红色脉冲）与行动约束（必须提供恢复路径）；
●令牌 → 字典注册：所有语义令牌在 语义字典 中注册，成为组织级唯一信源。契约（YAML）不定义令牌，只引用令牌；
●令牌 → 可执行规则：编译管线 将令牌表编译为 Prompt 前缀（注入 AI 上下文）、JSON Schema（组件 Props 校验）、CI 规则（流水线拦截）——同一组离散值，在不同工具链中以不同格式执行同一语义。
这与 语义规范体系 的关系：语义规范体系定义"有哪些语义维度"，语义令牌表定义"每个维度下有哪些离散值"。没有令牌表，规范体系只是分类框架；没有规范体系，令牌表只是孤立枚举。
3.1 把"意思"变成"编号"
机器看不懂"红色代表很危险"，机器看得懂 status.critical。把连续的自然语言描述，变成离散的编号（枚举值）。
Schema-As-Code 语义编码层 · ① 语义令牌表演示环境 里的例子：
- 不说"红色、很紧急、要刷新" → 说 status.critical
- 不说"黄色、等一等、能恢复" → 说 status.warning
- 不说"灰色、加载中、不用管" → 说 status.neutral
为什么这样做：自然语言有同义词（"严重"≈"Critical"≈"危急"），机器会搞混。编号没有同义词，一个编号只对应一个意思。
3.2 一个编号只绑定一套视觉
status.critical 只能是"红色脉冲 + 八边形图标"，不能今天是红色，明天变成橙色。编号和视觉参数是锁死的（一对一映射）。
Schema-As-Code 语义编码层 · ① 语义令牌表演示环境 里的例子：
| 编号 | 颜色 | 动画 | 图标 | 按钮样式 |
|---|---|---|---|---|
| status.critical | 红色 | 脉冲 | 八边形 | 必须二次确认 |
| status.warning | 黄色 | 静态 | 三角 | 显示恢复时间 |
| status.info | 蓝色 | 静态 | 信息 | 可自动消失 |
| status.neutral | 灰色 | 旋转 | 加载 | 无 |
为什么这样做：以前设计规范写"错误用红色"，但不同前端可能用不同红。编号锁死后，机器查表就知道唯一答案。
3.3 同一个编号能翻译成三种格式
设计师写了一份 status.critical 的定义，机器自动把它变成三种东西，给三种不同的人用。
Schema-As-Code 语义编码层 · ① 语义令牌表演示环境 里的三种格式：
| 给谁用 | 格式 | 内容 |
|---|---|---|
| 给 AI 写界面的工程师 | Prompt 前缀 | "生成致命错误时，必须用红色脉冲..." |
| 给校验代码的机器 | JSON Schema | {"color_token": "status.critical", "motion_token": "pulse.red.urgent"} |
| 给 CI 流水线 | 阻断规则 | "如果在 observational 域用 critical，阻断合并" |
为什么这样做：设计师只写一次，三种消费方自动拿到自己需要的东西。不用设计师给工程师写一遍、给运维写一遍、给测试写一遍。
3.4 同一个颜色，不同编号代表不同意思
机器看到 #EF4444（红色）不知道这是"系统故障"还是"删除按钮"。必须看编号才知道。
Schema-As-Code 语义编码层 · ① 语义令牌表演示环境 里的对比：
| 编号 | 都是红色 | 但意思完全不同 | 场景 |
|---|---|---|---|
| status.critical | 红色 | 系统故障，对话可能丢了 | 错误状态 |
| action.destructive | 红色 | 删除账户，数据永久没了 | 操作按钮 |
为什么这样做：以前设计规范只规定"红色用在危险场景"，但机器不知道"危险"有 10 种。编号把"哪种危险"说清楚了。
3.5 编号不能跨层乱用
status.critical（红色脉冲）只能在"错误状态"里用，不能拿到"提示信息"里用。跨层使用会被机器自动阻断。
Schema-As-Code 语义编码层 · ① 语义令牌表演示环境 里的例子：
- 合法：status.critical 用在"消息流中断"（系统故障）
- 非法：status.critical 用在"限流提示"（只是等一等，不是故障）
- 机器拦截：如果 AI 把限流提示做成红色脉冲，CI 直接阻断，代码合不进去
为什么这样做：防止"红色滥用"。以前所有错误都用红色，用户分不清多严重。现在每个编号有指定的"使用范围"，超范围就报错。
4. 本文的核心命题
"把语义编码成离散令牌"必须翻译成可验证的框架设计。本文回答三个命题：
| 命题 | 验证标准 |
|---|---|
| 语义可被离散编码 | error_severity 的四级后果差异能被编码为四个互斥枚举值，而非自然语言描述 |
| 令牌绑定唯一视觉映射 | 每个令牌（如 retryable）绑定且仅绑定一组视觉参数（status.warning + 时钟图标 + 倒计时），不可被自由替换 |
| 令牌可被机器消费 | 同一组令牌能被编译为 Prompt 前缀、JSON Schema、CI 规则三种格式，在不同工具链中执行同一语义判定 |
一、调整前：四个角色的真实反馈
在没有语义令牌之前，各角色在界面层"看到"的世界，用他们自己的话说：
🧑💻 前端与 AI 工程师的真实反馈：
"致命错误和限流提示，被渲染成了同一种红色背景条。"
AI 生成工具里只有 Design Token——color.danger: { value: "#EF4444" }。红色是一个色值，不附带任何场景含义。同一款 AI 对话产品中，"对话可能已丢失"的致命错误与"请求太频繁，请等 30 秒"的限流提示长得一模一样：色板合规、对比度达标，视觉走查挑不出任何毛病，但用户从界面上读不到两者的区别。
🧑💻 设计师与产品经理的真实反馈：
"同一个 alert，三个人三种理解，每个人都没错。"
组件库里的 Alert 只是视觉组件——圆角、图标位、关闭按钮。它不知道自己在交易确认场景里是阻断性语义，在信息展示场景里是旁观性语义。前端理解为弹窗，设计师指的是顶部通知条，两个人都对，因为没有任何注册表裁定。
🧑💻 前端与 AI 工程师的另一条真实反馈：
"LLM 把 Critical 降级为'严重'，代码里查不出来。"
在 LLM 的词汇表里，"Critical"和"严重"是近义词。AI 生成告警时把 "Critical" 替换为"严重"、把 "Data Loss Risk" 替换为"请稍后重试"——情绪权重在概率性输出中被随机降级，而没有任何机制判定这是违规。
🧑💻 DesignOps 与设计系统负责人的真实反馈：
"规范写在文档平台里，人可能看漏，AI 工具完全不可见。"
"错误状态分四级"供人阅读，机器查询不了，更校验不了。
汇总成一张表：
| 工具 / 环节 | 界面层呈现状态 | 缺失什么 |
|---|---|---|
| AI 生成工具 | 只有色值与样式，语义靠概率猜 | "这个红代表什么"的机器可读定义 |
| 组件库 | 组件只有视觉属性 | 组件在不同场景下的语义身份 |
| 文案生成 | 同义词自由替换 | 关键术语的权重锚定 |
| 规范文档 | 供人阅读 | 机器可查询、可校验的注册表 |
这四条反馈指向同一个根因：语义没有被编码成机器可读的东西。红色只是色值，组件只是容器，术语只是字符串——机器拿不到语义，就只能靠概率猜。
二、"把语义编码为离散令牌"不是自创概念
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 生成时代系统性失效， 自带语义导致升级时语义跟着重写。这恰恰反证了我为什么要设计覆盖层模型——语义必须外赋于组件（空容器），由域边界统一定义，可被机器校验。
参考链接：
●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 四大命名空间（码本原子集）
语义令牌按"回答的问题"分为四个命名空间，每个令牌是离散索引，编译管线 查表后展开为连续约束：
status._ —— 这件事有多严重？
| 令牌 | 含义 | 视觉映射示例 |
|---|---|---|
| status.critical | 致命：系统故障、数据丢失 | 红色脉冲 + 八边形警告 |
| status.warning | 警告：限流、降级、可恢复错误 | 黄色提示 + 时钟图标 |
| status.info | 信息：提示、说明、部分可用 | 蓝色静态 + 信息图标 |
| status.success | 成功：保存完成、操作成功 | 绿色静态 + 对勾图标 |
| status.neutral | 中性：加载中、等待中 | 灰色动画 + 旋转图标 |
【 Schema-As-Code 语义编码层 · ① 语义令牌表演示环境：status._ 命名空间令牌卡片】
对应 HTML 演示环境位置：页面中"status._"标签页下的五个彩色令牌卡片（critical 红脉冲 / warning 黄时钟 / info 蓝信息 / success 绿对勾 / neutral 灰旋转），每张卡片展示令牌名、含义、视觉映射（颜色+动画+图标+按钮样式）。
phase._ —— AI 处于什么阶段？用户在等什么？
| 令牌 | 含义 | 视觉映射示例 |
|---|---|---|
| phase.research | 检索：搜索信息、查找来源 | 蓝色 + 放大镜图标 + 来源计数 |
| phase.analysis | 综合：对比多源、识别分歧 | 黄色 + 大脑图标 + 共识度 |
| phase.check | 验证：核对链接、验证事实 | 绿色 + 盾牌图标 + 验证状态 |
| phase.output | 生成：生成答案、输出结果 | 紫色 + 文档图标 + 引用索引 |
boundary._ —— 系统拒绝用户时，权利边界在哪里？
| 令牌 | 含义 | 视觉映射示例 |
|---|---|---|
| boundary.soft | 软性拒绝：拒绝请求但保留会话 | 黄色提示条 + 保留输入框 |
| boundary.hard | 强制终止：终止会话清空上下文 | 红色退出面板 + 数据政策说明 |
| boundary.review | 升级审核：提交人工审核 | 蓝色提示 + 预计审核时间 |
action._ —— 用户点击后，后果是什么？
| 令牌 | 含义 | 视觉映射示例 |
|---|---|---|
| action.destructive | 破坏性：删除、清空、不可逆 | 红色空心 + 二次确认 + 输入验证 |
| action.constructive | 建设性：保存、提交、创建 | 蓝色实心 + 成功反馈 |
| action.neutral | 中性：取消、关闭、返回 | 灰色描边 + 无后果 |
3.2 字典注册的 6 个语义绑定（v1.0.0）
语义字典 v1.0.0 注册的 6 个语义绑定，构成组织级语义码本的最小可行原子集：
| 语义绑定 | 含义 | 核心约束注入 | 跨层禁止示例 |
|---|---|---|---|
| status.critical | 阻断性、可能不可恢复 | 红色脉冲、八边形图标；必须二次确认；文案必须说明后果 | 不可用于 observational 域（限流提示禁用致命红） |
| status.warning | 需注意、可恢复 | 黄色静态、三角图标；必须显示恢复时间；必须提供操作步骤 | — |
| status.info | 中性信息告知 | 蓝色静态、信息图标；可自动消失；禁止附加操作说明 | — |
| status.success | 操作成功确认 | 绿色静态、对勾图标；可自动消失；禁止附加操作说明 | — |
| action.destructive | 不可逆操作 | 红色空心描边、危险图标；必须二次确认；必须说明不可恢复 | 禁止使用普通主按钮样式 |
| action.primary | 场景主行动 | 品牌色实心、箭头图标；点击后跳转；显示下一步预览 | — |
3.3 令牌如何展开为连续约束
每个令牌在 契约 中展开为一组连续约束。以 status.critical 应用于致命错误（ERR-001 · fatal 级别）为例：
一个离散索引（status.critical）→ 展开为视觉方向（红色脉冲 + 八边形图标）+ 行为约束（恢复路径、二次确认）+ 文案约束（必须说明后果）+ 机器防线（跨层禁止 block）。这就是"码本解码"的完整形态。
码本解码演示：status.critical → 展开为连续约束
页面中"码本解码演示"区块，包含离散索引（status.critical）、视觉方向（红色脉冲 + 八边形图标）、行为约束（必须二次确认 + 恢复路径）、文案约束（必须说明后果）、机器防线·跨层禁止（observational/navigational/conversational 域下非法）五栏展开。
同一令牌编译为三种消费格式：
页面中"同一令牌编译为三种消费格式"区块，三栏并排展示 Prompt 前缀 / JSON Schema / CI 规则。
Prompt 前缀：
在生成致命错误界面时：
- 必须使用红色脉冲视觉
- 必须包含八边形警告图标
- 必须提供恢复路径按钮
- 文案必须说明后果严重性
- 禁止在 observational 域使用
JSON Schema：
{
"color_token": "status.critical",
"motion_token": "pulse.red.urgent",
"icon_token": "alert.octagon",
"required_actions": ["refresh", "export"],
"forbidden_domains": ["observational"]
}
CI 规则：
rules:
critical-token-usage:
token: "status.critical"
forbidden_in: ["observational"]
required_visual: "pulse.red.urgent"
violation: "block"
3.4 对比演示："同一个红色"在不同令牌下的不同含义
页面中"对比演示：同一个红色在不同令牌下的不同含义"区块，左右两张卡片对比展示 status.critical（系统故障）与 action.destructive（删除账户）。
| status.critical | action.destructive | |
|---|---|---|
| 都是红色 | 系统故障，对话上下文可能丢失 | 不可逆操作，数据将永久删除 |
| 覆盖层 | transactional | transactional |
| 行为 | 必须二次确认 + 恢复路径 | 必须二次确认 + 输入验证 |
| 样式 | 红色脉冲 + 八边形 | 红色空心描边（非实心） |
| 跨层 | observational 域非法 | — |
没有令牌时，机器只看到 #EF4444；有令牌时，机器知道这是 status.critical 还是 action.destructive。
页面中"跨层禁止"区块，展示 CI 阻断日志："[CI 阻断] error-severity-cross-layer / Token: status.critical / Used in: observational domain / Expected: status.warning / Action: BLOCK"。
3.5 五条思路的依赖关系
第1条：把意思变成编号（离散编码）
↓
第2条：编号锁死一套视觉（一对一映射）
↓
第4条：不同编号可以同颜色但不同意思（区分场景）
↓
第5条：编号不能跨层乱用（使用范围限制）
↓
第3条：编号自动翻译成三种格式（一次定义，多方消费）
四、架构层概念：设计背景
码本，而非术语表。 术语表供人查阅，码本供机器解码：每个令牌是离散索引，编译管线 查表后展开为连续约束（视觉方向 + 行为约束 + 文案语气）。这决定了令牌的读者不只是设计师，更是编译管线与 AI 工具。
令牌层与呈现层分离。 color_token 是语义标识，color 是实际色值：同一个 status.critical 在不同设计系统里可映射到不同色值（Tailwind #EF4444 / Ant Design #F5222D / DevUI #FF4D4F）。语义令牌不关心具体色值，只关心语义映射关系——设计系统更新时改映射表，契约不变。
语义覆盖层（Semantic Overlay）。 组件库是底层（Underlay），只负责渲染——它提供圆角、色值、图标位这些空容器；语义覆盖层在组件之上加盖业务语义，把空容器翻译为业务语义组件。令牌是覆盖层加盖语义时使用的"印泥"。
术语双轨。 面向不同读者群时，三层结构有两套叫法：语义域 ≈ 覆盖层目录；语义令牌 ≈ 语义重绑定；场景映射 ≈ 约束注入。两套术语指向同一份注册表。
五、这些坑怎么被解掉：场景与角色对照
回到开头那些真实反馈，看令牌就位后它们各自怎么闭环。
踩过的坑 1："这个红到底代表什么，走查时谁也说不清"
● 症状：AI 生成限流提示时，Before 形态下选 color-danger 无可指责——红色本身没错，视觉走查也合规，但用户看到红色以为账户出了问题，实际只是需要等 30 秒。合规，但错误。
● 根因：Token 只定义颜色，没定义场景语义，机器拿不到"限流 ≠ 致命"这条信息。
● 关联机制：①语义令牌与字典+ 《Token 层差异》
● 解法路径：有了令牌后，限流语义级别是 retryable（黄色时钟 + 倒计时）；AI 若选 status.critical，直接违反跨层规则，CI 阻断，PR 无法合入。错误在生成阶段就无法成立。
● 验证方式：前端与 AI 工程师的验收争议从"感觉不对"变成"违反了哪条绑定"——争议可引用、可定位、可裁决。
踩过的坑 2："LLM 把 Critical 降级为'严重'，代码里查不出来"
● 症状：AI 生成告警时把 "Critical" 替换为"严重"、把 "Data Loss Risk" 替换为"请稍后重试"——情绪权重被概率性输出随机降级，Schema 校验通过，语义却是错的。
● 根因：文案层没有术语锚定，同义词自由替换没有任何机制判定违规。
● 关联机制：①语义令牌与字典（B3 字典 synonym_firewall 同义词防火墙）+ 6 个漂移模式证据库（ALR-001）
● 解法路径：YAML 定义禁止词并编译进 Prompt 前缀，synonym_firewall 约束下关键术语替换即违规，生成阶段被校验规则命中。
● 验证方式：设计师与产品经理精心设计的语义权重不再被概率性输出随机抹平——"Critical" 在所有产出中保持锚定，替换即被校验规则命中。
六、调整后：工具界面层的呈现状态
同一批工具，在语义令牌就位之后：
| 工具 / 环节 | 调整前 | 调整后 |
|---|---|---|
| AI 生成工具 | 只有色值，限流与致命错误同红 | Prompt 前缀注入令牌约束后：致命错误 = 红色脉冲 + 八边形图标 + 恢复路径；限流提示 = 黄色时钟 + 倒计时.同模型同任务，产出语义分级 |
| 文案生成 | "Critical" 被随机替换为"严重" | synonym_firewall 锚定关键术语，替换即被校验规则命中 |
| 验收环节 | 走查结论停留在"感觉不对" | Checklist 逐项核对：语义分级 / 文案 / 红线，违反红线即阻断，结论注明契约版本号 |
【推演条件】
从演示环境进入生产环境，语义令牌表需要以下组织条件：
谁来维护令牌？ 建议由语义翻译设计师（角色 4）担任令牌管理员，负责定义和更新语义令牌；DesignOps（角色 3）负责版本发布与广播。令牌不是公共文档，而是组织的"语义宪法"，修改权限必须集中。
变更如何不击穿下游？ 令牌升级（如新增 status.degraded 级别）必须自动同步到所有消费面：设计师的 Checklist、前端的 Prompt 前缀、CI 的拦截规则。组织需要建立"字典变更 → 契约重编译 → 消费格式换版 → 角色通知"的闭环，避免"上游改了，下游还在用旧定义"。
谁来证明有效？ 每次令牌升级后，需通过语义分级器抽检一定数量的 AI 生成文案，验证新规则确实拦截了目标错误。验证结果应沉淀到模式卡片中，作为该模式置信度持续递增的证据。
边界声明
语义令牌表不解决视觉值的一致性（那是 Design Token 层的职责），不定义具体场景的约束实例（那是 YAML 契约 的职责），也约束不了"有没有人查它"（消费纪律在角色侧，见 角色专题 ①｜设计师与产品经理）。当前量化收益均为数据模型推演，待生产数据验证。
一句话总结（给不同角色）
给设计师："你以前写'错误用红色'，前端可能理解错。现在你写 status.critical，机器查表就知道必须是红色脉冲 + 八边形 + 二次确认，不会跑偏。"
给前端："你不需要猜设计师的意思，查 status.critical 的表就知道颜色、动画、图标、按钮样式，全部锁死。"
给 AI 工具开发者："你不需要自己判断用什么颜色，输入场景编号，查表输出 Prompt 前缀，AI 按规矩生成。"
给 DesignOps："你改一次编号定义，Prompt 前缀、JSON Schema、CI 规则三处自动更新，不用发三遍文档。"
1920
