协议驱动的设计系统引擎：让设计意图可编程

我是一个前端开发者，不是设计专家。但从接触 AI 开始，我就一直在琢磨一个问题：需求 → 视觉 → 页面 这条产线能不能尽量智能且自动化地跑下来？

折腾了挺久，一直没有跑得很好。

最近一个现象让我觉得这个问题更迫切了：越来越多的产品经理和业务方开始尝试 vibe coding——用 AI 直接生成页面。这本身是好事，让更多人可以快速把想法具象化。但实际跑下来的问题是：

• 缺少传递性——你生成的页面只有你自己理解，交给下一个人接手就变成了考古
• 缺少延续性——同一个产品的多次生成之间风格飘忽不定，前后不一致
• 审美与模型耦合——你的页面"长什么样"取决于你用的是哪个 AI 模型，换个模型风格就变了

对于被组件库限制住的业务方来说，vibe coding 像是一种解放。但对于下游的设计师和开发来说，这些产物带来了新的困扰——它们不符合现有设计体系，没有复用性，改都不知道往哪个方向改。

我和我们的设计专家聊了这些困惑。在他们的启发下，加上自己的实践，我逐渐形成了一个想法：问题不在 AI 能力不够，而在于 AI 缺少结构化的"设计约束"作为上下文。 如果我们能把设计体系变成机器可读的协议文件，AI 生成的产物是不是就可以自带一致性？

这是一个正在探索的方向，不是成熟的方案。分享出来供大家讨论和指教。

先看一下当前的产物

当前构建出的是一套协议驱动的设计系统引擎——不是一个组件库，而是一个治理组件库的基础设施层。

它由三套互相引用的协议文件 + Schema 验证 + 生成管线组成。所有协议文件都是标准 JSON/YAML，不依赖任何特定框架或 AI 产品。

当前已覆盖 14 个组件协议 + 6 个 Section 协议 + 1 套设计语言定义 + 1 套 Token 清单，以及对应的 JSON Schema 验证和注册表生成器。

我想解决什么问题，不解决什么问题

我想解决的：

1. 让 vibe coding 的产物有传递性和延续性。 不是生成完就是一次性的——而是生成的结果能被交接、能被复用、能在后续迭代中保持一致。关键是引入一层"设计约束协议"作为 AI 的上下文，让不同人、不同时间、不同模型的产出都在同一个框架下。

2. 让 AI 产出自带可解释性。 为什么用了这个颜色？为什么按钮是这个形状？不该由人事后猜测。协议中记录了设计决策的"为什么"，AI 生成时参考协议、产出时附带来源——让主观产出可分析、可对话。

3. 让业务方和产品可以在设计体系内自由创作，而不需要等设计排期。 现在的痛点是两极：要么受限于现有组件库的固定形态，要么 vibe coding 出一堆脱离设计体系的东西。协议提供的是"栏杆"——你在栏杆内可以自由奔跑。

4. 让创意可以多轨并行、快速具象化、然后理性比较。 同一个需求，在同一套设计约束下生成 3 种方案进行比稿。差异是可枚举的（用了不同的布局策略、不同的色彩强调），而不是"感觉不太对但说不清哪里不对"。

我不解决的：

• 不做 AI 生图（有专门的工具做这件事，我只管从设计到代码的结构化约束）
• 不做端到端全自动化（人的审美判断仍然是最终守门人，但 AI 可以大幅降低执行成本）
• 不做通用解决方案（每个品牌的设计语言不同，引擎需要为特定品牌定制协议内容）

我的思路是什么

核心想法：把"设计潜规则"变成"机器可读的协议"

这个想法是在和设计专家讨论后逐渐成形的。他们帮我意识到：设计系统里最值钱的不是组件代码，而是设计决策背后的"潜规则"——为什么是深色主题？为什么间距梯度是 4-8-12-16 而不是 5-10-15-20？为什么 Tab 溢出时用滚动而不是换行？

这些"潜规则"通常存在于：设计师的脑子里、评审会议的录音里、Figma 文件的批注里、或者根本没人记录。它们随着人员变动而丢失，对 AI 更是完全不可见。

所以我试着做的事情是：把这些潜规则变成结构化的协议文件（JSON），让它们可以被机器读取、被校验、被 AI 作为生成代码时的上下文。

打个比方：协议文件就像"开车的交规"。有了交规，不同的人开不同的车（不同的人用不同的 AI 模型），产出的行为都有一个共同的底线和规范。没有交规，每个人按自己的习惯来，结果就是混乱。

三层协议体系

设计语言协议（language.json）回答"我们的视觉体系是什么，为什么是这样"：

{
  "identity": {
    "name": "Horizon Design",
    "baseMode": "light",
    "description": "基于品牌基因的 B 端数字业务设计系统"
  },
  "principles": [
    {
      "id": "pure",
      "name": "纯粹",
      "statement": "去除一切不必要的视觉元素",
      "selfCheck": "去掉这个元素后页面会变差吗？"
    }
  ],
  "dimensions": {
    "color": {
      "intent": "以 6 组色板构建颜色层级：灰阶承载背景与文本，品牌 teal 负责关键高亮",
      "tokens": {
        "background": ["bg-base", "bg-surface", "bg-elevated"]
      }
    }
  }
}

每条设计原则的 selfCheck 不是装饰——它是一个可执行的验证问题。每个维度内嵌 Token 引用——查阅色彩意图时立即看到可用 Token，人和 AI 都不需要跳转。

组件协议（component.json）不仅描述组件"有什么"，还记录"为什么这样设计"：

{
  "name": "tabs",
  "level": "L2",
  "status": "stable",
 
  "designIntent": {
    "why": "内容分区导航的标准模式，减少页面层级深度",
    "decisions": [
      {
        "question": "Tab 溢出时如何处理？",
        "decision": "横向滚动 + 渐变遮罩，不换行",
        "rationale": "换行会破坏视觉一致性和空间效率"
      }
    ],
    "brandAlignment": "纯粹——简洁的导航体验"
  },
 
  "tokens": {
    "colors": ["background", "foreground", "muted", "muted-foreground"],
    "dimensions": ["radius"]
  },
 
  "states": {
    "required": ["default", "active"],
    "optional": ["disabled", "hover"]
  }
}

6 个月后有人问"这个交互为什么是这样"，答案在协议里，不在某个人的记忆里。AI 需要理解组件约束时，读取的是结构化的 decisions[] 数组，而非含混的自然语言。

验证管线：协议不只是文档

协议如果只能被人类阅读，那它和 README 没有本质区别。引擎的价值在于让协议可执行。

通过 JSON Schema 强制：增加一个 Token 但不解释它的用途 → CI 构建失败。组件引用了一个未注册的 Token → CI 构建失败。文档完整性通过 Schema 约束保障，而非依赖人工自觉。

引擎的端到端流程

把上面的各个部分串起来，整套引擎实际跑起来的流程是这样的：

流程说明：

1. 设计输入 — 设计专家从品牌手册、Figma 规范中提炼核心设计决策（"为什么深色"、"为什么这个间距"）
2. 协议编写 — 将设计决策结构化为三层 JSON 协议文件（目前主要由我来写，设计师 review）
3. 引擎处理 — Schema 验证确保格式正确、交叉验证确保 Token 引用完整，然后生成注册表
4. 产出 — 生成供不同消费者使用的产物：注册表（内部参考）、CSS 变量（开发直接用）、AI 索引（Agent 消费）
5. 消费 — 开发者基于组件协议实现组件；AI Agent 读取协议生成代码；业务方 vibe coding 时受协议约束

整个流程的核心设计原则是：协议是单一事实来源（Single Source of Truth）。无论是开发者查文档、AI 读上下文、还是 CI 跑校验——都指向同一份协议文件。改一处，所有下游自动对齐。

现有的方案有哪些，我的有什么不同

我对 8 个维度（Token 标准、组件协议、设计到代码追溯、AI 集成、治理验证、上游同步、文档生成、生态可移植性）进行了深度竞品分析，涵盖 Material Design 3、Ant Design、shadcn/ui、Adobe Spectrum、Carbon 等。

业界已经解决的

• Token 三层架构——Primitive → Semantic → Component 是行业共识。W3C DTCG 的 $type/$value 正在成为事实标准
• 组件文档自动化——Storybook Autodocs、TypeDoc 让 prop 表格不再手写
• 视觉回归测试——Chromatic/Percy 已成为设计系统 CI 的标配
• 代码是权威来源——Figma 是输入端，Git 是事实来源，业界共识是 diff→PR→审核→合并

与 DESIGN.md (Google Labs) 的对比

在这个方向上，必须提到 Google Labs 今年发布的 DESIGN.md 格式。它和我在做的事情目标高度一致——都是让设计系统变得 AI 可读。两者最相似，也最容易被拿来比较，所以有必要说清楚异同。

我的看法：DESIGN.md 走的是"标准格式"路线——定义一个好的格式，让所有 AI Agent 都能直接消费。这是一条正确且更轻量的路。我走的是"引擎"路线——更重、更完整，但也更适合需要深度治理的大型设计体系。

两者不是竞争关系，而是互补。我后续计划之一就是让协议引擎输出 DESIGN.md 格式——引擎做深度治理，DESIGN.md 做生态兼容。就像 TypeScript 编译后输出 JavaScript——内部用强类型，外部给标准格式。

业界没有解决的（也是我认为的差异化空间）

一个具体的对比：vibe coding 前后

没有协议时，产品经理用 AI 生成一个页面：

PM: "帮我生成一个数据看板页面"
AI: (按照 GPT 的通用审美生成一个浅色风格的看板)
PM: "不对，我们产品是深色的"
AI: (改成深色，但用了 AI 自己理解的蓝色调)
PM: "配色不太对，不是这个蓝"
AI: (换了个蓝，还是不对)
...反复调整，最终交付设计和开发时又要重做...

有协议时：

AI 读取 language.json → 深色主题，品牌基因是"纯粹"
AI 读取 tokens.json → 精确的颜色变量名和数值
AI 生成代码 → 直接使用 Token 变量，风格一致
不同人在不同时间用不同 AI 工具生成 → 都在同一套约束下，风格连贯

区别在于：前者的一致性依赖多轮人工纠正和个人经验，后者依赖一次性的结构化约束——无论谁来生成，无论用什么 AI 模型。

当前的前提和局限性

前提（这些东西如果不成立，方案就走不通）：

1. 设计团队愿意把设计决策写下来——协议的内容需要设计师参与定义，不是开发者能独立完成的。我自己在这个过程中大量依赖了设计专家的输入
2. 品牌设计语言已经相对成熟——引擎治理的是已有体系，不能帮你从零创建审美
3. AI 是辅助，人是守门人——协议降低的是执行成本和沟通成本，不是取消设计评审

局限（诚实地说）：

• 协议维护本身有成本——每个组件的"为什么这样设计"需要有人去填写和更新，这不是零成本的
• 对设计师来说 JSON 不友好——理想状态是有可视化的协议编辑器，目前还没有
• 多平台输出未实现——当前只输出 Web 端的 CSS 变量，移动端需要额外的构建管线
• AI 理解协议的深度有限——目前 AI 能用协议中的 Token 变量和颜色值，但对"设计意图"的理解还不够深
• 是一个人的探索——还没有经过大团队的验证和打磨，很多地方需要迭代

关于开发方式：

这套东西的设计和开发过程大量使用了 AI 协作——用 AI 来加速调研、写协议初稿、生成代码。但产出的文件本身（JSON 协议、校验规则、生成脚本）都是标准格式，不绑定任何 AI 产品。换句话说，协议可以完全手写维护，AI 只是让过程更快。

近期还有哪些想迭代的内容

短期（确定要做的）：

1. Token 迁移到 W3C DTCG 格式——采用 $type/$value 语法，三层命名（ref/sys/comp），接入 Style Dictionary v4，实现一份 Token 源文件多平台输出（CSS / Swift / Kotlin）
2. 将引擎驱动体系 CLI 化——协议校验、注册表生成、Token 编译等流程封装为 CLI 命令，减少人工介入、提升执行效率和准确率，同时降低使用门槛和成本
3. 泛化技术栈，支持多框架生成——同一套协议约束下，能够生成 React、Vue 3 或其他前端框架的设计体系页面，不再绑定单一技术栈

中期（想探索的方向）： 4. 完整实现 Horizon 设计系统的所有组件和部分 Section/页面——尝试对齐样板间（Showroom），从协议走到真正可交付的产物 5. 支持多方向多场景比稿——基于同一套协议约束，AI 生成多个视觉方案供选择，让创意决策有据可比 6. 整体流程线上化——从设计输入、协议编辑、验证、生成到交付，实现端到端的线上协作流程

结语

回到最初的问题：如何让 需求 → 视觉 → 页面 这条产线跑得更顺畅？

我现在的答案是：不是让 AI 更聪明，而是给 AI 更好的约束。 协议文件就是这个约束——它让不同的人、不同的工具、不同时间的产出都有一个共同的质量底线。

当这一点成立时：

• 产品经理 vibe coding 出来的页面不再让设计师崩溃——因为风格被协议约束住了
• 新人接手时不再需要考古——因为"为什么这样设计"记录在协议里
• 多轨比稿变得可行——因为约束相同时，差异就是有意义的创意差异，而非随机噪声

这仍然是一个非常早期的探索。我不确定所有的设计决策都能被结构化，也不确定协议维护的成本在大团队中是否可接受。但如果你也在思考类似的问题——如何在 AI 时代让设计产出既有创造力又有一致性——欢迎一起讨论。