契约写了不等于被机器守住。本文通过三道闸验证，证明结构、语义、同步三类违规能被机器自动拦截，让契约从'规范'变成'被执行的规则'。

在前序章节中，YAML 契约 已经证明了”形式化为代码的规矩在机器世界里长什么样“，同一份YAML能被编译为四种机器格式；字段层差异 已经证明了”自然语言规范无法被机器执行，契约字段可以“。但还有一个关键问题没有回答：

契约的7个字段冻结、单一来源编译、产物禁止手改，这些规则写在规范里，不等于被机器守住了。

设计运营DesignOps的真实反馈是：”契约升到了 v1.1.0，下游还在用 v1.0.0 的指令Prompt前缀，没人发现；直到有人嫌麻烦直接手改了编译产物，两套’真相’同时在线，评审时才发现对不上。”

本文要验证的正是这条”契约的机器防线”，不是人查文档，而是机器在契约全生命周期中自动守住结构、语义、同步三道闸。

本文核心回答三个问题：

① 契约缺字段、版本号乱写、非法引用，这些失效真的会被发现吗？

② 手改编译产物、下游拿着过期版本在用，这些违规真的会被拦住吗？

③ 这个防线是”写好了就完事”，还是”一直在工作”？

1. 问题：契约写了，不等于被机器守住了

YAML 契约 白纸黑字写着7个字段必须齐全，编译管线 明确约定产物禁止手改、单一来源编译。但团队的真实反馈是：

“契约升到了 v1.1.0，下游还在用 v1.0.0 的 Prompt 前缀，没人发现；直到有人嫌麻烦直接手改了编译产物，两套’真相’同时在线，评审时才发现对不上。”

一份YAML契约缺了 immutable_boundaries 字段、版本号写成 “1.0”（非 SemVer）、llm_constraints 挂错了层级，这些错误在造成伤害之前，机器能否识别并阻断？没有验证层，契约只是”写好了的规范”，不是”被执行的规则”。

这正是 从观察到契约的Semantic Pipeline 要解决的问题：诊断和契约化之后，必须进入验证阶段，证明契约自身的结构、语义、同步真的被机器守住了。

2. 为什么人工评审守不住：结构、语义、同步三重不可见

人工走查的局限不是责任心问题，是信息结构问题：

• 结构不可见：设计师手写YAML时，缩进错误、字段缺失、层级挂错，人眼扫一遍很难发现，尤其是 llm_constraints 挂在 semantic_tokens 下还是挂在根节点下，视觉差别极小。
• 语义不可见：description 写成”错误状态规范”（无现象+根因+后果）、llm_constraints 出现”文案要友好一点”（不可判定），这些语义缺陷在人工评审时容易被忽略，因为”看起来差不多”。
• 同步不可见：契约入库只是第一时刻。4种消费格式是编译产物，下游会不会拿着过期产物在用？有人手改产物怎么办？人工评审只审”当时”，不审”持续”。

这正是 Schema-As-Code 框架要解决的问题：契约不是”写好了就完事”，机器要在全生命周期中守住三道闸，写的时候防呆、入库前校验、入库后对账。

3. 设计思路：契约全生命周期三道闸

契约不是写完就完事，机器要全程守住。三道闸贯穿契约从写到用的完整生命周期：

第一道闸：入口防呆，写的时候，错误就写不出来

设计师不用手写规则文件，用表单填空：选组件类型 → 选场景 → 填必填项。填不完提交按钮是灰的，格式错误在产生前就消除。如果非要手写，机器先校验一遍，错了不让入库。

第二道闸：入库安检，提交前，机器逐项核对

契约提交前过五道机器安检：场景对不对？引用合不合法？字段齐不齐？版本号格式对吗？语法有没有错？任一不过直接阻断，错误定位到具体字段路径。

第三道闸：同步对账，用的时候，版本永远对得上

编译产物（给AI用的指令前缀、给代码用的校验规则等）头部自带版本声明。消费方加载时自动核对：是不是最新版？有没有被人手改过？四种格式表达的是不是同一个意思？版本不对或被人改了，机器5分钟内告警并阻断。

4. 本文的验证口径

本文要验证的不是”契约能不能被写出来”，而是”契约被写出来之后，机器能不能守住它”。本文验证三个命题：

一、验证对象：契约层的三类违规

本文验证的不是”契约写得好不好”，而是”契约被机器守住的能力”。验证对象锁定三类真实违规：

第一类：结构违规，契约本身写错了

• 缺必填字段（如缺了不可变边界（Immutable Boundaries））
• 版本号格式错误（如写成 “1.0” 而非语义化版本（SemVer）x.y.z）
• 字段层级挂错（如机器约束（LLM Constraints）挂在语义令牌（Semantic Tokens）下而非根节点下）
• 非法引用（如引用了字典中不存在的语义绑定）

第二类：语义违规，契约写对了，但不可判定

• 机器约束（LLM Constraints）出现不可判定表述（如”文案要友好一点””按钮看起来要舒服”）
• 描述（Description）缺少现象+根因+后果三要素
• 语义令牌（Semantic Tokens）的值不在字典预定义列表中

第三类：同步违规，契约更新了，但下游没跟上

• 下游消费方拿着过期版本的编译产物在用
• 有人直接手改编译产物（Compiled/）目录下的文件
• 编译产物与源契约版本不一致，但无人察觉

二、验证设计：三层

第一层：入口防呆，写的时候，格式错误在产生前就消除

问题：契约的第一道防线不该是”写错后拦截”，而是”写不出来”。手写 YAML 的缩进错误、字段缺失、层级挂错，能不能在产生前就消除？

我的设计：

• 表单防呆：不写YAML，只填表。选项来自字典下拉框，不可自创；语义、视觉、行动、约束四项必填，漏一项点不了下一步；层级由表单结构强制，挂不错。格式错误在产生前就被拦住。
• 手写兜底：允许手写契约，但必须通过接口校验（/api/contracts/validate，只校验不产出）才能入库。

验证方式：6组对抗用例（故意写错的契约）全部在表单层被拦截，拦截率 100%。

对抗用例：

【演示环境：入口防呆 · 表单层拦截】

在演示环境中，设计师填表单时，必填项没填完，提交按钮是灰的，点不了。选语义域时，下拉列表只显示字典里注册过的选项，没有”custom_domain”。想把手写约束挂错层级，表单结构不让。手写YAML缺字段直接提交，机器直接报错，不让。

● 链路 1 必填字段防呆校验：将缺 version 字段的契约识别为”提交按钮灰显”（已拦截），而非允许提交，证明格式错误在产生前即被消除，设计师写不出缺字段的契约。

● 链路 2 语义域下拉锁定：将 semantic_domain: “custom_domain” 识别为”下拉列表无此选项”（已拦截），而非合法域（transactional / observational / navigational / conversational / universal 及 L2 子层），证明域引用被字典注册项锁定，机器不会放行未注册覆盖层。

● 链路 3 字段层级强制：将 llm_constraints 挂在 semantic_tokens.fatal 下的尝试识别为”表单结构强制根节点”（已拦截），而非允许挂错层级，证明字段层级在表单层即被约束，无法绕过。

第二层：入库校验，五项前置安检，非法契约能被拦住吗？

问题：绕过编辑器的手写契约、历史契约，入库前能不能被系统性拦住？

我的设计：编译前置校验，任一不过即阻断（输出具体错误项）：

• 覆盖层存在性：语义域的值是否在字典预定义列表中
• 绑定存在性：契约引用的语义绑定是否都在字典中已定义
• 场景一致性：场景映射是否指向字典中已定义的覆盖层
• 字段完整性：7个顶层字段是否齐全、版本号是否符合语义化版本SemVerx.y.z
• 结构合法性：YAML语法、缩进、类型是否符合结构定义（schema/intent-schema.json），含令牌级必填子字段检查（每个级别必须有机器约束（LLM Constraints），缺失即定位到 语义令牌.组.级别.机器约束（semantic_tokens.{group}.{level}.llm_constraints））

错误响应统一 { 错误码（Code）, 错误信息（Message）, 错误位置（Location） }，错误位置（Location）定位到具体字段路径。

验证方式：6组对抗用例（故意写错的契约）全部在入库前被拦截，拦截率 100%。

对抗用例：

【演示环境：入库安检 · 五项前置安检】

在演示环境中，契约提交后过五道机器安检。覆盖层不存在、绑定不存在、场景不一致、字段不完整、结构不合法，任一不过直接阻断，返回具体错误码。语义不可判定（如”文案要友好一点”）标记为警告，提交人工。

● 链路 4 覆盖层存在性校验：将 semantic_domain: “custom_domain” 识别为 SEMANTIC_DOMAIN_UNDEFINED（已拦截），而非合法域（transactional / observational / navigational / conversational / universal 及 L2 子层），证明域引用被字典注册项锁定，机器不会放行未注册覆盖层。

● 链路 5 绑定存在性校验：将引用的语义绑定识别为 BINDING_NOT_FOUND（已拦截），而非字典已定义项，证明契约引用的每个语义绑定必须在字典中先注册、后引用。

● 链路 6 字段完整性校验：将缺 immutable_boundaries 的契约识别为 FIELD_MISSING（已拦截），而非 7 字段齐全，证明机器逐项核对 7 个顶层字段，缺一即阻断。

● 链路 7 语义可判定性校验：将”文案要友好一点”识别为 UNJUDGEABLE_CONSTRAINT（已拦截，转人工复核），而非可判定约束，证明机器能识别”友好”等形容词无法被校验，阻止不可判定约束流入生产环境。

第三层：同步防线，单一来源对账，产物与源契约会持续一致吗？

问题：契约入库只是第一时刻。4种消费格式是编译产物，下游会不会拿着过期产物在用？有人手改产物怎么办？

我的设计：

• 版本声明对账：每个编译产物头部嵌入版本声明（源契约、版本、编译时间，如”基于 ERR-001 v1.1.0 编译 / 编译时间：2026-07-13 / 源文件：contracts/ERR-001.yaml”）；消费方加载时核对声明版本与契约库当前版本。
• 手改拒绝：编译产物（Compiled/）目录全部由编译管线产出，持续集成CI校验产物哈希与编译记录一致性，手工修改的衍生格式在持续集成CI中被拒绝。
• 三层编译验证：每次编译执行，结构验证（编译后的结构校验JSON Schema是否合法，结构校验机制）、语义验证（指令Prompt前缀是否被AI正确理解，输入已知错误文案的测试用例集）、一致性验证（四种格式是否表达同一语义，交叉比对），产出编译报告。
• 失败判定：产物版本声明与源契约不一致；编译记录缺失；四种格式交叉比对出现语义分叉。

验证方式：3组对抗用例（模拟同步违规场景），机器在5分钟内告警并阻断。

对抗用例：

【演示环境：同步防线 · 版本对账与哈希校验】

描述： 在演示环境中，契约库显示当前版本 v1.1.0，四种下游格式均同步。下游过期 5 分钟告警，手改产物哈希校验阻断合并，编译记录缺失阻断

● 链路 8 版本声明对账：将下游消费的 v1.0.0 产物识别为”版本落后 43 天”（已告警），而非与契约库当前版本 v1.1.0 一致，证明产物头部嵌入的版本声明可被机器自动核对，版本脱节 5 分钟内即被发现。

● 链路 9 手改产物哈希校验：将手工修改的编译产物识别为”哈希不一致”（已阻断），而非与编译记录匹配，证明编译产物目录全部由编译管线产出，手工修改在持续集成（CI）中被拒绝，代码合并请求（PR）无法合并。

● 链路 10 编译记录一致性校验：将缺失编译记录的产物识别为”编译记录缺失”（已阻断），而非一致性验证通过，证明产物与编译记录必须同时存在，缺一即阻断消费。

三、它一直在工作吗：运行逻辑

• 执行链路：编辑器防呆（写不出来）→ 入库五项校验（错的进不来）→ 同步对账（进来的不变质），契约全生命周期三道闸。
• 版本同步闭环：设计师提交YAML新版本 → Git钩子触发编译管线 → 三层编译验证 → 生成4种格式新版本 → 自动通知下游（前端换 Prompt 前缀、DesignOps 换 Checklist、CI 规则下次提交生效）。
• 拦截统计与归因：结构违规按字段路径归因（哪个字段最常写错 → 编辑器表单优化输入）；语义违规按模式 ID 归因；同步违规按消费方归因。收益换算按返工成本模型推演，并标注推演口径。

回到开头那条 DesignOps 反馈。三道闸就位后，”下游拿着过期产物、手改产物两套真相”这个踩过的坑，走向完全不同：

诚实清单

这不是缺陷，是分工：本篇定义”守住契约应该测什么、通过标准是什么”，工程团队负责”怎么自动化跑、怎么接入生产环境”。

回到开篇的问题

契约7字段冻结、单一来源编译、产物禁止手改，这些规则真的被机器守住了吗？

• 结构层面：入口防呆让格式错误在产生前就消除，入库五项校验让非法契约 100% 被拦截，错误定位到具体字段路径。
• 语义层面：机器初筛可判定性（”文案要友好一点”被标记为不可判定），人工复核语义合理性，人机分担但不漏判。
• 同步层面：版本声明对账让过期产物自动告警，产物哈希校验让手改产物在CI中被拒绝，消费追踪让”谁在用哪个版本”全程可见。

这个防线不是”写好了就完事”，是”一直在工作”，写的时候防呆、入库前校验、入库后对账，三道闸贯穿契约全生命周期。

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

给设计师：”你写的规则文件，机器会先查字典确认每个词都注册过、版本都对，再让入库。引用了不存在的词，直接报错，不会带到生产环境。”

给前端 / AI 工程师：”契约入库前过五道机器安检，对抗用例拦截率 100%。不是人工审批，是机器逐项核对，错误定位到具体字段路径。”

给 DesignOps：”契约改了，Prompt 前缀、校验规则、走查清单、CI 规则四个消费点自动同步。哪个地方没跟上，机器 5 分钟内告警。规范更新从’人肉广播’变成’机器追踪’。”

给语义翻译设计师 / 体验架构师：”你的语义规则不是写完就完事。机器会验证：字段齐不齐？版本对不对？引用合不合法？违规了是阻断、警告还是升级审核？整条链路可被验证、可被追踪、可被归因。”

给管理层 / 决策者：”以前规范更新靠文档和会议，漏掉是常态。现在机器自动追踪：五道安检拦截错误入库，三档策略分级处理，版本兼容 90 天过渡，消费断裂 5 分钟告警。语义一致性从’人盯’变成’机管’。”

下一站：

契约自身的防线确认之后：

• 字典引用的合法性论证（覆盖层存在性 / 绑定存在性 / 场景一致性），见 D-T4《字典引用的机器防线》；
• 跨层非法绑定的拦截机制，见 D-T3《跨层禁止》；
• 该防线在角色工作流中的落地（DesignOps 怎么管版本、前端怎么接校验），见角色专题。

附录

【演示环境：契约的机器防线 契约不是文档，是机器执行的拦截规则】：https://2436041978-ops.github.io/semantic-pipeline/mechanism/03-yaml-contract/machine-guard.html

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

字段层差异：https://www.yuque.com/u222739/why7ts/tbsi58y574r3bbpa

边界动作诊断：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

从观察到契约的Semantic Pipeline：https://www.yuque.com/u222739/why7ts/pfaoq6xsftme601m

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

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

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