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

框架定义：当 AI 生成界面时，设计意图在偏离。Schema-As-Code 把设计规范写成代码格式，在语义层建立一套机器可读的约束契约，让 AI 在生成界面之前，先知道"这个场景下必须表达什么语义、不能突破什么边界"。框架不替代任何设计工具或 AI 工具，而是所有 AI 工具的上游约束层，AI 负责生成，规则负责把关。（方法论总纲：把设计规范写成代码格式，是所有 AI 工具的上游约束方法论）

本文定位：本文是 Schema-As-Code 框架中"Token 层差异"的验证切片。ERR-001 错误状态诊断、PRO-001 过程状态诊断、BND-001 边界动作诊断已经证明了：AI 生成界面的语义漂移可以被结构化定位、被契约修复、被机器验证。但论证成立之后，下一个问题自然浮现：修复这些漂移的"原材料"，Token 层真的够用吗？ 本文核心回答三个问题：① Design Token 改了名字，语义就能被机器理解了吗？② 从颜色值到语义状态的三层跃迁是不是真实存在？③ 这个差别带来的能力是不是不可替代。

一、问题：Design Token 改了名字，语义就能被机器理解了吗？

ERR-001 错误状态诊断、PRO-001 过程状态诊断、BND-001 边界动作诊断已经证明了：AI 生成界面的语义漂移不是"感觉不对"，而是可以被结构化定位的真实问题，错误状态共用同一种红色、过程状态用模糊标签掩盖认知阶段、边界动作中拒绝与终止混为一谈，这些漂移都有明确的根因（缺少语义令牌）和可验证的修复路径（契约约束 + 机器校验）。（6 个漂移模式：AI 生成界面的语义断层证据库 · 从观察到契约：Semantic Pipeline 的三阶段工作流）

论证成立之后，下一个问题自然浮现：语义漂移的根因只发生在"界面层"吗？Token 层，设计系统最底层的"原材料"是否也在制造这些漂移？

毕竟，很多团队的设计系统里早就有 Design Token 了。color-red-500 改成 color-danger，评审会上人人满意，团队以为"语义化"已经完成了。但面对"限流提示被 AI 生成成致命红色"时，color-danger 和 color-red-500 对机器来说没有任何区别，都只是一个字符串，字符串里没有"这个红代表不可恢复"的信息，没有"这个红不能用在限流场景"的约束，更没有"如果用了就阻断"的机器规则。

本文就回答这个问题，针对 Token 层一个场景：同一颜色（红色）在三种 Token 形态下（Style Token / Design Token / Semantic Token）分别长什么样、差别带来什么能力，以及最关键的这个差别是不是真实存在。

先看一个真实踩过的坑，再逐项展开设计前后的对照。

二、为什么 Design Token 不够用

2.1 一个真实踩过的坑

某 AI 对话产品的设计系统升级：团队花了三个月把 color-red-500 改名为 color-danger，评审会上展示了一张漂亮的 Token 映射表，"危险场景用 danger，成功场景用 success"。所有人都觉得"语义化"完成了。

三个月后，AI 生成的新界面出现 bug：限流提示（"请求过于频繁"）被渲染成 color-danger 红色。用户看到红色就刷新页面，以为系统崩溃，其实只是等 30 秒自动恢复。

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

2.2 根因：Design Token 只改了名字没改结构

Design Token 的升级路径是"改名"：#EF4444 → color-danger。这个改动只动了命名风格，没动机器可执行的结构。color-danger 对机器来说仍然是一个"颜色值"，不是"语义状态"。

Semantic Token 的升级路径是"编码"：color-danger → status.critical，同时挂载 semantic_domain: transactional、挂载 cross_layer_ban: [observational]、挂载 behavior_constraint: 必须二次确认。这个改动给 Token 增加了机器可查询的结构，编译管线可以查表展开，CI 可以按规则拦截，AI 可以按 Prompt 前缀注入约束。（语义规范体系：YAML 里写的不是颜色值，是语义令牌）

2.3 为什么团队会踩这个坑

因为 Design Token 的"语义化改名"在视觉上已经进步了，至少设计师看到 color-danger 会联想到"危险"，而不是看到 #EF4444 只会联想到"红色"。但这种进步停留在人脑理解层，没有到达机器执行层。

当 AI 生成工具接管界面生产时，问题暴露：AI 不读设计规范文档，它不领会"danger 代表不可恢复"的隐喻。它只看到一个字符串 color-danger，这个字符串对它来说和 #EF4444 没有本质区别，都是"用红色"的指令。

2.4 这个差别是真实存在的吗：跨角色反馈

【Schema-As-Code 语义编码层 · Token 层差异验证演示环境：跨角色反馈矩阵】

同一根因（Token 只有色值、没有语义结构）在五个角色身上长出的坑：设计师"新增 error 状态凭直觉选色"、前端"Token 只告诉我颜色没告诉我场景"、DesignOps"各产品线术语版本对不上"、语义翻译设计师"模式库维护成本高"、管理层"语义一致性投入产出看不到"。

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

三、关键设计：Token 层差异 Before/After

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

Token 层的演进不是线性升级，而是两次结构跃迁。每次跃迁都增加了机器可执行的信息维度，而非仅仅改善人类可读性。

第一层：Style Token（样式令牌）

机器理解：这是一个颜色值 #EF4444。没有场景语义，没有使用约束。

第二层：Design Token（设计令牌）

机器理解：这是一个被命名为"danger"的颜色值 #EF4444。description 字段对人类可读，对机器不可执行，机器不会自动把"危险场景"翻译成"限流不能用"。

第三层：Semantic Token（语义令牌）

机器理解：这是一个被编码为 status.critical 的语义状态，携带完整的机器可执行结构，域归属、跨层禁止、行为约束、视觉表达。编译管线可以查表展开，CI 可以按规则拦截，AI 可以按 Prompt 前缀注入约束。（语义字典：设计系统组件的语义覆盖层）

Before vs After 对照：

3.2 为什么不是"语义化改名"

关键差异：Design Token 的"语义化"是隐喻层面的，danger 这个名字暗示了"危险"，但机器不理解隐喻。Semantic Token 的"语义化"是结构层面的，status.critical 携带的 cross_layer_ban、behavior_constraint 是机器可以直接查询、校验、拦截的离散规则。

差异点拆解（四个维度）：

【Schema-As-Code 语义编码层 · Token 层差异验证演示环境：差异点拆解（四个维度对照表）】

Design Token vs 语义令牌的四个维度对照：表达内容（颜色是什么 vs 颜色在该场景代表什么）、机器可执行（只能渲染 vs 可校验可拦截）、行为约束（无 vs 必须二次确认）、跨层规则（无 vs status.critical 不可用于 observational 域）。

3.3 一个离散索引展开为连续约束

**Semantic Token 的核心设计是"离散索引，连续约束"。**status.critical 是一个离散的枚举值（像数据库主键），编译管线查表后展开为一组连续的约束参数（像 JOIN 查询后的完整记录）。（编译管线是语义一致性的"机器翻译层"）

【Schema-As-Code 语义编码层 · Token 层差异验证演示环境：码本解码演示】

离散索引 status.critical 经编译管线查表后展开为连续约束：视觉方向（红色脉冲 + 八边形图标）、行为约束（必须二次确认 + 必须提供恢复路径）、文案约束（必须说明后果）、机器防线·跨层禁止（observational/navigational/conversational 域下非法）。

码本解码演示：

离散索引: status.critical
    ↓ 编译管线查表
视觉方向: 红色脉冲 + 八边形图标
行为约束: 必须二次确认 + 必须提供恢复路径
文案约束: 必须说明后果
机器防线 · 跨层禁止: observational / navigational / conversational 域下非法

同一组令牌能被编译为三种消费格式：

Prompt 前缀（给 AI 用）：

在生成致命错误界面时：
- 必须使用红色脉冲视觉
- 必须包含八边形警告图标
- 必须提供恢复路径按钮
- 文案必须说明后果严重性
- 禁止在 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"

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

3.4 同一颜色不同令牌，"同一个红色"在不同语义下的不同含义

没有令牌时，机器看到 #EF4444（红色）不知道这是"系统故障"还是"删除按钮"。必须看令牌才知道"哪种危险"。

【Schema-As-Code 语义编码层 · Token 层差异验证演示环境："同一个红色"对比卡片】

左右并排展示 status.critical（系统故障，红色脉冲，必须二次确认+恢复路径）与 action.destructive（删除账户，红色空心描边，必须输入账户名二次确认），证明同一颜色值在不同令牌下携带完全不同的语义结构。

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

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

【Schema-As-Code 语义编码层 · Token 层差异验证演示环境：限流提示直观对照】

左右并排展示 Before（AI 生成红色限流提示，用户看到红色以为系统崩溃）与 After（AI 生成黄色时钟限流提示，字典定义 retryable = 黄色时钟 + 倒计时文案）。

3.5 跨层禁止：Token 层的域隔离

status.critical（红色脉冲）只能在"错误状态"里用，不能拿到"提示信息"里用。跨层使用会被机器自动阻断。

合法绑定：status.critical 用在"消息流中断"（系统故障）→ 编译期通过 → 入库成功

非法绑定：status.critical 用在"限流提示"（observational 域）→ 编译期查 cross_layer_ban → 命中禁止列表 → 返回 CROSS_LAYER_BAN_VIOLATION → 阻断入库

Design Token color-danger 没有 cross_layer_ban 结构，机器无法判定"这个红色在这个场景是否合法"，它只能看到"用红色"，看不到"不能在这里用红色"。（跨层禁止：机器如何拦截非法语义绑定）

【Schema-As-Code 语义编码层 · Token 层差异验证演示环境：跨层禁止演示（CI 阻断日志）】\

CI 阻断日志："[CI 阻断] error-severity-cross-layer / Token: status.critical / Used in: observational domain / Expected: status.warning / Action: BLOCK"。

CI 阻断日志示例：

[ERROR] semantic-layer-violation
  Token: status.critical
  Used in: observational domain (limit_rate_alert)
  Expected: status.warning (yellow + clock icon + countdown)
  Violation: immutable_boundary.cross_layer
  Action: BLOCK — PR cannot be merged

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

LLM 没有"语义权重"的概念，它只有"词频统计"和"上下文概率"。

【Schema-As-Code 语义编码层 · Token 层差异验证演示环境：三则线上反馈】

AI 运维助手（Critical 被替换为"严重"）、AI 客服系统（Data Loss Risk 被改写为"请稍后重试"）、AI 医疗辅助产品（诊断提示严重程度表述前后不一）三个真实案例。›

四、Token 层差异在 Schema-As-Code 中的位置

Token 层差异不是孤立的技术讨论，而是 Schema-As-Code 框架中"语义编码层"的核心设计。它位于编译管线的最上游，契约引用字典中的语义令牌，编译管线将令牌查表展开为连续约束，再翻译为四种消费格式。（YAML 契约格式：理解了语义规范体系后，怎么写语义规则 · 契约库：让设计规范像代码一样管理）

Token 层差异是这条链路的"原材料"，如果 Token 层只有颜色值没有语义结构，下游的契约、编译、验证全部失去根基。

五、诚实清单

六、推演条件

七、框架设计背景：从 Token 层差异回到 Schema-As-Code 全景

Token 层差异不是孤立的技术讨论，而是 Schema-As-Code 框架设计假设的一个验证切片。要理解这个案例的价值，需要先看到它在整个框架中的位置。

7.1 语义治理框架全景：三阶段与机制网络

Schema-As-Code 不是一套理论，是一条可执行的三阶段流水线（Semantic Pipeline）。（从观察到契约：Semantic Pipeline 的三阶段工作流）

Token 层差异横跨三个阶段：

• Guard 阶段：通过 6 个漂移模式 观察到"颜色值无法表达后果差异"（ERR-001 根因：缺少 error_severity 语义令牌）
• Contract 阶段：将颜色值升级为语义令牌，写入 YAML 契约，经 编译管线 生成 4 种消费格式
• Verify 阶段：通过三层验证（生成前注入、开发中校验、提交时拦截）证明 Semantic Token 可被机器执行，Design Token 不能

7.2 案例验证：Token 层差异证明了什么

证明1：语义漂移的根因可被定位到 Token 层

ERR-001 的根因不是"设计师没想清楚红色怎么用"，而是"Token 层只有颜色值、没有语义结构"。color-danger 无法表达"仅用于 transactional 域"的约束，这是数据结构层面的缺陷。这个发现不是某位设计师"感觉不对"，而是通过 三层判定模型 被归档为模式卡片：第一层识别组件类型为"错误状态"，第二层判定语义缺失为"后果差异未分级"，第三层校验视觉表达为"所有错误共用同一种红色"。（结构化诊断：三层判定模型与模式匹配机制）

证明2：语义必须编码为带结构的离散令牌

修复不是"改个更好的名字"，而是给 Token 挂结构，semantic_domain、cross_layer_ban、behavior_constraint。status.critical 经 编译管线 翻译后，可在生成前注入 Prompt、开发中校验 Schema、提交时拦截 CI。color-danger 做不到。这些令牌被写入 语义字典 注册为组织级语义码本。契约通过引用字典中的令牌，声明了跨层禁止规则（status.critical 不可用于 observational 域）。契约不是文档，是机器可执行的规则——前端按令牌映射渲染，CI 按规则拦截，AI 按 Prompt 前缀注入约束。（语义规范体系：YAML 里写的不是颜色值，是语义令牌）

证明3：Token 层的差别必须被证明有效

A/B 对比实验：同一 Prompt"生成限流提示"，未注入契约时 AI 输出 color-danger（红色），注入契约后 AI 输出 status.warning（黄色时钟）。**约束真的改变了 AI 的行为。编译为 Prompt 前缀 后，AI 生成错误状态时不再只有"红色"一个语义槽位；编译为 JSON Schema 后，前端实现时硬编码颜色值被强制替换为 color_token 引用；**编译为 CI 规则后，缺少恢复路径的致命错误场景在提交时被阻断。这套验证机制在《字典引用的机器防线》中被完整定义。《前端与 AI 工程师》详细描述了三项资产如何在工程师工作流中被消费。

7.3 回到开篇的问题

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

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

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

是。Style Token（#EF4444）→ Design Token（color-danger）→ Semantic Token（status.critical + 结构）的两次跃迁，每次都在增加机器可执行的信息维度。

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

是。**没有 Semantic Token 的结构挂载，编译管线无法生成 Prompt 前缀、JSON Schema、CI 规则；AI 无法按约束生成；CI 无法按规则拦截。**Design Token 的"语义化改名"在 AI 生成时代失效了。

这个案例同时也回答了更底层的问题：为什么需要 Schema-As-Code把设计规范写成代码格式 这套框架？

因为语义漂移的根因不止在界面层，也在 Token 层。当颜色值无法表达"这个红代表不可恢复"时，框架提供的不只是诊断方法，而是一套从 Token 编码 到 机器验证 的完整工作流。

八、一句话总结（给不同角色）

给设计师：\
"以前凭直觉选色，走查时才发现用错了。现在查字典，颜色自带场景档案，生成前机器就拦住错误。"

给前端 / AI 工程师：\
"Token 以前只告诉你颜色值，现在告诉你这个颜色在这个场景下必须附带什么交互、不能出现在哪里。"

给 DesignOps：\
"以前各产品线颜色命名不一样，同一个词三套说法。现在一本字典管全公司，改一次定义，全局自动对齐。"

给语义翻译设计师 / 体验架构师：\
"以前每次诊断语义漂移都从零开始，现在站在字典已注册的 Token 上复用，诊断成本从 2 小时降到 10 分钟。"

给管理层 / 决策者：\
"以前语义一致性投入多少、产出在哪，看不到。现在 Token 标准化后，一致性覆盖率可量化、可追踪、可考核。"

九、下一站

Token 层的差别确认之后：

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