我在前文《从"规则被写下"到"规则被正确翻译"》讲了设计系统负责人如何评审YAML契约的语义准确性，以及如何确认编译产物（Prompt前缀 / JSON Schema / Checklist / CI规则）的语义一致性。那些内容偏"机制"，回答的是"为什么需要这样做"。
这篇我们换个角度，把镜头拉近，只看一件事：设计系统负责人最少做多少，就能开始建立"编译产物确认"的能力？
答案是：从你确认过的契约里抽1个语义点，在四种格式里各找1处表达，核对它们说的是否是同一件事。仅此而已。
一、为什么要从1个语义点开始
很多设计系统负责人看到"编译产物确认"，第一反应是：
"四种格式、四套语法，Prompt前缀是文本、JSON Schema是类型定义、Checklist是走查项、CI规则是拦截脚本——是不是意味着我四种都要学会、逐条都要看懂？"
不是的。
编译管线把一份YAML契约翻译成四种消费格式，每种格式有自己的消费者和场景：
| 格式 | 消费者 | 消费场景 | 机器校验什么 | 人判断什么 |
|---|---|---|---|---|
| Prompt前缀 | AI工程师 | 注入AI生成工具的system message | 文本是否生成成功 | 约束强度是否与源契约一致 |
| JSON Schema | 前端工程师 | 组件Props的类型校验 | Schema是否合法（每次编译自动验证） | 枚举/正则是否保留了语义约束 |
| Checklist | 设计师 / DesignOps | 设计稿完成后的语义走查 | 检查项是否生成 | 检查项是否覆盖关键语义点 |
| CI规则 | 前端工程师 | 代码提交时的自动化拦截 | 规则是否可执行 | 拦截强度是否与文案要求一致 |
四种格式是否正确、能不能编译、Schema合不合法——这些全部由机器在每次编译时自动校验：结构验证、语义验证（对抗测试用例）、一致性验证（交叉比对脚本），机器一直在跑。
设计系统负责人要确认的，是机器确认不了的那件事：语义一致性——四种格式是不是在表达同一个语义？有没有"Prompt前缀说必须用红色，但JSON Schema允许蓝色"的分叉？
而这件事，不需要你逐条检查所有字段——机器已经做了结构校验。人的确认动作是语义抽样：随机抽取几个关键语义点，验证四种格式是否一致表达。
为什么只从1个语义点开始？因为四种格式逐条看，等于把编译管线的工作重做一遍。但如果告诉你："不需要看懂四种语法，只需要抽1个语义点，在四种产物里各找1处表达"，门槛就低了很多。
二、四格式抽样：对1个语义点各找1处表达
打开编译产物的发布目录，找到你确认过的那条契约的四种产物。我们以"致命错误"这个语义点为例——它是评审结论里最重的一条，分叉代价最高。
源语义（你评审确认过的定义）：
致命错误 = 红色脉冲 + 八边形图标
+ 必须提供刷新/导出历史按钮
+ 文案必须说明对话上下文可能已丢失
抽样1：Prompt前缀——文案约束在不在
在Prompt前缀文本里，搜索"致命"或"fatal"相关段落，找到文案约束：
- 是否包含"必须包含'对话上下文可能已丢失'"或等效表述？
- 约束是强制的（"必须"），还是弱化的（"建议""尽量"）？
抽样2：JSON Schema——枚举范围收窄了没
在JSON Schema里，找到color_token字段：
- 枚举值是否只包含status.critical？
- 如果文案有约束，对应字段是pattern正则匹配（强制包含关键词），还是只查了minLength（只要够长就行）？
抽样3：Checklist——走查项覆盖了没
在Checklist里，找到错误状态相关检查项：
- 是否有"错误状态是否按级别区分颜色？"这类检查项？
- 是否有"文案是否说明上下文可能已丢失？"这类检查项？
抽样4：CI规则——拦截脚本拦了什么
在CI规则里，找到severity相关拦截规则：
- 是否有severity-color-match拦截规则（颜色与级别不匹配时拦截）？
- 是否只检查severity字段存在，而不检查文案内容？
把四处抽样结果填进这张表：
| 语义点要求 | Prompt前缀 | JSON Schema | Checklist | CI规则 | 判定 |
|---|---|---|---|---|---|
| 必须用红色 | ✅ 文本声明 | ✅ 枚举仅status.critical | ✅ 有颜色走查项 | ✅ 有拦截规则 | ✅ 一致 |
| 文案必须说明上下文丢失 | ✅ 强制要求 | ⚠️ 只查minLength | ✅ 有检查项 | ⚠️ 只查severity存在 | ⚠️ 分叉 |
你的动作：逐行填写上表的"判定"列。任何一格的强度弱于源语义，就是语义分叉——不是格式错误，是同一件事被四种方言说成了四种严格程度。
三、把抽样结果写成"可修复"的格式
抽样完四个格式后，你手里是一份"分叉记录"。下一步是把它写成编译管线的维护者能直接修改的反馈——不是提模糊的"感觉不一致"，而是指出"哪个格式、哪个字段、丢失了什么约束、要求补什么"。
先看一个真实的分叉片段。某次契约变更后，对"文案必须说明上下文可能已丢失"这个语义点，四种产物的表达是：
| 格式 | 实际表达 | 问题 |
|---|---|---|
| Prompt前缀 | "文案必须包含'对话上下文可能已丢失'" | 严格 ✅ |
| Checklist | 检查项："文案是否说明上下文可能已丢失？" | 严格 ✅ |
| JSON Schema | user_message字段minLength为10，无关键词要求 | 语义约束丢失 ⚠️ |
| CI规则 | 只检查severity字段存在，不检查文案内容 | 语义约束丢失 ⚠️ |
你写的结构化反馈应该是这样：
【语义点】"文案必须说明对话上下文可能已丢失"
【分叉点1】JSON Schema中user_message仅约束minLength=10
未强制包含"上下文"关键词
【根因】编译映射规则对llm_constraints的翻译过于简化，
只保留了结构约束，丢失了语义约束
【修复要求】增加pattern正则匹配，强制包含"上下文"关键词
【分叉点2】CI规则只检查severity字段存在
【修复要求】增加文案内容检查项
【影响】前端Props校验通过，但AI生成的文案可能遗漏关键信息；
CI拦截不到文案语义错误——用户可能在不知情的情况下
丢失对话上下文
你的动作：把这份反馈贴在编译管线的变更记录里。不需要你改映射规则，只需要指出分叉点，管线的维护者会调整编译映射。
四、真的发生过吗：一个你可以在自己组织里验证的案例
你们组织里一定有这样的情况：同一条契约编译出的四种产物，对同一件事的严格程度不一样。
你可以做的验证动作：
验证三步
1. 找到1条你已确认过的契约，定位它的编译产物发布目录
2. 打开Prompt前缀、JSON Schema、Checklist、CI规则四份产物
3. 挑1个你最关心的语义点（比如某个"绝对不能"），
在四份产物里各找1处表达，并排对比
大概率你会发现：
| 你确认过的语义 | Prompt前缀 | JSON Schema | Checklist | CI规则 |
|---|---|---|---|---|
| 文案必须说明后果 | 强制要求 | 无文案约束 | 有检查项 | 只查字段存在 |
| 必须用指定颜色 | 文本声明 | 枚举约束 | 有走查项 | 无颜色校验 |
| 必须提供恢复按钮 | 强制要求 | 无对应字段 | 有检查项 | 无拦截规则 |
这就是语义分叉：规则被正确编译了，但编译出的四种方言，说的不是同一件事的同一个严格程度。
你的动作：把四份产物并排投在屏幕上，在评审会上问一句："这个语义点，四种格式说的严格程度一样吗？"——这就是编译产物确认的起点。
五、一直在工作吗：怎么让这条抽样不被遗忘
抽样完1个语义点后，最怕的是：这次抽样了，下次契约变更后，新的分叉又悄悄出现。
最小可行的保鲜机制：
| 检查项 | 频率 | 谁做 | 怎么做 |
|---|---|---|---|
| 每次Major版本变更后是否有语义抽样记录 | 每次Major版本 | 设计系统负责人 | 查看发布检查单，确认抽样已完成 |
| 交叉比对脚本报告的分叉告警是否有人复核 | 每次告警 | 设计系统负责人 | 机器发信号时介入，判断是真分叉还是误报 |
| 新消费格式引入时是否做过人在场确认 | 每次新格式 | 设计系统负责人 | 确认格式必要性、映射合理性、与现有格式的一致性 |
流程钩子（最小改动）
在Major版本发布检查单里加一行：
[ ] 语义抽样：已对1个语义点完成四格式核对
你的动作：先在发布检查单里加上这行勾选框。机器的三层验证（结构验证 / 语义验证 / 一致性验证）每次编译后都在自动跑，你只需要在"机器发信号时"和"版本要发布时"各出现一次。
六、生长路径：从1个语义点到分叉守门人
抽样1个语义点只是起点。设计系统负责人的编译确认能力，会沿着这条路径自然生长：
| 阶段 | 时间 | 动作 | 产出 |
|---|---|---|---|
| 阶段0：抽样1个语义点 | 现在 | 挑1个你确认过的语义点，四格式各找1处表达 | 1份抽样记录 |
| 阶段1：抽样3类语义点 | 1-2周后 | 把抽样方法复制到颜色类、文案类、行动类语义点 | 1份抽样记录集 |
| 阶段2：建立抽样清单 | 1个月后 | 把"语义点×四格式核对表"写成团队共享模板 | 1份《编译产物一致性抽样表》 |
| 阶段3：参与消费验证 | 2-3个月后 | 复核对抗测试用例通过率，确认Prompt前缀被AI正确理解 | 用例通过率复核记录 |
| 阶段4：主导新格式评审 | 6个月后 | 成为"机器没见过时"的固定确认者，评审新消费格式的映射规则 | 新格式确认记录 |
关键原则：不是"等四种格式都逐条看完再开始"，而是"从1个语义点开始，在抽样中建立标准，在标准中完善确认流程"。
结语
《从"规则被写下"到"规则被正确翻译"》讲了设计系统负责人在编译确认链路中的确认职责——从YAML契约的语义保真评审，到四种编译产物的一致性确认，再到评审→确认→验证的完整闭环。那些是"地图"，让你知道这片领域长什么样。
本篇讲的是"第二步"：不需要看懂四种语法、逐条检查所有字段，只需要抽1个语义点，在Prompt前缀、JSON Schema、Checklist、CI规则里各找1处表达，核对的严格程度是否一致。
抽样本身就是确认。当你开始抽样，你就已经从"规则被正确翻译"生长到了"规则被一致地翻译"。
希望能帮到你。如果你在抽样过程中发现了有趣的分叉案例（比如发现某个语义点在Checklist里很严格、在CI规则里完全没拦），欢迎在评论区分享——这些真实的分叉，正是语义治理最好的证据。
后续我会针对"消费验证"展开，聊聊设计系统负责人怎么通过对抗测试用例和消费追踪数据，确认规则在实际使用中是否被遵守、语义漂移是否被及时发现——那是《消费验证与运营追踪（DesignOps篇）》要讨论的内容。
1920.png.png
