AI工具正在重塑产品开发的workflow，但语义层的缺失正成为新的挑战。当AI能够自动生成界面元素时，如何确保设计意图准确传递？本文通过四个真实领域的对比案例，揭示了语义漂移带来的隐性成本，并提出了用Schema-As-Code构建语义约束层的创新解决方案，让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 不是替代，是叠加

关键洞察：

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

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

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

具体做法：

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

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

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

六、在线体验

约束显化演示：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 流水线。