阶段一 Guard 结构化诊断 通过 组件语义快照 与 三层判定模型 证明了漂移真实存在；阶段二 Contract 语义契约化 将设计意图写入了 YAML 契约与 语义字典。
前序章节，第一步，定义了"场景决定语义"的规矩框架（语义域）。 组件本身是空容器，语义由场景定义，同一个按钮在交易场景里是"必须处理的阻断警告"，在信息场景里只是"可看可忽略的提示条"。这套规矩写进了规矩手册（语义字典），并通过覆盖层和域边界，把"什么场景下能用什么颜色/文案/图标"变成了可查询、可引用的规则。
第二步，通过真实案例证明了语义漂移真实存在。边界动作诊断（BND-001）发现：AI 把"拒绝请求"（对话继续，权利还在）和"终止会话"（上下文清空，权利已失）画成了同一种灰色提示条，用户无法判断"我的对话还在吗？能申诉吗？"类似的，错误状态诊断（ERR-001）证明四种错误共用同一种红色，过程状态诊断（PRO-001）证明进度标签掩盖了认知阶段。
但契约写在文件里不等于边界被守住 。 规矩手册里白纸黑字写着"致命红（status.critical）不能用在信息场景"、"终止会话必须显示数据保留政策和申诉入口"，可这些规矩写在文件里，不等于 AI 在生成界面时会遵守，也不等于前端工程师写代码时不会手滑写错。人工评审守不住那么机器能守住吗？
本文要验证的正是：当语义域定义了跨层禁止规则 后，机器能否在编译期、代码检查期、生成期三层独立拦截非法语义绑定，证明"场景决定语义"不只是纸面上的规矩，而是可以被机器执行、被工具验证、被流程兜底的防线。
1. 问题：规则写在字典里，不等于边界被守住了
语义字典 的 cross_layer_ban 字段白纸黑字写着"status.critical 不可用于 observational 域"，边界动作诊断 也证明了域内漂移真实存在。但团队的真实反馈是："规范里写着'限流提示禁用致命红'，上线前才发现 AI 还是把它画成了红色。
"规则防不住看不见规则的人，更防不住根本读不到规则的机器。
限流提示被画上致命红、同一界面点被声明两个 L1 域、L2 脱离父层单独声明，这三类越界的共同特征是：它们单看 YAML 契约 都"合法"，字段存在、绑定已注册、语法正确。只有对照 语义域 的边界规则才能判定非法。人工评审看到的是"语法没问题的契约"，机器对照规则树看到的才是"越界的引用"。
2. 为什么人工评审守不住：认知负荷与可见性盲区
人工走查的局限不是责任心问题，是信息结构问题。组件语义快照 的 6字段记录的是界面表象，评审者看到的是 color_token: status.critical，却看不到 语义规范体系 中该令牌的 cross_layer_ban 列表；看到的是两个 L1 声明，却看不到"每个界面点必须且只能被一个 L1 覆盖"的硬性约束；看到的是 data-destructive，却看不到它缺失了父层 transactional 的声明。
AI 生成工具更是如此，它的训练语料里没有这份 语义规范，提示词里不写，它就按旧习惯继续生成。工程师被迫在每次生成任务里手工复述规范要点，重复、易漏、不可追溯。
这正是 从观察到契约 的 Semantic Pipeline 要解决的问题：诊断和契约化之后，必须进入验证阶段，证明规则真的被机器守住了。
3. 设计思路：从"文档约定"到"机器规则"
跨层禁止必须从"评审纪律"升级为"机器防线"。设计思路是：
- 编码为可运算规则 ：语义字典 中的
cross_layer_ban、L1 互斥、L2 层级不再是文档里的文字，而是 契约库 中的结构化字段，可被规则树逐条核对； - 编译为可执行指令 ：编译管线 将契约翻译为 Prompt 前缀、JSON Schema、CI 规则等消费格式，让规则到达工程师手中；
- 三层独立校验：编译期（契约加载时）、Lint 期（代码提交时）、生成期（AI 输出时）------同一规则在三个时刻被三处独立校验，任一失守有下一层兜底。
4. 本文的验证口径
"守住域边界"必须翻译成可测试的命题。 本文验证三类违规，对应 6 个漂移模式 中 组件语义分类与漂移模式匹配 所定义的跨域漂移：
| 测试类型 | 测试用例 | 预期结果 |
|---|---|---|
| 绑定越域使用 | observational 域的契约引用 status.critical |
编译前置校验命中 cross_layer_ban，阻断并返回字段路径 |
| L1 互斥违反 | 同一界面点同时声明 transactional + observational | 互斥校验阻断，提示"每个界面点必须且只能被一个 L1 覆盖" |
| L2 脱离父层 | 声明 data-destructive（L2）但未声明父层 transactional |
层级校验阻断，提示 L2 必须叠加于父层 |
一、验证对象：跨层禁止的三类违规
先把"守住域边界"翻译成可测试的命题。 跨层禁止面临三类违规，每一类对应一条可判定的预期结果：
| 测试类型 | 测试用例 | 预期结果 |
|---|---|---|
| 绑定越域使用 | observational 域的契约引用 status.critical（如限流提示用致命红） | 编译前置校验命中 cross_layer_ban，阻断并返回字段路径 |
| L1 互斥违反 | 同一界面点同时声明 transactional + observational 两个 L1 覆盖层 | 互斥校验阻断，提示"每个界面点必须且只能被一个 L1 覆盖" |
| L2 脱离父层 | 声明 data-destructive（L2）但未声明父层 transactional | 层级校验阻断，提示 L2 必须叠加于父层而非替代 |
三类违规的共同本质：它们单看 YAML 都"合法"，字段存在、绑定已注册、语法正确，只有对照域边界规则（cross_layer_ban / L1 互斥 / L2 层级）才能判定非法。 这正是域边界必须由机器守护而非人工评审的原因：人工评审看到的是"语法没问题的契约"，机器对照规则树看到的是"越界的引用"。
二、验证设计：三层
2.1 编译期：字典规则树对账，越界引用在入库前能被拦住吗？
问题： 契约文件里写了"这个按钮用红色"，但规矩手册（语义字典）里可能没登记这个用法，或者登记在"A场景"却被用到了"B场景"。契约入库前，机器能拦住这种"跨场景乱用"吗？
我的设计：
- 规矩手册回查（字典回查） ：加载契约时逐条核对"颜色/图标/动画"的引用是否在规矩手册里登记过。发现手册外的条目（如私自发明了一个不存在的颜色名），立即阻断。
- 跨场景禁止解析（cross_layer_ban 解析） ：核对"禁止跨场景使用"的声明，比如"致命红"（status.critical）在手册里登记为"仅限交易场景使用"，那么契约把它用到"观察场景"（observational）就是跨场景乱用。
- 版本锁定（版本锚定） ：契约头部声明依赖的规矩手册版本（如 v1.1.0），加载时锁定该版本快照。手册升级不会意外破坏旧契约的禁止规则。
演示环境证明：
- 链路 4（规矩手册查询） ："致命红"的登记信息明确标注"仅限交易场景使用"，与契约中的跨场景禁止声明相互校验
- 链路 3（模式卡片） ：同一份契约编译为 4 种格式，证明跨场景禁止规则可被统一消费
- 链路 5（角色工作台） ：设计运营（DesignOps）能准确列出三类使用方，证明引用关系被完整解析
【演示环境：编译期跨场景禁止规则解析验证报告】
描述： 在演示环境中，上传错误状态契约文件（ERR-001.yaml）后，系统执行编译期前置校验：
- 契约加载机制：输入错误状态契约文件，解析"语义级别"（4 个级别：致命/网络抖/限流/部分可用）和"跨场景禁止规则"，生成内存中的规则树。
- 引用对账：规则树生成时，逐条核对契约引用的场景与颜色/图标/动画是否都在规矩手册登记项内。
-
- 场景"观察层"（observational）→ 手册已登记 ✓
- 颜色"致命红/中性灰/警告黄/信息蓝"（status.critical / neutral / warning / info）→ 手册已登记 ✓
- 动画 + 图标组合 → 手册已登记 ✓
- 跨场景禁止核对："致命红"的登记信息标注"仅限交易场景使用"，契约中将其用于"观察场景" → 触发跨场景拦截 ✓
- 解析指标：4 个语义级别 / 14 个校验规则节点 / 6 个引用对账项全部通过 / 解析耗时 12ms
推演条件：
需明确组织分工，语义翻译设计师维护规矩手册定义，设计运营（DesignOps）负责版本发布。规矩手册是"语义宪法"，修改权限集中。
2.2 Lint 期：代码静态检查------实现层的越界能被拦住吗？
问题： 前端工程师写代码时，可能手滑把"致命红"（status.critical）写进了限流组件的颜色配置。契约入库时拦住了，但代码层面的硬编码引用怎么拦？
我的设计：
- 编译前置校验：核对所有"语义级别"（semantic_tokens）的引用路径。引用不存在的令牌，或令牌与场景不匹配（如"致命红"出现在"观察场景"），编译直接阻断。
- 跨场景禁止规则落地（跨层禁止规则硬编码） ：规矩手册中登记的 6 个语义绑定均附带"跨场景禁止"声明（如"致命红"禁止用于观察/导航/对话场景）。契约若违反，生成前即被拦截。
- 代码检查规则同步（ESLint 规则同步） ：规矩手册变更后，代码检查规则自动同步更新。前端提交代码时，硬编码的非法颜色引用直接报错。
演示环境证明：
- 链路 5（前端工作台） ：选择错误状态契约后，输出的 AI 指令前缀（Prompt 前缀）自动注入"限流提示禁止红色"约束，证明规矩手册的跨场景禁止规则已被编译为可执行指令
- 链路 2（语义分级机制） ："请求过于频繁"被识别为"限流级"（黄色时钟），而非"致命级"（红色脉冲），证明颜色-场景映射被规矩手册锁定
- 链路 4（规矩手册查询） ："致命红"的登记信息明确标注"仅限交易场景使用"，与契约中的场景声明相互校验
【演示环境：代码检查期代码级语义绑定校验报告】
描述： 在演示环境中，模拟前端代码提交场景，系统执行五项前置校验，任一不过即阻断合入：
| 安检项 | 查什么 | 对抗用例拦截结果 |
|---|---|---|
| 场景存在性 | 场景是否在规矩手册预定义列表 | 自定义场景 → 场景未定义 ✓ 已拦截 |
| 颜色存在性 | 颜色/动画/图标是否在规矩手册 | 未知颜色 → 颜色未登记 ✓ 已拦截 |
| 跨场景禁止一致性 | 跨场景禁止是否指向手册已登记的禁止规则 | "致命红"用于观察场景 → 跨场景违规 ✓ 已拦截 |
| 场景一致性 | 场景映射是否指向手册已登记的场景 | 未登记场景 → 场景不匹配 ✓ 已拦截 |
| 字段完整性 | 7 个顶层字段是否齐全、版本号是否符合规范 | 缺字段 + 版本格式错误 → 字段不完整 ✓ 已拦截 |
推演条件：
需前端工程团队接入代码检查插件（ESLint 插件），将规矩手册的跨场景禁止规则编译为代码级校验规则。规则更新与规矩手册版本同步，避免"上游改了，下游还在用旧定义"。
2.3 生成期：四层推演机制------AI 生成结果中的越界能被拦住吗？
问题： 即使契约入库了、代码写对了，AI 在生成内容时仍可能"自由发挥"------比如把限流提示做成了红色。这是最后一道防线，机器能实时拦截并给出修正建议吗？
我的设计：
- 四层检查机制（四层推演机制） ：AI 输出后，机器执行四层递进校验------语法层（结构完整）→ 语义层（颜色在这个场景下是否合法）→ 安全层（执行阻断）→ 美感层（信息密度）。
- 跨场景拦截 + 修正建议（越域拦截 + 修正建议） ：不是只说"错了"，而是明确告诉 AI："限流场景应该用警告黄，也就是黄色时钟 + 倒计时，不是红色脉冲。"
- A/B 对比验证：同一指令，无规则时 AI 自由发挥（红色），有规则时 AI 按手册生成（黄色），证明约束真的改变了 AI 的行为。
演示环境证明：
- 链路 2（语义分级机制） ：B 组红色误用 vs A 组黄色时钟，差异显著，证明生成期拦截有效
- 链路 5（设计师工作台） ：验收检查清单（Checklist）中，红线项未过则结论为"不通过，必须修改"
- 链路 1（结构化问诊） ：若用户勾选"所有错误都用红色"，系统直接匹配错误状态模式（ERR-001）并标注"视觉校验失败"
【演示环境：生成期实时拦截与修正建议验证报告】
描述： 在演示环境中，执行 A/B 对比实验，验证同一指令在有/无跨场景禁止规则时的 AI 生成结果差异：
- B 组（无规则） ：只给指令，不给规则 → AI 生成红色限流提示 "请求过于频繁" → ❌ 越界：用了"致命红"（status.critical）
- A 组（有规则） ：指令 + 错误状态跨场景禁止规则 → AI 生成黄色时钟 + 倒计时 "请在 42 分钟后重试" → ✓ 合规：用了"警告黄"（status.warning）
四层检查机制拦截过程：
- 语法层：检查输出结构是否完整 → 通过
- 语义层：检查颜色在这个场景下是否合法 → 命中跨场景禁止（"致命红"不可用于观察场景）
- 安全层：执行阻断 → 返回修正建议："替换为警告黄（黄色时钟 + 倒计时）"
- 美感层：因安全层已阻断，跳过
修正建议输出：
消费追踪：错误状态契约（ERR-001）v1.1.0 的 4 个下游消费点（AI 指令前缀 / 数据校验格式 / 检查清单 / 持续集成规则）全部同步，版本号 v1.1.0、最后同步时间戳已记录，消费断裂点 0 个。
推演条件：
需 AI 工程团队接入四层检查机制（四层推演机制），将规矩手册的跨场景禁止规则编译为生成期拦截规则。规则更新与规矩手册版本同步，A/B 实验持续验证约束有效性。
三、它一直在工作吗：运行逻辑
●执行链路： 字典 cross_layer_ban 定义（单一来源）→ 编译期规则树对账 → Lint 期静态检查 → 生成期四层推演------同一规则在三个时刻被三处独立校验，任一失守有下一层兜底。
●版本同步闭环： 字典跨层禁止规则变更（如 Major 版本调整绑定所属域）→ Git Diff 触发重编译 → 编译时对引用方输出影响面报告（哪些契约的域声明受影响）→ 下游 Lint 规则与推演断言同步更新。
●拦截统计与归因：三个时刻的拦截次数统一按模式 ID 与绑定 ID 归因；区分"编译期拦截"（设计侧错误）与"生成期拦截"（AI 侧漂移），分别计入走查覆盖率与契约有效性指标。
●失败判定：字典声明的 cross_layer_ban 未出现在任何一层校验规则中（规则断链）；拦截日志缺失或版本不匹配。
回到开头那条反馈。机器防线就位后，"限流提示被画成致命红"这个踩过的坑，走向完全不同：
| 对比项 | 调整前（真实踩坑场景） | 调整后 |
|---|---|---|
| 发现时机 | 上线前走查（甚至更晚） | 编译期 / Lint 期 / 生成期即时阻断 |
| 发现方式 | 人眼抽查，漏检率高 | 三层独立校验，任一失守有下一层兜底 |
| 反馈内容 | "这个红色好像不对" | 错误码 + 字段路径 + 正确绑定建议 |
| 归因留痕 | 口头同步，无法统计 | 按模式 ID 与绑定 ID 归因，区分设计侧错误与 AI 侧漂移 |
诚实清单：
| 已完成的（设计层） | 需工程团队补齐的（执行层） |
|---|---|
| 三类违规的用例定义与预期结果 | /api/contracts/validate 生产部署与 CI 接入 |
| cross_layer_ban 对账与互斥/层级校验的判定逻辑 | ESLint 规则的批量生成（编译管线格式四） |
| 语义分级器的单点演示（演示环境） | 四层推演机制工程实现（里程碑 M4） |
| A/B 对比的单点验证 | 对抗用例库 ×12 全量构建与自动重跑 |
这不是缺陷，是分工：本篇定义"守住域边界应该测什么、通过标准是什么"，工程团队负责"怎么自动化跑、怎么接入生产环境"。
