Token 层差异：从颜色值到语义状态的三层跃迁

《语义令牌表》与 《语义字典》讲了这套设计的合法性——语义令牌把"这个红代表什么"编码为机器可查的绑定，语义字典作为注册表保证全组织引用同一份定义，背后是 MOSS、W3C、Databricks 等学术界与工业界的对应实践。

论证成立之后，下一个问题自然浮现：这套东西和团队已经在用的 Design Token 到底有什么实际差别？ 毕竟很多团队的设计系统里早就有 Token 了，"再加一层"值不值，得看差别本身。

本文就回答这个问题，针对 Token 层一个层级：同一对象（"致命错误的红色"）在传统 Design Token 形态与语义令牌形态下分别长什么样、差别带来什么能力，以及——最关键的——这个差别是不是真实存在。先看一个真实踩过的坑，再逐项展开设计前后的对照。

一、一个真实踩过的坑：改个名字，机器能执行的多了几项？

某设计系统团队的真实反馈："我们把 color-red-500 全部改名成 color-danger，评审会上人人满意。三个月后 AI 生成工具接入，color-danger 出现在了一个成功状态的对勾旁边。"

• 症状：改名改造动了 Token 层的名字，没动结构。对机器来说，danger 和 red-500 没有任何区别，都只是一个字符串；字符串里没有"这个红代表不可恢复"的信息。
• 根因："语义化"停留在命名风格层面，机器可执行的结构一行没加——没有场景、没有行为约束、没有禁止项。
• 关联机制：①语义令牌与字典（B1/B3）+ D-T4（非法引用的机器阻断）
• 解法路径：不是给 Token 起更好的名字，而是给 Token 挂结构——场景语义、行为约束、跨层禁止，全部由字典注册、编译管线校验。
• 验证方式：改造后同一个 AI 生成场景，误用 status.critical 的 PR 在 CI 阶段被阻断，而不是三个月后在界面上被发现。

这就是本篇要拆解的差别：Design Token 与语义令牌之间，隔的不是命名风格，而是机器可执行的结构。

二、Before：Design Token 形态

W3C Design Tokens 格式下的典型定义：

{
   
  "color": {
   
    "danger": {
    "value": "#EF4444", "type": "color" },
    "danger-emphasis": {
    "value": "#DC2626", "type": "color" }
  }
}

先肯定它好的一面：单一来源、多平台编译（CSS / Swift / Kotlin）、视觉一致性——这是工业界成熟实践，W3C 已发布稳定规范（Primitive → Semantic → Component 三层分类学）。它把"红色是什么"管理得很好，这套基础设施应当保留，不需要推倒。

但它在机器可执行性上的边界同样明确：

• 没有场景：这个红用在哪——致命错误还是促销标签，定义里没有；
• 没有行为约束：用这个红时必须附带什么交互（二次确认？恢复路径？），定义里没有；
• 没有禁止项：什么情况下绝对不许用这个红，定义里没有。

AI 工具读到 color-danger，能做的只有"把颜色渲对"，做不到"把语义用对"。

三、After：语义令牌形态

同一对象在语义字典 + YAML 契约中的定义：

semantic_tokens:
  error_severity:
    fatal:
      description: "致命错误：数据可能丢失或会话不可恢复"
      visual_mapping:
        color_token: status.critical      # 引用字典绑定，非色值
        motion_token: pulse.red.urgent    # 红色脉冲：注意力强制的最高档
        icon: octagon-alert
        user_action: [refresh_page, export_history]  # 必须提供恢复路径
      llm_constraints:
        - "文案必须说明'对话可能已丢失'"
        - "禁止仅显示'出错了'等模糊文案"
        - "禁止显示纯技术错误码"
      immutable_boundaries:
        - rule: "禁止把 fatal 级错误渲染为普通文字提示"
          violation_action: block
        - rule: "status.critical 不可用于 observational 域"
          violation_action: block

四、差异点拆解

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

• Before 形态：AI 选 color-danger 无可指责。红色本身没错，视觉走查也合规——但用户看到红色会以为账户出了问题，实际上只是需要等 30 秒。合规，但错误。
• After 形态：限流的语义级别是 retryable，字典定义为黄色时钟 + 倒计时文案。AI 若选 status.critical，直接命中跨层禁止规则，CI 阻断，PR 无法合入。错误在生成阶段就无法成立。

五、这个差别是真实存在的吗：跨角色真实反馈汇编

令牌没有锚定的后果，不是理论推演，是跨产品反复观察到的现实。三则线上反馈：

• 某 AI 运维助手：告警文案中 "Critical" 被替换为"严重"——情绪权重降低，值班员延迟响应，故障扩大；
• 某 AI 客服系统：风险提示中 "Data Loss Risk" 被改写为"请稍后重试"——真实后果被掩盖，用户误以为只是临时抖动；
• 某 AI 医疗辅助产品：诊断提示的严重程度表述前后不一——用户误判紧急程度。

共性结论：LLM 没有"语义权重"的概念，只有词频统计和上下文概率。"严重"和 "Critical" 在 LLM 语义空间中等价，在用户认知空间中紧急感不同。没有锚定的令牌，降级就是概率的奴隶。 这正是语义绑定（如 status.critical）与同义词防火墙（synonym_firewall，ALR-001）必须成对存在的原因——完整证据见《6 个漂移模式：AI 生成界面的语义断层证据库》。

而这个差别不止影响一个角色。同一根因（Token 只有色值、没有语义结构），在五个角色身上长出的坑各不相同：

六、下一站

Token 层的差别确认之后：

• 令牌与字典的合法性论证（为什么是码本、为什么需要注册表），见《语义令牌表》与 《语义字典》；
• 字典引用如何被机器守住、写错的令牌如何被阻断，见《字典引用的机器防线》；
• 该差别在角色工作流中的落地（设计师查询、验收、PRD 引用），见《设计师与产品经理：消费路径与接手交付件》。