我在《从"画对界面"到"标对语义"》文中讲了设计师与产品经理如何理解并使用语义层基础设施来表达设计意图，从语义令牌的选定、语义域的场景标注，到约束显化的规则输入。那些内容偏"机制"，回答的是"为什么需要这样做"。
这篇我们只讲一件事：设计师最少做多少，就能开始建立"选语义"的标注能力？
答案是：打开你的设计稿，给1个界面元素选定1个语义令牌。
一、为什么要从1个界面元素开始
很多设计师看到"语义令牌"，第一反应是：
"这是不是意味着要把设计稿里所有颜色、所有状态全部重新标注一遍？"
不是的。
语义令牌不是替代Design Token，而是在色值之上加盖一层语义含义。 你稿子里那个#EF4444继续保留，颜色值不变、视觉不变。变化的是：在旁边多写一行字，这个颜色，在这个场景下，意味着什么。
为什么只从1个元素开始？因为组织对抗往往来自"又要做一套新东西"的疲惫感。但如果告诉你： "不需要重新标注任何东西，只需要给你最熟悉的那个元素，选定1个语义令牌" ，门槛就低了很多。
二、选定1个语义令牌：问三个问题
打开你的设计稿，找到那个最有把握的状态色，通常是错误色。以它为例。
问题1：这个元素现在用的是什么？
- 现有答案： 一个颜色值，比如
#EF4444。 - 需要追问到： 这个色值对应的Design Token叫什么名字？（如
color-error） - 你的动作： 确认这个元素走的是哪个Design Token，这是语义标注的锚点。
问题2：这个颜色在什么场景下使用？
- 现有答案： 通常写着"错误提示"。
- 需要追问到： 是系统级故障（服务挂了、数据丢了），还是用户可恢复错误（网络抖动、请求太频繁）？这两个场景的色值可能都是红色，但语义完全不同。
- 你的动作： 把场景写具体，写到"别人不需要问你就能理解"的颗粒度。
问题3：这个场景该引用哪个语义令牌？
- 现有答案： 通常没有。过去这就是前端"猜"的空间。
- 需要追问到： 打开模式库的语义字典查询界面，按场景描述检索已注册令牌。系统级故障 →
status.critical；可恢复错误 →status.warning。拿不准就查，查不到就发起新令牌申请，而不是自己造一个词。 - 你的动作： 在设计稿上写下选定的语义令牌名称。
三、把选定结果写成"下游能读"的格式
选定前（你的直觉）：
"这个地方要很醒目，用户必须马上处理，不能随便点掉。"
选定后（结构化语义标注）：
【场景】系统级故障提示
【引用令牌】status.critical
【语义含义】系统级故障，用户必须立即处理，必须提供恢复路径
【对应Design Token】color-error: #EF4444
【绝对不能】不得用于普通通知；文案不得建议用户"等待"或"稍后重试"
你的动作： 把这份标注贴在设计稿对应元素旁边。不需要你写YAML，不需要你懂机器规则的语法，写到这个颗粒度，下游的语义翻译环节会把它编码进契约。
四、（真的发生过吗）一个你可以在自己组织里验证的案例
你们组织里一定有这样的情况： 同一个红色错误提示，在不同产品或不同页面里，语义表达完全不同。
你可以做的验证动作：
- 打开你们的主产品，找到一处红色错误提示，截图
- 问自己：它是系统故障还是可恢复错误？界面上有恢复路径吗？
- 再打开另一个产品（或另一个页面）的同类提示，同样问自己，截图
- 把几张截图并排，尝试给每一处标注你认为正确的语义令牌
大概率你会发现：
- 产品 A 是系统故障样式，但没有提供任何恢复按钮
- 产品 B 是可恢复错误，却用了红色脉冲的致命样式，用户恐慌性刷新
- 产品 C 的文案连是什么错误都说不清楚
这就是语义漂移： 同一类界面元素，语义表达各不相同，因为从来没有人给它选定过语义令牌，AI只能按概率平均生成。
你的动作： 把并排截图发在团队群里，附一句："这个元素的语义，是否应该统一下？"这就是语义标注的起点。
五、（一直在工作吗）怎么让这条标注不被遗忘
选定1个语义令牌后，最怕的是：标注躺在设计稿里，没人引用，慢慢过期。
最小可行的保鲜机制：
| 检查项 | 频率 | 谁做 | 怎么做 |
|---|---|---|---|
| 这个令牌的标注是否被契约或模式库引用 | 每月 | 设计师 | 查看模式库索引，确认有规则引用了这个标注 |
| 对应的Design Token色值是否变更 | 每次Token更新 | 设计师 | 对比映射，确认语义标注是否需要同步修正 |
| 是否出现该令牌覆盖不了的新状态 | 每次走查或复盘 | 设计师 | 记录困惑，准备发起新令牌申请 |
你的动作： 在日历上设一个每月提醒，"检查那1个语义标注是否仍在工作"。只需要5分钟，就能确认这条标注还在链路里流通。
六、生长路径：从1个元素到语义源头
给1个元素选定1个语义令牌只是起点。设计师的语义标注能力，会沿着这条路径自然生长：
| 阶段 | 时间 | 动作 | 产出 |
|---|---|---|---|
| 阶段0：选定1个元素的令牌 | 现在 | 给错误提示选定 status.critical，写下结构化标注 |
1份语义标注 |
| 阶段1：选定3个元素的令牌 | 1-2周后 | 把方法复制到警告色、成功色、信息色 | 1份语义标注清单 |
| 阶段2：建立标注模板 | 1个月后 | 把"场景+令牌+含义+绝对不能"的格式写成团队模板 | 1份《语义令牌标注模板》 |
| 阶段3：参与契约评审 | 2-3个月后 | 语义翻译设计师编码契约时，用这份标注核对保真 | 标注被契约引用的记录 |
| 阶段4：主导新令牌申请 | 6个月后 | 新状态（如"资金冻结"）出现时，发起新令牌提案 | 新令牌评审记录 |
关键原则：不是"等语义字典建好了再标注"，而是"从1个元素开始，在标注中建立标准，在标准中完善基础设施"。
结语
《从画对界面到标对语义》讲了设计师与产品经理在语义令牌、语义域、约束显化中的标注职责。那些是"地图"，让你知道这片领域长什么样。
本文讲的是"第一步"：不需要标注整个设计系统，只需要打开你的稿子，给你最熟悉的那个错误提示，选定1个语义令牌，写清它在什么场景、意味着什么、绝对不能怎么用。
选定本身就是标注。当你给1个元素选定语义，你就已经从"画对界面"生长到了"标对语义"。
希望能帮到你。如果你在选定过程中遇到了有趣的发现（比如发现你们组织里同一个红色错误有三种语义身份），欢迎在评论区分享，这些真实的混乱，正是语义治理最好的起点。
下一篇会针对"语义域"展开，聊聊设计师怎么在同一个Alert组件的"系统故障"和"新功能通知"两个场景上，练习场景标注。
本文由作者@魏雯，授权发布于平台，未经许可禁止转载。
