定位：Schema-As-Code 证据链的"认知 + 合法性"站（B 列：全景 + 背书），覆盖主题行①的第一个关键设计——语义令牌表（Semantic Token Table）。回答"凭什么成立"：语义令牌把"这个红代表什么"编码为离散、可查询、可校验的机器码本，而非换名的色值别名。
快速阅读：
方法论总纲与开源：把设计规范写成代码格式，是所有 AI 工具的上游约束方法论
阶段一结构化诊断：组件语义快照与模式诊断：AI 生成界面的第一道检查
阶段二语义契约化：设计师作为"语义翻译者" 当AI生成界面时我怎么用规则锁住设计意图
角色专题1:设计师与产品经理：AI 界面语义走查指南

一、调整前：四个角色的真实反馈

在没有语义令牌之前，各角色在界面层"看到"的世界，用他们自己的话说：

前端与 AI 工程师的真实反馈：“致命错误和限流提示，被渲染成了同一种红色背景条。”
AI 生成工具里只有 Design Token——color.danger: { value: "#EF4444" }。红色是一个色值，不附带任何场景含义。同一款 AI 对话产品中，"对话可能已丢失"的致命错误与"请求太频繁，请等 30 秒"的限流提示长得一模一样：色板合规、对比度达标，视觉走查挑不出任何毛病，但用户从界面上读不到两者的区别。

设计师与产品经理的真实反馈：“同一个 alert，三个人三种理解，每个人都没错。”
组件库里的Alert只是视觉组件——圆角、图标位、关闭按钮。它不知道自己在交易确认场景里是阻断性语义，在信息展示场景里是旁观性语义。前端理解为弹窗，设计师指的是顶部通知条，两个人都对，因为没有任何注册表裁定。

前端与 AI 工程师的另一条真实反馈：“LLM 把 Critical 降级为’严重’，代码里查不出来。”
在 LLM 的词汇表里，“Critical"和"严重"是近义词。AI 生成告警时把 “Critical” 替换为"严重”、把 “Data Loss Risk” 替换为"请稍后重试"——情绪权重在概率性输出中被随机降级，而没有任何机制判定这是违规。

DesignOps 与设计系统负责人的真实反馈：“规范写在文档平台里，人可能看漏，AI 工具完全不可见。”
"错误状态分四级"供人阅读，机器查询不了，更校验不了。

汇总成一张表：

这四条反馈指向同一个根因：语义没有被编码成机器可读的东西。红色只是色值，组件只是容器，术语只是字符串——机器拿不到语义，就只能靠概率猜。

二、"把语义编码为离散令牌"不是自创概念

2025年7月，arXiv上的MOSS论文提出Token Codebook——把语义概念锁进可查询的离散字典，让概率生成不再自由浮动。这与我们的语义令牌表是同一逻辑。

同期STCC框架将其定义为"码本"：离散令牌指向一组连续约束（视觉、行为、文案）。编译管线查表展开的过程，就是码本解码。

工业界也在做。W3C DTCG的Design Token Taxonomy已定义Semantic Token层，把颜色和间距抽象为语义。我们在其之上扩展了行为约束与跨域规则。

但行业也有反面的声音。Design Systems Collective今年指出，很多所谓"语义令牌"只是换名（color-red-500改叫color-danger），没有场景定义。这恰恰反证了我们为什么需要真正的语义字典——不是换名，而是锁义。

参考链接：
MOSS · W3C DTCG · When “semantic tokens” are no longer semantic · STCC（检索关键词 “Semantic Token Coding Framework arXiv 2026”）

三、关键设计：语义令牌表

3.1 四大命名空间（码本原子集）

语义令牌按"回答的问题"分为四个命名空间，每个令牌是离散索引，编译管线查表后展开为连续约束：

status._ —— 这件事有多严重？_*

phase._ —— AI 处于什么阶段？用户在等什么？_*

boundary._ —— 系统拒绝用户时，权利边界在哪里？_*

action._ —— 用户点击后，后果是什么？_*

3.2 字典注册的 6 个语义绑定（v1.0.0）

字典 v1.0.0 注册的 6 个语义绑定，构成组织级语义码本的最小可行原子集：

3.3 令牌如何展开为连续约束

每个令牌在契约中展开为一组连续约束。以status.critical应用于致命错误（ERR-001 · fatal 级别）为例：

semantic_tokens:error_severity:fatal:description:"致命错误：数据可能丢失或会话不可恢复"visual_mapping:color_token:status.critical# 引用字典绑定，非色值motion_token:pulse.red.urgent# 红色脉冲：注意力强制的最高档icon_token:octagon-alertuser_action:# 必须提供恢复路径-label:"刷新页面"action:refresh_pagepriority:1-label:"导出历史"action:export_historypriority:2llm_constraints:-"文案必须说明'对话可能已丢失'"-"禁止仅显示'出错了'等模糊文案"-"禁止显示纯技术错误码"immutable_boundaries:-boundary_type:semanticrule:"禁止把 fatal 级错误渲染为普通文字提示"violation_action:block-boundary_type:semanticrule:"status.critical 不可用于 observational 域"violation_action:block

一个离散索引（status.critical）→ 展开为视觉方向（红色脉冲 + 八边形图标）+ 行为约束（恢复路径、二次确认）+ 文案约束（必须说明后果）+ 机器防线（跨层禁止 block）。这就是"码本解码"的完整形态。

四、架构层概念：设计背景

码本，而非术语表。术语表供人查阅，码本供机器解码：每个令牌是离散索引，编译管线查表后展开为连续约束（视觉方向 + 行为约束 + 文案语气）。这决定了令牌的读者不只是设计师，更是编译管线与 AI 工具。

令牌层与呈现层分离。color_token是语义标识，color是实际色值：同一个status.critical在不同设计系统里可映射到不同色值（Tailwind #EF4444 / Ant Design #F5222D / DevUI #FF4D4F）。语义令牌不关心具体色值，只关心语义映射关系——设计系统更新时改映射表，契约不变。

语义覆盖层（Semantic Overlay）。组件库是底层（Underlay），只负责渲染——它提供圆角、色值、图标位这些空容器；语义覆盖层在组件之上加盖业务语义，把空容器翻译为业务语义组件。令牌是覆盖层加盖语义时使用的"印泥"。

术语双轨。面向不同读者群时，三层结构有两套叫法：语义域 ≈ 覆盖层目录；语义令牌 ≈ 语义重绑定；场景映射 ≈ 约束注入。两套术语指向同一份注册表。

五、这些坑怎么被解掉：场景与角色对照

回到开头那些真实反馈，看令牌就位后它们各自怎么闭环。

踩过的坑 1：“这个红到底代表什么，走查时谁也说不清”

• 症状：AI 生成限流提示时，Before 形态下选color-danger无可指责——红色本身没错，视觉走查也合规，但用户看到红色以为账户出了问题，实际只是需要等 30 秒。合规，但错误。
• 根因：Token 只定义颜色，没定义场景语义，机器拿不到"限流 ≠ 致命"这条信息。
• 关联机制：①语义令牌与字典（本篇 B1 + B3）+ C-D2《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” 在所有产出中保持锚定，替换即被校验规则命中。

六、调整后：工具界面层的呈现状态

同一批工具，在语义令牌就位之后：

边界声明

语义令牌表不解决视觉值的一致性（那是 Design Token 层的职责），不定义具体场景的约束实例（那是 YAML 契约的职责），也约束不了"有没有人查它"（消费纪律在角色侧，见角色 1 长篇）。当前量化收益均为数据模型推演，待生产数据验证。