设计系统负责人的编译确认：YAML契约评审拿1条真实契约做语义保真检查

前文《从"规则被写下"到"规则被正确翻译"》讲了设计系统负责人如何评审YAML契约的语义准确性，以及如何确认编译产物（Prompt前缀 / JSON Schema / Checklist / CI规则）的语义一致性。那些内容偏"机制"，回答的是"为什么需要这样做"。

这篇我们换个角度，把镜头拉近，只看一件事：设计系统负责人最少做多少，就能开始建立"语义保真检查"的评审能力？

答案是：从语义翻译设计师已提交的契约里挑1条，核对两个字段。仅此而已。

一、为什么要从1条契约开始

很多设计系统负责人看到"YAML契约评审"，第一反应是：

"这是不是意味着我要把7个冻结字段全部学一遍，每条提交的契约都逐字逐行看？"

不是的。

YAML契约由语义翻译设计师编写，包含7个冻结字段。每个字段谁该操心，分工是这样的：

因为YAML语法是否正确、字段是否完整、版本号格式是否合规、引用的Token是否存在——这些全部由机器在每次契约提交时自动校验：

机器自动执行的4项结构检查
├── 编译前置校验   ：字段完整性、版本号格式、引用存在性
├── 结构校验规则   ：YAML语法、缩进、类型
├── 影响面分析     ：自动列出受变更影响的产品和团队
└── 历史版本Diff   ：展示本次变更与上一版本的差异

设计系统负责人要检查的，是机器检查不了的那件事：语义保真——契约里写的，是不是评审结论里说的。

而这件事，在7个字段里真正需要人做语义判断的，核心只有两个：

• semantic_tokens：语义编码是否忠实于评审结论
• immutable_boundaries（及其中的 llm_constraints）：红线是否完整、是否被降格、是否可执行

其余字段，机器已经替你校验过了。

为什么只从1条契约开始？因为组织对抗往往来自"每条都要我看，根本看不完"的疲惫感。但如果告诉你："不需要看所有契约，只需要挑1条你参与过评审结论的，核对两个字段"，门槛就低了很多。

二、核对两个字段：从"语法正确"到"语义保真"

打开你们的规则仓库，找到最近提交的、且你参与过评审结论的那条契约。我们以错误状态的致命级别为例。

核对字段1：semantic_tokens——视觉映射是否忠实于评审结论

评审结论里说的是：

致命级别 = 红色脉冲 + 八边形图标
         + 刷新/导出历史两个行动按钮（刷新优先）
         + 文案必须说明对话上下文可能已丢失

契约里写的是：

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:
        - "必须明确告知用户对话上下文可能已丢失"
        - "禁止仅显示'出错了'等模糊文案"

你的核对动作：

你的动作：逐行填写上表的"判定"列。任何一格对不上，就是语义失真——不是语法错误，是意思被改掉了。

核对字段2：immutable_boundaries——红线是否完整、是否可执行

评审结论里的"绝对不能"是这样的：

【绝对不能】
- 绝对不能在文案中建议用户"等待"或"稍后重试"
- 绝对不能省略恢复路径（至少提供一个行动按钮）

逐条对照契约中的约束条目：

三条判断标准：

红线核对三问
1. 完整吗？——评审结论里每一条"绝对不能"，契约里都有对应吗？
2. 降格吗？——"绝对不能"被写成了"建议""推荐""尽量避免"吗？
3. 可执行吗？——这条约束能被编译成机器校验规则，还是一句只有人懂的模糊描述？

你的动作：对照评审结论逐条打勾。任何一条缺失、降格或对不上，就在评审记录里标注"语义失真"，退回给语义翻译设计师。

三、把核对结果写成"可退回"的格式

核对完两个字段后，你手里是一份"核对记录"。下一步是把它写成语义翻译设计师能直接修改的反馈——不是提模糊的"感觉不对"，而是指出"哪一行、哪个词、与评审结论的哪一句不一致"。

先看一个真实的失真片段。这是语义翻译设计师提交的"删除账户"契约：

# 失真示例：action.destructive 片段
user_action:
  - label: "确认删除"
    action: "confirm_delete"
    priority: 1
  - label: "取消"
    action: "cancel"
    priority: 2
# 问题：评审结论要求"必须输入账户名二次确认"，
# 但契约里只有一个普通确认按钮，缺少 confirmation_step 字段

你写的结构化反馈应该是这样：

【契约】action.destructive 相关片段

【对照评审结论】"删除账户必须输入账户名二次确认"

【失真点】契约中 user_action 仅提供"确认删除"按钮，
         缺少 confirmation_step 字段

【根因】将"二次确认"理解为"弹窗确认"，
       而非"输入账户名确认"

【修复要求】补充 confirmation_step: "type_account_name"

【影响】AI生成代码时将只生成普通确认弹窗，缺少输入验证环节
       ——用户误触风险未消除

你的动作：把这份反馈贴在契约的评审记录里。不需要你改YAML，只需要指出失真点，语义翻译设计师会完成修改。

四、真的发生过吗：一个你可以在自己组织里验证的案例

你们组织里一定有这样的情况：同一条"绝对不能"，在评审结论里是一种说法，在契约里被写成了另一种说法。

你可以做的验证动作：

验证三步
1. 找到1条你参与过评审结论的契约
   （优先找涉及"删除""支付""发布"这类高风险动作的）
2. 打开契约，找到 immutable_boundaries / llm_constraints 段落
3. 对照当时的评审结论，逐条核对：
   结论里的每一条"绝对不能"，契约里是否都有对应？

大概率你会发现：

这就是语义失真：规则被写下来了，但写下来的规则，不是原来那条规则。

你的动作：把这条契约和评审结论并排放在一起，在评审会上问一句："我们确认过的'二次确认'，怎么到契约里变成一个按钮了？"——这就是契约评审的起点。

五、一直在工作吗：怎么让这条核对不被遗忘

核对完1条契约后，最怕的是：这次核对了，下次提交的契约又回到"只有机器校验通过、没人看语义"的状态。

最小可行的保鲜机制：

流程钩子（最小改动）
在契约提交流程里加一个勾选框：

[ ] 语义保真检查：已完成 / 不适用

你的动作：先在契约提交流程里加上这个勾选框。只需要在流程上留一个钩子，机器的结构校验就再也替代不了这一步。

六、生长路径：从1条契约到语义保真守门人

核对1条契约只是起点。设计系统负责人的契约评审能力，会沿着这条路径自然生长：

关键原则：不是"等所有契约逐条看完再开始"，而是"从1条契约开始，在核对中建立标准，在标准中完善评审流程"。

结语

《从"规则被写下"到"规则被正确翻译"》篇讲了设计系统负责人在编译确认链路中的确认职责——从YAML契约的语义保真评审，到四种编译产物的一致性确认，再到评审→确认→验证的完整闭环。那些是"地图"，让你知道这片领域长什么样。

本篇讲的是"第一步"：不需要看懂所有字段，只需要打开1条契约，核对两个字段——语义编码是否忠实于评审结论、红线是否完整且可执行。

核对本身就是确认。当你开始核对，你就已经从"规则被写下"生长到了"规则被正确翻译"。

希望能帮到你。如果你在核对过程中发现了有趣的失真案例（比如发现某条"绝对不能"在契约里变成了"建议不要"），欢迎在评论区分享——这些真实的失真，正是语义治理最好的证据。

下一篇会针对"编译产物确认"展开，聊聊设计系统负责人怎么抽样验证：同一条契约编译出的Prompt前缀、JSON Schema、Checklist、CI规则，是否说的是同一件事。

1200/.png.png