AI生成时代，设计师交付的不再是像素或组件，而是“意图的坐标”。本文深入拆解语义令牌与语义域两大核心工具，通过真实案例揭示：设计师少写一个词，AI就把两个世界平均成一个。从选颜色到选语义，从画组件到标场景，这是一场关于“定义正确答案”的协作革命。

开篇：这个角色从哪来

设计师与产品经理是组织里“离用户困惑最近的人”，任何定义界面”应该是什么样”的人天然就是这个体系的第一环。变化的不是岗位，是工作对象。

设计工具的每一次革命，都在改写设计师交付的东西：

• Sketch时代，交付的是“像素”，一张精确到标注的图，前端按图施工
• Figma时代，交付的是“组件”，一套可组装的零件，前端按规范拼装
• AI生成时代，交付的是“语义”，意图的坐标

过去设计师交付”一张图”，AI按图生成；现在AI生成的是“概率性内容”，同一段提示词每次生成的界面可能都不一样，图不再是可靠的传递媒介。设计师需要交付的是”意图的坐标”：这个组件在这个场景下，必须表达什么语义、不能表达什么语义。坐标定了AI生成的概率分布才有了锚点。

核心转变：设计师不再只是”画出正确答案的人”，而是”定义什么是正确答案的人”。

本篇展开三件事：理解语义令牌、使用语义域、遵守约束显化规则。这三件事的共同点是设计师不生产机器规则，但设计师是所有规则的语义源头，令牌需要设计师选，场景需要设计师标，约束需要设计师提。

协作埋点：标注的语义由谁评审、如何进入规则体系见《设计系统负责人的语义生长》。

语义令牌：设计师与语义令牌的关系从”选颜色”到”选语义”

1. 角色消费场景：传统设计中，设计师在色板里选 #EF4444

在传统设计流程里，设计师在色板里选 #EF4444。这个颜色值由Design Token层管，设计师只需要”选得好看、选得一致”。

AI时代，设计师需要选的是 status.critical。色值由Token层管，语义由令牌层管。当AI生成界面时，它不需要知道 #EF4444 是什么色值（那是 Token 层的事），但它必须知道：这个状态是”致命”还是”可恢复”？用户必须”立即处理”还是”等一等就好”？

这两个问题的答案，过去靠前端工程师”猜设计师的意图”。现在猜不猜得准直接决定生成质量，语义标注缺位，AI就按概率平均地生成，界面就失控。

关键设计详情：《Token层差异 从颜色值到语义状态的三层跃迁》，Design Token管”长什么样”，语义令牌管”意味着什么”。两者互补不替代：设计系统更新时改映射表，契约不变。设计师的工作对象，从色板迁移到了语义枚举。

2. 翻译能力：把”这个地方要很醒目”标注为正确的语义令牌

设计师每天都在做”这个状态很重要”的直觉判断。翻译能力，就是把这个直觉标注为正确的语义令牌，而不是留给前端猜。

标注前（人懂的直觉）：

“这个地方要很醒目，用户必须马上处理，不能随便点掉。”

标注后（机器可引用的语义令牌）：

“这个场景引用 status.critical（致命状态）：系统级故障，用户必须立即处理，必须提供恢复路径。”

设计师的标注动作不是写代码，而是在设计稿上、在走查记录里，明确写下“这个场景属于什么语义”。这一跳完成与否，就是“画对界面”和”标对语义”的分界线。

3. 关键决策点 1：机器不确定时，降级复用还是发起新令牌申请

当设计方案中的状态无法匹配现有令牌时，机器”不确定”，设计师需要在场判断。

场景示例：组织内出现了”资金冻结”这一新状态。它比普通警告严重（涉及用户资产），但比系统故障轻（不是服务中断）。现有令牌库里没有它的位置。

• 选项 A：降级使用 status.warning，在文案中强调严重性
• 选项 B：发起新令牌申请（如 status.alert，高优先级警告），定义新的语义层级

机器无法做这个判断，因为它不理解”资产安全”在用户心智中的权重。设计师基于对用户认知的理解做判断：资金冻结涉及资产安全，用户的紧张程度接近”致命”，降级为警告会导致用户低估风险；但冻结不是系统坏了，升级致命状态会让用户恐慌性操作。判断结论连同理由一起提交，这个理由会成为令牌评审的重要输入。

这就是”机器不确定时，人在场”。设计师的判断，就是语义令牌体系的活水源头。

4. 语义标注缺位导致的生成失控

某AI运维助手的产品设计师，在设计错误提示时只标注了”错误提示”，没有区分”可恢复错误”（网络抖动）与”系统故障”（数据丢失）。

问题诊断：

• 语义层：两类错误在标注里都是”错误提示”，AI将两者生成同一红色、同一图标
• 后果：用户把可恢复错误当系统故障，恐慌性刷新、重复提交工单；把系统故障当可恢复错误，坐等恢复而错过导出数据的窗口
• 根因：不是AI生成错了，是设计师没有给AI”区别这两类错误的坐标”
• 修复：设计师在标注中区分 status.critical（系统故障，红色脉冲，必须提供恢复路径）与 status.warning（可恢复错误，黄色，建议重试）

这个案例说明：AI生成失控的第一责任人不是AI，是语义标注缺位。设计师少写一个词，AI就把两个世界平均成一个。

5. 语义字典的查询机制

设计师不用背下所有语义令牌。语义字典是组织级唯一信源，设计师通过模式库的Web查询界面使用它：

• “这个场景该引用哪个令牌？”，按场景描述检索已注册令牌
• “status.warning 的定义是什么？”，查询令牌的完整语义包与使用边界
• “没有匹配的场景怎么办？”，发起新令牌申请入口

机器保证字典是唯一信源，设计师保证”拿不准就查，查不到就申请”，而不是”自己造一个词”。语义碎片化的源头，就是每个人都觉得自己造的那个词”差不多就是这个意思”。

语义域：设计师与语义域的关系，从”画组件”到”标场景”

1. 角色消费场景：视觉对了，语义错了

同一个Alert组件，设计师在”系统故障”和”新功能上线”两个场景下画出完全相同的样式，视觉对了，语义错了。前者是阻断器，用户必须立即处理，否则系统状态恶化；后者是信息条，用户可选择性关注，不影响系统状态。

语义域要求设计师标注”这个组件属于什么场景”。组件是空容器，语义由场景定义。设计稿上多一个场景标注，机器才知道该注入什么约束。

关键设计详情：《语义域 组件是空容器语义由场景定义》，组件库是底层（Underlay）只负责渲染；语义覆盖层在组件之上加盖业务语义，把空容器翻译为业务语义组件。同一个Alert，被不同覆盖层引用时获得完全不同的语义身份与约束。设计师标注的，正是这层”语义外赋”的输入。

2. 翻译能力：把”这个弹窗是阻断性的”翻译成场景标注

标注前（人懂的直觉）：

“这个弹窗是阻断性的，用户必须处理完才能继续。”

标注后（机器能查的场景标注）：

“场景：支付确认 → overlay=transactional（交易与操作域），绑定 status.critical + action.destructive。”

设计师的标注动作，是让机器知道该注入什么约束：transactional 域注入”必须二次确认”，observational 域注入”可选择性关注”。同一个组件，因为标注不同，生成结果被约束向完全不同的方向。

3. 关键决策点 2：机器没见过时，新业务场景的域归属判断

当组织出现新业务场景，机器”没见过”对应的域映射，设计师需要在场判断该归入哪个域，或发起新域。

场景示例：组织内新增”AI助手对话”场景。对话中的错误提示（如提示”无法回答这个问题”）应该属于什么域？

• 选项 A：conversational，双向交流，上下文持续
• 选项 B：observational，仅接收信息，无需立即行动
• 选项 C：发起新域 ai-assistant，专门用于AI生成内容的场景

机器无法做这个判断，因为它不理解”对话上下文保留”在用户体验中的权重。设计师基于对场景的理解判断：对话错误需要保留上下文、提供替代建议，属于 conversational 域而非 observational 域。判断结论提交后，进入域评审流程，由设计系统负责人核对。

4. 场景标注错误比不标注更危险

某团队在后台管理系统中，将”批量删除用户”按钮画成普通蓝色，场景标注为 navigational（导航与引导域）。理由是”它是页面里的一个操作”。

问题诊断：

• 语义层：批量删除是数据销毁操作，属于 transactional 域，应绑定 action.destructive
• 后果：标注为 navigational 后，AI生成时注入的是”引导动作”约束，缺少二次确认，用户误触后批量删除数据
• 根因：不标注只是”语义缺失”，错误标注是”语义误导”。机器信任标注，比不信任更危险，它不会怀疑你给它的坐标
• 修复：设计师在走查时纠正场景标注为 transactional + action.destructive

这个案例说明：语义域标注的责任，比看起来重得多。你标的不只是一个分类，是机器生成时的全部约束来源。标错了，机器会理直气壮地生成错误。

5. 跨层禁止的界面呈现

当设计师标注了与语义令牌冲突的域，Figma插件实时提示”该场景禁止绑定致命状态”。跨层禁止规则由机器执行，设计师的标注动作就是触发点：

• status.critical 禁止用于 observational / navigational / conversational 域
• action.destructive 禁止用于 navigational 域
• status.info 禁止用于 transactional 域

机器在每次标注时自动执行检查。设计师只在”机器发信号时”在场：当插件弹出禁止提示、当走查发现生成结果突破预期、当新场景没有现成域映射时。

约束显化：设计师与约束显化的关系，从”口头强调”到”规则输入”

1. 角色消费场景：评审会上那句”这个绝对不能这样”，过去到会议结束为止

评审会上说”这个绝对不能这样”，过去这句话的生命周期到会议结束为止。现在它可以成为约束显化的输入：设计师的”绝对不能”，是所有约束规则的语义源头。

设计师不直接写机器规则，但每一条不可变边界，都从一个设计师的”绝对不能”开始。

约束显化规则分两类：不可变边界（Immutable Boundaries，违约动作为block，违反即阻断）与推荐约束（LLM Constraints，违约动作为warn，违反即警告），这个分级，也就是违约动作选block还是warn的判断，依赖设计师对”后果有多严重”的原始输入。

关键设计详情：《约束显化 把隐含的语义假设变成显式规则》，传统规范面向人阅读，机器无法消费。设计师的口头强调被翻译成显式规则后，获得可被机器读取、可被自动校验、可被版本管理、可被多格式分发的能力。

2. 翻译能力：把口头强调转化为”约束意图描述”

翻译前（口头强调）：

“删除按钮绝对不能做成普通蓝色，用户会误触的。”

翻译后（约束意图描述）：

设计师的翻译动作，不是写YAML而是把“绝对不能”说清楚：什么不能做、后果是什么。语义翻译设计师会把它编码成机器规则。设计师说清楚的程度，决定了机器规则保真的程度。

3. 关键决策点 3：机器发信号时，走查发现未显化的隐含假设

约束显化规则一旦进入系统，机器在每次编译和每次生成时自动执行。设计师不需要逐条检查，机器在自动运行。设计师只在”机器发信号时”在场，走查时发现AI生成的界面突破了某个未被显化的隐含假设（如”删除按钮文案不能是’确认'”），此时发起约束补充。

机器发信号的形式：

• 走查发现生成结果与预期不符：设计稿标注了 action.destructive，AI生成的按钮文案却是”确认”
• 约束追踪面板告警：某条约束的对抗测试用例通过率下降
• 同类问题重复出现：同一个”口头补充”在评审会上出现了三次以上

设计师的走查记录是约束显化的第一信号源：发现一次，口头补充一次；同类问题出现三次以上，就应该提交正式的约束意图，让它从”个人记忆”变成”组织规则”。

3. 口头意图与显式规则的颗粒度差

设计师在评审时口头强调”删除必须有二次确认”，语义翻译设计师据此编码了约束：action.destructive 必须包含 confirmation_dialog（确认弹窗）。

问题诊断：

• 语义层：设计师的意图是”用户必须输入账户名确认”，契约约束的是”必须有弹窗”
• 后果：AI生成了”点击确认即删除”的假二次确认，有弹窗，但没有输入验证环节，用户误触风险未消除
• 根因：口头意图与显式规则之间存在颗粒度差。”二次确认”这个词，人听懂的版本和机器执行的版本不一样
• 修复：设计师补充约束意图：”二次确认 = 必须输入账户名，不是点一个确认按钮”，约束改写为 confirmation_step: “type_account_name”

这个案例说明：设计师提供约束意图时，”说清楚”的标准不是”人听懂了”，而是”机器不会误解”。颗粒度差是语义断层的主要来源之一而堵住它的最便宜的位置，就是设计师提交约束意图的那一刻。

4. 约束显化的输入接口

设计师通过“约束意图”表单提交：什么绝对不能做 + 后果是什么。不需要手写YAML，不需要懂机器规则的语法，不需要知道 violation_action 怎么填。

机器在约束入库后自动执行：自动编译、自动校验、自动拦截。设计师只在提交意图时在场，其余时间机器在跑。

结语：语义养成的终点

本文展开了三件事：

1. 在语义令牌中，设计师把”这个地方要醒目”的直觉，标注为机器可引用的语义令牌
2. 在语义域中，设计师把”这个弹窗是阻断性的”的判断，标注为场景与域的绑定
3. 在约束显化中，设计师把”这个绝对不能这样”的口头强调，转化为约束意图描述

这三个动作的共同特征：设计师不生产机器规则，但设计师是所有规则的语义源头。翻译发生在”直觉→证据”这一跳，直觉被结构化的那一刻，翻译就开始了。

设计师在整条链路上的”在场”，同样被压缩到三个关键决策点：

1. 机器不确定时——新状态的语义权重判断（降级复用还是新令牌申请）
2. 机器没见过时——新业务场景的域归属判断
3. 机器发信号时——走查发现的未显化假设，发起约束补充

其余时间，机器在跑。

语义觉醒终点，产生了一个新问题：这些标注和快照交给谁？怎么变成规则？规则又如何回到设计师手里，反向服务于设计工作？——我会在下文《消费路径》与《快照的流转》中展开。