开篇：这个角色从哪来
设计师与产品经理是组织里 "离用户困惑最近的人" ，任何定义界面"应该是什么样"的人天然就是这个体系的第一环。变化的不是岗位，是工作对象。
设计工具的每一次革命，都在改写设计师交付的东西：
- 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. 翻译能力：把口头强调转化为"约束意图描述"
翻译前（口头强调）：
"删除按钮绝对不能做成普通蓝色，用户会误触的。"
翻译后（约束意图描述）：
【约束意图】action.destructive 场景
- 什么绝对不能做：删除按钮不得使用 action.primary 的主按钮样式
- 后果是什么：用户误触后发生不可逆的数据删除
- 建议的判定方式：样式绑定检查
设计师的翻译动作，不是写YAML而是把 "绝对不能" 说清楚：什么不能做、后果是什么。语义翻译设计师会把它编码成机器规则。设计师说清楚的程度，决定了机器规则保真的程度。
3. 关键决策点 3：机器发信号时，走查发现未显化的隐含假设
约束显化规则一旦进入系统，机器在每次编译和每次生成时自动执行。 设计师不需要逐条检查，机器在自动运行。设计师只在"机器发信号时"在场，走查时发现AI生成的界面突破了某个未被显化的隐含假设（如"删除按钮文案不能是'确认'"），此时发起约束补充。
机器发信号的形式：
- 走查发现生成结果与预期不符：设计稿标注了
action.destructive，AI生成的按钮文案却是"确认" - 约束追踪面板告警：某条约束的对抗测试用例通过率下降
- 同类问题重复出现：同一个"口头补充"在评审会上出现了三次以上
设计师的走查记录是约束显化的第一信号源： 发现一次，口头补充一次；同类问题出现三次以上，就应该提交正式的约束意图，让它从"个人记忆"变成"组织规则"。
4. 口头意图与显式规则的颗粒度差
设计师在评审时口头强调"删除必须有二次确认"，语义翻译设计师据此编码了约束：action.destructive 必须包含 confirmation_dialog（确认弹窗）。
问题诊断：
- 语义层：设计师的意图是"用户必须输入账户名确认"，契约约束的是"必须有弹窗"
- 后果：AI生成了"点击确认即删除"的假二次确认，有弹窗，但没有输入验证环节，用户误触风险未消除
- 根因：口头意图与显式规则之间存在颗粒度差。"二次确认"这个词，人听懂的版本和机器执行的版本不一样
- 修复：设计师补充约束意图："二次确认 = 必须输入账户名，不是点一个确认按钮"，约束改写为
confirmation_step: "type_account_name"
这个案例说明：设计师提供约束意图时，"说清楚"的标准不是"人听懂了"，而是"机器不会误解"。 颗粒度差是语义断层的主要来源之一而堵住它的最便宜的位置，就是设计师提交约束意图的那一刻。
5. 约束显化的输入接口
设计师通过 "约束意图" 表单提交：什么绝对不能做 + 后果是什么。不需要手写YAML，不需要懂机器规则的语法，不需要知道 violation_action 怎么填。
机器在约束入库后自动执行：自动编译、自动校验、自动拦截。 设计师只在提交意图时在场，其余时间机器在跑。
结语：语义养成的终点
本文展开了三件事：
- 在语义令牌中，设计师把"这个地方要醒目"的直觉，标注为机器可引用的语义令牌
- 在语义域中，设计师把"这个弹窗是阻断性的"的判断，标注为场景与域的绑定
- 在约束显化中，设计师把"这个绝对不能这样"的口头强调，转化为约束意图描述
这三个动作的共同特征： 设计师不生产机器规则，但设计师是所有规则的语义源头。翻译发生在"直觉→证据"这一跳，直觉被结构化的那一刻，翻译就开始了。
设计师在整条链路上的"在场"，同样被压缩到三个关键决策点：
- 机器不确定时——新状态的语义权重判断（降级复用还是新令牌申请）
- 机器没见过时——新业务场景的域归属判断
- 机器发信号时——走查发现的未显化假设，发起约束补充
其余时间，机器在跑。
语义觉醒终点，产生了一个新问题：这些标注和快照交给谁？怎么变成规则？规则又如何回到设计师手里，反向服务于设计工作？——我会在下文《消费路径》与《快照的流转》中展开。
1920.png.png
