产品人人都是产品经理·阿基拉de_Akir··AI 生成
设计师作为“语义翻译者” 当AI生成界面时我怎么用规则锁住设计意图
设计规范以文档形式存在时，AI 无法直接读取，导致生成界面出现语义混乱。作者提出 Schema-As-Code 方法，将设计意图翻译为 YAML 语义契约，包含语义令牌、语义域、不可变边界等核心概念，并编译为 Prompt、Checklist、JSON Schema 和 CI 规则四种消费格式，让 AI 在生成前就知道什么能做、什么不能做。文章来自作者在 ChatGPT、文心一言等产品中的实践总结，适合正在探索 AI 辅助设计规范的团队参考。原文 ↗原文 ↗
核心观点
- ▍设计规范写在文档里只能给人看，AI 无法读取，必须翻译成机器可读的语义契约（YAML），才能从源头锁住设计意图的语义漂移。
- ▍设计师的核心能力不是画界面，而是理解场景语义并翻译成机器可读的规则。
- 01作者经历：设计规范更新后，前端和 AI 仍按旧版本生成，导致 3 个产品的 AI 生成界面全红，因为文档式规范对机器不可见。
- 02语义令牌（Semantic Tokens）比传统 Design Token 多一层语义：例如红色在系统故障场景代表致命（status.critical），在促销场景代表优惠（status.promotion）。
- 03不可变边界（Immutable Boundaries）定义 AI 绝对禁止的行为，如“禁止直接执行删除操作而不显示二次确认”，违反时直接阻止生成。
- 04YAML 契约可编译为四种格式：Prompt 前缀、设计走查 Checklist、JSON Schema（结构校验）、CI 规则（自动化流水线），实现一次编写、四端消费。
- 05契约库采用 Git 版本管理，变更时自动触发影响面分析，通知所有消费该契约的 AI 工具重编译。
- 06YAML 契约不包含 CSS 类名或框架名，仅写设计意图（如“删除按钮必须是红色空心，必须有二次确认”），可跨 Tailwind、Material UI 等框架使用。
反方 / 局限
- — 文章未讨论 YAML 契约在非 AI 原生团队中的推行成本（如设计师学习、组织认同），也未提及与现有设计系统（如 Figma Tokens）的集成难度。
- — 对小型团队或个人开发者而言，维护一套完整的契约库可能过于沉重，文章没有给出轻量化替代方案。
概念锚点
前置背景
平行视角
未来推演
延伸追问