当设计规范变成机器可读的契约，前端工程师的工作方式正在被重构。本文深入解析语义令牌、语义域与约束显化三层设计如何落地到日常开发：从枚举值替代布尔值、类型系统拦截非法Props，到CI流水线的可追溯阻断。这不是岗位的消失，而是交付物上游形态的进化——规则不再靠读文档，而是挂在你工具链上的机器产物。

开篇：这个角色从哪来

前端与AI工程师不是 Schema-As-Code 把设计规范写成代码格式 框架中新发明的岗位。在大多数组织中，这个角色早已存在，变化的不是岗位，是交付物的上游形态。

工程侧的每一次协作革命，都在改写工程师”按什么施工”：

• 设计稿时代，按图施工，意图靠猜，设计稿只给像素，”这个红是多严重的红”靠工程师读空气
• 接口文档时代，按字段施工，语义靠枚举，但 isError: true 这样的布尔值把”多严重”整个维度压没了
• AI生成时代，按提示词生成，约束靠运气，Prompt里写了”不要用红色”，模型更新一次，约束失效一次

本文要展开的是第三条路：按契约施工。规则不再以”需要你去读的文档”形态存在，而是以”已经挂在你工具链上的机器产物”形态存在。

先给一个预期管理：这个角色篇读起来会比系列里其他篇”薄”。这不是内容单薄，是设计目标，约束的成本被刻意压在上游（快照的采集、契约的编写、评审的确认），消费侧的无感知，是上游工作做对的证据。一条需要你读三遍文档才能遵守的规则，是上游的失败；一条你挂着Schema就自然遵守的规则，才是这套体系的存在理由。

本文只回答一个问题：语义令牌、语义域、约束显化论证过的三层设计，在你的工作面上分别长什么样。你不生产它们，但你每天都在消费它们。

一、语义令牌：你代码里的枚举值

1.1 角色消费场景：从布尔值到枚举值

过去你拿到的接口字段是 isError: true，一个布尔值，”多严重”这个维度根本不在数据里。你想分级都没数据，只能自己加字段硬编码，或者按 type=”error” 一个参数打天下。

现在接口字段是 error_severity: “retryable”，语义维度随数据一起到达。你消费的JSON Schema里，这个字段的类型定义不是 boolean，而是枚举：

你的工作没有改变，你的依据改变了。 以前是”设计稿画了红色所以用红色”，现在是”字段说 retryable 所以按 retryable 的映射渲染”。枚举值写错，比如手滑写成 fatal，编译期就被Schema拦下，不需要等走查。拦下的那一刻，报错长这样：

注意这份报错的三要素：违反的是哪条契约的哪个版本、错在哪个字段哪个值、按什么指引修。一份只说”参数错误”的报错会迫使你猜规则的含义，猜测就会出错。报错的及格线和拦截报告是同一条：可追溯。

关键设计详情：《Token层差异》：Design Token管”长什么样”，语义令牌管”意味着什么”。你代码里的枚举值，就是语义令牌的工程形态。

1.2 翻译能力：你没有翻译动作，只有一条纪律

对语义令牌，前端与AI工程师不做翻译，翻译发生在上游（设计师标注、契约编写、评审确认），到你这层已经是确定性的枚举。你的角色只有一条纪律：不绕过枚举。

不允许的两种写法：

1. 嫌 Schema 麻烦，把字段类型改回 string，校验失效
2. 在组件里写死色值 #EF4444，不引用 color_token，映射链路断裂

这两种写法都能跑通。跑通的代价是语义链路在你的代码里断裂：上游规则再完善，到你这层被旁路，消费追踪上的”拦截记录”就变成了”拦截不到”。

绕过枚举省的是两分钟，断的是整条证据链。

1.3 关键决策点：机器没见过时

当业务出现新场景，字典里没有对应的令牌，比如组织第一次出现”资金冻结”这类状态，现有四级枚举都不贴切，你的动作不是现场造一个 severity: “frozen”，而是提交消费侧反馈：”场景 X 无对应令牌，当前用基础枚举兜底。”

反馈回到评审队列，由上游判断复用、降级还是发起新令牌评审。机器没见过时，人的动作是上报，不是就地立法。 就地发明的枚举值，是这个体系里最危险的一类”善意的绕过”。

1.4 布尔值压掉语义维度

某AI对话产品的限流误报事件：接口只下发 isError: true，前端按 type=”error” 渲染红色，用户看到全红错误条以为系统崩溃，刷新后丢失未发送的长文。

问题诊断：

• 语义层：限流是 retryable（等待即可），界面表达成了 fatal（必须抢救）
• 根因：语义在接口定义时就被压缩成布尔值，前端拿到的数据里根本没有”级别”
• 修复：接口字段按契约升级为 error_severity 枚举，前端按令牌映射渲染，retryable 渲染为黄色时钟加倒计时

这个案例说明：前端不是表达力不够，是接口就没给你语义数据。契约把布尔值升级为枚举之后，按映射渲染是直线，不用再猜。

案例口径：本案例为推演案例，非组织实测记录。来源是公开产品语义断层诊断中反复出现的失真模式，推演到工程工作流的消费形态。

1.5 枚举校验的持续生效

二、语义域：同一个组件在不同场景的合法Props

1.1 角色消费场景：域约束写进类型系统

同一个 <Alert> 组件，在系统故障里是阻断器，在新功能通知里是信息条。过去这个差异只存在于设计稿的标注里，你看不见；现在它存在于类型系统里，编译器看得见：

跨层禁止由机器执行：在 observational 域的组件上引用 status.critical，编译期直接报错，不需要你记住”哪个域不能用什么令牌”，类型系统替你记住。报错的形态：

这条报错的价值不在”拦住了这一次”，而在争议可裁决：验收时如果有人说”这里用红色更有警示效果”，争议不再是感觉对感觉，而是”违反了哪条绑定”，可引用、可定位、可裁决。

关键设计详情：《语义域：组件是空容器，语义由场景定义》；《跨层禁止：机器如何拦截非法语义绑定》

1.2 翻译能力：把”这个场景”翻译成”这个Props类型”

你依然不做翻译。域声明由设计师标注、契约定义，到你这层已经是两组不同的Props类型。你的动作是按场景选类型，而不是按视觉选组件。 选错类型，编译器会告诉你；类型不存在，按”机器没见过时”的纪律上报。

1.3 关键决策点：机器发信号时

跨层禁止的拦截报错出现在你本地时，比如在 observational 域组件上引用了高危令牌，两种可能：

• 你绑错了：修正域声明或令牌引用，结束
• 规则错了：这个绑定在该场景下业务上合理，但规则没覆盖，提交消费侧反馈，标注”疑似误报”，附场景说明

判断不了是哪种，默认按第一种处理；处理不了，按第二种上报。拦截报告的条款编号会告诉你该去哪查。

1.4 真的发生过吗：域绑定错误的代价

某团队开发后台管理系统时，将”批量删除用户”按钮声明为 overlay=”navigational”，绑定 action.primary。理由是”它是页面里的一个操作”。

问题诊断：

• 语义层：批量删除是数据销毁操作，属于 transactional 域，应绑定 action.destructive
• 后果：AI生成代码时按钮样式为蓝色实心，缺少二次确认，用户误触后批量删除数据
• 修复：纠正域声明为 transactional + action.destructive，类型系统从此拦住同类错误

这个案例说明：类型系统只能拦住”已声明的错”。域声明本身是上游评审的对象，你的责任是选对类型，域定义对不对，有专门的评审节点在管。

案例口径：推演案例，同上。

三、约束显化：提交时的那一次拦截

1.1 角色消费场景：CI拦截报告长什么样

约束显化在你工作面上的形态，是CI流水线里的一次阻断。一次合规的拦截报告，必须包含三样东西：

三条消费约定中的”可追溯阻断”，就是这份报告的及格线：阻断必须能追溯到具体契约条款编号，修复指引必须指向契约定义。一份只说”语义校验失败”的报告，会迫使你猜规则的含义，猜测就会出错。报告不合格，是编译管线的问题，不是你的问题，可以反馈。

关键设计详情：《编译前置校验 显式规则的5项机器安检》

1.2 翻译能力：拦截报告就是你的翻译件

你不需要读契约原文，拦截报告就是契约在你这个场景下的即时翻译：违反了哪条、在哪个文件哪一行、按什么指引修。 你的动作是按指引修，不猜。

1.3 关键决策点：机器发信号时，拦截误报怎么办

CI拦住了你，但你判断这是误报，比如边界场景合法、但规则描述没覆盖。你的动作不是绕过拦截，也不是强行降级规则，而是提交消费侧反馈并标注误报。

回流的落点是评审队列，但修订的对象从来不是评审标准本身，是规则定义是否完整、约束是否可执行、场景是否被覆盖、分级是否正确。合法的例外通过显式豁免清单处理，不通过放松规则处理。

误报不是拦截系统的失败，是规则的迭代输入。你提交的每一次误报标注，都在校准下一版契约。

1.4 拦截的纪律

四、同一约束的两层落地：引导与拦截的分工

前三章展开的三层设计，枚举值、类型约束、拦截报告，全部是确定执行：机器校验，违例必拦。但你的工作面上还有一类约束，执行性质完全不同。

一个来自行业的对照样本：Figma的增长产品经理Ezra Mechaber把自己九年的领域经验外化成了一份 CLAUDE.md 和31个 SKILL.md，全公司的产品经理都在用，其中写了”删除按钮必须二次确认”这类约束。 这类约束的执行方式是模型自觉：模型大概率遵守，但”大概率”不是”一定”，它可能第三周就忘了，而没有任何机制会发现它忘了。这个体系的维护者自己承认，他不清楚这套定制配置比裸agent好多少，约束有没有被遵守，没有任何读数可以回答。

这是这类载体的属性：文档级指令载体管”怎么生成得更好”，是概率执行；Schema与CI管”什么不能生成”，是确定执行。 同一约束在两层各落一次，分工是：

• 写在 CLAUDE.md 里，生成时往正确的方向偏，漏网无感
• 编译进Schema与CI，跑偏了必被拦，拦下附条款定位

你工作面上的三层设计（枚举、类型、拦截报告）全部属于后者。属于你的分层工作只有一件：涉及契约已覆盖的语义边界，走产物不走散文，不止你自己不按”经验”写，你团队的 AGENTS.md 里也不要再手写”错误提示别全用红”，改挂引用块。手写散文约束不是错，错的是把它当成约束已经落地。

口径提醒：上述行业案例为播客自述样本，未经独立验证；引用它说明的是载体的执行性质，不是某家公司做得不好。事实上，那套体系在”怎么做好”的层面支撑了几十人每天使用，这正是两层分工各自成立的证据。

结语：三层设计，三种工程形态

本篇展开了语义令牌、语义域、约束显化在前端与AI工程师工作面上的投影：

• 语义令牌 → 你代码里的枚举值，纪律只有一条：不绕过
• 语义域 → 你类型系统里的Props约束，动作只有一个：按场景选类型
• 约束显化 → 你提交时的CI拦截报告，及格线只有一条：报告可追溯

三层设计你都不生产，但你都是它们的终端执行面，上游所有角色的工作，最终要靠你”不绕过”来兑现。第四章补上了同一约束的两层落地：载体层的概率引导值得用，但确定性的拦截永远要有人接住漏网之鱼，在你的工作面上，这个人是机器。

这些产物从哪来、以什么形态到达你、版本怎么保持新鲜，我会在下一篇展开，包括一件为AI编码工具准备的新交付物：契约引用块。