设计系统负责人的语义生长：从管"长什么样"到管"意味着什么"

开篇：这个角色从哪来

设计系统负责人不是 Schema-As-Code把设计规范写成代码格式 体系中新发明的岗位。在大多数组织中，这个角色已经存在，只是过去的工作对象是"视觉规范"（颜色、字体、间距、组件形态），现在需要延伸到"语义规范"（组件在不同场景下必须表达什么含义、不能突破什么边界）。

当AI开始生成界面，设计系统负责人面临一个新的问题：组件库管住了"长什么样"，但没管住"意味着什么"。同一个按钮，AI在"删除草稿"和"删除账户"两个场景下可能生成完全相同的样式，视觉对了，语义错了。设计系统负责人需要把"这个场景下组件必须表达什么"的评审能力，从人脑中的经验，转化为机器可执行的规则。

这就是本文要展开的内容：设计系统负责人如何参与语义令牌定义、语义域划分、约束显化规则的评审，不是作为"人肉审查员"逐条检查，而是作为"规则定义者"在关键决策点确认机器无法自行判断的标准。

语义令牌定义，从"色值"到"语义"的评审

角色消费场景：设计系统负责人为什么必须参与语义令牌评审

在传统设计系统中，设计系统负责人管理的是Design Token，color-primary: #1890FF、font-size-large: 16px。这些令牌回答的是"长什么样"。

语义令牌回答的是"意味着什么"。status.critical 不只是一个颜色值，它携带的是"系统级故障、必须立即处理、必须二次确认"的完整语义包。当AI生成界面时，它不需要知道 #1890FF 是什么色值（那是Design Token层的事），但它必须知道 status.critical 代表"致命"，这个致命状态不能用于普通通知，不能降级为"严重"或"紧急"，必须伴随明确的恢复路径。

设计系统负责人参与语义令牌评审的核心价值，在于确认"这个令牌的语义边界是否清晰、是否与现有Design Token映射兼容、是否覆盖组织内所有必要场景"。

📎 关键设计详情：《① 语义字典：组织级语义注册表，契约的唯一信源》阅读原文\
语义字典是组织内唯一定义覆盖层、语义绑定、场景映射的资产。所有 YAML 契约必须引用字典中的已注册项，禁止自创覆盖层或绑定——非法引用在编译前置校验时直接阻断。设计系统负责人是这本字典的评审者和维护者。

翻译能力：从"人懂的直觉"到"机器读的规则"

语义令牌的评审过程，本质上是一次翻译：把设计系统负责人对"这个状态意味着什么"的专业直觉，翻译成机器可以消费的离散枚举。

评审前（人懂的直觉） ：

"系统出大事的时候要用红色，而且要很显眼，让用户知道必须马上处理，不能随便点掉。"

评审后（机器读的规则） ：

status.critical:
  description: "系统级故障，用户必须立即处理，否则系统状态恶化"
  visual_mapping:
    color_token: "status.critical"  # 映射到 Design Token #EF4444
    motion_token: "pulse.red.urgent"
    icon_token: "alert.octagon"
  llm_constraints:
    - "必须明确告知用户系统状态恶化的后果"
    - "禁止仅显示'出错了'等模糊文案"
    - "必须提供恢复路径（刷新或导出历史）"

设计系统负责人的评审动作，不是判断"红色好不好看"，而是判断：

• 这个令牌的语义描述是否足够精确，让机器不会误解？
• 这个令牌的视觉映射是否与现有Design Token兼容？
• 这个令牌的LLM约束是否可执行（每条都能被机器校验）？

📎 关键设计详情：《① 语义令牌表：把语义概念编码成离散枚举》阅读原文\
本文把"红色代表告警"这种模糊直觉，编码为 status.critical 这样的离散语义令牌，让机器能区分"致命"与"严重"的语义权重差异。设计系统负责人评审的，正是这些离散枚举的边界是否清晰。

📎 关键设计详情：《① Token 层差异：从颜色值到语义状态的三层跃迁》阅读原文\
Design Token 管"长什么样"（#EF4444），语义令牌管"意味着什么"（status.critical）。两者互补不替代：设计系统更新时改映射表，契约不变。设计系统负责人需要确认这两层映射的一致性。

关键决策点 1：机器不确定时

语义令牌评审发生在机器"不确定"的时候，即当一个新场景需要一个新令牌，或者一个现有令牌的语义边界需要扩展时。

场景示例：组织内出现了"资金冻结"这一新状态。它比普通警告严重（涉及用户资产），但比系统故障轻（不是服务中断）。设计系统负责人需要判断：

• 选项 A：复用 status.warning，在文案中强调严重性
• 选项 B：升级 status.critical，放宽致命状态的定义
• 选项 C：新增 status.alert（高优先级警告），定义新的语义层级

机器无法做这个判断，因为它不理解"资金冻结"在业务中的真实权重。设计系统负责人基于对业务场景的理解，选择选项C，并定义新令牌的完整语义包，这就是"机器不确定时，人在场" 。

真的发生过吗：令牌语义漂移的典型案例

某AI运维助手在生成告警卡片时，将"数据库主从延迟超过阈值"标记为 status.critical（致命），同时文案写为"数据库延迟，请稍后重试"。

问题诊断：

• 语义层：status.critical 要求"必须立即处理"，但文案建议"稍后重试"，语义冲突
• 根因：status.critical 的LLM约束中缺少"禁止建议延迟处理"的条款
• 修复：设计系统负责人在评审时补充约束，"致命状态文案必须包含立即行动指令，禁止建议等待"

这个案例说明：语义令牌的评审不是一次性工作，而是在实际使用中持续发现边界、补充约束的过程。

一直在工作吗：语义令牌的版本追溯机制

语义令牌一旦发布，进入冻结状态（immutable: true）。设计系统负责人可以通过以下机制确认令牌在持续生效：

设计系统负责人不需要每天检查这些指标，机器在自动运行。人只在"机器发信号时"在场：当对抗测试用例失败率超过阈值、当有团队申请扩展令牌语义、当Design Token映射表发生变更时。

📎 关键设计详情：《① 语义字典引用的机制防线：三层验证，证明语义可被机器执行》阅读原文\
语义字典的引用机制包含三层验证：覆盖层存在性、绑定存在性、场景一致性。这三层验证确保契约引用的都是字典中已注册的合法项，防止团队自创术语导致语义碎片化。设计系统负责人通过这三层验证的通过率，确认字典的权威性和一致性。****

语义域划分，核对组件的语义边界

角色消费场景：为什么设计系统负责人需要核对语义域声明

语义域定义了组件在特定场景下的语义身份。同一个 <Alert> 组件：

• 在 transactional 域（交易与操作）是"阻断器"。用户必须立即处理，否则系统状态恶化
• 在 observational 域（观察与信息）是"信息条"，用户可选择性关注，不影响系统状态
• 在 navigational 域（导航与引导）是"路径提示"，用户需要方向确认，无状态风险

设计系统负责人核对语义域声明，是确认"这个组件在这个场景下的语义身份是否正确"。 这不是视觉判断（"这个 Alert 好不好看"），而是语义判断（"这个 Alert 在这个场景下是否承担了正确的语义责任"）。

📎 关键设计详情：《② 语义域：组件是空容器，语义由场景定义》阅读原文\
组件库是底层（Underlay），只负责渲染；语义覆盖层在组件之上加盖业务语义，把空容器翻译为业务语义组件。同一个 Alert，被不同覆盖层引用时获得完全不同的语义与约束。设计系统负责人核对的，正是这层"语义外赋"是否正确。

翻译能力：把"我觉得这个组件在这里不对"变成"机器能查的域绑定规则"

设计系统负责人在走查设计稿时，经常有一种直觉："这个错误提示放在这里不太对。"过去，这种直觉只能口头传达，无法被机器执行。现在，这种直觉可以被翻译成语义域绑定规则：

评审前（直觉） ：

"这个删除账户的确认弹窗，不应该用普通的蓝色主按钮，应该是危险样式，而且要有二次确认。"

评审后（机器能查的规则） ：

scenario: "删除账户"
overlay: "transactional"
bindings: ["status.critical", "action.destructive"]
constraints:
  - "按钮样式必须为 outline_danger（红色空心描边）"
  - "必须包含二次确认弹窗"
  - "必须输入账户名确认"
  - "文案必须包含'此操作不可恢复'"

设计系统负责人的核对动作，是将这种直觉转化为"跨层禁止"规则：

• status.critical 禁止用于 observational 域（不能拿致命状态当普通通知）
• action.destructive 禁止用于 navigational 域（不能拿危险操作当导航按钮）

📎 关键设计详情：《② 跨层禁止：机器如何拦截非法语义绑定》阅读原文\
跨层禁止是语义域的核心约束机制：status.critical 禁止用于 observational / navigational / conversational 域；status.info 禁止用于 transactional 域。这些禁止规则由机器在编译和运行时自动执行，设计系统负责人负责确认规则的完整性和合理性。

关键决策点 2：机器没见过时

当组织出现新的业务场景，机器"没见过"对应的语义域映射时，设计系统负责人需要在场。

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

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

设计系统负责人基于对场景的理解，判断选项A最合适（对话错误需要保留上下文、提供替代建议），并定义该域下的约束注入规则。机器无法做这个判断，因为它不理解"对话上下文保留"在用户体验中的权重。

真的发生过吗：域绑定错误的典型案例

某团队在开发后台管理系统时，将"批量删除用户"按钮声明为 overlay="navigational"，绑定 action.primary（引导动作）。

问题诊断：

• 语义层：批量删除是数据销毁操作，属于 transactional 域，应绑定 action.destructive
• 后果：AI生成代码时，按钮样式为蓝色实心（action.primary 的标准映射），缺少二次确认，用户误触后批量删除数据
• 根因：开发团队对语义域的理解错误，将"删除"理解为"导航到删除页面"而非"执行删除操作"
• 修复：设计系统负责人在核对时发现域声明错误，纠正为 transactional + action.destructive

这个案例说明：语义域的核对不能依赖开发团队的自觉，必须有设计系统负责人的主动评审，尤其是在新场景、新团队首次接入时。

📎 关键设计详情：《② 边界动作诊断：拒绝 ≠ 终止 权利差异未区分》阅读原文\
边界动作组件（如AI的"拒绝请求"与"终止会话"）在界面上都是"拒绝"表达，但用户的权利状态完全不同。这篇文章展示了语义域划分在边界动作场景中的关键作用，设计系统负责人需要确认"拒绝"与"终止"在语义域中的正确归属。

一直在工作吗：语义域的合规检查机制

设计系统负责人通过以下机制确认语义域声明持续合规：

机器在每次编译和每次生成时自动执行这些检查。设计系统负责人只在"机器发信号时"在场：当校验失败、当有团队申请新域、当跨层禁止被触发时。

约束显化规则，确认"不能做什么"的边界

角色消费场景：设计系统负责人为什么需要确认约束显化规则

约束显化是把"隐含的语义假设"变成"显式的机器规则"。设计系统负责人是组织中最理解"这些假设是否合理"的人，因为他们长期维护设计规范，知道哪些规则是"绝对不能突破的"，哪些规则是"建议遵守的"。

约束显化规则分为两类：

• 不可变边界（Immutable Boundaries）：违反即阻断，如"高危操作必须二次确认"
• 推荐约束（LLM Constraints）：违反即警告，如"文案长度不超过50字"

设计系统负责人确认约束显化规则，是判断"这条约束是否属于不可变边界、是否可执行、是否与组织现有规范冲突"。

📎 关键设计详情：《③ 约束显化：把隐含的语义假设变成显式规则》阅读原文\
约束显化的核心判断：设计规范必须从"人读的文档"变成"机器可消费的代码"。传统规范面向人阅读（PDF、语雀、Figma 注释），机器无法消费；规范写成代码格式后，获得四项能力：可被机器读取、可被自动校验、可被版本管理、可被多格式分发。设计系统负责人确认的，正是这些显式规则是否忠实于原有设计意图。

📎 关键设计详情：《合 ③ 约束显化：把隐含的语义假设变成显式规则》阅读原文\
合集版本系统阐述了约束显化的完整方法论：从自然语言规范到YAML契约的翻译过程，以及为什么"约束显化"是AI时代设计规范的唯一可行路径。

翻译能力：把"这个绝对不能做"变成"机器能拦截的禁令"

设计系统负责人在评审设计稿时，经常说："这个绝对不能这样。"过去，这句话只能停留在评审会上。现在，它可以被翻译成机器可执行的禁令：

评审前（口头禁令） ：

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

评审后（机器拦截规则） ：

immutable_boundaries:
  - boundary_type: "safety"
    rule: "action.destructive 禁止映射为 action.primary 或 action.constructive 的视觉样式"
    violation_action: "block"
  - boundary_type: "safety"
    rule: "action.destructive 必须伴随 confirmation_dialog 组件"
    violation_action: "block"

设计系统负责人的确认动作，是判断：

• 这条约束是否属于"绝对不能"（不可变边界）还是"最好不要"（推荐约束）？
• 这条约束是否可执行（机器能判断是否违反）？
• 这条约束是否与现有规范冲突（如与某团队的特殊需求矛盾）？

📎 关键设计详情：《③ 语义断层地图的三栏断裂：意图、设计稿与工程实现的系统性衰减》阅读原文\
设计意图、设计稿表现、工程实现三者之间存在系统性衰减。约束显化的价值，正是在这三栏之间建立"机器可校验"的桥梁，防止语义在传递过程中丢失。设计系统负责人确认的约束规则，就是这座桥梁的承重结构。

关键决策点 3：机器发信号时

约束显化规则一旦进入系统，机器会在每次编译和每次生成时自动执行。设计系统负责人不需要逐条检查，机器在自动运行。人只在"机器发信号时"在场：

信号 1：拦截事件上报

"某团队的契约提交触发了跨层禁止：试图将 status.critical 用于 observational 域。"\
设计系统负责人判断：这是团队理解错误（纠正域声明），还是场景特殊需要申请豁免？

信号 2：对抗测试用例失败

"用例'诱导AI生成无二次确认的删除按钮'未通过拦截。"\
设计系统负责人判断：是约束定义有漏洞（补充约束），还是AI模型更新导致绕过（调整Prompt前缀）？

信号 3：团队扩展申请

"支付团队申请在 action.destructive 上增加'二次人脸验证'约束。"\
设计系统负责人判断：这是团队级合理扩展（批准），还是应升级为组织级基线（提交规范评审组）？

真的发生过吗：约束显化不足的典型案例

某AI生成工具在生成"清空回收站"界面时，按钮文案为"确认"，样式为蓝色实心，无二次确认弹窗。

问题诊断：

• 约束层：action.destructive 的不可变边界中，只规定了"必须包含 confirmation_dialog"，但未规定"按钮文案不能为'确认'"
• 后果：AI在技术上满足了"有 confirmation_dialog"的要求（实际上没有），但语义上完全偏离了"危险操作"的警示意图
• 根因：约束定义过于笼统，未覆盖"文案语义权重"维度
• 修复：设计系统负责人补充约束，"action.destructive 的按钮文案必须包含'删除''清空''永久'等不可逆语义词汇，禁止仅使用'确认''确定'等中性词汇"

这个案例说明：约束显化不是"写几条规则就够了"，而是在实际使用中不断发现边界情况、补充约束条款的持续过程。

一直在工作吗：约束显化的三层验证

设计系统负责人通过以下机制确认约束显化规则持续有效：

机器在每次契约变更后自动执行三层验证。设计系统负责人只在验证失败时介入，其余时间，机器在跑。

📎 关键设计详情：《③ 编译前置校验：显式规则的5项机器安检》阅读原文\
编译前置校验是约束显化的第一道机器防线：覆盖层存在性、绑定存在性、场景一致性、字段完整性、结构合法性。这5项安检在契约入库前自动执行，任一不过即阻断。设计系统负责人通过这5项安检的通过率，确认约束显化规则的合规性。

渐进式生长：从现有规范中延伸语义评审能力

设计系统负责人参与把"人懂的直觉"翻译成"机器读的规则"，不需要等待语义字典全量定义、不需要等待漂移模式全部归档、也不需要等待编译管线完全稳定。最小可行起点，是从组织内已经存在的Design Token和设计规范中，生长出第一条语义评审能力。

第一步：选一个已经存在的 Design Token 追问它的语义

组织内已经存在的设计规范中，必然有类似"错误色 = #EF4444"这样的定义。最小可行的第一个动作，不是新建一套语义令牌，而是对现有 Design Token 追问三个问题：

最小可行动作：选1个最常用的Design Token（如错误色），补充1条语义定义。不需要覆盖所有场景，只需要让这条定义可被机器引用。

验收标准：这条语义定义能被写入YAML契约的 semantic_tokens 节点，且通过编译前置校验的"绑定存在性"检查。

第二步：在 1 个组件上核对语义域声明

不需要一次性为所有组件定义语义域。最小可行的第二个动作，是在组织内最高频的1个组件上（如 Alert 或 Button），核对它在不同场景下的语义身份：

最小可行动作：选1个组件的2个典型场景，确认它们的语义域声明是否正确。不需要覆盖所有场景，只需要建立"核对"的工作习惯。

验收标准：这2个场景的语义域声明能被写入契约的 semantic_domain 字段，且不触发跨层禁止。

第三步：确认 1 条不可变边界

组织内的设计规范中，必然有"绝对不能"的口头规则（如"删除操作必须有二次确认"）。最小可行的第三个动作，是把这条口头规则翻译成机器可执行的不可变边界：

评审前（口头规则） ：

"删除按钮绝对不能没有二次确认。"

评审后（机器拦截规则） ：

immutable_boundaries:
  - boundary_type: "safety"
    rule: "action.destructive 必须伴随 confirmation_dialog 组件"
    violation_action: "block"

最小可行动作：选1条团队内共识度最高的"绝对不能"规则，翻译成1条不可变边界。不需要覆盖所有边界，只需要证明"口头规则可以被机器执行"。

验收标准：这条边界能被编译为CI规则，并在1次模拟提交中成功拦截违规代码。

试点范围与可量化的小收益

关键原则：不是"等全套基础设施建好再开始评审"，而是"从现有规范中生长出第一条语义评审能力，在评审中完善基础设施"。

组织生长路径：从兼职评审到专职维护

设计系统负责人参与语义评审，不需要组织立即招聘专人。生长路径如下：

兼任声明：阶段0和阶段1中，语义评审可以作为设计系统负责人的兼职职责，不需要专人专岗。阶段2和阶段3的投入增加，与组织内语义规则的数量和团队数成正比，不是强制增长，而是自然生长。

结语：承上篇的终点，是启下篇的起点

本文展开了设计系统负责人在主题行语义令牌定义、语义域划分、约束显化规则中的评审职责：

• 在语义令牌定义中，确认语义边界清晰、与Design Token兼容、约束可执行
• 在语义域划分中，核对组件的语义身份正确、域绑定不触发跨层禁止
• 在约束显化规则中，判断不可变边界的合理性、可执行性、与现有规范的兼容性

这三个动作的共同特征：设计系统负责人不是"人肉审查员"，而是"规则定义者" 。翻译发生在规则被写下的那一刻，把"人懂的直觉"翻译成"机器读的规则"。 一旦规则进入系统，机器就在自动执行：自动归档、自动校验、自动编译、自动拦截、自动追踪、自动标记。

设计系统负责人在整条链路上的 "在场" ，被压缩到三个关键决策点：

1. 机器不确定时——新令牌、新域、新场景需要语义判断
2. 机器没见过时——新模式、新团队、新业务需要标准定义
3. 机器发信号时——校验失败、拦截事件、扩展申请需要人工裁决

其余时间，机器在跑。

本文的终点，是规则被定义、被评审、被确认。下一篇的起点，是这些规则进入YAML契约、进入编译管线、进入四种消费格式，设计系统负责人如何确认契约语义的准确性、如何验证编译产物的语义一致性。从"定义规则"到"确认规则被正确翻译"的自然过渡。