在前序章节中，YAML 契约 已经证明了”形式化为代码的规矩在机器世界里长什么样“，同一份规则文件（YAML）能被编译为四种机器格式：放在 AI 指令前面的规则（Prompt 前缀）、给代码自动校验用的规则（JSON Schema）、给设计师走查用的清单（Checklist）、给自动化流水线用的拦截规则（CI 规则）。机器拿到这些格式后，能在AI生成界面之前自动拦住违规内容。

但这里有一个前提被忽略了：机器能执行规则，前提是规则本身写得对。如果规则的”原材料”设计规范，本身写的是”严重的用红色”这种机器读不懂的自然语言，那么再强大的编译管线也翻译不出精确的机器指令。

本文要回答的正是这个被忽略的前提：当设计意图需要被机器执行时，同样的意图，写成自然语言规范和写成规则文件字段，到底有什么实际差别？这个差别带来的能力是不是不可替代？

本文核心回答三个问题：

① 团队文档里写的”错误状态要分级”，机器能看懂吗？

② 同样的设计意图，写成自然语言规范和写成规则文件YAML字段，到底有什么实际差别？

③ 这个差别带来的能力是不是不可替代。

一、问题：同样的设计意图，写成自然语言规范和写成契约字段，到底有什么实际差别？

某AI对话产品的设计团队花了三个月整理了一份“界面规范文档”，语雀里写得清清楚楚：

“错误状态要分级显示。严重的用红色，一般的用黄色，轻微的用灰色。文案要写清楚，让用户知道该做什么。高危操作要二次确认。边界动作要礼貌，涉及敏感内容要说明原因，有时候需要终止对话。”

三个月后，AI生成的新界面出现 bug：

• 限流提示（“请求过于频繁”）被渲染成红色，用户看到红色就刷新页面，以为系统崩溃，其实只是等 30 秒自动恢复
• 删除账户按钮是蓝色实心“确认”，用户误触，账户没了
• AI 说“I can’t help with that”，用户不知道这是“换个话题还能聊”还是“被请出门了”

问题不是文档写错了。文档本身没问题。问题是：这段自然语言对机器来说仍然只是文字。

机器读”严重的用红色”，只知道”用红色”，不知道：

• 这个红色在什么场景下合法？（语义域（Semantic Domain）约束）
• 这个红色必须附带什么交互？（用户行动（User Action）约束）
• 这个红色不能出现在哪里？（不可变边界（Immutable Boundary）约束）

同样的设计意图“错误状态分四级”，写成自然语言规范和写成契约字段，差别不是“格式不同”，而是“机器能不能执行”。

二、为什么自然语言规范不够用

2.1 根因：自然语言规范的四项缺失

2.2 为什么团队会踩这个坑

自然语言规范的”清晰表达”在视觉上已经进步了，设计师看到”严重的用红色”会联想到”危险”。但这种进步停留在人脑理解层，没有到达机器执行层。

当AI生成工具接管界面生产时，问题暴露：AI不读设计规范文档。它只看到一段文字，这段文字对它来说和“随便发挥”没有本质区别。

2.3 跨角色反馈：同一根因，五种坑

三、关键设计：字段层差异 Before / After

3.1 设计思路

3.1.1 给规范“挂档案”，而不是只写段落

以前把”错误状态要分级”写在文档里，以为这样就”规范化了”。但对机器来说，这段文字和”随便发挥”没有任何区别，都是一段自然语言，机器只知道“渲染成文字”，不知道“这段文字代表什么约束”。

真正的规范化是给规范挂一份档案：这个约束在什么场景下生效？用户看到这个界面该做什么？什么情况下绝对不能这样写？

3.1.2 机器看到的不只是文字，还有“场景+行为+禁区”

传统的自然语言规范只有一段：”严重的用红色，文案要写清楚”

契约字段有三层：

1. 颜色背后的意思（Semantic Token）：这个红色代表什么（致命/警告/通知）
2. 场景归属（Semantic Domain）：这个红色在什么场景下合法
3. 不可突破的边界（Immutable Boundary）：这个红色绝对不能出现在哪里

3.1.3 从“走查时发现问题”变成“生成时直接拦住”

以前：AI生成红色限流提示 → 设计师走查发现不对 → 前端修改 → 再测试 → 再上线

现在：AI想生成红色限流提示 → 查字典发现限流 = 黄色时钟 → 若AI硬要用红色 → 机器直接阻断

3.1.4 同义词替换是语义漂移的最大元凶

大语言模型LLM没有“情绪权重”的概念，它只有“词频统计”。在它眼里，“Critical”和“严重”是等价的同义词，可以随便替换。

但对用户来说：”Critical” = 立刻处理，否则系统挂了；”严重” = 等会儿再看也行。

契约字段的做法：在字典里定义“这个场景下必须用 Critical，不能用严重”。大语言模型LLM若输出“严重”，机器直接拦截。

3.1.5 两层跃迁

3.2 案例 1：错误状态分级，自然语言 vs 契约字段

Before（自然语言规范）：

“错误状态要分级显示。严重的用红色，一般的用黄色，轻微的用灰色。文案要写清楚，让用户知道该做什么。高危操作要二次确认。”

问题拆解：

• “严重”是形容词，机器不知道什么算严重
• “写清楚”是主观标准，走查时各执一词
• “高危操作”没有明确定义，AI 不知道哪些操作算高危
• 没有“绝对不能碰”的红线

After（契约字段）：

【演示环境：错误状态分级 · 自然语言 vs 契约字段】

演示环境对比了两种表达方式。自然语言规范只有“严重红、一般黄”的模糊描述，机器只能当文字渲染，不懂场景合法性；契约字段则用七项档案（带版号的编号、明确定义、绑定的语义域、适用产品范围、四级令牌及各绑定的颜色行为、限流禁红的生成前拦截约束、违反即阻断的不可变边界）精确锁定意图。机器读取时按字段路径查询，是“执行规则”，而非“渲染文字”。

链路 1（字段完整性校验）：将自然语言”严重的用红色”识别为缺少 intent_id / version / semantic_domain / applicable_products / user_action / llm_constraints / immutable_boundaries 七个字段（已拦截），而非完整契约字段（7 字段齐全），证明自然语言规范无法被机器执行，契约字段可被机器查询、校验、拦截。

链路 2（语义域存在性校验）：将自然语言”错误状态要分级”识别为缺少 semantic_domain 声明（已拦截），而非合法域”观察性（observational）”，证明机器不知道自然语言规范该查哪本字典，契约字段通过语义域声明锁定字典查询路径。

链路 3（语义令牌离散性校验）：将自然语言”严重的用红色”识别为形容词不可判定（已拦截），而非语义令牌枚举值 fatal / transient / retryable / degraded（已绑定颜色+行为+文案），证明自然语言规范的”严重”是主观标准，契约字段的语义令牌是机器可查询的离散枚举。

3.3 案例 2：边界动作区分，自然语言 vs 契约字段

Before（自然语言规范）：

“AI拒绝用户请求时，要礼貌一点。如果涉及敏感内容，要说明原因。有时候需要终止对话，让用户知道。”

问题拆解：

• “礼貌一点”是形容词，机器无法执行
• “有时候”是模糊副词，机器不知道什么情况下终止
• “让用户知道”没有明确标准，用户不知道权利还在不在

After（契约字段）：

关键差异：边界动作 字段把自然语言里的“拒绝/终止/升级”三个模糊动词，变成了机器可区分的三级枚举。每个级别绑定不同的用户权利（上下文是否保留、能否申诉）。（ 详见：边界动作诊断：拒绝 ≠ 终止，权利差异未区分）

【演示环境：边界动作区分 · 自然语言 vs 契约字段】

同一份设计意图，自然语言只写了“要礼貌，有时候需终止对话”，机器只能“渲染文字”，无法理解“礼貌”、“有时候”的具体含义。契约字段将其变成三级枚举：refusal（拒绝，保留上下文）、termination（终止，清空上下文并提示数据政策）、escalation（升级人工）。每级绑定用户具体权利。机器读取时按字段查询，是执行规则，而非渲染文字。

链路 4（行为约束可判定性校验）：将自然语言”要礼貌一点”识别为不可判定表述（已拦截），而非边界动作枚举值 refusal / termination / escalation（已绑定用户权利+数据政策+申诉路径），证明自然语言规范的”礼貌”无法被机器校验，契约字段的边界动作是机器可执行的枚举值。

链路 5（不可变边界存在性校验）：将自然语言”有时候需要终止对话”识别为缺少 immutable_boundaries 声明（已拦截），而非”终止会话必须告知数据政策+提供申诉入口”（已绑定违反动作 block），证明自然语言规范没有”绝对不能碰”的红线，契约字段通过不可变边界设定违反即阻断。

3.4 逐字段差异：7个字段 × 自然语言痛点

3.5 不是”翻译格式”，是”增加机器可执行结构”

四、字段层差异在 Schema-As-Code 中的位置

字段层差异不是孤立的技术讨论，而是 Schema-As-Code 框架中”语义编码层”的核心设计。它位于编译管线的最上游，契约引用语义字典中的语义令牌，编译管线将令牌查表展开为连续约束，再翻译为四种消费格式。

字段层差异是这条链路的“原材料”，如果规范层只有自然语言没有机器可读字段，下游的契约、编译、验证全部失去根基。

依赖关系：语义令牌表（离散值）→ 语义字典（注册表）→ 语义域（覆盖层）→ 契约字段（原材料）→ 编译管线（执行层）→ 四种机器形态（消费层）

面向不同读者群时，字段层差异有两套叫法：

• 面向设计师/产品经理：自然语言规范 vs 机器可读字段
• 面向工程师：文档约束 vs 代码约束

两套术语指向同一事实：规范必须携带机器可执行的结构，才能进入AI生成流程。

五、诚实清单

字段层差异不定义新的语义（那是语义字典的职责），不约束视觉值的具体色值（那是设计令牌（Design Token）层的职责），也不约束”字段被不被正确引用”（消费纪律在角色侧，见 角色专题 ①｜设计师与产品经理）。当前量化收益均为数据模型推演，待生产数据验证。

六、推演条件

已验证：7字段结构在3个漂移模式（ERR-001 错误状态诊断、PRO-001 过程状态诊断、 BND-001 边界动作诊断）中跑通

• 待验证：7字段结构在6个漂移模式全量中的覆盖度
• 待验证：自然语言规范 → 契约字段的转换成本（设计师学习曲线）
• 待验证：契约字段对AI生成准确率的提升幅度（A/B 测试）

七、框架设计背景：从字段层差异回到 Schema-As-Code 全景

字段层差异不是孤立的技术讨论，而是 Schema-As-Code 框架设计假设的一个验证切片。要理解这个案例的价值，需要先看到它在整个框架中的位置。

7.1 语义治理框架全景：三阶段与机器网络

Schema-As-Code 不是一套理论，是一条可执行的三阶段流水线（Semantic Pipeline）。

字段层差异横跨三个阶段：

• Guard 阶段：通过 6个漂移模式 观察到”自然语言规范无法被机器执行“（ERR-001 根因：文档里写的”严重的用红色”机器读不懂；BND-001 根因：文档里写的”要礼貌一点”机器无法执行）
• Contract 阶段：将自然语言规范升级为契约字段，写入YAML契约，经 编译管线 生成4种消费格式

Verify 阶段：在真实组织中运转，设计师用表单写规则、前端按规则开发、AI 按规则生成、DesignOps 追踪版本、机器自动拦截违规。不是证明”规则有效”，是证明”这套工作流在真实团队中能跑起来”。

7.2 案例验证：字段层差异证明了什么

证明 1：自然语言规范对机器不可执行

“严重的用红色”对设计师是清晰的，对机器只是文字。机器不知道”严重”在什么场景下合法、必须附带什么交互、不能出现在哪里。自然语言规范的四项缺失（无机器结构、无审计记录、无生成注入、无版本管理）导致规范是“死的”，存在但不被执行。

这个发现不是某位设计师”感觉不对”，而是通过 三层判定模型 被归档为模式卡片：第一层识别组件类型为”错误状态”，第二层判定语义缺失为”后果差异未分级”，第三层校验视觉表达为”所有错误共用同一种红色”。（ 结构化诊断：三层判定模型与模式匹配机制）

证明 2：契约字段增加了机器可执行的结构

同样的设计意图，写成契约字段后，机器获得了六项能力：按字段查询、按规则校验、按边界拦截、按场景匹配、按版本追溯、按指令Prompt注入。不是“翻译了格式”，是“增加了机器能读懂的结构”。

这些字段被写入 语义字典 注册为组织级语义码本。契约通过引用字典中的字段，声明了 跨层禁止规则（如 致命错误 fatal 不可用于 观察性场景 ）。契约不是文档，是机器可执行的规则，前端按字段映射渲染，持续集成CI按规则拦截，AI按指令Prompt前缀注入约束。（ 语义规范体系：YAML里写的不是颜色值，是语义令牌）

证明 3：字段层差异是下游一切机制的前提

如果规范层只有自然语言，YAML契约无法被机器编译（机器读不懂”严重的用红色”），编译管线无法展开令牌（没有离散枚举值），验证工具无法拦截违规（没有可判定的约束标准）。字段层差异是 Schema-As-Code 的“原材料层”，原材料不对，下游全部失效。

A/B对比实验：同一Prompt”生成删除账户弹窗”，未注入契约时AI输出”确认”按钮（蓝色实心），注入契约后AI输出”确认删除账户”按钮（红色空心描边 + 二次确认）。约束真的改变了AI的行为。编译为指令Prompt前缀后，AI生成界面时不再只有”按钮”一个语义槽位；编译为结构校验JSON Schema后，前端实现时硬编码样式被强制替换为语义令牌引用；编译为持续集成CI规则 后，缺少二次确认的高危操作场景在提交时被阻断。这套验证机器在《字典引用的机器防线》中被完整定义。《前端与AI工程师》详细描述了三项资产如何在工程师工作流中被消费。

7.3 回到开篇的问题

回到开篇的三个问题：

① 团队文档里写的”错误状态要分级”，机器能看懂吗？

→ 不能。”分级”是形容词，机器不知道什么算”严重”、什么算”一般”。

② 同样的设计意图，写成自然语言规范和写成契约字段，到底有什么实际差别？

→ 差别不是”格式不同”，是”机器能不能执行”。自然语言规范机器只能”渲染成文字”，契约字段机器能”查字典、能校验、能拦截、能同步、能版本追溯”。

③ 这个差别带来的能力是不是不可替代？

→ 是。没有机器可执行的字段，契约无法编译，验证无法拦截，同步无法自动。自然语言规范在 AI 生成时代失效了。

这个案例同时也回答了更底层的问题：为什么需要 Schema-As-Code把设计规范写成代码格式这套框架？

因为语义漂移的根因不止在界面层，也在规范层。当”严重的用红色”无法被机器理解时，框架提供的不只是诊断方法，而是一套从 规范编码 到 机器验证 的完整工作流。

八、一句话总结（给不同角色）

给设计师

“你以前写’严重的用红色’在语雀文档里，前端可能看漏。现在你写 状态.致命 Status.Critical = {颜色+场景+行为+禁区}，机器自动把它变成指令Prompt前缀、结构校验 JSON Schema、清单 Checklist、持续集成CI规则，四种人自动拿到自己需要的东西，不用你发四遍通知。”

给前端

“规范以前只告诉你’写清楚’，注释不参与编译。现在规范告诉你这个字段在这个场景下必须附带什么交互、不能出现在哪里，而且写成了机器可校验的结构，漏掉持续集成CI直接阻断。”

给 AI 工程师

“你不需要在指令Prompt里手动粘贴设计规范，规范写不全、版本还乱。现在契约自动编译成指令Prompt前缀，注入你的AI上下文，AI生成前先加载约束，不会再把删除按钮做成蓝色实心。”

给设计运营（DesignOps）

“你不需要@全员开会同步规范，改一次YAML契约，差异Git Diff自动告诉你影响了哪些产品、哪些文件。规范同步从2周降到5分钟。”

给管理层

“以前规范是’死的’，写在文档里，机器读不到。现在规范是’活的’，写成契约字段，机器自动编译、自动校验、自动同步。语义一致性从’人盯’变成’机查’，返工率从 30% 降到 5%。”

九、下一站

本文回答了”同样的设计意图，写成自然语言规范和写成契约字段有什么实际差别”。下一站需要回答的问题是：

• 契约字段写好了，机制怎么守住它？（④ 契约的机制防线：契约不是文档，是机制执行的拦截规则）
• 契约字段怎么被不同角色消费？（角色专题 ①｜设计师与产品经理、②｜前端与 AI 工程师、③｜设计运营（DesignOps））
• 契约字段的量化收益怎么度量？（⑥ 度量层：从定性到定量的推演方法）

附录：

【演示环境：字段层差异颜色、文案、图标各自有独立的语义定义】：https://2436041978-ops.github.io/semantic-pipeline/mechanism/03-yaml-contract/field-divergence.html

④ YAML 契约：https://www.yuque.com/u222739/why7ts/xxrmf2wlhh6h0wxc

② 边界动作诊断：https://www.yuque.com/u222739/why7ts/ki9gy53rywsp9m6h

编译管线是语义一致性的”机器翻译层”：https://www.yuque.com/u222739/why7ts/yvrpvhwawyb9b54u

① 语义字典：https://www.yuque.com/u222739/why7ts/mr4mqy0cnkl8gmab

① 语义令牌表：https://www.yuque.com/u222739/why7ts/ahgd86ugl61h6dy3

角色专题 ①｜设计师与产品经理：https://www.yuque.com/u222739/why7ts/nlwd1q32ny08n317

角色专题 ② ｜前端与 AI 工程师：https://www.yuque.com/u222739/why7ts/pspi1r6iypclto8x/edit

Guard 结构化诊断：https://www.yuque.com/u222739/why7ts/lzwfwmg2iwde0qfw

6 字段快照：https://www.yuque.com/u222739/why7ts/eh9r40xm1wwku0os

三层判定模型：https://www.yuque.com/u222739/why7ts/rdyspgtkuky50zie

模式库：https://www.yuque.com/u222739/why7ts/rwlzmucm3lgxzm10

语义规范体系：https://www.yuque.com/u222739/why7ts/ugxdg4go2t7tlf9l

Contract 语义契约化：https://www.yuque.com/u222739/why7ts/xqcb55ikrtpyeqih

YAML 契约：https://www.yuque.com/u222739/why7ts/orfwe0f15ga79wdg

契约库：https://www.yuque.com/u222739/why7ts/cn0l4ewmwvzeqsdo

4 种编译格式：https://www.yuque.com/u222739/why7ts/yvrpvhwawyb9b54u

机器防线（守住规则）：https://www.yuque.com/u222739/why7ts/dxsrr7dt1b32clzq

6个漂移模式：https://www.yuque.com/u222739/why7ts/rwlzmucm3lgxzm10

跨层禁止规则：https://www.yuque.com/u222739/why7ts/ko79ri1t7pxkq9wx

字典引用的机器防线：https://www.yuque.com/u222739/why7ts/dxsrr7dt1b32clzq

前端与AI工程师：https://www.yuque.com/u222739/why7ts/pspi1r6iypclto8x