← Schema-As-Code / Token 层差异

Schema-As-Code 语义编码层 · Token 层差异验证

从颜色值到语义状态的三层跃迁

ERR-001、PRO-001、BND-001 证明了语义漂移可被修复。但修复的"原材料"——Token 层——真的够用吗？
Design Token 改了名字，语义就能被机器理解了吗？

Design Token 改了名字，语义就能被机器理解了吗？

color-danger 对人类是"危险"的隐喻，对机器是"用红色"的指令。改名只动了命名风格，没动机器可执行的结构。

答案：不能

从颜色值到语义状态的三层跃迁是不是真实存在？

Style Token → Design Token → Semantic Token 的两次跃迁，每次都在增加机器可执行的信息维度。

答案：是

这个差别带来的能力是不是不可替代？

没有 Semantic Token 的结构挂载，编译管线无法生成 Prompt 前缀、JSON Schema、CI 规则。

答案：是

一个真实踩过的坑

color-danger 改名三个月后的 bug

团队做了什么

花三个月把 color-red-500 改名为 color-danger。
评审会上展示了一张漂亮的 Token 映射表——"危险场景用 danger，成功场景用 success"。
所有人都觉得"语义化"完成了。

三个月后发生了什么

AI 生成的新界面出现 bug：
限流提示（"请求过于频繁"）被渲染成 color-danger 红色。

用户看到红色就刷新页面，以为系统崩溃——
其实只是等 30 秒自动恢复。

根因

color-danger 这个名字本身没问题。问题是：这个名字对机器来说仍然只是一个颜色值，它不携带"这个红代表不可恢复"的语义结构，也不携带"不能用在限流场景"的域约束。AI 生成工具看到 color-danger，只知道"用红色"，不知道"这个红色在什么场景下合法、什么场景下非法"。

三层跃迁：Style Token → Design Token → Semantic Token

每次跃迁都增加了机器可执行的信息维度

L1 Style Token

样式令牌

color-red-500: "#EF4444"

机器理解：这是一个颜色值

能做什么：只能渲染

场景语义：无

使用约束：无

L2 Design Token

设计令牌

color-danger:
  value: "#EF4444"
  description: "用于危险场景"

机器理解：被命名为"danger"的颜色值

能做什么：还是只能渲染

场景语义：description 对人可读，对机器不可执行

使用约束：无

L3 Semantic Token

语义令牌

status.critical:
  color_token: "status.critical"
  motion_token: "pulse.red.urgent"
  icon_token: "alert.octagon"
  semantic_domain: "transactional"
  cross_layer_ban: ["observational"]
  behavior_constraint:
    - "必须二次确认"
    - "必须提供恢复路径"

机器理解：带语义结构的离散索引

能做什么：可校验、可拦截、可阻断

场景语义：域归属 + 跨层禁止 + 行为约束

使用约束：编译期查表展开，CI 按规则拦截

维度

Style Token

Design Token

Semantic Token

表达内容

颜色是什么 #EF4444

颜色是什么 color-danger

颜色在该场景代表什么不可恢复

机器可执行

只能渲染

可校验、可拦截

行为约束

无

无（只有人类可读的 description）

必须二次确认、必须提供恢复路径

跨层规则

无

status.critical 不可用于 observational 域

⊞

差异点拆解（四个维度对照表）

Design Token vs 语义令牌：差别不是名字，是差异带来的能力

维度

Before · Design Token

After · Semantic Token

差异带来的能力

表达内容

颜色是什么 #EF4444

颜色在该场景代表什么不可恢复

AI 生成前可注入语义约束

机器可执行

只能渲染

可校验、可拦截

编译期与 CI 期阻断违规

行为约束

无

必须提供恢复路径；高危操作必须二次确认

交互语义不可被生成器省略

跨层规则

无

status.critical 不可用于 observational 域

场景误用（限流提示用致命红）被拦截

⇄

码本解码演示

离散索引，连续约束：status.critical 经编译管线查表后展开

离散索引（像数据库主键）

status.critical

编译管线查表 →

视觉方向

红色脉冲 + 八边形图标

行为约束

必须二次确认 + 必须提供恢复路径

文案约束

必须说明后果

机器防线 · 跨层禁止

observational / navigational / conversational 域下非法

⧉

编译为三种消费格式

同一组令牌，编译为 Prompt 前缀 / JSON Schema / CI 规则

Prompt 前缀

给 AI 用

生成 Alert 时：
- status.critical → 红色脉冲
  + 八边形图标
- 必须二次确认
- 必须提供恢复路径
- 必须说明后果
- 禁止用于 observational 域

JSON Schema

给前端校验用

{
  "color_token": {
    "enum": ["status.critical"],
    "semantic_domain":
      "transactional",
    "cross_layer_ban":
      ["observational"]
  }
}

CI 规则

给流水线拦截用

rule: error-severity-cross-layer
when:
  token: status.critical
  domain: observational
then:
  action: BLOCK
  suggest: status.warning

Design Token color-danger 无法生成以上任何产物——它只有一个 description 字段，机器无法把"用于危险场景"翻译成可执行的校验规则。

≠

"同一个红色"在不同令牌下的不同含义

没有令牌时，机器只看到 #EF4444；有令牌时，机器知道这是"系统故障"还是"删除按钮"

status.critical

系统级故障，对话上下文可能丢失

🚨 消息流中断

对话上下文可能已丢失，建议刷新页面重新开始。

刷新页面导出历史

覆盖层：transactional

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

跨层：observational 域非法

action.destructive

不可逆操作，数据将永久删除

⚠️ 删除账户

此操作不可恢复。请输入账户名确认。

取消确认删除

覆盖层：transactional

行为：必须输入账户名二次确认

样式：红色空心描边（非实心）

💡 关键洞察：以前设计规范只规定"红色用在危险场景"，但机器不知道"危险"有 10 种。Semantic Token 把"哪种危险"说清楚了——status.critical 和 action.destructive 可以共用同一种红色值 #EF4444，但携带完全不同的语义结构、域归属和行为约束。

A/B

直观对照：AI 生成"限流提示"

同一 Prompt，Token 层不同，输出完全不同

Before · Design Token

🔴 请求过于频繁，请稍后再试

AI 选择：color-danger

视觉走查：✓ 合规（danger = 红色）

用户反应：看到红色以为系统崩溃，立即刷新

实际情况：只需等 30 秒自动恢复

❌ 合规，但错误。color-danger 无可指责，但用户误解了后果。

After · Semantic Token

⏱️ 请求频率已达上限

请在 42 分钟后重试，或升级至 Plus 获得更高限额。

升级 Plus 设置提醒

AI 选择：status.warning（字典定义 retryable = 黄色时钟）

视觉走查：✓ 合规（限流 = 黄色）

用户反应：看到黄色知道可以自助恢复

实际结果：用户选择等待或升级

✓ 语义正确。AI 若选 status.critical，直接命中跨层禁止，CI 阻断。

跨层禁止：Token 层的域隔离

status.critical 只能在 transactional 域使用，observational 域下非法

✓ 合法绑定

component: "Alert"
context: "消息流中断"
overlay: "transactional"
color_token: "status.critical"

编译期通过 → 入库成功

✕ 非法绑定 — 被阻断

component: "Alert"
context: "限流提示"
overlay: "observational"
color_token: "status.critical"  # ← 跨层非法

[CI 阻断] error-severity-cross-layer

Token: status.critical

Used in: observational domain (limit_rate_alert)

Expected: status.warning (yellow + clock)

Action: BLOCK — PR cannot be merged

⚠️ Design Token color-danger 没有 cross_layer_ban 结构，机器无法判定"这个红色在这个场景是否合法"——它只能看到"用红色"，看不到"不能在这里用红色"。

👥

跨角色反馈矩阵

同一根因（Token 只有色值、没有语义结构），在五个角色身上长出的坑各不相同

🎨

设计师

"新增了 error 状态也直接用红色，两周后走查才发现字典里根本没这个级别"

根因：字典是文档不是代码

解法：字典 YAML 化，未注册编译阻断

💻

前端 / AI 工程师

"Token 只告诉我颜色，没告诉我这个场景该用哪个语义级别"

根因：缺少 semantic_domain

解法：color_token + semantic_domain 联合定义

📋

DesignOps

"各产品线的术语版本对不上，同一个词三套说法"

根因：没有统一术语源

解法：字典作为组织级唯一真相源

🔍

语义翻译设计师

"模式库维护成本高，每次诊断都从零开始"

根因：Token 没有复用

解法：从字典复用 Token，快速匹配

📊

管理层

"语义一致性投入多少、产出在哪，看不到"

根因：缺少度量基准

解法：字典标准化后，覆盖率可量化

⚠️

三则线上反馈：没有锚定的令牌，降级就是概率的奴隶

LLM 没有"语义权重"的概念，它只有"词频统计"

AI 运维助手

告警文案中 "Critical" 被替换为"严重"，情绪权重降低

值班员延迟响应，故障扩大

根因：同义词防火墙缺失

AI 客服系统

"Data Loss Risk" 被改写为"请稍后重试"，真实后果被掩盖

用户误以为只是临时抖动

根因：语义降级未被拦截

AI 医疗辅助

诊断提示的严重程度表述前后不一

用户误判紧急程度

根因：语义令牌未锚定

✓

诚实清单

验证项与当前状态

验证项

状态

说明

三层跃迁是否真实存在

✅ 已验证

Style → Design → Semantic 的结构差异在代码层面可观测

Design Token 改名是否足够

✅ 已证伪

color-danger 无法被编译为机器规则，A/B 对比可见

Semantic Token 是否可被机器消费

✅ 已验证

同一组令牌编译为三种格式，各角色可接入工具链

跨层禁止是否可执行

✅ 已验证

cross_layer_ban 在编译期阻断非法绑定，返回修正建议

同一颜色不同令牌是否被区分

✅ 已验证

status.critical vs action.destructive 结构差异在契约中显式声明

对抗用例库是否完整

⚠️ 待补充

需持续补充诱导越界的对抗 Prompt

生产环境实测数据

⚠️ 待采集

当前为演示环境单点验证，接入生产后需采集真实拦截率

Token 层差异确认之后

语义令牌表 → 语义字典 → 契约库 → 编译管线 → 验证闭环

进入语义令牌表 →