AI-first 设计系统的两条路线：格式层 vs 引擎层
一个令人意外的发现
2025 年中，我在做设计系统自动化——一个叫 Horizon 的内部引擎。五层架构、30 个 AI Agent Skill、CLI 工具链、从上游文档自动采集 Token……做了半年，感觉方向对了。
然后 Google Labs 发布了 DESIGN.md。
一个文件。4 条 CLI 命令。npx @google/design.md lint 就能验证。任何 AI Agent 都能直接消费。
我看完的第一反应：这么轻？
第二反应：它解决的问题，和我解决的是同一个问题吗？
答案是：是的，也不是。它让我意识到 AI-first 设计系统存在两种完全不同的路线——格式层 (Format Layer) 和 引擎层 (Engine Layer)。
什么是"AI-first 设计系统"
先定义问题。
传统设计系统为人类设计师服务——Figma 组件库、Storybook 文档、设计规范 PDF。
AI-first 设计系统为 AI Agent 服务——它的核心问题是：如何让 AI 正确理解和应用设计约束？
AI-first 设计系统的核心诉求只有一个：让设计意图变成可编程的约束，而不是需要人肉记忆的规范。
在这个前提下，格式层和引擎层给出了不同的答案。
路线 A：格式层 (DESIGN.md 的哲学)
DESIGN.md 的核心主张：
"定义一个足够好的格式，让任何 AI Agent 都能自助服务。"
它的实现极其精简：
# DESIGN.md 文件结构 (一个完整的设计系统定义)
---
name: "My Design System"
colors:
primary: "#1a73e8"
secondary: "#34a853"
typography:
heading: { family: "Inter", weight: 700 }
body: { family: "Inter", weight: 400 }
spacing: [4, 8, 12, 16, 24, 32, 48, 64]
rounded: [4, 8, 12, 16, 9999]
components:
Button:
background: colors.primary
padding: [spacing.3, spacing.4]
rounded: rounded.2
---
# Design System Documentation
(人类可读的说明...)一个文件就是整个设计系统的 SSOT（单一数据源）。CLI 工具只做四件事：
| 命令 | 功能 |
|---|---|
lint | 验证格式 + WCAG 无障碍检查 |
diff | 对比两个版本的 Token 变更 |
export | 导出为 Tailwind / W3C DTCG 格式 |
init | 创建模板 |
格式层的设计哲学是Agent 无关性：它不关心你用 Claude Code、Cursor 还是 Copilot——只要 Agent 能读文件，就能理解设计系统。
格式层的优势：
- 5 分钟上手
- 任何 AI 工具直接可用
- W3C DTCG 标准兼容
- 零框架绑定
路线 B：引擎层 (我的选择)
我走的是另一条路：
"构建一个 Agent 军团，让它们主动驱动设计系统的全生命周期。"
Horizon 的架构不是一个文件，而是一个多层系统：
引擎层不只是"定义格式让 AI 读"——它让 AI 主动执行设计系统的所有操作：
| 能力 | 格式层能做吗 | 引擎层做法 |
|---|---|---|
| 从企业文档采集设计规范 | ❌ | 自动批量采集飞书/Notion |
| 从已有代码逆向提取 Token | ❌ | 解析组件库源码 |
| 追踪"当前状态"vs"目标状态" | ❌ | Reality Baseline 双轨 |
| 自动生成组件代码 | ❌ (Agent 自行决定) | Spec→Code 管道 |
| 结构化验证一致性 | ✅ (lint 基础) | 四向验证框架 |
| 管理设计系统演进 | ❌ | Evolution 主题追踪 |
引擎层的优势：
- AI 深度控制
- 全生命周期覆盖
- 独有的上游采集和逆向能力
- 理论上限极高
真实对比：不是谁更好，是解决不同问题
当我把两个系统放在 8 个维度上做对比后，结论出乎意料：
核心发现：
- DESIGN.md 在 AI 深度上接近引擎层（都是为 AI Agent 设计），但在生态开放度上远超
- 引擎层在 AI 深度上独占鳌头，但生态开放度是最大弱点
- 其他所有产品（Style Dictionary、Supernova、Tokens Studio）都在"AI 辅助"象限——AI 是锦上添花，不是核心
这意味着：AI-first 设计系统的市场目前只有两个玩家在真正定义赛道。
两种哲学的关键分歧
| 方面 | 格式层 (DESIGN.md) | 引擎层 (Horizon) |
|---|---|---|
| 核心隐喻 | 食谱——写好配方，谁都能做 | 厨师——训练专业团队来做 |
| 复杂度 | 1 个文件 + 4 条命令 | 5 层架构 + 30 Skills + 多目录 |
| 上手成本 | 5 分钟 | 数小时 |
| AI 角色 | 被动消费者：读格式，自行应用 | 主动执行者：驱动全流程 |
| 上限 | 中（定义格式，不负责执行） | 高（理论上可驱动一切） |
| 标准化 | W3C DTCG 对齐 | 自定义 |
| 适用场景 | 小团队、快速启动、多 Agent 环境 | 大系统、全链路管控、深度定制 |
这不是"哪个更好"的问题——是你的设计系统复杂度在哪个区间的问题。
我从格式层学到了什么
做了半年引擎后再看格式层，最大的感触是：我在很多地方过度工程了。
教训 1：不是所有 Agent 都需要"被管理"
格式层假设 AI Agent 足够聪明——你给它规则，它自己执行。引擎层假设 Agent 不可靠——必须用 Skill 链条约束它。
现实介于两者之间。Agent 在 Token 应用这种"查表"任务上，确实不需要专门的 Skill 来管。
教训 2：标准比自定义格式重要
我用自定义 JSON Manifest 定义 Token，这意味着只有我的系统能读。DESIGN.md 选择 W3C DTCG 标准 + Tailwind 生态——全世界的工具都能读。
长期来看，格式的开放性比功能的深度更影响采用率。
教训 3：引擎的真正价值在"格式做不到的事"
引擎层的护城河不在于 Token 管理（格式层在这里更优雅），而在于三个格式层做不到的能力：
- 上游采集——从企业知识库自动抽取设计规范
- 逆向工程——从已有代码反向提取设计 Token
- Reality Sync——持续追踪"当前实现"vs"设计规范"的偏差
这三个能力市面上没有替代品。它们的价值不在于"让 AI 读懂设计系统"（格式层解决了），而在于"让设计系统从混沌中诞生并持续演进"。
融合策略：引擎生产，格式消费
最终的洞察是：两层不是竞争关系，是上下游关系。
- 引擎层负责"生产"：从混沌中建立秩序——采集、逆向、校准、生成
- 格式层负责"消费"：把秩序标准化——让任何工具、任何 Agent 都能使用
这意味着我下一步的方向不是"替代 DESIGN.md"，而是"让 Horizon 能导出 DESIGN.md 格式"。引擎的价值不是锁定用户在自己的格式里，而是做格式层做不到的脏活，然后把结果以标准格式输出。
给选择者的建议
如果你正在考虑让设计系统 AI 化：
选格式层 (DESIGN.md) 如果：
- 你的设计系统已经存在且稳定
- 你希望多种 AI 工具都能使用
- 你追求最短时间上手
- 你不需要从头建立设计系统
选引擎层如果：
- 你的设计系统需要从散乱的文档/代码中重建
- 你需要自动化的上游同步（从 Figma/Notion/飞书持续采集）
- 你需要代码级的组件生成和验证
- 你愿意投入时间换取长期的全链路管控
两个都要如果：
- 你用引擎层做"生产"
- 你导出格式层做"消费"
- 这是我目前认为的最优解
尾声：格式层的出现让我更清楚引擎层的价值
半年前如果有人问我"Horizon 的核心价值是什么"，我可能会说"它让 AI 能理解设计系统"。
现在我的答案变了：DESIGN.md 让 AI 理解设计系统的问题已经解决了——一个文件就够。
Horizon 的价值是：在设计系统不存在、或者散落在 50 篇文档和 200 个组件里的时候，从混沌中把它提取出来。
格式是终点。引擎是过程。
格式层回答"Agent 怎么读设计系统"。引擎层回答"设计系统怎么诞生和演进"。
两个问题都重要。但如果你只有格式而没有引擎——你需要有人（或某个 Agent）手工维护那个 DESIGN.md 文件。在设计系统超过 50 个 Token、20 个组件之后，那个"有人"会变成瓶颈。
这就是引擎存在的意义。