当 AI 生成界面时，谁在守住设计意图？

在大型软件团队做体验架构期间，我观察到一种系统性失真：设计师在 Figma 中标注了"高危操作需红色描边+二次确认"，但 AI 生成的代码中，删除按钮为蓝色实心样式，文案仅显示"确认"。这不是代码缺陷，而是设计意图在从人脑到机器的过程中，丢失了语义层。

一、AI 压缩了传统 workflow，但语义层尚未被覆盖

传统产品团队的 workflow 通常包含多个翻译环节：

PM 写文档 → 设计师出图 → 前端写代码 → 走查发现不一致 → 再改一遍

每个环节都是一次翻译，每次翻译都有损耗。

当前 AI 工具正在压缩这些翻译环节。PM 可以直接输出原型，设计师可以在真实代码上工作，AI 可以生成可运行页面。形态层（长什么样、用什么组件、怎么写代码）的效率问题，已基本被各类 Design-to-Code 工具覆盖。

但还有一层翻译，当前工具链尚未系统化覆盖：

设计意图 → AI 生成内容

当 AI 用概率生成文案、按钮样式、错误状态时，它理解"这里需要一个按钮"，但不理解"这个按钮按下去会删除用户数据，因此必须是红色描边，必须有二次确认"。

形态层解决"长什么样、怎么写"，语义层解决"意味着什么、不能突破什么"。

当前者被各类工具覆盖时，后者尚未建立系统化的约束机制。

二、形态层 vs 语义层：一张分工图

*图1：形态层-语义层分工示意图工具在形态层竞争，语义层是空白。

我通过两年时间验证了一个假设：当界面从"人画"变成"AI 生成"，语义层比视觉层更容易产生漂移。

传统设计流程中，语义是"隐性共识"------设计师和前端通过面对面沟通约定"这个场景下用 Critical 不用严重"。但 AI 不接收这些口头约定，它从训练数据中进行概率推断，而推断结果是随机的。

这种漂移的代价，视觉走查通常无法发现。 一个按钮颜色正确，但语义错误（将"删除账户"做成普通按钮），用户误触后产生不可逆后果。JSON 结构正确，但字段值错误（将 Critical 写成严重），可能导致运维响应延迟。

三、四个领域的"前后对比"：不讲概念，只讲成本

领域 1：DesignOps ------ 规范同步从人工分发到代码级编译

以前：

规范中增加一条"告警卡片必须使用 Critical 不能用严重"。DesignOps 需同步 10 个前端负责人，组织 3 场对齐会，2 周后走查发现 3 个产品的 AI 生成内容未更新。同步一次规范 ≈ 2 人周。

现在：

规范以 YAML 形式写入 Git 仓库。Diff 自动触发影响面分析，下游所有 Prompt 模板和组件约束自动重编译。同步一次规范 ≈ 0.5 人天。

核心数字：

以前人工审 100 张图，依赖人眼逐张检查。现在机器推演覆盖率可达 100%，人工仅处理 BLOCK 事件。

* $图2：YAML规范变更截图$ 规则即代码，变更可追溯。

领域 2：Design System ------ 从视觉字典到语义层

以前：

Design Token 管理了颜色、字体、间距。但 AI 将 status.critical 用于提示场景，将"删除"按钮做成蓝色实心。50 个产品 × 500 页面人工走查，覆盖率 20%，漏掉的语义漂移上线后产生用户投诉。

现在：

Token 之上叠加语义层。status.critical 携带 semantic_domain: observational + llm_constraints: ["禁止在提示场景使用"]。AI 生成前自动匹配场景语义，走查覆盖率从 20% 提升到 100%。

核心数字：

以前 Design Token 是视觉字典，AI 查字典知道用什么颜色，但不知道什么场景下不该用。现在 Token 是语义层的一部分，AI 生成前先过场景匹配。

* $图3：同义词防火墙拦截DEMO$ 机器能查清单，人眼查不过来。

领域 3：前端工程 ------ AI 返工的 30% 不是修样式，是修语义

以前：

AI 生成一个删除账户弹窗，前端收到的代码中，"删除"按钮为 variant="contained" 蓝色，文案为"确认"，无二次确认。修一张图 10 分钟，修 100 张图 ≈ 2 人天。返工率 30%。

现在：

语义错误在生成前被拦截。前端仅接收"通过约束检查"的代码------按钮样式已为 outline_danger，二次确认弹窗已插入。返工率从 30% 降到 5% 以内。

核心数字：

以前前端是 AI 生成内容的修图师，反复修复语义错误。现在前端是语义规则的编写者，将反复修复的问题写成一次性约束，由机器拦截。

* $图4：高危操作语义约束对比$ 语义层先对齐，视觉层自然对齐。

领域 4：设计基础设施 / 研发效能 ------ 一套语义层，N 个产品共享

以前：

公司 5 个 AI 产品并行开发，各管各的 Prompt。规范更新后 10 个前端负责人手动同步，遗漏率随产品数指数增长。语义漂移导致的线上问题占 15%。

现在：

设计意图以 YAML 形态存在于 Git 仓库，一次定义，全局生效。5 个产品共享同一套语义层，维护成本从 O(N) 降到 O(1)。语义漂移导致的线上问题趋近于 0。

核心数字：

以前 5 个产品各管各，现在一套语义层全域共享。不治理的代价 > 治理的投入。

四、具体工具对标：Schema-As-Code 不是替代，是叠加

* $图5：工具对标矩阵图$

工具	解决什么（形态层）	不解决什么（语义层）	Schema-As-Code 怎么叠加
DevUI HMC	从截图到符合组件库的 Vue 代码	AI 把"Critical"写成"严重"	YAML 约束编译进 HMC 的 Prompt 前缀
v0 / Framer AI	从自然语言到可交互原型	高危操作按钮做成普通样式	YAML 约束作为生成前的语义校验
Claude Code / Copilot	从自然语言到生产级代码	删除按钮遗漏二次确认	YAML 约束注入 Prompt 上下文
DESIGN.md	视觉规范的机器可读化	语义规范的场景约束	消费 Semantic Token，叠加语义层
Figma MCP	历史设计资产的上下文检索	AI 生成时偏离历史意图	YAML 约束作为 Figma 插件的校验规则
LoongSuite / LangSmith	运行时语义漂移观测	生成前的语义预防	设计时约束 + 运行时观测 = 双轨闭环

关键洞察：

这些工具在形态层竞争，Schema-As-Code 在语义层补位。YAML 语义契约可被任何工具消费------约束的不是"怎么写代码"，而是"这个场景下不能做什么"。

五、我的解法：从"一个组件的语义对齐"开始

我最初试图拉通整个研发环境来解决这个问题，后来发现范围过大。现在将范围收缩到一个组件的语义对齐。

具体做法：

选一个最混乱的组件（如告警卡片、删除按钮、错误状态）
画出语义断层地图：设计意图 → 自然语言规范 → LLM 输出，标红断裂点
写成"设计-开发语义词典"的一个条目：定义这个组件在这个场景下必须表达什么语义、不能突破什么边界
用 YAML 形式化：让机器可读、可编译、可校验

* $图6：语义断层地图$ 这张地图本身就是体验架构设计师的核心产出。

这不需要我会写代码。我作为语义翻译者，比工程师更懂设计意图的语义，比设计师更懂实现的约束。我的产出是设计规范中"可被工程消费"的那一层------让设计意图在跨角色传递时不变形。

六、在线体验

约束显化演示：

体验"同义词防火墙"：输入含"严重"的 JSON，看机器怎么拦截
体验"四层推演"：语法 → 语义 → 安全 → 美感

语义断层诊断：

对比 ChatGPT 四种错误状态的语义混乱 vs 语义分级后的明确状态

七、总结

AI 正在压缩 PM→设计师→Dev 之间的翻译环节，这是当前工具链的主流方向。但还有一层翻译尚未被系统化覆盖：设计意图 → AI 生成内容。

Schema-As-Code 不是另一个 Design-to-Code 工具，它是所有 Design-to-Code 工具的上游约束层。它让 AI 在生成内容之前，先知道：

这个场景下不能说什么词
这个按钮按下去会有什么后果
这个错误状态代表什么级别的严重性

当语义层先对齐，视觉层自然会对齐。

Gap 期局限性声明

本文所述"意图协议"目前处于架构推演与最小可行原型阶段。具体的协议模板、YAML 规范与编译逻辑将在下一篇中完整展开；当前校验引擎为逻辑定义（伪代码），尚未接入生产级 LLM API 或 CI 流水线。

关于作者

魏雯，体验架构设计师。

专注于：AI 界面的语义治理。解决的核心问题：让 LLM 生成的界面不偏离设计规范。 10+ 年互联网设计经验。设计系统 / 体验工程 / AI 原生｜广州 / 深圳