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

---

四、差异点拆解

维度	Before（Design Token）	After（语义令牌）	差异带来的能力
表达内容	颜色是什么（#EF4444）	颜色在该场景代表什么（不可恢复）	AI 生成前可注入语义约束
机器可执行	只能渲染	可校验、可拦截	编译期与 CI 期阻断违规
行为约束	无	必须提供恢复路径；高危操作必须二次确认	交互语义不可被生成器省略
跨层规则	无	status.critical 不可用于 observational 域	场景误用（限流提示用致命红）被拦截

一个直观对照------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 只有色值、没有语义结构），在五个角色身上长出的坑各不相同：

角色	踩过的坑（真实反馈）	根因	机制如何解	验证方式
设计师	"新增了 error 状态也直接用红色，两周后走查才发现字典里根本没这个级别"	字典是文档不是代码，新增状态凭直觉选色	字典 YAML 化、变更走 PR；契约必须引用已注册 Token，未注册编译阻断	CI 自动拦截未注册映射，问题在 PR 阶段暴露而不是两周后
前端 / AI 工程师	"Token 只告诉我颜色，没告诉我这个场景该用哪个语义级别"	缺少 semantic_domain，颜色与场景脱钩	color_token + semantic_domain 联合定义，覆盖层强制注入语义	Schema 校验场景绑定，限流误用致命红直接被拦
DesignOps	"各产品线的术语版本对不上，同一个词三套说法"	没有统一术语源，各自维护私有字典	字典作为组织级唯一真相源，禁止平行私有字典	版本同步机制自动分发，Git Diff 可追溯
语义翻译设计师	"模式库维护成本高，每次诊断都从零开始"	Token 没有复用，诊断无法站在已注册定义上	从字典复用 Token，快速匹配既有模式	快照模板生成器自动填充
管理层	"语义一致性投入了多少、产出在哪，看不到"	缺少度量基准	字典标准化后，一致性覆盖率可量化	ROI 计算模型中的覆盖率指标

---

六、下一站

Token 层的差别确认之后：

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

---