你在 Figma 里把按钮改成圆角，工程师却仍在代码里沿用旧样式。几周后，设计稿和上线产品各有一套“正确答案”。AI 开始批量生成界面后，这类小分叉还会更快累积。Christine Vallaure 介绍的解法，是不再争论 Figma 和代码谁说了算，而是在两者之间放一份机器可读的“组件契约”。
这里的设计系统（Design System），不只是 Figma 中的一套组件库，而是可复用的界面组件、设计规则、代码实现和维护机制。本文的具体机制与效果均来自 Vallaure 的单篇介绍；材料没有提供真实项目数据，以下更适合看作一个值得验证的架构提案，而非已经得到规模化证明的方案。
别让两个副本争当原件
一个按钮通常同时活在两个地方。设计师使用 Figma 组件，工程师交付代码组件。团队可以规定“以代码为准”，也可以规定“以 Figma 为准”，但另一端仍然需要有人跟着更新。只要两边分别维护，就可能发生漂移——也就是同名组件逐渐拥有不同的属性、状态或样式。
Vallaure 转述称，Nathan Curtis 近几年一直倡导把组件描述成普通数据，并发表了《Components as Data》。设计系统咨询公司 Southleft 随后发布了基于相同思路的代码仓库和浏览器概念演示，并把中间这层定义称为“design system contract”。Southleft 由 TJ Petri 创立；原文还称他“刚刚加入 Figma”，但这一具有时效性的信息没有第二个来源核实。
所谓契约（Contract），就是对一个组件叫什么、有哪些属性和状态、允许什么内容、会怎样响应操作作出明确约定。它可以为每个组件保存成一份 JSON 或 YAML 文件——两者都是带有固定字段和层级的文本格式，电脑不必猜测一段话的含义，就能逐项读取和检查。
中间那份文件写什么？
以按钮为例，契约可以写明它有 primary、secondary 等选项，默认使用哪一种，采用哪些颜色和设计令牌，内部允许放什么，以及点击后应有什么行为。设计令牌（Design Tokens）是用名称记录颜色、字号、间距等基础决定的数据，例如让“brand-blue”在设计工具和代码中指向同一种颜色。它已经是跨工具同步的常见思路，但通常不足以独自描述组件的结构和行为。
按 Vallaure 的介绍，Figma 组件与代码组件都可以从同一份契约自动生成：代码端直接写出相应文件；Figma 端则由插件读取指令并建立组件。按钮的一项状态，在 Figma 中成为 variant（同一组件的不同样式或状态），在代码中成为带类型的选项。两端不是互相抄写，而像是同一份配方打印出的两份成品。
这份契约因此承担“单一事实来源”（Single Source of Truth）的角色：团队共同承认它是权威定义，其他实现从中派生或接受检查。文章还描述了一种检查器，可以比较契约、Figma 库和代码，指出三者在哪里不再一致。检查需要由人主动运行，或交给开发流程运行，并不会自行弹出警报。
为什么不用一篇 Markdown？
现在的 AI 很擅长阅读 Markdown——一种用标题、段落和列表组织内容的文本格式。但“读懂一段描述”和“核对固定字段”是两回事。
如果文档写着“按钮通常使用品牌色，必要时也可低调一些”，不同的人或模型可能作出不同解释。JSON 或 YAML 更像一张字段固定的表格：variant 只能从列出的选项中选择，默认值也明确写出。相同输入应得到相同检查结果，这就是确定性。契约要解决的不是让电脑更会理解，而是尽量减少需要理解的空间。
这也是它在 AI 参与开发后值得关注的原因。过去，设计师和工程师还能在评审中发现两端差异；当 AI 能更快地产生更多界面与代码时，含糊约定也可能被更快复制。机器可读的契约给 AI 划出一条清楚边界：可以生成，但生成结果仍要符合明确的属性、选项和内容约束。
严格之处，也正是代价
这套设想有一条关键规则：Figma 和代码不能直接更新彼此。设计师改颜色，或工程师增加选项，都要先修改契约、接受审查，再重新生成两端。它把同步问题从“记得通知另一个人”，改成“改动必须经过同一入口”。
代价也很直接。契约本身可能成为第三份需要维护的资产。如果它不能真正驱动两端生成，只是多放了一份说明文件，同步面反而会从两个增加到三个。它能否覆盖复杂布局、交互、无障碍要求和运行时行为，也决定了这份“权威定义”究竟能走多远。
局限与未知
- 材料没有提供实际项目、采用规模、漂移减少幅度或对照实验，无法判断双端自动生成能否长期稳定运行。
- 原文对 Figma 插件流程的介绍并不完整，尚不足以确认生成机制、覆盖范围和成熟度。
- 契约适合表达多少复杂行为仍不清楚。它目前最有说服力的价值，是把原本散落在人和文件之间的约定，变成可以检查的数据。