夜雨聆风当 AI 生成界面时，设计意图在偏离。不是 AI 故意做错，而是系统缺少一层"语义约束"。
本文提出 Schema-As-Code：一套让设计师用 YAML 契约锁住设计意图的三阶段流水线。不是替代任何工具，是所有 AI 工具的上游约束。
1. AI生成界面时谁在守住设计意图？
2024-2025 年，设计团队全面进入AI辅助生产时代：
- v0 / Framer AI 用一句话生成可交互原型
- Claude Code / Cursor 用自然语言写前端代码
- DevUI HMC / DESIGN.md 让AI按组件库规范输出代码
这些工具都在解决"形态层"的问题，界面长什么样、用什么组件、怎么写代码。
但没有人解决"语义层"的问题，这个界面在这个场景下表达了什么意思、不能突破什么边界。
结果是：
AI生成"删除账户"按钮，给了个蓝色实心按钮，用户一点，账户没了 AI生成告警卡片，把 Critical 写成 "严重"，值班员觉得不严重，延迟响应，系统挂了 设计规范更新了"错误状态分四级"，发在文档里，前端没看，AI更没看还是按老样子生成 一个产品500个页面，人工走查100个就累了，剩下400个的语义错误上线后才被用户投诉
这不是某个产品的Bug，而是整个行业在AI生成界面时代共同面临的结构性断层。
2. 把设计规范写成代码格式的规则文件是所有工具的上游约束
我提出的方法叫 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 生成的内容是否偏离了设计意图"
这四层缺一不可，且互不替代。
3. 三阶段流水线：从发现问题到证明有效
阶段一：Guard 组件语义快照与模式诊断
回答的问题："我的产品有没有语义断层？"
我设计了一套"结构化问诊"流水线：
- 组件语义快照：用6个字段记录一个界面组件的语义特征（组件类型、视觉、文案、交互、上下文、产品来源）
- 三层判定模型：回答3组问题 → 自动匹配语义断层模式
第一层：什么组件类型？（错误状态 / 过程状态 / 边界动作 / 操作按钮 / 状态提示） 第二层：用户的核心困惑是什么？（不知道多严重 / 不知道在干什么 / 不知道权利还在不在） 第三层：当前界面的视觉表达有什么特征？（全部红色 / 文案模糊 / 缺少行动指引）
- 模式匹配：自动输出"这是 ERR-001 类型的断层"，附带同类产品证据
结构化问诊界面截图
模式库卡片截图
阶段一（发现问题）产出： 诊断报告 + 同类产品证据截图 + 根因分析
阶段二：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 验证闭环与工具落地
回答的问题："我怎么证明规则真的防住了语义漂移？"
三层验证工具：
- 语义分级器：输入任意错误文案，1 秒内返回语义分级建议（致命/网络抖/限流/部分可用）
- JSON语义校验器：粘贴组件语义快照，自动匹配已知模式并标记风险
- 四层检查引擎：结构检查 → 语义检查 → 安全检查 → 质量检查
语义分级器界面截图
A/B 对比截图
验证指标：
阶段三产出： 验证报告 + 返工率数据 + 可复用的验证工具
4. 设计师不需要写代码但需要写"规矩"
这是被问得最多的问题："我不会写代码，能参与这个方法吗？"
答案是：不仅能，而且正因为不会写代码，你才是最适合写规则文件的人。
为什么？
会写代码的人，看到问题后会直接去写脚本、搭平台，结果卷进了工程实现层，和 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" # 视觉权重与主按钮同等
这段YAML规则文件里：
没有 CSS 类名 没有 React/Vue 组件名 没有文件路径
只有设计师的意图："删除按钮必须是红色空心，必须有二次确认。"
前端工程师拿到这份规则，可以翻译成 Tailwind、Material UI、DevUI 或任何框架。规矩是跨框架的。
5. 组织经济价值：一个设计师解决跨域协调问题
Schema-As-Code（把设计规范写成代码格式的规则文件）的价值不止于技术，更在于组织经济。
传统工作流的隐性成本
总成本 = 设计意图在跨角色传递中不断失真，反复修复。
Schema-As-Code 工作流的经济价值
总收益 = 设计意图从"人传人的方言"变成"机器可读的普通话"。
设计师的新角色："语义翻译者"
在AI生成界面的时代，设计师的核心竞争力不是"会不会写代码"，
而是："能不能把设计意图翻译成机器可读的规则，让AI在生成内容之前就知道什么不能说、什么不能做。"
这个角色：
比工程师更懂设计意图的语义 比设计师更懂实现的约束 是"设计 → 工程"之间的翻译层
而规则文件就是这个翻译层的载体。
6.与其他工具的关系：不是替代是叠加
Design Token 定义"颜色是什么"（如 #EF4444），语义令牌定义"颜色代表什么"（如 status.critical）。Schema-As-Code 消费 DESIGN.md 的视觉定义，但约束的是语义映射关系。
7. 仓库与在线体验
已开源
- GitHub 仓库
：https://github.com/2436041978-ops/semantic-pipeline - 在线体验
：https://2436041978-ops.github.io/semantic-pipeline/
8. 下一步：阶段二（写出规则）文章
本文是 Schema-As-Code（把设计规范写成代码格式的规则文件） 体系的总纲与预告。
接下来将发布《阶段二：设计师作为"语义翻译者"：当 AI 生成界面时，我怎么用规则锁住设计意图》，深度展开：
从意图到规则：文本格式规则文件作为中间翻译层的设计哲学 设计师的规则文件书写规范（不会写代码也能写） 契约库：让设计规范像代码一样版本管理 从契约到消费格式：一份规则文件如何编译为 AI 指令 / 走查清单 / 自动校验规则 真实案例：ERR-001 从诊断到契约的完整过程
如果你也在经历"AI 生成的界面偏离设计意图"的困扰，欢迎关注这个系列。
结语
AI 时代的设计工作流正在重构。
不是"设计师会不会被 AI 替代"的问题，而是"设计师在 AI 工作流中扮演什么新角色"的问题。
Schema-As-Code（把设计规范写成代码格式的规则文件）给出的答案是：
设计师不需要写代码，但需要写"规矩"，把设计意图翻译成机器可读的规则，成为 AI 生成界面的上游约束层。
这不是一个工具，是一个方法论。
不是替代任何现有工具，是所有工具的上游约束。
