跨层禁止：机器如何拦截非法语义绑定

本文是 Schema-As-Code 证据链 的"可靠性"站（D 列：验证 + 工具），属于主题行②（语义域）。在前序章节中，阶段一 Guard 结构化诊断 通过 组件语义快照 与 三层判定模型 证明了漂移真实存在；阶段二 Contract 语义契约化 将设计意图写入了 YAML 契约 与 语义字典。但契约写在文件里不等于边界被守住——本文要验证的正是：当 语义域 定义了跨层禁止规则后，机器能否在编译期、Lint 期、生成期三层独立拦截非法语义绑定。

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 个漂移模式 中 组件语义分类与漂移模式匹配 所定义的跨域漂移：

一、验证对象：跨层禁止的三类违规

先把"守住域边界"翻译成可测试的命题。跨层禁止面临三类违规，每一类对应一条可判定的预期结果：

三类违规的共同本质：它们单看 YAML 都"合法"——字段存在、绑定已注册、语法正确——只有对照域边界规则（cross_layer_ban / L1 互斥 / L2 层级）才能判定非法。 这正是域边界必须由机器守护而非人工评审的原因：人工评审看到的是"语法没问题的契约"，机器对照规则树看到的是"越界的引用"。

二、验证设计：三层

2.1 编译期：字典规则树对账——越界引用在入库前能被拦住吗？

问题： 契约引用绑定与覆盖层时，cross_layer_ban 是否被逐条核对？

我的设计：

●规则树对账：契约加载时，将 semantic_domain 与全部引用的绑定编译为内存规则树；逐条核对每个绑定的 cross_layer_ban 列表是否包含契约声明的域，命中即阻断。

●互斥与层级校验：同一 intent_id 作用域内出现两个 L1 声明 → 阻断；L2 声明缺失父层 → 阻断。

●错误返回：统一 { code, message, location } 结构，定位到具体字段路径（如 semantic_tokens.error_severity.retryable.visual_mapping.color_token），并附带正确绑定建议（如"限流提示应使用 status.warning"）。

演示环境证明： 在演示环境中，语义分级器输入"限流提示"场景，输出 retryable 级别（status.warning：黄色时钟 + 倒计时）；手动构造引用 status.critical 的输入，被判定为越域并返回修正建议。域归属校验逻辑在单点成立。

推演条件： 接入生产环境后，由 /api/contracts/validate（POST，只校验不产出）在 CI 中自动执行；对抗用例库需覆盖全部 6 个绑定 × 各自 cross_layer_ban 列表的笛卡尔积（含边界条件），目标拦截率 ≥ 95%。

2.2 Lint 期：代码静态检查——实现层的越界能被拦住吗？

问题： 契约层合法，不等于代码层守法。前端 JSX 里硬编码一个红色，或者组件 color 与契约声明的语义级别不一致，能不能拦住？

我的设计： 编译管线产出的 ESLint 自定义规则，在提交时静态检查（CI 集成）：

演示环境证明： 当前演示环境覆盖契约加载与语义分级（见 2.1）；Lint 规则属编译管线 v1 的产出范围（对应工程里程碑 M3 / M6 的 CI 集成模板），随管线一并落地。

推演条件： 接入生产环境后，npx eslint --rulesdir ./compiled/ci-rules src/ 在 PR 流水线执行，error 级命中即阻断合入；拦截记录按模式 ID 归因入库。

2.3 生成期：四层推演引擎——AI 生成结果中的越界能被拦住吗？

问题： 编译期与 Lint 期守住的是"人写的契约与代码"，AI 生成物（组件树 / 界面描述）在生成过程中越界，能不能拦住？

我的设计： 四层推演引擎逐层校验、逐层短路，跨层禁止由其中两层承担：

配套对抗性测试：用例库中包含"诱导越界"用例——输入"生成一个醒目的限流提示"（诱导 AI 使用致命红），断言"生成结果必须命中跨层禁止拦截，输出 status.warning 映射"。契约或字典变更后全量重跑，用例即回归资产。

演示环境证明： A/B 对比已在演示环境单点验证——同一 Prompt，注入契约编译的 Prompt 前缀组（A 组）生成的限流提示为黄色时钟 + 倒计时，未注入组（B 组）出现红色误用；"约束真的改变了 AI 的行为"闭环成立。

推演条件： 接入生产环境后，对抗用例库扩展至 6 模式 × 每模式 2 用例（共 12 例）并覆盖全部 cross_layer_ban 组合；A/B 语义合规率差值纳入收益度量，按返工成本模型推演并标注推演口径。

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

●执行链路：字典 cross_layer_ban 定义（单一来源）→ 编译期规则树对账 → Lint 期静态检查 → 生成期四层推演——同一规则在三个时刻被三处独立校验，任一失守有下一层兜底。

●版本同步闭环：字典跨层禁止规则变更（如 Major 版本调整绑定所属域）→ Git Diff 触发重编译 → 编译时对引用方输出影响面报告（哪些契约的域声明受影响）→ 下游 Lint 规则与推演断言同步更新。

●拦截统计与归因：三个时刻的拦截次数统一按模式 ID 与绑定 ID 归因；区分"编译期拦截"（设计侧错误）与"生成期拦截"（AI 侧漂移），分别计入走查覆盖率与契约有效性指标。

●失败判定：字典声明的 cross_layer_ban 未出现在任何一层校验规则中（规则断链）；拦截日志缺失或版本不匹配。

回到开头那条反馈。机器防线就位后，"限流提示被画成致命红"这个踩过的坑，走向完全不同：

诚实清单：

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

1920