产品人人都是产品经理·阿基拉de_Akir··AI 生成
把设计规范写成代码格式，是所有AI工具的上游约束方法论
本文提出Schema-As-Code方法论，解决AI生成界面时设计意图偏离的结构性问题。作者认为当前AI工具（如v0、Claude Code）只解决了界面'形态层'（长什么样），但缺失了'语义层'（表达什么含义、不能越过什么边界）。文章提出三阶段流水线：Guard（诊断语义断层）、Contract（设计师用YAML规则文件锁住意图）、Verify（验证闭环），并开源了配套工具。文章适合关注AI辅助设计、设计系统、前端规范化的设计师与工程师阅读。原文 ↗原文 ↗
核心观点
- ▍AI生成界面时设计意图偏离的根本原因是系统缺少'语义约束'层，而不仅是技术实现问题。
- ▍Schema-As-Code不是另一个Design-to-Code工具，而是一套上游约束机制，通过YAML规则文件锁住设计语义，供所有AI工具消费。
- 01三个典型案例说明语义断层：AI将'删除账户'按钮设计为蓝色实心；将Critical错误写成'严重'导致误判；设计规范更新后AI仍按旧规范生成。
- 02文章提出三阶段流水线：Guard阶段用'组件语义快照'6字段记录+三层判定模型+模式匹配，已识别5个通用语义断层模式。
- 03Contract阶段的核心输出是YAML规则文件，它可编译为四种消费格式：规则文件本体、AI指令前缀、走查清单、自动校验规则。
- 04规则文件中引入'语义令牌'（如status.critical）而非具体颜色值，它与Design Token的关系是：Token定义'颜色是什么'，Semantic Token定义'颜色代表什么'。
反方 / 局限
- — 作者承认设计师需要学习YAML语法和规则文件书写规范，这构成了真实的认知门槛。
- — 文章未提供大型团队或复杂产品落地Schema-As-Code的实证数据，目前仅停留在方法论与小范围工具验证层面。
17 分钟 · 5 卡片 · 11 资料
读原文 →概念锚点
前置背景
平行视角
未来推演
延伸追问