把设计规范写成代码格式,是所有 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而是整个行业在概率性界面时代共同面临的结构性断层。二、把设计规范写成代码格式的规则文件是所有工具的上游约束方法论我提出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 —— 组件语义快照与模式诊断回答的问题“我的产品有没有语义断层”我设计了一套结构化问诊流水线组件语义快照用 6 个字段记录一个界面组件的语义特征组件类型、视觉、文案、交互、上下文、产品来源三层判定模型回答 3 组问题 → 自动匹配语义断层模式第一层这是什么组件类型错误状态 / 过程状态 / 边界动作 / 操作按钮 / 状态提示第二层用户的核心困惑是什么不知道多严重 / 不知道在干什么 / 不知道权利还在不在第三层当前界面的视觉表达有什么特征全部红色 / 文案模糊 / 缺少行动指引模式匹配自动输出这是 ERR-001 类型的断层附带同类产品证据【结构化问诊界面截图】目前已验证 5 个通用模式模式 ID组件类型断层名称典型症状ERR-001错误状态后果差异未分级多种错误共用红色PRO-001过程状态认知阶段未显化Searching/Reading 模糊BND-001边界动作权利差异未区分拒绝 vs 终止混为一谈ACT-001高危操作风险未约束删除按钮做成蓝色实心ALR-001告警文案语义降级Critical 被写成严重【模式库卡片截图】阶段一产出诊断报告 同类产品证据截图 根因分析阶段二Contract —— 设计师作为语义翻译者回答的问题“我怎么用规则锁住设计意图”本文重点预告完整内容见下篇当设计师发现语义断层后传统做法是写一份设计规范文档PDF/语雀 全员通知2 周后走查发现 3 个产品没改对Schema-As-Code 的做法是把设计意图翻译成 YAML 契约机器可读的规则文件放在 Git 仓库里变更自动同步AI 工具自动消费机器走查覆盖率 100%YAML 契约示例ERR-001intent_id:ERR-001semantic_domain:observationalsemantic_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_historyllm_constraints:-必须明确告知用户对话上下文可能已丢失-禁止仅显示出错了等模糊文案transient:description:网络抖动系统可自动恢复visual_mapping:color_token:status.neutral# 语义令牌定义这个颜色代表中性状态motion_token:spinner# 语义令牌定义这个动效代表加载中icon_token:loader# 语义令牌定义这个图标代表等待user_action:-label:等待自动恢复action:waitllm_constraints:-禁止红色背景避免情绪过载-必须显示自动重试进度retryable:description:请求频率已达上限visual_mapping:color_token:status.warning# 语义令牌定义这个颜色代表警告状态motion_token:none# 语义令牌定义这个动效代表静态icon_token:clock# 语义令牌定义这个图标代表限时user_action:-label:等待倒计时action:wait_countdown-label:升级套餐action:upgradellm_constraints:-必须显示剩余等待时间-必须提供升级/扩容路径degraded:description:部分功能可用可继续生成visual_mapping:color_token:status.info# 语义令牌定义这个颜色代表信息状态motion_token:none# 语义令牌定义这个动效代表静态icon_token:info.circle# 语义令牌定义这个图标代表提示user_action:-label:继续生成action:continue-label:简化问题重试action:retry_simplifiedstatus.critical是语义令牌Semantic Token定义这个颜色在这个场景下代表致命状态。完整的语义令牌体系status.* / phase.* / boundary.* / action.*见契约书写规范。关键设计一份 YAML 契约编译为四种消费格式YAML 本体供 DesignOps 版本管理Prompt 前缀供 Claude Code / Cursor 注入 AI 指令Checklist 走查清单供设计师人工复核CI 校验规则供自动化流水线拦截【契约库界面截图】阶段二产出YAML 契约文件 多格式编译输出阶段三Verify —— 验证闭环与工具落地回答的问题“我怎么证明规则真的防住了语义漂移”三层验证工具语义分级器输入任意错误文案1 秒内返回语义分级建议Fatal/Transient/Retryable/DegradedJSON 语义校验器粘贴组件语义快照自动匹配已知模式并标记风险四层推演引擎语法推演 → 语义推演 → 安全推演 → 美感推演【语义分级器界面截图】【A/B 对比截图】验证指标指标之前之后语义返工率30%5%规范同步时间2 人周0.5 天走查覆盖率20%100%阶段三产出验证报告 返工率数据 可复用的验证工具四、关键洞察设计师不需要写代码但需要写规矩这是被问得最多的问题“我不会写代码能参与 Schema-As-Code 吗”答案是不仅能而且正因为不会写代码你才是最适合写 YAML 契约的人。为什么会写代码的人看到问题后会直接去写脚本、搭平台——结果卷进了工程实现层和 DevUI HMC / v0 竞争。不会写代码的人站在意图层——只关心这个场景下必须表达什么语义、不能突破什么边界而不关心用什么框架实现。YAML 契约的本质是设计意图的翻译不是代码实现。intent_id:ACT-001semantic_domain:transactionalsemantic_tokens:destructive_action:description:不可逆的数据销毁操作# 语义令牌定义视觉元素的语义含义visual_mapping:color_token:status.critical# 语义令牌定义这个颜色代表致命状态button_style:outline_danger# 语义令牌定义这个按钮样式代表危险空心描边icon_token:alert.triangle# 语义令牌定义这个图标代表警告# 不可变边界绝对不能突破的红线immutable_boundaries:-boundary_type:safetyrule:禁止直接执行删除操作而不显示二次确认violation_action:block-boundary_type:safetyrule:禁止将删除按钮设计为普通主按钮样式violation_action:block# LLM 约束AI 生成内容时必须遵守的规则llm_constraints:-必须包含二次确认弹窗-文案必须明确说明此操作不可恢复-必须提供取消选项且视觉权重不低于确认按钮-禁止在二次确认弹窗中使用确认等模糊文案必须使用确认删除# 用户行动与后果级别匹配的操作user_action:primary:label:确认删除账户action:confirm_deleterequires_input:true# 要求输入账户名确认input_field:account_namesecondary:label:取消action:cancelvisual_weight:equal# 视觉权重与主按钮同等这段 YAML 里没有 CSS 类名没有 React/Vue 组件名没有文件路径只有设计师的意图“删除按钮必须是红色空心必须有二次确认。”前端工程师拿到这份 YAML可以翻译成 Tailwind、Material UI、DevUI 或任何框架。契约是跨框架的。五、组织经济价值一个设计师解决跨域协调问题Schema-As-Code 的价值不止于技术更在于组织经济。传统工作流的隐性成本环节成本问题规范定义设计师写文档意图无法被机器消费规范同步管理人员全员2 周覆盖遗漏率高规范执行前端凭经验实现每个人理解不同规范走查设计师人眼检查500 页面只能看 100 个规范修复上线后用户投诉修复成本 ×10总成本 设计意图在跨角色传递中不断失真反复修复。Schema-As-Code 工作流的经济价值环节改变节省规范定义设计师写规则文件意图直接机器可读规范同步Git 变更自动触发从 2 周 → 0.5 天规范执行AI 自动读取指令前缀前端不再凭经验猜规范走查机器自动校验 100%设计师只处理异常规范修复生成前拦截上线后零语义事故总收益 设计意图从人传人的方言变成机器可读的普通话。设计师的新角色“语义翻译者”在 AI 生成界面的时代设计师的核心竞争力不是会不会写代码而是“能不能把设计意图翻译成机器可读的规则让 AI 在生成内容之前就知道什么不能说、什么不能做。”这个角色比工程师更懂设计意图的语义比设计师更懂实现的约束是设计 → 工程之间的翻译层而 YAML 契约就是这个翻译层的载体。六、与其他工具的关系不是替代是叠加工具类型解决什么问题Schema-As-Code 怎么叠加Design-to-CodeAnima/Builder从设计稿到代码在导出前加语义校验防止代码生成后语义漂移AI 原型v0/Framer AI快速验证想法在生成前注入 Prompt 前缀约束原型语义AI 编程Claude Code/Copilot自然语言写代码在 Prompt 上下文注入 YAML 约束代码生成前已知语义边界企业规范DevUI HMC符合组件库的代码在组件语义映射时叠加语义层组件用对了但场景语义也要对设计系统规范DESIGN.md视觉规范的机器可读化消费 DESIGN.md 的 Token但约束的是语义映射关系Design Token 定义颜色是什么如 #EF4444语义令牌定义颜色代表什么如 status.critical。Schema-As-Code 消费 DESIGN.md 的视觉定义但约束的是语义映射关系。七、仓库与在线体验已开源GitHub 仓库https://github.com/2436041978-ops/semantic-pipeline在线体验https://2436041978-ops.github.io/semantic-pipeline/八、下一步阶段二文章本文是 Schema-As-Code 体系的总纲与预告。接下来将发布《阶段二设计师作为语义翻译者当 AI 生成界面时我怎么用规则锁住设计意图》深度展开从意图到规则YAML 作为中间翻译层的设计哲学设计师的 YAML 书写规范不会写代码也能写契约库让设计规范像代码一样管理从契约到消费格式编译真实案例ERR-001 从诊断到契约的完整过程如果你也在经历AI 生成的界面偏离设计意图的困扰欢迎关注这个系列。结语AI 时代的设计工作流正在重构。不是设计师会不会被 AI 替代的问题而是设计师在 AI 工作流中扮演什么新角色的问题。Schema-As-Code 给出的答案是设计师不需要写代码但需要写语义契约——把设计意图翻译成机器可读的规则成为 AI 生成界面的上游约束层。这不是一个工具是一个方法论。不是替代任何现有工具是所有工具的上游约束。Gap 期局限性声明当前状态 架构推演与最小可行原型阶段。YAML 规范、校验逻辑为定义层实现尚未接入生产级 LLM API 或 CI 流水线。欢迎基于现有思路共建。关于作者魏雯体验架构设计师。专注于AI 界面的语义治理。解决的核心问题让 LLM 生成的界面不偏离设计规范。10 年互联网设计经验。设计系统 / 体验工程 / AI 原生广州 / 深圳