前端与AI工程师不是 Schema-As-Code 把设计规范写成代码格式 框架中新发明的岗位。在大多数组织中，这个角色早已存在，变化的不是岗位，是交付物的上游形态。
工程侧的每一次协作革命，都在改写工程师”按什么施工”：
本文要展开的是第三条路：按契约施工。规则不再以”需要你去读的文档”形态存在，而是以”已经挂在你工具链上的机器产物”形态存在。
先给一个预期打理：这个角色篇读起来会比系列里其他篇”薄”。这不是消息单薄，是设计目标，约束的成本被刻意压在上游（快照的采集、契约的编写、评审的确认），消费侧的无感知，是上游工作做对的证据。一条需要你读三遍文档才能遵守的规则，是上游的失败；一条你挂着Schema就自然遵守的规则，才是这套体系的存在理由。
本文只回答一个问题：语义令牌、语义域、约束显化论证过的三层设计，在你的工作面上分别长什么样。你不生产它们，但你每天都在消费它们。
过去你拿到的接口字段是 isError: true，一个布尔值，”多严重”这个维度根本不在数据里。你想分级都没数据，只能自己加字段硬编码，或者按 type=”error” 一个参数打天下。
现在接口字段是 error_severity: “retryable”，语义维度随数据一起到达。你消费的JSON Schema里，这个字段的类型定义不是 boolean，而是枚举：
你的工作没有改变，你的依据改变了。 以前是”设计稿画了红色所以用红色”，现在是”字段说 retryable 所以按 retryable 的映射渲染”。枚举值写错，比如手滑写成 fatal，编译期就被Schema拦下，不需要等走查。拦下的那一刻，报错长这样：
注意这份报错的三要素：违反的是哪条契约的哪个版本、错在哪个字段哪个值、按什么指引修。一份只说”参数错误”的报错会迫使你猜规则的含义，猜测就会出错。报错的及格线和拦截报告是同一条：可追溯。
重点设计详情：《Token层差异》：Design Token管”长什么样”，语义令牌管”意味着什么”。你代码里的枚举值，就是语义令牌的工程形态。
对语义令牌，前端与AI工程师不做翻译，翻译发生在上游（设计师标注、契约编写、评审确认），到你这层已经是确定性的枚举。你的角色只有一条纪律：不绕过枚举。
这两种写法都能跑通。跑通的代价是语义链路在你的代码里断裂：上游规则再优化，到你这层被旁路，消费追踪上的”拦截记录”就变成了”拦截不到”。
绕过枚举省的是两分钟，断的是整条证据链。
当业务出现新场景，字典里没有对应的令牌，比如组织第一次出现”资金冻结”这类状态，现有四级枚举都不贴切，你的动作不是现场造一个 severity: “frozen”，而是提交消费侧反馈：”场景 X 无对应令牌，当前用基础枚举兜底。”
反馈回到评审队列，由上游判断复用、降级还是发起新令牌评审。机器没见过时，人的动作是上报，不是就地立法。 就地发明的枚举值，是这个体系里最危险的一类”善意的绕过”。
某AI对话业务的限流误报事件：接口只下发 isError: true，前端按 type=”error” 渲染红色，使用者看到全红错误条以为体系崩溃，刷新后丢失未发送的长文。
这个案例说明：前端不是表达力不够，是接口就没给你语义数据。契约把布尔值升级为枚举之后，按映射渲染是直线，不用再猜。
案例口径：本案例为推演案例，非组织实测记录。来源是公开业务语义断层诊断中反复出现的失真模式，推演到工程工作流的消费形态。
同一个 <Alert> 组件，在体系故障里是阻断器，在新功能通知里是消息条。过去这个差异只存在于设计稿的标注里，你看不见；现在它存在于类型体系里，编译器看得见：
跨层禁止由机器执行：在 observational 域的组件上引用 status.critical，编译期直接报错，不需要你记住”哪个域不能用什么令牌”，类型体系替你记住。报错的形态：