7.5
深览指数
产品人人都是产品经理·阿基拉de_Akir··AI 生成
契约库：让设计规范像代码一样管理
本文提出了一套将设计规范管理从『文档』升级为『代码化基础设施』的完整方案。核心论点是：仅将设计意图写成 YAML 语义契约（形式化）不足以解决规模化问题，必须建立组织级的「契约库」——一个基于 Git 仓库、具备语义版本管理、MR 评审工作流、自动影响面分析和权限控制四大能力的规范仓库。文章详细给出了契约库的目录结构、每个子目录的职责、变更记录（Changeset）的模板，以及它与编译管线的关系。适合正在建构或重构设计系统的大厂设计/前端负责人、DesignOps 阅读，以理解如何将设计规范从『人读』文档变为『机读+人审』的可执行代码。原文 ↗
核心观点
- ▍传统设计规范以文档形态存在，版本不可追溯、变更不可同步、影响不可分析；Schema-As-Code 的解法不仅是形式化，更需要建立组织级的语义规范仓库——契约库，将设计规范从『文档』变成『代码』，从『人读』变成『机读+人审』。
- 01YAML 写完后面临四个问题：版本无法追踪（是 v1.0.0 还是 v1.1.0）、同步无法通知（5 个产品怎么同步）、追溯无记录（三个月前谁决定的为什么）、权限不可控（谁可以改/审/看）。
- 02契约库的目录结构包含 contracts/（核心契约文件，如 ERR-001.yaml）、schema/（结构校验规则，类似 JSON Schema）、snapshots/（版本快照，如 v1.0.0/）、changesets/（变更记录，含 Why、Impact、Approver）、compiled/（自动生成的消费格式，如 Prompt 前缀、JSON Schema、CI 规则、走查清单）。
- 03版本管理采用语义化版本规范（MAJOR.MINOR.PATCH），版本声明嵌入每个契约文件头部。Git 同步遵循代码开发工作流：修改 YAML → 创建分支 → 编写 Changeset → 提交 MR → 评审 → 合并 → 自动触发编译管线通知下游。
- 04影响面分析自动生成报告，包含变更摘要、影响产品（如 ChatGPT、文心一言等 6 个产品）、影响团队（前端/AI 工程/设计团队）、建议行动。
- 05权限控制明确角色：设计师（提交）、设计系统负责人（评审）、前端 TL（确认影响）、DesignOps（审批合并）。
- 06编译管线根据 contracts/ 内的 YAML 契约自动生成 compiled/ 下的 4 种消费格式，下游工具从此目录取消费格式，不直接读取原始 YAML。
反方 / 局限
- — 文章隐含的前提是『组织已具备成熟的 Git 工作流和 CI/CD 文化』，对于设计团队仍在手工协作、技术基础设施薄弱的组织，引入契约库的学习成本和管理开销可能远大于收益，文章未讨论这种过渡路径。
- — 文章将『设计规范』限定为『可被形式化为 YAML 的语义规则』，但大量设计规范（如交互动效时距、色彩情感、排版节奏）难以被量化为 YAML 字段，这类规范的管理方案未被覆盖。
YAML契约库Schema-As-CodeDesignOps语义化版本规范GitMerge Request编译管线FigmaChatGPT文心一言通义千问Kimi豆包DeepSeek阿基拉de_Akir
14 分钟 · 4 卡片 · 5 资料
读原文 →