本文是 Schema-As-Code把设计规范写成代码格式 证据链的"差异+案例"站，属于主题行 ④ YAML 契约 的子文档。
在前序章节中，④ 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 根因：自然语言规范的四项缺失
| 规范形态 | 呈现状态 | 缺失什么 |
|---|---|---|
| 规范文档 | 供人阅读，形容词表达 | 机器可执行的结构 |
| 口头约定 | 存在会议室与记忆里 | 可追溯、可审计的记录 |
| 设计稿标注 | 与实现人工转译 | 生成时可注入的机器格式 |
| 指令（Prompt）文本 | 每个项目重写一遍 | 可复用、可版本管理的资产形态 |
2.2 为什么团队会踩这个坑
自然语言规范的"清晰表达"在视觉上已经进步了，设计师看到"严重的用红色"会联想到"危险"。但这种进步停留在人脑理解层，没有到达机器执行层。
当AI生成工具接管界面生产时，问题暴露：AI不读设计规范文档。它只看到一段文字，这段文字对它来说和"随便发挥"没有本质区别。
2.3 跨角色反馈：同一根因，五种坑
| 角色 | 踩过的坑 | 根因 | 机器如何解 |
|---|---|---|---|
| 设计师 | "新增了错误状态凭直觉写文案，两周后走查才发现规范里根本没这个级别" | 字典是文档不是代码，新增状态凭直觉描述 | 语义字典变成代码格式YAML，变更走代码合并请求PR；契约必须引用已注册字段，未注册编译阻断 |
| 前端 / AI 工程师 | "规范只告诉我'写清楚'，没告诉我这个场景该用哪个字段" | 缺少结构化字段，场景与约束脱钩 | 契约字段 + 语义域联合定义，覆盖层强制注入语义 |
| 设计运营（DesignOps） | "各产品线的规范版本对不上，同一个词三套说法" | 没有统一规范源，各自维护私有文档 | 契约库作为组织级唯一真相源，禁止平行私有字典 |
| 体验架构师 | "模式库维护成本高，每次诊断都从零开始" | 字段没有复用，诊断无法站在已注册定义上 | 从字典复用字段，快速匹配既有模式 |
| 管理层 | "语义一致性投入多少、产出在哪，看不到" | 缺少度量基准 | 字段标准化后，一致性覆盖率可量化 |
三、关键设计：字段层差异 Before / After
3.1 设计思路
3.1.1 给规范"挂档案"，而不是只写段落
以前把"错误状态要分级"写在文档里，以为这样就"规范化了"。但对机器来说，这段文字和"随便发挥"没有任何区别，都是一段自然语言，机器只知道"渲染成文字"，不知道"这段文字代表什么约束"。
真正的规范化是给规范挂一份档案：这个约束在什么场景下生效？用户看到这个界面该做什么？什么情况下绝对不能这样写？
3.1.2 机器看到的不只是文字，还有"场景+行为+禁区"
传统的自然语言规范只有一段："严重的用红色，文案要写清楚"
契约字段有三层：
- 颜色背后的意思（Semantic Token）：这个红色代表什么（致命/警告/通知）
- 场景归属（Semantic Domain）：这个红色在什么场景下合法
- 不可突破的边界（Immutable Boundary）：这个红色绝对不能出现在哪里
3.1.3 从"走查时发现问题"变成"生成时直接拦住"
以前：AI生成红色限流提示 → 设计师走查发现不对 → 前端修改 → 再测试 → 再上线
现在：AI想生成红色限流提示 → 查字典发现限流 = 黄色时钟 → 若AI硬要用红色 → 机器直接阻断
3.1.4 同义词替换是语义漂移的最大元凶
大语言模型LLM没有"情绪权重"的概念，它只有"词频统计"。在它眼里，"Critical"和"严重"是等价的同义词，可以随便替换。
但对用户来说："Critical" = 立刻处理，否则系统挂了；"严重" = 等会儿再看也行。
契约字段的做法：在字典里定义"这个场景下必须用 Critical，不能用严重"。大语言模型LLM若输出"严重"，机器直接拦截。
3.1.5 两层跃迁
| 阶段 | 机器知道什么 | 能做什么 | 例子 |
|---|---|---|---|
| 第一层：自然语言 | 这是一段文字 | 只能供人阅读 | "严重的用红色" |
| 第二层：契约字段 | 这是致命错误，必须二次确认，不能用在通知里 | 可校验、可拦截、可阻断 | 状态.致命（Status.Critical）= {颜色+场景+行为+禁区} |
3.2 案例 1：错误状态分级，自然语言 vs 契约字段
Before（自然语言规范）：
"错误状态要分级显示。严重的用红色，一般的用黄色，轻微的用灰色。文案要写清楚，让用户知道该做什么。高危操作要二次确认。"
问题拆解：
- "严重"是形容词，机器不知道什么算严重
- "写清楚"是主观标准，走查时各执一词
- "高危操作"没有明确定义，AI 不知道哪些操作算高危
- 没有"绝对不能碰"的红线
After（契约字段）：
演示环境对比了两种表达方式。自然语言规范只有“严重红、一般黄”的模糊描述，机器只能当文字渲染，不懂场景合法性；契约字段则用七项档案（带版号的编号、明确定义、绑定的语义域、适用产品范围、四级令牌及各绑定的颜色行为、限流禁红的生成前拦截约束、违反即阻断的不可变边界）精确锁定意图。机器读取时按字段路径查询，是“执行规则”，而非“渲染文字”。
| 契约字段 | 自然语言怎么写的（Before） | 自然语言的问题 | 契约怎么解决的（After） |
|---|---|---|---|
| 意图编号（Intent ID） | "错误状态要分级" | 没有唯一标识，沟通时说"那个错误状态的东西" | ERR-001：精确指向，验收时引用版本号 |
| 描述（Description） | "严重的用红色" | "严重"是形容词，机器不知道什么算严重 | 现象+根因+后果，一句话说清边界 |
| 语义域（Semantic Domain） | 文档里没提 | 设计师知道"错误状态"是观察性的，机器不知道 | 观察性：机器知道该查哪本字典 |
| 适用产品（Applicable Products） | 无 | 不知道这个规范在哪个产品生效 | ["ChatGPT", "Kimi", "DeepSeek"]：明确生效范围 |
| 语义令牌（Semantic Tokens） | "文案要写清楚" | "清楚"是主观标准，走查时各执一词 | 四级枚举（致命/网络抖动/限流/降级），每级绑定颜色+行为+文案 |
| 机器约束（LLM Constraints） | "高危操作要二次确认" | 写在文档里，AI生成时不读 | 机器在生成前注入指令Prompt，直接拦截 |
| 不可变边界（Immutable Boundaries） | 无 | 没有"绝对不能碰"的红线 | 违反即阻断Block，不可协商 |
● 链路 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（契约字段）：
关键差异：边界动作 字段把自然语言里的"拒绝/终止/升级"三个模糊动词，变成了机器可区分的三级枚举。每个级别绑定不同的用户权利（上下文是否保留、能否申诉）。（ 详见：边界动作诊断：拒绝 ≠ 终止，权利差异未区分）
同一份设计意图，自然语言只写了“要礼貌，有时候需终止对话”，机器只能“渲染文字”，无法理解“礼貌”、“有时候”的具体含义。契约字段将其变成三级枚举：refusal（拒绝，保留上下文）、termination（终止，清空上下文并提示数据政策）、escalation（升级人工）。每级绑定用户具体权利。机器读取时按字段查询，是执行规则，而非渲染文字。
● 链路 4（行为约束可判定性校验）：将自然语言"要礼貌一点"识别为不可判定表述（已拦截），而非边界动作枚举值 refusal / termination / escalation（已绑定用户权利+数据政策+申诉路径），证明自然语言规范的"礼貌"无法被机器校验，契约字段的边界动作是机器可执行的枚举值。
● 链路 5（不可变边界存在性校验）：将自然语言"有时候需要终止对话"识别为缺少 immutable_boundaries 声明（已拦截），而非"终止会话必须告知数据政策+提供申诉入口"（已绑定违反动作 block），证明自然语言规范没有"绝对不能碰"的红线，契约字段通过不可变边界设定违反即阻断。
3.4 逐字段差异：7个字段 × 自然语言痛点
| 自然语言痛点 | 契约字段解法 | 机器获得的能力 |
|---|---|---|
| 形容词无法执行（"严重的""清楚的""礼貌的"） | 语义令牌 Semantic Tokens 离散枚举 | 机器按枚举值查询，不再自由发挥 |
| 没有唯一标识（"那个错误状态的东西"） | 意图编号 Intent ID + 版本 Version | 精确引用、版本追溯、差异Diff可见 |
| 没有场景归属（不知道查哪本字典） | 语义域 | 机器知道该查哪本字典，跨层禁止可执行 |
| 没有生效范围（不知道哪个产品用） | 适用产品 | 全局/局部生效明确，排除列表可配 |
| 没有用户行动指引（"让用户知道"） | 用户行动 User Action 结构化列表 | 每个级别绑定明确的用户下一步行动 |
| 没有机器约束（"写清楚"但AI不读） | 机器约束 LLM Constraints 三型规则 | 生成前注入指令Prompt，生成时校验，提交时拦截 |
| 没有红线（"有时候"终止） | 不可变边界 Immutable Boundaries + 违反动作 Violation Action | 违反即阻断/升级，不可协商 |
3.5 不是"翻译格式"，是"增加机器可执行结构"
| 维度 | Before（自然语言规范） | After（契约字段） | 差异带来的能力 |
|---|---|---|---|
| 表达内容 | 一段文字 | 字段路径 + 值 + 约束 | 机器可按字段查询、校验、拦截 |
| 机器可执行 | 只能供人阅读 | 可校验、可拦截、可阻断 | 编译期与持续集成 CI 期阻断违规 |
| 行为约束 | 无 只有人类可读的形容词 | 用户行动 User Action + 机器约束 LLM Constraints | 交互语义不可被生成器省略 |
| 跨层规则 | 无 | 语义域 + 跨层禁止 | 场景误用被拦截 |
| 版本管理 | 文档过期无人知 | 版本 Version + 差异 Git Diff | 变更可追溯、可回滚 |
| AI 消费 | AI看到文字，自由发挥 | AI按指令 Prompt 前缀注入约束 | 按规则生成，不按概率生成 |
四、字段层差异在 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 字段快照 + 三层判定模型 + 模式库 |
| 阶段二 | Contract 语义契约化 | 我怎么用规则锁住设计意图？ | YAML 契约 + 契约库 + 4 种编译格式 |
| 阶段三 | Verify 验证闭环 | 框架在真实组织中怎么运转？ | 机器防线（守住规则）+ 角色工作流（设计师/前端/DesignOps 怎么用起来）+ 度量层（怎么量化效果）+ 持续迭代（怎么根据反馈优化规则） |
字段层差异横跨三个阶段：
- 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））
● 契约字段的量化收益怎么度量？（⑥ 度量层：从定性到定量的推演方法）
1920
