当 AI 生成界面时，设计意图在偏离。
不是 AI 故意做错，而是系统缺少一层"规矩"——告诉 AI 什么场景下必须说什么、绝对不能做什么。本文提出一套方法：让设计师用一份文本格式的规则文件（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 是所有工具的上游约束
我提出的方法叫 Schema-As-Code（把设计规范写成代码格式的规则文件）。
它不是另一个 Design-to-Code 工具，而是所有工具的"上游约束层"。
┌─ 语义层：Schema-As-Code（规矩层）─┐
│ 什么场景下必须表达什么 │
│ 什么词不能用 │
└────────── ↓ 编译为规则 ───────────┘
┌─ 形态层：v0 / Claude Code / DevUI ┐
│ 长什么样、用什么组件、怎么写代码 │
└────────────────────────────────────┘
关键洞察：
- v0 解决的是"AI 能不能生成界面"
- Claude Code 解决的是"AI 能不能写代码"
- DevUI HMC 解决的是"代码是否符合组件库规范"
- Schema-As-Code 解决的是"AI 生成的内容是否偏离了设计意图"
这四层缺一不可，且互不替代。
三、三阶段流水线：从发现问题到证明有效
Schema-As-Code 不是一套理论，是一条可执行的三阶段流水线。
【三阶段流水线图】
阶段一：Guard —— 组件语义快照与模式诊断
回答的问题："我的产品有没有语义断层？"
我建立了一套"结构化问诊"系统：
- 组件语义快照：用 6 个字段记录一个界面组件的语义特征（组件类型、视觉、文案、交互、上下文、产品来源）
- 三层判定模型：回答 3 组问题 → 自动匹配语义断层模式
- 第一层：这是什么组件类型？（错误状态 / 过程状态 / 边界动作 / 操作按钮 / 状态提示）
- 第二层：用户的核心困惑是什么？（不知道多严重 / 不知道在干什么 / 不知道权利还在不在）
- 第三层：当前界面的视觉表达有什么特征？（全部红色 / 文案模糊 / 缺少行动指引）
- 模式匹配：自动输出"这是 ERR-001 类型的断层"，附带同类产品证据
【结构化问诊界面截图】
| 模式卡片 | 模式 ID | 组件类型 | 断层名称 | 典型症状 | 产品实例 | 验证状态 |
|---|---|---|---|---|---|---|
| ACT-001 | ACT-001 | 高危操作 | 风险未约束 | 删除按钮做成蓝色实心，没有二次确认 | 通用 | ✅ 已验证 |
| ERR-001 | ERR-001 | 错误状态 | 后果差异未分级 | 多种错误共用红色，用户无法判断后果 | ChatGPT / 文心一言 / 通义千问 | ✅ 已验证 |
| ALR-001 | ALR-001 | 告警文案 | 语义降级 | Critical 被写成"严重"，情绪权重降低 | 通用 | ✅ 已验证 |
| PRO-001 | PRO-001 | 过程状态 | 认知阶段未显化 | Searching / Reading / Wrapping up 模糊 | Perplexity | ✅ 已验证 |
| BND-001 | BND-001 | 边界动作 | 权利差异未区分 | 拒绝 vs 终止混为一谈，用户不知道权利还在不在 | Claude | ✅ 已验证 |
| ACT-001-pop | ACT-001 | 高危操作 | 确认强度不足 | 不可逆操作，必须输入账户名确认（弹窗形态） | 通用 | 🔁 同模式补充 |
【模式库卡片截图】
阶段一产出： 诊断报告 + 同类产品证据截图 + 根因分析
阶段二：Contract —— 设计师作为"语义翻译者"
回答的问题："我怎么用规则锁住设计意图？"
（本文重点预告，完整内容见下篇）
当设计师发现语义断层后，传统做法是：
- 写一份设计规范文档（PDF/语雀）
- @ 全员通知
- 2 周后走查发现 3 个产品没改对
Schema-As-Code 的做法是：
- 把设计意图翻译成文本格式的规则文件（YAML）
- 放在 Git 仓库里，变更自动同步
- AI 工具自动读取，机器走查覆盖率 100%
规则文件示例（ERR-001）：
# 错误状态的规矩
场景: 系统报错
绝对不能碰的红线:
- 禁止所有错误状态共用同一种红色
- 禁止只显示"出错了"等模糊文案
- 禁止暴露技术错误码（如 429、500）
错误级别:
致命:
什么情况: 对话断了，内容可能丢了
颜色: 红色 + 脉冲动画
用户该做什么: 刷新页面 / 导出历史
网络抖:
什么情况: 网络不稳，等一等就好
颜色: 灰色 + 加载动画
用户该做什么: 等自动恢复，不用刷新
限流:
什么情况: 请求太多，被限流了
颜色: 黄色
用户该做什么: 等倒计时 / 升级套餐
部分可用:
什么情况: 一部分坏了，另一部分还能用
颜色: 蓝色
用户该做什么: 继续生成 / 简化问题重试
关键设计： 一份规则文件，编译为四种消费格式：
- 规则文件本体：供规范管理人员版本管理（放在 Git 里）
- AI 指令前缀：供 AI 编程工具（Claude Code / Cursor）在生成代码前读取
- 走查清单：供设计师人工复核时逐项打勾
- 自动校验规则：供 CI 流水线自动拦截不合规的生成内容
【契约库界面截图】
阶段二产出： 规则文件 + 多格式编译输出
阶段三：Verify —— 验证闭环与工具落地
回答的问题："我怎么证明规则真的防住了语义漂移？"
三层验证工具：
- 语义分级器：输入任意错误文案，1 秒内返回语义分级建议（致命/网络抖/限流/部分可用）
- JSON 语义校验器：粘贴组件语义快照，自动匹配已知模式并标记风险
- 四层检查引擎：结构检查 → 语义检查 → 安全检查 → 质量检查
【语义分级器界面截图】
【A/B 对比截图】
验证指标：
| 指标 | 之前 | 之后 |
|---|---|---|
| 语义返工率 | 30% | 5% |
| 规范同步时间 | 2 人周 | 0.5 天 |
| 走查覆盖率 | 20% | 100% |
阶段三产出： 验证报告 + 返工率数据 + 可复用的验证工具
四、关键洞察：设计师不需要写代码，但需要写"规矩"
这是被问得最多的问题："我不会写代码，能参与这个方法吗？"
答案是：不仅能，而且正因为不会写代码，你才是最适合写规则文件的人。
为什么？
会写代码的人，看到问题后会直接去写脚本、搭平台——结果卷进了工程实现层，和 DevUI HMC / v0 竞争。
不会写代码的人，被迫站在"意图层"——只关心"这个场景下必须表达什么语义、不能突破什么边界"，而不关心"用什么框架实现"。
规则文件的本质是"设计意图的翻译"，不是"代码实现"。
# 设计师写的：语义约束
场景: 删除账户
绝对不能碰的红线:
- 禁止把删除按钮做成普通蓝色按钮
- 禁止跳过二次确认
- 禁止不写"此操作不可恢复"
颜色背后的意思:
高危操作:
颜色: 红色
样式: 空心描边（不是实心）
必须包含: 二次确认弹窗 + 不可恢复警告文案
这段规则文件里：
- 没有 CSS 类名
- 没有 React/Vue 组件名
- 没有文件路径
只有设计师的意图："删除按钮必须是红色空心，必须有二次确认。"
前端工程师拿到这份规则，可以翻译成 Tailwind、Material UI、DevUI 或任何框架。规矩是跨框架的。
五、组织经济价值：一个设计师解决跨域协调问题
Schema-As-Code 的价值不止于技术，更在于组织经济。
传统工作流的隐性成本
| 环节 | 成本 | 问题 |
|---|---|---|
| 规范定义 | 设计师写文档 | 意图无法被机器消费 |
| 规范同步 | 管理人员@全员 | 2 周覆盖，遗漏率高 |
| 规范执行 | 前端凭经验实现 | 每个人理解不同 |
| 规范走查 | 设计师人眼检查 | 500 页面只能看 100 个 |
| 规范修复 | 上线后用户投诉 | 修复成本 ×10 |
总成本 = 设计意图在跨角色传递中不断失真，反复修复。
Schema-As-Code 工作流的经济价值
| 环节 | 改变 | 节省 |
|---|---|---|
| 规范定义 | 设计师写规则文件 | 意图直接机器可读 |
| 规范同步 | Git 变更自动触发 | 从 2 周 → 0.5 天 |
| 规范执行 | AI 自动读取指令前缀 | 前端不再凭经验猜 |
| 规范走查 | 机器自动校验 100% | 设计师只处理异常 |
| 规范修复 | 生成前拦截 | 上线后零语义事故 |
总收益 = 设计意图从"人传人的方言"变成"机器可读的普通话"。
设计师的新角色："语义翻译者"
在 AI 生成界面的时代，设计师的核心竞争力不是"会不会写代码"，而是：
"能不能把设计意图翻译成机器可读的规则，让 AI 在生成内容之前就知道什么不能说、什么不能做。"
这个角色：
- 比工程师更懂设计意图的语义
- 比设计师更懂实现的约束
- 是"设计 → 工程"之间的翻译层
而规则文件就是这个翻译层的载体。
六、仓库与在线体验
已开源
- GitHub 仓库：https://github.com/2436041978-ops/semantic-pipeline
- 在线体验：https://2436041978-ops.github.io/semantic-pipeline/
七、下一步：阶段二文章
本文是 Schema-As-Code 体系的总纲与预告。
接下来将发布《阶段二：设计师作为"语义翻译者"：当 AI 生成界面时，我怎么用规则锁住设计意图》，深度展开：
- 从意图到规则：文本格式规则文件作为中间翻译层的设计哲学
- 设计师的规则文件书写规范（不会写代码也能写）
- 契约库：让设计规范像代码一样版本管理
- 从契约到消费格式：一份规则文件如何编译为 AI 指令 / 走查清单 / 自动校验规则
- 真实案例：ERR-001 从诊断到契约的完整过程
如果你也在经历"AI 生成的界面偏离设计意图"的困扰，欢迎关注这个系列。
结语
AI 时代的设计工作流正在重构。
不是"设计师会不会被 AI 替代"的问题，而是"设计师在 AI 工作流中扮演什么新角色"的问题。
Schema-As-Code 给出的答案是：
设计师不需要写代码，但需要写"规矩"，把设计意图翻译成机器可读的规则，成为 AI 生成界面的上游约束层。
这不是一个工具，是一个方法论。
不是替代任何现有工具，是所有工具的上游约束。
Gap 期局限性声明
当前状态： 架构推演与最小可行原型阶段。YAML 规范、校验逻辑为定义层实现，尚未接入生产级 LLM API 或 CI 流水线。欢迎基于现有思路共建。
关于作者
魏雯，体验架构设计师。
专注于：AI 界面的语义治理。解决的核心问题：让 LLM 生成的界面不偏离设计规范。
10+ 年互联网设计经验。设计系统 / 体验工程 / AI 原生｜广州 / 深圳
