设计系统负责人的编译确认：从"规则被写下"到"规则被正确翻译"

开篇：从"定义规则"到"确认规则被正确翻译"

承上篇《从管"长什么样"到管"意味着什么"》展开了设计系统负责人在语义令牌定义，语义域划分，约束显化规则中的评审职责：确认语义令牌边界清晰、核对语义域声明正确、判断约束显化规则合理。这些动作的共同结果，是一份被确认过的语义定义——它回答了"这个场景下必须表达什么语义、不能突破什么边界"。

但这份语义定义还坐在设计系统负责人的评审结论里，没有进入机器可执行的形态。本篇要展开的，是这份语义定义如何被翻译成YAML契约，以及YAML契约如何被编译成四种消费格式——设计系统负责人在其中承担"确认翻译准确性"的职责。

这不是"替语义翻译设计师写契约"，也不是"替工程团队做编译"——而是作为"规则定义者"，在机器无法自行判断的节点上，确认"人定义的语义"被"机器正确理解"。

YAML 契约评审（主题行④）——确认"人定义的语义"被"正确编码"

角色消费场景：设计系统负责人为什么必须评审 YAML 契约

YAML契约是语义定义进入机器执行链路的第一个形态。它由语义翻译设计师编写，引用语义字典中的已注册项，包含7个冻结字段：

设计系统负责人的评审，不是检查YAML语法是否正确（机器做），而是检查"语义编码是否忠实于承上篇确认过的语义定义"。

翻译能力：从"评审结论"到"机器可执行的契约"

前文《从管"长什么样"到管"意味着什么"》中，设计系统负责人对某个漂移模式的评审结论可能是：

"ERR-001（后果差异未分级）的致命级别，必须使用红色脉冲、八边形图标、必须提供刷新和导出历史两个行动按钮，文案必须说明对话上下文可能已丢失。"

这条评审结论需要被翻译成YAML契约中的 semantic_tokens.error_severity.fatal 节点。设计系统负责人的评审动作，是确认这个翻译没有失真：

评审前（评审结论）：

致命级别 = 红色脉冲 + 八边形 + 刷新/导出按钮 + "上下文可能已丢失"文案

评审后（YAML 契约片段）：

semantic_tokens:
  error_severity:
    fatal:
      description: "系统级故障，对话上下文可能丢失"
      visual_mapping:
        color_token: "status.critical"
        motion_token: "pulse.red.urgent"
        icon_token: "alert.octagon"
      user_action:
        - label: "刷新页面"
          action: "refresh"
          priority: 1
        - label: "导出历史"
          action: "export_history"
          priority: 2
      llm_constraints:
        - "必须明确告知用户对话上下文可能已丢失"
        - "禁止仅显示'出错了'等模糊文案"

设计系统负责人核对的关键点：

• color_token: "status.critical" 是否正确映射到承上篇确认的致命状态？
• motion_token: "pulse.red.urgent" 是否与"红色脉冲"的评审结论一致？
• user_action 是否包含"刷新"和"导出历史"两个行动？优先级是否正确？
• llm_constraints 是否覆盖了"文案必须说明上下文可能已丢失"的要求？

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

YAML契约评审中，机器"不确定"的情况通常出现在语义边界模糊的场景。

场景示例：语义翻译设计师在编写"限流提示"（Retryable）的契约时，对 user_action 的设计存在两种方案：

• 方案A：只提供"等待倒计时"一个行动，强制用户等待
• 方案B：提供"等待倒计时"和"升级套餐"两个行动，给用户选择

机器无法判断哪个方案更符合用户体验——这需要设计系统负责人基于对业务目标的理解做出判断。如果组织的策略是"优先引导用户升级而非等待"，则选择方案B；如果策略是"限制高并发时段的资源消耗"，则选择方案A。

设计系统负责人在此节点的评审结论，直接决定了契约中 user_action 的列表内容和优先级排序。

真的发生过吗：契约语义失真的典型案例

某语义翻译设计师在编写"删除账户"契约时，将 action.destructive 的 user_action 设计为：

user_action:
  - label: "确认删除"
    action: "confirm_delete"
    priority: 1
  - label: "取消"
    action: "cancel"
    priority: 2

问题诊断：

• 语义层：action.destructive 的评审结论要求"必须输入账户名二次确认"，但契约中只提供了"确认删除"按钮，没有输入验证
• 根因：语义翻译设计师将"二次确认"理解为"弹窗确认"，而非"输入账户名确认"
• 后果：AI生成代码时，只生成了普通确认弹窗，缺少输入验证环节——用户误触风险未消除
• 修复：设计系统负责人在评审时发现语义失真，要求补充 confirmation_step: "type_account_name"

这个案例说明：YAML契约的评审不是"格式检查"，而是"语义保真检查"——确认人定义的语义意图，在编码过程中没有丢失或简化。

一直在工作吗：契约评审的自动化辅助

设计系统负责人的评审工作，由以下自动化机制辅助，减少重复劳动：

机器在每次契约提交时自动执行这些检查。设计系统负责人只在"机器不确定时"介入——即当自动化检查通过，但语义编码存在模糊或多义时。

编译产物确认（主题行⑤）——确认"同一语义"被"四种格式正确表达"

角色消费场景：设计系统负责人为什么需要确认编译产物

编译管线将一份YAML契约翻译成四种消费格式：

设计系统负责人需要确认：这四种格式是否表达了同一语义？是否存在"Prompt 前缀说必须用红色，但JSON Schema允许蓝色"的语义分叉？

这不是检查格式是否正确（机器做），而是检查"四种方言是否说的是同一件事"（需要语义判断）。

翻译能力：确认"同一语义"的四种表达不失真

设计系统负责人在承上篇中确认的语义定义，经过YAML契约编码后，被编译管线翻译成四种格式。设计系统负责人的确认动作，是抽样验证这四种格式的语义一致性：

源语义（前文《从管"长什么样"到管"意味着什么"》评审结论）：

"致命错误必须使用红色脉冲、八边形图标，必须提供刷新和导出历史按钮，文案必须说明上下文可能已丢失。"

四种格式的抽样验证：

设计系统负责人不需要逐条检查所有字段——机器在编译时已经做了结构校验。人的确认动作是语义抽样：随机抽取几个关键语义点，验证四种格式是否一致表达。

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

当组织引入新的消费格式（如新增"Figma 插件配置"格式），或者现有格式的版本升级（如JSON Schema从 Draft-07 升级到 Draft-2020-12），机器"没见过"这种新映射关系，需要设计系统负责人在场确认。

场景示例：编译管线新增第五种格式——"设计系统文档自动生成"（将契约翻译成设计规范文档的Markdown片段）。

设计系统负责人需要判断：

• 这种新格式是否必要？（是否有团队消费？）
• 新格式的语义映射规则是否合理？（是否忠实于源契约？）
• 新格式是否与现有四种格式保持语义一致？

机器无法做这个判断，因为它不理解"设计规范文档的可读性"和"语义保真"之间的权衡。

真的发生过吗：编译产物语义分叉的典型案例

某次契约变更后，设计系统负责人在抽样验证时发现：

• Prompt前缀中：fatal 级别的文案约束为"必须包含'对话上下文可能已丢失'"
• JSON Schema中：user_message 字段的 minLength 为10，但未强制包含特定关键词
• Checklist中：包含"文案是否说明上下文可能已丢失？"检查项
• CI规则中：只检查 severity 字段是否存在，不检查文案内容

问题诊断：

• 语义分叉：Prompt前缀和Checklist要求文案包含特定信息，但JSON Schema和CI规则只检查字段存在性——四种格式对"文案要求"的严格程度不一致
• 根因：编译管线的映射规则中，JSON Schema和CI规则对 llm_constraints 的翻译过于简化，只保留了结构约束，丢失了语义约束
• 后果：前端工程师的Props校验通过，但AI生成的文案可能遗漏关键信息；CI拦截不到文案语义错误
• 修复：设计系统负责人要求调整编译映射规则——JSON Schema增加 pattern 正则匹配（强制包含"上下文"关键词），CI规则增加文案内容检查

这个案例说明：编译产物的确认不是"格式检查"，而是"语义一致性检查"——确认四种格式对同一语义点的表达强度一致。

一直在工作吗：编译产物的三层验证机制

设计系统负责人通过以下机制确认编译产物持续语义一致：

机器在每次编译后自动执行三层验证。设计系统负责人只在"机器发信号时"介入——即当对抗测试用例失败、当一致性验证发现分叉、当新格式引入时。

从评审到确认——设计系统负责人在整条链路上的位置

承上启下的完整闭环

设计系统负责人在 Schema-As-Code把设计规范写成代码格式 框架中的完整工作流，可以概括为一条"评审→确认→验证"的闭环：

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   评审（Review）        确认（Confirm）        验证（Verify）   │
│                                                                 │
│   ① 语义令牌定义  ──→  ④ YAML 契约编码  ──→  ⑤ 编译产物      │
│      （边界清晰吗？）      （编码保真吗？）      （翻译一致吗？） │
│                                                                 │
│   ② 语义域划分  ──→    （语义翻译设计师编写）  （编译管线翻译） │
│      （身份正确吗？）                                           │
│                                                                 │
│   ③ 约束显化规则 ──→                                          │
│      （可执行吗？）                                             │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

评审：发生在规则被定义之前。设计系统负责人确认"这个语义边界是否清晰、这个域声明是否正确、这条约束是否可执行"。评审的输出是评审结论——一份关于"这个场景下必须表达什么语义"的确定性判断。

确认：发生在规则被编码之后。设计系统负责人确认"YAML 契约是否忠实于评审结论、四种编译产物是否对同一语义一致表达"。确认的输出是确认标记——一个关于"这条规则可以被机器正确理解"的放行信号。

验证：发生在规则被消费之后。设计系统负责人通过对抗测试用例、消费追踪数据、语义分叉检测，确认"规则在实际使用中是否被遵守、是否发现了未覆盖的边界情况"。验证的输出是反馈数据——驱动下一轮评审的输入。

三个关键决策点的完整映射

设计系统负责人在整条链路上的"在场"，被压缩到机器无法自行判断的三个节点：

不是流水线，是反复出现的确认节拍

这条闭环不是"评审做完了就做确认，确认做完了就做验证"的单向流水线。在实际工作中，设计系统负责人可能在同一天内同时处于三个阶段：

• 上午：评审一条新提交的语义令牌扩展申请（评审阶段）
• 下午：确认一条已编码契约的语义保真性（确认阶段）
• 傍晚：查看消费追踪面板，发现某条规则的对抗测试用例通过率下降（验证阶段 → 触发新一轮评审）

验证发现的问题，会回流到评审阶段，驱动评审结论的更新。 例如：消费追踪显示某条"不可变边界"被频繁触发人工升级，说明边界定义可能过严——设计系统负责人需要回到评审阶段，重新判断这条边界是否属于"绝对不能"，还是应降级为"建议遵守"。

生长原则：从兼职评审到主导验证

设计系统负责人参与这条闭环，不需要组织立即建立完整的验证体系。生长路径与组织的规则成熟度同步：

兼任声明：兼职评审阶段和定期确认阶段中，这条闭环可以作为设计系统负责人的兼职职责，与现有的设计规范维护工作合并进行。主导验证阶段和质量守门人阶段的投入增加，与组织内语义规则的数量和消费团队数成正比——不是强制增长，而是自然生长。

核心设计原则：人在关键决策点定义规则，机器在执行链路自动运行

这条闭环的核心特征：

• 人在关键决策点定义规则：设计系统负责人在评审阶段确认语义标准，在确认阶段验证编码保真，在验证阶段判断是否需要回流修正
• 机器在执行链路自动运行：编译、校验、拦截、追踪、标记全部由机器自动完成
• 翻译发生在规则定义时：不是每次执行时重新翻译，而是规则被写下时就完成了从"人懂"到"机器读"的翻译
• 验证驱动持续优化：消费数据不是监控，而是让"规则该不该改、该怎么改"从主观猜测变成数据驱动

设计系统负责人的价值，不是"逐条检查所有规则"，而是确保"源头的语义定义"在传递到下游的过程中不失真。这是语义翻译能力在组织中的第一个关键锚点。

结语：从"规则被写下"到"规则被正确翻译"的终点，是验证的起点

我在本文中展开了设计系统负责人在编译产物确认和从评审到确认环节的确认职责：

• 在YAML契约评审中，确认语义编码忠实于承上篇的评审结论
• 在编译产物确认中，验证四种消费格式对同一语义的一致表达

这两个动作的共同特征：设计系统负责人不是"格式检查员"，而是"语义保真确认者"。翻译发生在规则被写下的那一刻——前文《从管"长什么样"到管"意味着什么"》把"人懂的直觉"翻译成"评审结论"，本文把"评审结论"翻译成"机器可执行的契约和产物"。一旦进入编译管线，机器就在自动执行：自动编译、自动校验、自动分发、自动拦截、自动追踪。

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

1. 机器不确定时——契约编码存在多义性，需要语义判断
2. 机器没见过时——新消费格式引入，需要映射规则确认
3. 机器发信号时——对抗测试失败、语义分叉、版本冲突需要裁决

其余时间，机器在跑。

从"规则被写下"到"规则被正确翻译"的终点，是规则被正确编码、被正确编译、被正确分发。但规则是否被正确消费、是否正确拦截了语义漂移、是否为组织节省了返工成本——这些不是设计系统负责人独自能回答的问题。它们需要DesignOps 的运营追踪、前端工程师的接入反馈、管理层的资源决策。我会在角色工作流DesignOps篇和管理层篇展开。

设计系统负责人的工作，是确保"源头的语义定义"在传递到下游的过程中不失真。这是语义翻译能力在组织中的第一个关键锚点。

1920.png.png