定位：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 工具完全不可见。"
"错误状态分四级"供人阅读，机器查询不了，更校验不了。
汇总成一张表：
| 工具 / 环节 | 界面层呈现状态 | 缺失什么 |
|---|---|---|
| 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.__ —— 这件事有多严重？*
| 令牌 | 含义 | 视觉映射示例 |
|---|---|---|
| status.critical | 致命：系统故障、数据丢失 | 红色脉冲 + 八边形警告 |
| status.warning | 警告：限流、降级、可恢复错误 | 黄色提示 + 时钟图标 |
| status.info | 信息：提示、说明、部分可用 | 蓝色静态 + 信息图标 |
| status.success | 成功：保存完成、操作成功 | 绿色静态 + 对勾图标 |
| status.neutral | 中性：加载中、等待中 | 灰色动画 + 旋转图标 |
phase.__ —— AI 处于什么阶段？用户在等什么？*
| 令牌 | 含义 | 视觉映射示例 |
|---|---|---|
| phase.research | 检索：搜索信息、查找来源 | 蓝色 + 放大镜图标 + 来源计数 |
| phase.analysis | 综合：对比多源、识别分歧 | 黄色 + 大脑图标 + 共识度 |
| phase.check | 验证：核对链接、验证事实 | 绿色 + 盾牌图标 + 验证状态 |
| phase.output | 生成：生成答案、输出结果 | 紫色 + 文档图标 + 引用索引 |
boundary.__ —— 系统拒绝用户时，权利边界在哪里？*
| 令牌 | 含义 | 视觉映射示例 |
|---|---|---|
| boundary.soft | 软性拒绝：拒绝请求但保留会话 | 黄色提示条 + 保留输入框 |
| boundary.hard | 强制终止：终止会话清空上下文 | 红色退出面板 + 数据政策说明 |
| boundary.review | 升级审核：提交人工审核 | 蓝色提示 + 预计审核时间 |
action.__ —— 用户点击后，后果是什么？*
| 令牌 | 含义 | 视觉映射示例 |
|---|---|---|
| action.destructive | 破坏性：删除、清空、不可逆 | 红色空心 + 二次确认 + 输入验证 |
| action.constructive | 建设性：保存、提交、创建 | 蓝色实心 + 成功反馈 |
| action.neutral | 中性：取消、关闭、返回 | 灰色描边 + 无后果 |
3.2 字典注册的 6 个语义绑定（v1.0.0）
字典 v1.0.0 注册的 6 个语义绑定，构成组织级语义码本的最小可行原子集：
| 语义绑定 | 含义 | 核心约束注入 | 跨层禁止示例 |
|---|---|---|---|
| status.critical | 阻断性、可能不可恢复 | 红色脉冲、八边形图标；必须二次确认；文案必须说明后果 | 不可用于 observational 域（限流提示禁用致命红） |
| status.warning | 需注意、可恢复 | 黄色静态、三角图标；必须显示恢复时间；必须提供操作步骤 | — |
| status.info | 中性信息告知 | 蓝色静态、信息图标；可自动消失；禁止附加操作说明 | — |
| status.success | 操作成功确认 | 绿色静态、对勾图标；可自动消失；禁止附加操作说明 | — |
| action.destructive | 不可逆操作 | 红色空心描边、危险图标；必须二次确认；必须说明不可恢复 | 禁止使用普通主按钮样式 |
| action.primary | 场景主行动 | 品牌色实心、箭头图标；点击后跳转；显示下一步预览 | — |
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-alert
user_action: # 必须提供恢复路径
- label: "刷新页面"
action: refresh_page
priority: 1
- label: "导出历史"
action: export_history
priority: 2
llm_constraints:
- "文案必须说明'对话可能已丢失'"
- "禁止仅显示'出错了'等模糊文案"
- "禁止显示纯技术错误码"
immutable_boundaries:
- boundary_type: semantic
rule: "禁止把 fatal 级错误渲染为普通文字提示"
violation_action: block
- boundary_type: semantic
rule: "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" 在所有产出中保持锚定，替换即被校验规则命中。
六、调整后：工具界面层的呈现状态
同一批工具，在语义令牌就位之后：
| 工具 / 环节 | 调整前 | 调整后 |
|---|---|---|
| AI 生成工具 | 只有色值，限流与致命错误同红 | Prompt 前缀注入令牌约束后：致命错误 = 红色脉冲 + 八边形图标 + 恢复路径；限流提示 = 黄色时钟 + 倒计时——同模型同任务，产出语义分级 |
| 文案生成 | "Critical" 被随机替换为"严重" | synonym_firewall 锚定关键术语，替换即被校验规则命中 |
| 验收环节 | 走查结论停留在"感觉不对" | Checklist 逐项核对：语义分级 / 文案 / 红线，违反红线即阻断，结论注明契约版本号 |
边界声明
语义令牌表不解决视觉值的一致性（那是 Design Token 层的职责），不定义具体场景的约束实例（那是 YAML 契约的职责），也约束不了"有没有人查它"（消费纪律在角色侧，见角色 1 长篇）。当前量化收益均为数据模型推演，待生产数据验证。
