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

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

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

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

三类违规的共同本质：它们单看 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（规矩手册查询）："致命红"的登记信息明确标注"仅限交易场景使用"，与契约中的场景声明相互校验
  

【演示环境：代码检查期代码级语义绑定校验报告】

描述： 在演示环境中，模拟前端代码提交场景，系统执行五项前置校验，任一不过即阻断合入：

推演条件：

需前端工程团队接入代码检查插件（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）

四层检查机制拦截过程：

1. 语法层：检查输出结构是否完整 → 通过
2. 语义层：检查颜色在这个场景下是否合法 → 命中跨场景禁止（"致命红"不可用于观察场景）
3. 安全层：执行阻断 → 返回修正建议："替换为警告黄（黄色时钟 + 倒计时）"
4. 美感层：因安全层已阻断，跳过

修正建议输出：

消费追踪：错误状态契约（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 未出现在任何一层校验规则中（规则断链）；拦截日志缺失或版本不匹配。

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

诚实清单：

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

1920