AI生成界面时，设计意图为何频频偏离？问题根源在于缺少语义约束层。本文提出Schema-As-Code解决方案，通过YAML契约文件构建三阶段流水线，为AI工具建立上游约束机制。从组件语义快照到模式诊断，从规则文件编译到验证闭环，这套系统正在重新定义AI时代的设计规范管理方式。
当 AI 生成界面时，设计意图在偏离。不是 AI 故意做错，而是系统缺少一层”语义约束”。
本文提出 Schema-As-Code：一套让设计师用 YAML 契约锁住设计意图的三阶段流水线。不是替代任何工具，是所有 AI 工具的上游约束。
本文是 Schema-As-Code 第一阶段 《组件语义快照与模式诊断：AI 生成界面的第一道检查》 的方法论总纲与开源仓库发布。
一、问题：AI 生成界面时谁在守住设计意图？
2024-2025 年，设计团队全面进入AI辅助生产时代：
- v0 / Framer AI 用一句话生成可交互原型
- Claude Code / Cursor 用自然语言写前端代码
- DevUI HMC / DESIGN.md 让AI按组件库规范输出代码
这些工具都在解决”形态层“的问题，界面长什么样、用什么组件、怎么写代码。
但没有人解决”语义层“的问题，这个界面在这个场景下表达了什么意思、不能突破什么边界。
结果是：
- AI 生成”删除账户”按钮，给了个蓝色实心按钮，用户一点，账户没了
- AI 生成告警卡片，把 Critical 写成 “严重”，值班员觉得不严重，延迟响应，系统挂了
- 设计规范更新了”错误状态分四级”，发在文档里，前端没看，AI更没看，还是按老样子生成
- 一个产品500个页面，人工走查100个就累了，剩下400个的语义错误上线后才被用户投诉
这不是某个产品的Bug，而是整个行业在AI生成界面时代共同面临的结构性断层。
二、把设计规范写成代码格式的规则文件是所有工具的上游约束
我提出 Schema-As-Code（把设计规范写成代码格式的规则文件），不是要做另一个 Design-to-Code 工具，而是要建立一层上游约束。
┌─────────────────────────────────────────┐
│ 语义层：Schema-As-Code（你） │ ← 你在这里
│ “这个场景下必须表达什么语义、不能突破什么边界” │
└─────────────────────────────────────────┘
↓ 编译为 Prompt 前缀 / 校验规则
┌─────────────────────────────────────────┐
│ 形态层：v0 / Claude Code / DevUI HMC │ ← 现有工具
│ “长什么样、用什么组件、怎么写代码” │
└─────────────────────────────────────────┘
关键洞察：
- v0 解决的是“AI能不能生成界面”
- Claude Code 解决的是“AI能不能写代码”
- DevUI HMC 解决的是“代码是否符合组件库规范”
- Schema-As-Code 解决的是”AI生成的内容是否偏离了设计意图”
这四层缺一不可，且互不替代。
三、三阶段流水线：从发现问题到证明有效
Schema-As-Code 不是一套理论，是一条可执行的三阶段流水线。
【三阶段流水线图】
阶段一：Guard —— 组件语义快照与模式诊断
详细设计方案见上一篇《从语义快照到结构化诊断：三层判定模型与模式匹配机制》
回答的问题：“我的产品有没有语义断层？”
我建立了一套”结构化问诊”系统：
- 第一层：这是什么组件类型？（错误状态 / 过程状态 / 边界动作 / 操作按钮 / 状态提示）
- 第二层：用户的核心困惑是什么？（不知道多严重 / 不知道在干什么 / 不知道权利还在不在）
- 第三层：当前界面的视觉表达有什么特征？（全部红色 / 文案模糊 / 缺少行动指引）
【结构化问诊界面截图】
目前已验证 5 个通用模式：
【模式库卡片截图】
阶段一产出： 诊断报告 + 同类产品证据截图 + 根因分析
阶段二：Contract —— 设计师作为”语义翻译者”
回答的问题：“我怎么用规则锁住设计意图？”（本文重点预告，完整内容见下篇）
当设计师发现语义断层后，传统做法是：
- 写一份设计规范文档（PDF/语雀）
- @ 全员通知
- 2 周后走查发现3个产品没改对
Schema-As-Code 的做法是：
- 把设计意图翻译成文本格式的规则文件（YAML）
- 放在Git仓库里，变更自动同步
- AI工具自动读取，机器走查覆盖率100%
规则文件示例（ERR-001）：
intent_id: “ERR-001”
semantic_domain: “observational”
semantic_tokens:
error_severity:
fatal:
description: “系统级故障，对话上下文可能丢失”
visual_mapping:
color_token: “status.critical” # 语义令牌：定义这个颜色代表”致命状态”
motion_token: “pulse.red.urgent” # 语义令牌：定义这个动效代表”紧急”
icon_token: “alert.octagon” # 语义令牌：定义这个图标代表”危险”
user_action:
– label: “刷新页面”
action: “refresh”
– label: “导出历史”
action: “export_history”
llm_constraints:
– “必须明确告知用户对话上下文可能已丢失”
– “禁止仅显示’出错了’等模糊文案”
transient:
description: “网络抖动，系统可自动恢复”
visual_mapping:
color_token: “status.neutral” # 语义令牌：定义这个颜色代表”中性状态”
motion_token: “spinner” # 语义令牌：定义这个动效代表”加载中”
icon_token: “loader” # 语义令牌：定义这个图标代表”等待”
user_action:
– label: “等待自动恢复”
action: “wait”
llm_constraints:
– “禁止红色背景（避免情绪过载）”
– “必须显示自动重试进度”
retryable:
description: “请求频率已达上限”
visual_mapping:
color_token: “status.warning” # 语义令牌：定义这个颜色代表”警告状态”
motion_token: “none” # 语义令牌：定义这个动效代表”静态”
icon_token: “clock” # 语义令牌：定义这个图标代表”限时”
user_action:
– label: “等待倒计时”
action: “wait_countdown”
– label: “升级套餐”
action: “upgrade”
llm_constraints:
– “必须显示剩余等待时间”
– “必须提供升级/扩容路径”
degraded:
description: “部分功能可用，可继续生成”
visual_mapping:
color_token: “status.info” # 语义令牌：定义这个颜色代表”信息状态”
motion_token: “none” # 语义令牌：定义这个动效代表”静态”
icon_token: “info.circle” # 语义令牌：定义这个图标代表”提示”
user_action:
– label: “继续生成”
action: “continue”
– label: “简化问题重试”
action: “retry_simplified”
status.critical 是语义令牌（Semantic Token），定义”这个颜色在这个场景下代表致命状态”。完整的语义令牌体系（status.* / phase.* / boundary.* / action.*）见契约书写规范。
关键设计： 一份规则文件，编译为四种消费格式：
- 规则文件本体：供规范管理人员版本管理（放在Git里）
- AI 指令前缀：供AI编程工具（Claude Code / Cursor）在生成代码前读取
- 走查清单：供设计师人工复核时逐项打勾
- 自动校验规则：供CI流水线自动拦截不合规的生成内容
【契约库界面截图】
阶段二产出： 规则文件 + 多格式编译输出
阶段三：Verify —— 验证闭环与工具落地
回答的问题：“我怎么证明规则真的防住了语义漂移？”
三层验证工具：
【语义分级器界面截图】
【A/B 对比截图】
阶段三产出： 验证报告 + 返工率数据 + 可复用的验证工具
四、设计师不需要写代码，但需要写”规矩”
这是被问得最多的问题：”我不会写代码，能参与这个方法吗？”
答案是：不仅能，而且正因为不会写代码，你才是最适合写规则文件的人。
为什么？
会写代码的人，看到问题后会直接去写脚本、搭平台，结果卷进了工程实现层，和 DevUI HMC / v0 竞争。
不会写代码的人，被迫站在”意图层”，只关心”这个场景下必须表达什么语义、不能突破什么边界”，而不关心”用什么框架实现”。
规则文件的本质是“设计意图的翻译”，不是”代码实现”。
intent_id: “ACT-001”
semantic_domain: “transactional”
semantic_tokens:
destructive_action:
description: “不可逆的数据销毁操作”
# 语义令牌：定义视觉元素的语义含义
visual_mapping:
color_token: “status.critical” # 语义令牌：定义这个颜色代表”致命状态”
button_style: “outline_danger” # 语义令牌：定义这个按钮样式代表”危险空心描边”
icon_token: “alert.triangle” # 语义令牌：定义这个图标代表”警告”
# 不可变边界：绝对不能突破的红线
immutable_boundaries:
– boundary_type: “safety”
rule: “禁止直接执行删除操作而不显示二次确认”
violation_action: “block”
– boundary_type: “safety”
rule: “禁止将删除按钮设计为普通主按钮样式”
violation_action: “block”
# LLM 约束：AI 生成内容时必须遵守的规则
llm_constraints:
– “必须包含二次确认弹窗”
– “文案必须明确说明’此操作不可恢复'”
– “必须提供取消选项，且视觉权重不低于确认按钮”
– “禁止在二次确认弹窗中使用’确认’等模糊文案，必须使用’确认删除'”
# 用户行动：与后果级别匹配的操作
user_action:
primary:
label: “确认删除账户”
action: “confirm_delete”
requires_input: true # 要求输入账户名确认
input_field: “account_name”
secondary:
label: “取消”
action: “cancel”
visual_weight: “equal” # 视觉权重与主按钮同等
这段规则文件里：
- 没有 CSS 类名
- 没有 React/Vue 组件名
- 没有文件路径
只有设计师的意图：“删除按钮必须是红色空心，必须有二次确认。”
前端工程师拿到这份规则，可以翻译成 Tailwind、Material UI、DevUI 或任何框架。规矩是跨框架的。
五、组织经济价值：一个设计师解决跨域协调问题
Schema-As-Code 的价值不止于技术，更在于组织经济。
传统工作流的隐性成本
总成本 = 设计意图在跨角色传递中不断失真，反复修复。
Schema-As-Code 工作流的经济价值
总收益 = 设计意图从“人传人的方言”变成“机器可读的普通话”。
设计师的新角色：”语义翻译者”
在 AI 生成界面的时代，设计师的核心竞争力不是”会不会写代码”，而是：
“能不能把设计意图翻译成机器可读的规则，让AI在生成内容之前就知道什么不能说、什么不能做。”
这个角色：
- 比工程师更懂设计意图的语义
- 比设计师更懂实现的约束
- 是”设计 → 工程”之间的翻译层
而规则文件就是这个翻译层的载体。
六、与其他工具的关系：不是替代是叠加
Design Token 定义“颜色是什么”（如 #EF4444），语义令牌定义“颜色代表什么”（如 status.critical）。Schema-As-Code 消费 DESIGN.md 的视觉定义，但约束的是语义映射关系。
七、仓库与在线体验
已开源
GitHub 仓库：
在线体验：
八、下一步：阶段二文章
本文是 Schema-As-Code 体系的总纲与预告。
接下来将发布《阶段二：设计师作为“语义翻译者”：当 AI生成界面时，我怎么用规则锁住设计意图》，深度展开：
- 从意图到规则：文本格式规则文件作为中间翻译层的设计哲学
- 设计师的规则文件书写规范（不会写代码也能写）
- 契约库：让设计规范像代码一样版本管理
- 从契约到消费格式：一份规则文件如何编译为 AI 指令 / 走查清单 / 自动校验规则
- 真实案例：ERR-001 从诊断到契约的完整过程
题图来自Unsplash，基于CC0协议