前一篇《从管"长什么样"到管"意味着什么"》讲了设计系统负责人如何参与语义层基础设施的评审与维护，从语义令牌的定义、语义域的划分，到约束显化规则的确认。那些内容偏"机制"，回答的是"为什么需要这样做"。
这篇我们换个角度，把镜头拉近，只看一件事：设计系统负责人最少做多少，就能开始建立"从色值到语义"的评审能力？
答案是：找到你们规范里使用频率最高的那个Design Token，追问它三个问题。仅此而已。
一、为什么要从1个Token开始
很多设计系统负责人看到"语义令牌"这个词，第一反应是："这是不是意味着我要把整套Design Token重新做一遍？"
不是的。
语义令牌不是替代Design Token，而是在Design Token之上加盖一层语义含义。你们已经有的 color-error: #EF4444 继续保留，颜色值不变、使用方式不变。变化的是：在这行颜色定义旁边，多写三行注释，回答"这个颜色在什么场景下使用、用户看到它该做什么、这个场景下绝对不能做什么"。
这三行注释，就是语义令牌的起点。
为什么只从1个Token开始？因为组织对抗往往来自"又要做一套新东西"的疲惫感。但如果告诉你："不需要新建任何东西，只需要在现有规范上追问三个问题"，门槛就低了很多。
二、追问三个问题：从"这是什么颜色"到"这意味着什么"
打开你们的设计规范文档，找到使用频率最高的那个状态色，通常是错误色、警告色、成功色中的一个。我们以错误色为例。
问题1：这个颜色用在什么场景？
现有规范中的答案通常是："错误提示"。
需要追问到：是"系统级故障"（服务挂了、数据丢了），还是"用户可恢复错误"（网络抖动、请求太频繁）？
这两个场景的视觉表达可能都是红色，但用户看到后的行动完全不同：
- 系统级故障 → 用户需要立即刷新页面、导出历史、联系客服
- 用户可恢复错误 → 用户只需要等一等、或者换个网络环境
你的动作：在规范文档里，把"错误提示"拆成两个具体场景，分别标注。
问题2：这个场景下用户该做什么？
现有规范中通常没有定义。
需要补充：用户看到红色错误后，界面上应该提供什么行动按钮？
| 场景 | 用户行动 | 按钮文案 |
|---|---|---|
| 系统级故障 | 刷新页面 / 导出历史 | "刷新页面" / "导出对话" |
| 网络抖动 | 等待自动恢复 / 手动重试 | "等待中..." / "重新加载" |
| 请求太频繁 | 等待倒计时 / 升级套餐 | "42分钟后重试" / "升级Plus" |
你的动作：在规范文档里，为每个场景补充"用户行动"列。
问题3：这个场景下绝对不能做什么？
现有规范中通常也没有定义。
需要补充：这个红色错误状态，绝对不能用在什么场景？
比如：
- 绝对不能把"系统级故障"的红色，用在"新功能上线通知"上，用户会误以为服务挂了
- 绝对不能把"请求太频繁"的黄色提示，做成红色背景，用户会恐慌性刷新
- 绝对不能在"系统级故障"的文案里写"请稍后重试"，用户会误以为等一等就好
你的动作：在规范文档里，为每个场景补充"绝对不能"列。
三、把追问结果写成"机器能读"的格式
追问完三个问题后，你手里有了一份"人懂的"语义定义。下一步是把它翻译成"机器能读"的格式，不是让你写代码，而是写一段结构化的注释，让下游的语义翻译设计师能直接把它编码成YAML契约。
追问前（人懂的直觉）：
"系统出大事的时候要用红色，而且要很显眼，让用户知道必须马上处理，不能随便点掉。"
追问后（结构化语义定义）：
【语义令牌】status.critical（致命状态）
【对应Design Token】color-error: #EF4444
【使用场景】系统级故障，如服务中断、数据丢失、流式输出中断
【用户行动】必须提供"刷新页面"和"导出历史"两个按钮
【绝对不能】
- 绝对不能用于普通通知或新功能上线提示
- 绝对不能在文案中建议用户"等待"或"稍后重试"
- 绝对不能省略恢复路径（至少提供一个行动按钮）
【视觉映射】红色脉冲 + 八边形警告图标
你的动作：把这份结构化定义，贴在你们设计规范的对应Token旁边。不需要写YAML，只需要写到这个颗粒度，下游的语义翻译设计师会把它编码成契约。
四、真的发生过吗：一个你可以在自己组织里验证的案例
你们组织里一定有这样的情况：同一个红色错误提示，在不同产品或不同页面里，文案和行动按钮都不一样。
你可以做的验证动作：
- 打开你们的主产品，触发一个错误状态（比如断网）
- 截图，记录：颜色是什么、文案是什么、提供了什么行动按钮
- 再打开你们的另一个产品（或另一个页面），触发同样的错误状态
- 截图，对比：两个产品的红色错误，文案和行动是否一致？
大概率你会发现：
- 产品A说"网络错误，请刷新"，只有一个"刷新"按钮
- 产品B说"连接断开，建议检查网络"，没有按钮，只有文字提示
- 产品C说"Something went wrong"，连"网络"两个字都没提
这就是语义漂移：同一个错误场景，三个产品给出了三种不同的语义表达。用户在产品A知道要刷新，在产品B不知道要做什么，在产品C以为系统崩了。
你的动作：把这三个截图并排放在一起，在团队群里发一句："我们的错误提示，好像没有统一标准？"，这就是语义评审的起点。
五、一直在工作吗：怎么让这条定义不被遗忘
追问完三个问题、写成结构化定义后，最怕的是：这份定义躺在文档里，没人看，慢慢过期。
最小可行的保鲜机制：
| 检查项 | 频率 | 谁做 | 怎么做 |
|---|---|---|---|
| 这个Token的语义定义是否被契约引用 | 每月 | 设计系统负责人 | 查看规则仓库索引，确认有契约引用了这个Token |
| 这个Token的Design Token色值是否变更 | 每次Design Token更新 | 设计系统负责人 | 对比映射表，确认语义映射仍然正确 |
| 这个Token对应的场景是否出现新的边界情况 | 每次线上问题复盘 | 设计系统负责人 | 在复盘会上追问"这个错误的语义表达是否准确" |
你的动作：先在日历上设一个每月提醒，"检查错误色的语义定义是否被引用"。只需要5分钟，就能确认这条定义还活着。
六、生长路径：从1个Token到组织级语义标准
追问1个Token只是起点。设计系统负责人的语义评审能力，会沿着这条路径自然生长：
| 阶段 | 时间 | 动作 | 产出 |
|---|---|---|---|
| 阶段0：追问1个Token | 现在 | 找到错误色，追问三个问题，写成结构化定义 | 1份语义定义草稿 |
| 阶段1：追问3个Token | 1-2周后 | 把追问方法复制到警告色、成功色、信息色 | 1份4色语义定义表 |
| 阶段2：建立评审模板 | 1个月后 | 把追问三个问题的方法，写成团队共享的评审清单 | 1份《语义令牌评审Checklist》 |
| 阶段3：参与契约评审 | 2-3个月后 | 语义翻译设计师开始写契约时，用这份Checklist评审 | 评审通过率数据 |
| 阶段4：主导字典维护 | 6个月后 | 新Token的注册、旧Token的弃用、映射表的更新 | 语义字典版本管理权 |
关键原则：不是"等全套建好再开始"，而是"从1个Token开始，在追问中建立标准，在标准中完善基础设施"。
结语
前一篇讲了设计系统负责人在语义层基础设施中的评审职责，从语义令牌到语义域，从约束显化到字典维护。那些是"地图"，让你知道这片领域长什么样。
这篇讲的是"第一步"：不需要走完整个地图，只需要找到你们规范里那个最常用的错误色，追问它三个问题，用在什么场景、用户该做什么、绝对不能做什么。
追问本身就是评审。 当你开始追问，你就已经从"管颜色值"生长到了"管语义含义"。
希望能帮到你。如果你在追问过程中遇到了有趣的案例（比如发现你们组织里同一个红色错误有五种不同的文案），欢迎在评论区分享，这些真实的混乱，正是语义治理最好的起点。
下一篇会针对"核对组件的语义边界"展开，聊聊设计系统负责人怎么判断：同一个Alert组件，在"系统故障"和"新功能通知"两个场景下，是否承担了正确的语义身份。
