设计系统负责人如何低成本启动契约评审？本文提出只需从已提交的YAML契约中挑1条，核对semantic_tokens和immutable_boundaries两个字段，就能建立语义保真检查能力。通过真实失真案例和可退回的反馈格式，手把手教你迈出规则治理的第一步。

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

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

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

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

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

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

不是的。

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

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

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

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

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

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

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

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

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

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

评审结论里说的是：

契约里写的是：

你的核对动作：

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

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

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

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

三条判断标准：

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

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

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

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

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

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

四、一个你可以在自己组织里验证的案例

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

你可以做的验证动作：

大概率你会发现：

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

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

五、怎么让这条核对不被遗忘

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

最小可行的保鲜机制：

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

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

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

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

结语

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

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

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

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

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