在大型软件团队做体验架构期间，我观察到一种系统性失真：设计师在 Figma 中标注了"高危操作需红色描边+二次确认"，但 AI 生成的代码中，删除按钮为蓝色实心样式，文案仅显示"确认"。这不是代码缺陷，而是设计意图在从人脑到机器的过程中，丢失了语义层。
一、AI 压缩了传统 workflow，但语义层尚未被覆盖
传统产品团队的 workflow 通常包含多个翻译环节：
PM 写文档 → 设计师出图 → 前端写代码 → 走查发现不一致 → 再改一遍
每个环节都是一次翻译，每次翻译都有损耗。
当前 AI 工具正在压缩这些翻译环节。PM 可以直接输出原型，设计师可以在真实代码上工作，AI 可以生成可运行页面。形态层（长什么样、用什么组件、怎么写代码）的效率问题，已基本被各类 Design-to-Code 工具覆盖。
但还有一层翻译，当前工具链尚未系统化覆盖：
设计意图 → AI 生成内容
当 AI 用概率生成文案、按钮样式、错误状态时，它理解"这里需要一个按钮"，但不理解"这个按钮按下去会删除用户数据，因此必须是红色描边，必须有二次确认"。
形态层解决"长什么样、怎么写"，语义层解决"意味着什么、不能突破什么"。
当前者被各类工具覆盖时，后者尚未建立系统化的约束机制。
二、形态层 vs 语义层：一张分工图
工具在形态层竞争，语义层是空白。
我通过两年时间验证了一个假设：当界面从"人画"变成"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：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：前端工程 —— AI 返工的 30% 不是修样式，是修语义
以前：
AI 生成一个删除账户弹窗，前端收到的代码中，"删除"按钮为
variant="contained"蓝色，文案为"确认"，无二次确认。修一张图 10 分钟，修 100 张图 ≈ 2 人天。返工率 30%。
现在：
语义错误在生成前被拦截。前端仅接收"通过约束检查"的代码——按钮样式已为
outline_danger，二次确认弹窗已插入。返工率从 30% 降到 5% 以内。
核心数字：
以前前端是 AI 生成内容的修图师，反复修复语义错误。现在前端是语义规则的编写者，将反复修复的问题写成一次性约束，由机器拦截。
语义层先对齐，视觉层自然对齐。
领域 4：设计基础设施 / 研发效能 —— 一套语义层，N 个产品共享
以前：
公司 5 个 AI 产品并行开发，各管各的 Prompt。规范更新后 10 个前端负责人手动同步，遗漏率随产品数指数增长。语义漂移导致的线上问题占 15%。
现在：
设计意图以 YAML 形态存在于 Git 仓库，一次定义，全局生效。5 个产品共享同一套语义层，维护成本从 O(N) 降到 O(1)。语义漂移导致的线上问题趋近于 0。
核心数字：
以前 5 个产品各管各，现在一套语义层全域共享。不治理的代价 > 治理的投入。
四、具体工具对标：不是替代，是叠加
关键洞察：
这些工具在形态层竞争，把设计规范写成代码格式（Schema-As-Code） 在语义层补位。YAML 语义契约可被任何工具消费——约束的不是'怎么写代码'，而是'这个场景下必须表达什么语义、不能突破什么边界'"。
五、我的解法：从"一个组件的语义对齐"开始
我最初试图拉通整个研发环境来解决这个问题，后来发现范围过大。现在将范围收缩到一个组件的语义对齐。
具体做法：
- 选一个最混乱的组件（如告警卡片、删除按钮、错误状态）
- 画出语义断层地图：设计意图 → 自然语言规范 → LLM 输出，标红断裂点
- 写成"设计-开发语义词典"的一个条目：定义这个组件在这个场景下必须表达什么语义、不能突破什么边界
- 用 YAML 形式化：让机器可读、可编译、可校验
这张地图本身就是体验架构设计师的核心产出。
这不需要我会写代码。我作为语义翻译者，比工程师更懂设计意图的语义，比设计师更懂实现的约束。我的产出是设计规范中"可被工程消费"的那一层——让设计意图在跨角色传递时不变形。
六、在线体验
约束显化演示：https://2436041978-ops.github.io/intent-schema-compiler/demo/
- 体验"同义词防火墙"：输入含"严重"的 JSON，看机器怎么拦截
- 体验"四层推演"：语法 → 语义 → 安全 → 美感
语义断层诊断：https://2436041978-ops.github.io/intent-schema-compiler/showcase/
- 对比 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 原生｜广州 / 深圳
