《从"画对界面"到"标对语义"》一文讲了设计师与产品经理如何理解并使用语义层基础设施来表达设计意图，从语义令牌的选定、语义域的场景标注，到约束显化的规则输入。那些内容偏"机制"，回答的是"为什么需要这样做"。
现在我们只看一件事：设计师最少做多少，就能开始建立"标场景"的能力？
答案是：挑你们最高频的1个组件，在它的2个场景上分别练习标注。仅此而已。
一、为什么要从1个组件的2个场景开始
很多设计师看到"语义域"，第一反应是：
"这是不是意味着要给设计稿里每个组件的每个场景都做一次标注？"
不是的。
场景标注的价值不在覆盖量，在于让机器知道该注入什么约束。标对1个组件的2个场景，你就建立了"视觉对了、语义错了"的敏感度， 这是场景标注的核心肌肉。
为什么从2个场景开始？因为对比最能暴露语义差异：同一个组件，画得一模一样，在两个场景下却承担完全不同的语义身份。一个组件、两个场景，半小时即可完成。组织对抗往往来自"每个场景都要标"的疲惫感，而"只标2个场景"的工作量完全可预期。
二、练习标注：同一个组件，两个场景
打开你们的设计稿，挑最高频的1个组件（Alert或Button），找到它的2个典型场景。以Alert为例。
场景A：系统故障提示
- 问：这个Alert在这里是什么身份？
- 直觉答案是"错误提示"。追问到：它是阻断器，用户必须立即处理，否则系统状态恶化。
- 你的动作：标注
overlay=transactional（交易与操作域），绑定status.critical。
场景B：新功能上线通知
- 问：这个Alert在这里是什么身份？
- 直觉答案可能也是"提示"。追问到：它是信息条，用户可选择性关注，不影响系统状态。
- 你的动作：标注
overlay=observational（观察与信息域），绑定status.info。
把两个标注并排放，问第三个问题：这两个场景的Alert，画成一样可以吗？
答案是： 视觉可以一致，语义标注必须不同。因为机器不看你画得对不对，机器读的是你标注的语义身份，标注不同，注入的约束就不同，AI生成的行为就不同。
你的动作： 在设计稿上写下两个场景各自的域标注。
三、把标注结果写成"下游能读"的格式
标注前（你的直觉）：
"这个弹窗是阻断性的，用户必须处理完才能继续。"
标注后（结构化场景标注）：
【组件】Alert
【场景A】系统故障提示
→ overlay=transactional（交易与操作域）
→ 绑定 status.critical + action.destructive
→ 注入约束：必须二次确认、必须提供恢复路径
【场景B】新功能上线通知
→ overlay=observational（观察与信息域）
→ 绑定 status.info
→ 注入约束：可选择性关注，不得使用阻断样式
你的动作： 把这份标注贴在设计稿旁。下游会把场景标注编码成域绑定规则，你标的不只是一个分类，是机器生成时的全部约束来源。
四、（真的发生过吗）一个你可以在自己组织里验证的案例
你们组织里一定有这样的情况： 同一个组件出现在多个场景里，却从来没有人区分过它的语义身份。
你可以做的验证动作：
- 找1个在你们产品里出现在多个场景的组件（Alert / Button / Dialog）
- 把它的不同场景截图，并排摆放
- 逐个问自己：这个场景下它的语义身份是什么？是否已完成标注？
大概率你会发现：
- 同一个Alert，在系统故障时是红色阻断样式，在新功能通知时也是同样的红色。视觉对了，语义错了
- 更危险的：某处"批量删除"按钮被画成了普通蓝色，标注成了navigational域。机器信任这个标注，生成时注入了"引导动作"约束，缺少二次确认
不标注只是"语义缺失"，错误标注是"语义误导"。机器信任你给的坐标，比不信任更危险。
你的动作： 把并排截图和各自标注发在评审会上，问一句："同一个组件，场景标注是否统一？"。这就是场景标注的起点。
五、（一直在工作吗）怎么让标注习惯不被遗忘
练完1个组件的2个场景后，最怕的是：这次标了，下次画稿又回到"只画不标"。
最小可行的保鲜机制：
| 检查项 | 频率 | 谁做 | 怎么做 |
|---|---|---|---|
| 新设计稿的场景标注是否与生成结果一致 | 每次走查 | 设计师 | 对比AI生成稿与自己的标注，发现偏差即修正 |
| 标注是否触发跨层禁止提示 | 每次标注 | 设计师 | 留意Figma插件实时提示，如"该场景禁止绑定致命状态" |
| 是否出现没有现成域的新场景 | 每次项目复盘 | 设计师 | 记录困惑，准备发起新域归属判断 |
你的动作： 在走查流程里加固定一步 "核对场景标注" 。只需要每次走查多花2分钟，就能确认标注习惯仍在保持。
六、生长路径：从2个场景到域归属判断
练习1个组件的2个场景只是起点。设计师的场景标注能力，会沿着这条路径自然生长：
| 阶段 | 时间 | 动作 | 产出 |
|---|---|---|---|
| 阶段0：标注2个场景 | 现在 | Alert的系统故障与新功能通知两个场景分别标注 | 1份场景标注 |
| 阶段1：标注3个组件 | 1-2周后 | 把方法复制到Button、Dialog的各2个场景 | 1份场景标注集 |
| 阶段2：建立标注模板 | 1个月后 | 把"场景→域→绑定→注入约束"的格式写成团队模板 | 1份《场景标注模板》 |
| 阶段3：参与域归属判断 | 2-3个月后 | 新业务场景（如AI对话）出现时，判断该归入哪个域 | 域归属判断记录 |
| 阶段4：主导新域提案 | 6个月后 | 机器"没见过"的场景积累到阈值，发起新域申请 | 新域评审记录 |
关键原则：不是"等所有场景都有现成域再标注"，而是"从2个场景开始，在对比中建立语义敏感度，在敏感度中完善域体系"。
结语
《从画对界面到标对语义》一文讲了设计师与产品经理在语义令牌、语义域、约束显化中的标注职责。那些是"地图"，让你知道这片领域长什么样。
这里讲的是"第二步"：不需要给所有组件的所有场景做标注，只需要挑最高频的那个组件，找两个场景，分别写下它的语义身份，阻断器还是信息条，交易域还是观察域。
标注本身就是区分。当你给同1个组件的2个场景分别标注，你就已经在管"意味着什么"，而不只是"长什么样"。
希望能帮到你。如果你在练习中发现了有趣的场景（比如发现某个组件在你们产品里有五种身份却长得一模一样），欢迎在评论区分享，这些真实的混乱，正是语义域治理最好的起点。
下一篇会针对"约束显化"展开，聊聊设计师怎么把评审会上那句"这个绝对不能这样"，写成一条三要素齐备的约束意图。
本文由作者@魏雯，授权发布于平台，未经许可禁止转载。
