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


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

传统产品团队的 workflow 通常包含多个翻译环节：
> PM 写文档 → 设计师出图 → 前端写代码 → 走查发现不一致 → 再改一遍

每个环节都是一次翻译，每次翻译都有损耗。
当前 AI 工具正在压缩这些翻译环节。PM 可以直接输出原型，设计师可以在真实代码上工作，AI 可以生成可运行页面。**形态层**（长什么样、用什么组件、怎么写代码）的效率问题，已基本被各类 Design-to-Code 工具覆盖。
**但还有一层翻译，当前工具链尚未系统化覆盖：**
> **设计意图 → AI 生成内容**

当 AI 用概率生成文案、按钮样式、错误状态时，它理解"这里需要一个按钮"，但不理解"这个按钮按下去会删除用户数据，因此必须是红色描边，必须有二次确认"。
**形态层解决"长什么样、怎么写"，语义层解决"意味着什么、不能突破什么"。**
当前者被各类工具覆盖时，后者尚未建立系统化的约束机制。


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

![image](https://developer.qcloudimg.com/http-save/yehe-12505371/eef085d23290e38dd82d4d76ebc1bfca.png)
工具在形态层竞争，语义层是空白。

我通过两年时间验证了一个假设：**当界面从"人画"变成"AI 生成"，语义层比视觉层更容易产生漂移。**
传统设计流程中，语义是"隐性共识"——设计师和前端通过面对面沟通约定"这个场景下用 Critical 不用严重"。但 AI 不接收这些口头约定，它从训练数据中进行概率推断，而推断结果是随机的。
**这种漂移的代价，视觉走查通常无法发现。** 一个按钮颜色正确，但语义错误（将"删除账户"做成普通按钮），用户误触后产生不可逆后果。JSON 结构正确，但字段值错误（将 Critical 写成严重），可能导致运维响应延迟。


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

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

**以前：**
> 规范中增加一条"告警卡片必须使用 Critical 不能用严重"。DesignOps 需同步 10 个前端负责人，组织 3 场对齐会，2 周后走查发现 3 个产品的 AI 生成内容未更新。同步一次规范 ≈ 2 人周。
**现在：**
> 规范以 YAML 形式写入 Git 仓库。Diff 自动触发影响面分析，下游所有 Prompt 模板和组件约束自动重编译。同步一次规范 ≈ 0.5 人天。
**核心数字：**
> 以前人工审 100 张图，依赖人眼逐张检查。现在机器推演覆盖率可达 100%，人工仅处理 BLOCK 事件。

![image](https://developer.qcloudimg.com/http-save/yehe-12505371/807533830c385374106b370732df869f.png)
规则即代码，变更可追溯。


----
### 领域 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 生成前先过场景匹配。

![image](https://developer.qcloudimg.com/http-save/yehe-12505371/42f28ca15c6a796eda17f723df5b5018.png)
机器能查清单，人眼查不过来。


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

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

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

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

![image](https://developer.qcloudimg.com/http-save/yehe-12505371/77d0cd3de25721909fd1d96be67db49c.png)
语义层先对齐，视觉层自然对齐。


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

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

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

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


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

![_Users_weiwen_Downloads_semantic_constraint_protocol.html.png](https://developer.qcloudimg.com/http-save/yehe-12505371/a3c8b76554ee29d048f29b2fba4417bc.png)
​![多维表一：产品:工具类型 × 层级定位 × 语义盲区 × 语义约束协议叠加方式.png](https://developer.qcloudimg.com/http-save/yehe-12505371/5b09c6c027af9f0d5a89df64a685948d.png)
![多维表二：语义约束协议叠加方式 × 领域消费方（价值落地矩阵）.png](https://developer.qcloudimg.com/http-save/yehe-12505371/0173b6030c473d9920080cfda1ead0d3.png)


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

我最初试图拉通整个研发环境来解决这个问题，后来发现范围过大。现在将范围收缩到**一个组件的语义对齐**。
具体做法：
1. **选一个最混乱的组件**（如告警卡片、删除按钮、错误状态）
2. **画出语义断层地图**：设计意图 → 自然语言规范 → LLM 输出，标红断裂点
3. **写成"设计-开发语义词典"的一个条目**：定义这个组件在这个场景下必须表达什么语义、不能突破什么边界
4. **用 YAML 形式化**：让机器可读、可编译、可校验

![image](https://developer.qcloudimg.com/http-save/yehe-12505371/999a914ccf3d65b3a8dddeb50b5d4412.png)
这张地图本身就是体验架构设计师的核心产出。

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


----
## 六、在线体验

![image](https://developer.qcloudimg.com/http-save/yehe-12505371/203977bed3793c8c3b764ada07034d19.png)
**约束显化演示**
- 体验"同义词防火墙"：输入含"严重"的 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 原生｜广州 / 深圳
:::

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

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

本文提出“语义层”概念，指出AI生成界面时虽解决了形态层（视觉/代码）效率问题，却严重丢失设计意图的语义——如将“删除按钮”误生成蓝色实心+单“确认”。作者主张用YAML定义可编译、可校验的“意图协议”，在AI生成前强制约束语义边界，实现设计-开发语义对齐。

人工智能

前端

架构设计

AI时代设计意图传递面临语义断层问题，传统设计规范在AI生成内容时出现漂移。通过建立机器可读的语义层约束，将设计意图转化为YAML协议，实现从"人画"到"AI生成"的可靠转换。关键解决告警卡片、删除按钮等组件的语义对齐，使设计规范在跨角色传递时不变形，降低30%返工率。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

当 AI 生成界面时，谁在守住设计意图？-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐