1. 项目概述：当设计遇上智能体

最近在跟几个做产品经理和前端开发的朋友聊天，大家不约而同地提到了一个词：Agent。无论是讨论如何用AI自动生成UI，还是研究如何让一个智能助手理解并执行“把那个按钮调大一点，颜色再柔和些”这样的模糊指令，我们都发现了一个核心痛点——现有的设计工具和流程，似乎有点跟不上“智能体”的思维速度了。我们习惯了为“人”设计规则清晰、步骤明确的界面，但当交互对象变成一个能自主感知、决策和执行的AI Agent时，传统的那套设计方法论，就像用马车交通规则去管理自动驾驶汽车，处处透着别扭。

这就是Vibe Design出现的背景。它不是一个具体的设计软件，也不是某个UI框架，而是一套正在被社区热烈讨论的、面向AI Agent（智能体）的设计规则与范式。你可以把它理解为，为了让人类设计师、开发者能与AI Agent高效协作，甚至是为Agent之间能够互相理解彼此的“产出物”（比如界面、布局、指令），而建立的一套“通用语言”和“行为准则”。简单来说，Vibe Design的核心目标是：让设计变得可被Agent感知、理解和执行。

这听起来有点抽象，我举个例子。以前我们设计一个登录框，会在Figma里画好矩形、输入框、按钮，标注好间距、颜色、字体。这些信息是给人（开发者）看的。但一个AI Agent要自动实现这个登录框，它需要“读懂”Figma文件，这中间存在巨大的语义鸿沟。Vibe Design试图做的，就是定义一种结构化的描述方式，比如一个DESIGN.md文件，里面用Agent能直接解析的格式写明：“这里需要一个表单容器，包含两个文本输入字段（标签为‘用户名’和‘密码’），一个提交按钮，整体遵循简约风格。” Agent拿到这个文件，就能像读取API文档一样，准确地生成或修改代码。

所以，Vibe Design适合谁？所有需要与AI协作进行数字产品创造的人。这包括但不限于：希望用AI提效的UI/UX设计师、正在构建具备前端能力的AI Agent的开发者、研究人机交互与AI生成内容的工程师、以及任何对“未来如何设计”感到好奇的从业者。接下来，我将结合最近的实践和思考，拆解Vibe Design的核心思路、关键规则以及我们如何在项目中应用它。

2. Vibe Design的核心规则拆解：从“像素精确”到“意图传达”

传统的GUI设计规则，无论是苹果的《人机界面指南》还是Material Design，其终极服务对象是人类用户和人类开发者。规则侧重于视觉美学、交互逻辑和可访问性，其传达依赖于人类的视觉感知和经验理解。而Vibe Design的规则，首要服务对象是AI Agent。这意味着规则必须从“视觉描述”转向“结构化意图描述”，从“模糊的审美”转向“可计算、可推理的参数”。

2.1 规则基石：结构化设计描述（DESIGN.md）

这是Vibe Design最核心的载体。它不是一个简单的注释文件，而是一个机器可读的“设计契约”。其内容超越了传统的设计标注（尺寸、颜色值），更侧重于组件语义、布局关系、交互状态和设计约束。

一个基础的DESIGN.md可能包含以下模块：

# 页面：用户主页 ## 设计意图 (Design Intent) - 目标：展示用户核心信息，提供快捷操作入口。 - 情绪基调 (Vibe)：专业、清晰、略带亲和力。 - 核心用户任务：查看概览、快速导航至设置或消息中心。 ## 布局系统 (Layout System) - 类型：响应式网格布局 (12列栅格)。 - 断点定义： - `mobile`: < 768px， 单列流式布局。 - `tablet`: 768px - 1024px， 双列布局。 - `desktop`: >= 1024px， 三列布局，侧边导航固定宽度。 - 间距基准：`8px` (所有内外边距应为8的倍数)。 ## 核心组件规格 (Component Specs) ### 1. 用户信息卡片 (UserProfileCard) - **语义角色**： `region`， `article`。 - **层级结构**： 1. 容器 (Container): 圆角`12px`， 背景色`surface-primary`， 内边距`24px`。 2. 头像 (Avatar): 圆形， 尺寸`64px`， 边框`2px solid border-subtle`。 3. 姓名 (Name): 标题级别 `h2`， 字体权重 `semibold`， 颜色 `text-primary`。 4. 描述 (Bio): 段落文本， 颜色 `text-secondary`， 最大行数 `3` (超出显示省略号)。 - **交互状态**： - `hover`: 容器阴影提升一级 (`shadow-md` -> `shadow-lg`)。 - `active`: 容器背景色轻微变深 (`surface-primary-hover`)。 - **数据绑定**： `avatar_url`, `user_name`, `user_bio`。 ### 2. 主要操作按钮 (PrimaryActionButton) - **语义角色**： `button`。 - **变体**： `default`, `danger`, `disabled`。 - **约束规则**： - 同一视图内， 最多出现一个 `danger` 变体。 - `disabled` 状态必须同时设置 `aria-disabled="true"` 和视觉灰化。

为什么需要如此详细的结构化？因为AI Agent不具备人类的“常识”和“审美直觉”。你告诉它“做一个好看的卡片”，它可能无所适从。但如果你告诉它“创建一个符合UserProfileCard规格的组件，绑定{user_name: ‘张三’}数据”，它就能准确无误地执行。这极大地减少了歧义和反复沟通的成本。

注意：DESIGN.md的颗粒度需要权衡。过于粗放则指导性不足，过于细致则维护成本高，可能扼杀Agent的创造性。实践中，我们通常只为核心业务组件和全局设计令牌定义详细规格，对于一次性或简单的展示元素，可以只描述意图和约束，给予Agent一定的发挥空间。

2.2 规则核心：设计令牌的Agent友好化

设计令牌（Design Tokens）是存储视觉设计属性的变量（如颜色、字体、间距）。在Vibe Design中，令牌系统必须升级。

1. 语义化命名取代具体值：不要用color: #3b82f6， 而要用color: primary-action。Agent只需要知道这里需要用“主要操作颜色”，具体的色值由另一套令牌系统或品牌主题决定。这保证了设计的一致性和主题切换能力。
2. 定义状态和上下文：令牌需要包含状态信息。例如：
   • text-primary(默认状态)
   • text-primary-hover(悬停状态)
   • text-primary-disabled(禁用状态)
   • text-primary-on-dark(深色背景上的状态) 这样，当Agent需要为一个处于禁用状态的按钮应用文字颜色时，它可以直接查找text-primary-disabled这个令牌，而不需要去推理“禁用状态应该是灰色，灰色是#6b7280”。
3. 暴露计算关系：有些属性是关联的。例如，border-radius可能是spacing-unit / 2。在令牌系统中明确定义这种计算关系，能让Agent在响应式调整时保持比例和谐，而不是机械地缩放所有数值。

2.3 规则延伸：组件组合与布局逻辑

Vibe Design鼓励定义组件组合模式，而不仅仅是原子组件。这类似于告诉Agent一些“设计套路”。

例如，在DESIGN.md中可以定义：

## 组合模式：数据仪表盘卡片 (DashboardCardPattern) - **适用场景**：展示关键指标（KPI）。 - **固定结构**： 1. 标题区 (Header): 包含指标名称和一个可选的`info`图标。 2. 主体区 (Body): 核心数值， 使用强调字体。 3. 趋势区 (Trend): 可选， 显示环比/同比变化， 用箭头图标和颜色表示正负。 - **布局规则**： 主体区垂直居中于卡片， 标题左对齐， 趋势右对齐。 - **变体**： `compact` (紧凑， 减少内边距)， `highlight` (高亮， 使用主色边框)。

当Agent需要创建一个展示“今日活跃用户”的卡片时，它可以直接实例化DashboardCardPattern，并填入“活跃用户”、“15,842”、“+12%”等数据，快速生成一个符合设计规范且语义正确的组件，而不是从零开始拼凑一个标题、一个数字和一个箭头。

3. 实操：将Vibe Design集成到Agent开发工作流

理论说再多，不如看看怎么用。假设我们正在开发一个“前端代码生成Agent”，它接收产品原型的自然语言描述或草图，输出符合Vibe Design规则的React组件代码。以下是关键步骤。

3.1 第一步：建立项目级设计契约

在项目根目录创建/design-system/文件夹，里面存放Vibe Design的核心文件：

/design-system/ ├── DESIGN.md # 主设计文档，描述全局意图、布局、核心模式 ├── tokens.json # 设计令牌定义（JSON或YAML格式，便于程序读取） ├── components/ # 核心组件规格库 │ ├── Button.spec.md │ ├── Input.spec.md │ └── Card.spec.md └── patterns/ # 组合模式库 ├── DataCard.pattern.md └── FormSection.pattern.md

tokens.json示例：

{ "color": { "primary": { "value": "#3b82f6", "type": "color" }, "surface-primary": { "value": "#ffffff", "type": "color" }, "text-primary": { "value": "{color.gray.900}", "type": "color" }, "text-primary-hover": { "value": "{color.primary}", "type": "color" } }, "spacing": { "unit": { "value": "8px", "type": "spacing" }, "sm": { "value": "{spacing.unit}", "type": "spacing" }, "md": { "value": "calc({spacing.unit} * 2)", "type": "spacing" } } }

关键点：使用{...}引用其他令牌，建立动态关系。Agent的解析器需要能解析这种引用链。

3.2 第二步：构建Agent的“设计理解”模块

你的AI Agent需要有一个模块，专门负责解析和理解DESIGN.md和设计令牌。这通常结合以下技术：

1. 文档解析器：将Markdown解析成结构化的JSON或Python字典。可以使用python-markdown等库，并自定义扩展来识别特定的元数据（如## 组件规格后面的内容）。
2. 令牌解析器：读取tokens.json，并解析其中的引用和计算。最终输出一个平坦的、包含最终计算值的字典，供代码生成时使用。
3. 语义映射层：这是最核心的部分。它需要将设计文档中的语义描述映射到具体的实现技术。
   • 输入：“创建一个UserProfileCard”
   • 映射过程：
     • 查找components/UserProfileCard.spec.md。
     • 解析其层级结构：容器(div)、头像(img)、姓名(h2)。
     • 应用对应的样式类或内联样式（从设计令牌获取值）。
     • 应用交互逻辑（如hover状态对应CSS:hover伪类）。
     • 绑定数据占位符。

这个模块的输出，是一个中间表示，它包含了生成最终代码所需的所有结构化信息，但独立于任何前端框架（React, Vue, Svelte）。

3.3 第三步：实现代码生成与“缝合”

有了中间表示，就可以进行代码生成。这里就涉及到另一个热词：Stitch。你可以把Stitch理解为一种“代码缝合”理念或工具，它负责将不同的代码片段、逻辑和资源，按照设计规则“缝合”成可运行的产物。

在我们的场景下，代码生成器就是执行“缝合”的角色。它根据中间表示和目标技术栈，选择对应的代码模板进行填充。

以生成React组件为例：

1. 模板定义：为每种组件类型（如Card，Form）准备基础的JSX/TSX模板。
2. 属性注入：将解析得到的设计令牌值（如颜色、间距）注入到模板的样式部分（可能是CSS-in-JS对象或Tailwind CSS类名）。
3. 结构生成：根据层级结构描述，递归生成嵌套的JSX元素。
4. 交互绑定：为元素添加事件处理器（如onClick）和状态逻辑（如useState）。

最终，Agent输出的是一个完整的、符合项目设计规范的React组件文件。如果设计令牌或DESIGN.md更新，重新运行Agent，就能批量更新所有相关组件的外观，确保一致性。

实操心得：在初期，不要追求Agent生成100%完美的生产代码。更务实的路径是让Agent生成高质量的、符合设计规范的样板代码和静态结构，然后由开发者填充复杂的业务逻辑和状态管理。这已经能节省大量重复性布局和样式工作。我们团队内部称之为“80%解决方案”，即Agent负责那80%枯燥、规范化的部分，人负责20%需要创意和复杂判断的部分。

4. 面向Agent的设计思维转变与常见挑战

adopting Vibe Design不仅仅是引入一套新工具，更要求设计师和开发者进行思维模式的转变。

4.1 从“视觉驱动”到“语义驱动”的设计

设计师不能再只专注于“这个圆角是4px还是6px看起来更舒服”，而要思考“这个元素的语义角色是什么？它在不同状态和上下文下应该如何表现？” 你需要用Agent能理解的语言去定义设计系统。这促使设计决策更加理性、系统化，减少主观随意性。

4.2 从“一次性交付”到“持续协作”的开发

开发者与设计师的协作节点发生了变化。以前是“设计稿交付，开发实现”。现在则是“共同维护DESIGN.md和设计令牌，Agent基于此持续生成和同步代码”。开发者需要理解设计规则的机器可读性，设计师需要了解技术实现的基本约束，双方在“定义规则”这个层面需要更紧密的协作。

4.3 常见问题与排查技巧

在实际推行Vibe Design的过程中，我们遇到了不少坑，这里分享几个典型的：

问题1：Agent生成的设计过于呆板，缺乏“灵气”。

• 原因：DESIGN.md规则定义得过于死板，只规定了“必须怎么做”，没有给Agent留下任何“可以怎么做”的弹性空间。
• 解决方案：在规则中引入“权重”或“优先级”概念。例如，定义“主要按钮必须是品牌主色”为高优先级约束，而“按钮圆角在4-8px之间”为低优先级建议。同时，可以提供多个符合规则的“优秀示例”供Agent参考学习，而不仅仅是冰冷的参数。

问题2：设计令牌更新后，已有生成的代码不会自动同步。

• 原因：生成的代码是静态的，与动态的设计令牌源文件失去了链接。
• 解决方案：不要直接生成最终的颜色值或尺寸值。而是生成对设计令牌的引用。
  • 较差的做法：生成style={{ color: ‘#3b82f6’ }}
  • 推荐的做法：生成style={{ color: ‘var(--color-primary)’ }}或使用Utility Class如className=“text-primary”。 这样，当tokens.json中的primary值改变时，所有引用该令牌的样式都会自动更新。这要求你的前端工程体系支持CSS变量或Tailwind等原子化CSS框架。

问题3：多Agent协作时，设计规则理解不一致。

• 原因：一个团队可能有负责生成UI的Agent、负责生成文案的Agent、负责检查可访问性的Agent。如果它们对“标题”的语义级别理解不同，就会产出混乱的结果。
• 解决方案：建立统一的、共享的语义化词汇表。这个词汇表需要所有Agent共同遵守。例如，在项目级定义：
  • heading-1: 用于页面主标题，视觉上最大，对应HTML<h1>。
  • heading-2: 用于主要章节标题，对应<h2>。
  • body-large: 用于重点正文。 每个Agent在生成或处理内容时，都必须使用这个标准词汇表来引用样式，而不是直接使用具体的字体大小或权重值。

问题4：如何处理复杂交互和动态布局？

• 原因：DESIGN.md擅长描述静态结构和样式，但对“点击这个按钮后，侧边栏滑入，同时主内容区变暗”这样的连续交互逻辑，描述起来很吃力。
• 解决方案：将交互逻辑与视觉规则分离定义。DESIGN.md专注于视觉和结构。对于复杂交互，可以定义“交互模式”或“行为片段”，并用伪代码或状态机来描述。

  ## 交互模式：模态框唤起 (ModalTriggerPattern) - **触发元素**： 任意按钮或链接。 - **关联元素**： 一个ID为 `modal-{id}` 的模态框组件。 - **行为**： 1. 点击触发元素。 2. 将关联模态框的 `isOpen` 状态设为 `true`。 3. 为 `<body>` 添加 `overflow: hidden` 样式。 - **退出方式**： 点击模态框遮罩或关闭按钮，反转上述状态。

  Agent在生成触发按钮的代码时，会附带一个调用openModal(‘modal-id’)的onClick事件。这需要前后端Agent有一定的逻辑协同能力。

5. 进阶应用：多模态输入与动态设计调整

Vibe Design的终极愿景，是让Agent成为设计的“协作者”而不仅仅是“执行者”。这意味着Agent需要能理解更模糊的输入，并做出合理的、符合规则的设计决策。

场景：通过自然语言指令调整设计。用户对Agent说：“把这个页面的色调调得温暖一些。”

• 传统方式：Agent不知所措，或者胡乱调整几个色值。
• 基于Vibe Design的方式：
  1. Agent解析指令，识别关键词“色调”、“温暖”。
  2. Agent查询设计令牌系统，找到影响“色调”和“温度感”的令牌，主要是color.primary，color.secondary等基础色板，以及color.surface等背景色。
  3. Agent根据内置的色彩理论（例如，增加红色/黄色分量，减少蓝色分量可以营造“温暖”感），在不违反品牌色相基本约束的前提下，生成一组新的、色温更高的颜色候选值。
  4. Agent将候选值应用到当前页面的设计令牌副本中，生成一个临时的预览，并询问用户：“已根据‘温暖’主题调整了主色和背景色，这是预览A（偏橘）和预览B（偏米黄），您更喜欢哪一种？”
  5. 用户选择后，Agent可以将这次调整记录为一个“主题变体”，或如果用户确认，则提议更新全局的tokens.json。

这个过程体现了Vibe Design的高阶能力：在规则边界内进行创造性推理和迭代。它要求设计系统本身具备一定的“弹性”和“可推导性”，而Agent则需要具备基础的色彩、布局知识模型。

6. 工具链展望与当前生态

目前，Vibe Design更像是一个理念和社区共识，还没有一个叫“Vibe Design”的官方工具。但其思想正在被多个工具和框架吸收。

• 设计工具侧：Figma、Sketch等正在加强其API和插件能力，允许更结构化地导出设计数据，这为生成DESIGN.md类文件提供了基础。一些插件已经开始尝试将设计稿自动转换为设计令牌。
• 开发框架侧：Tailwind CSS、Styled System 等本身倡导的Utility-First和约束性设计，与Vibe Design的令牌化、规则化思想高度契合。它们可以很好地作为Vibe Design规则的实现层。
• AI Agent框架侧：像Hermes、AutoGPT等AI Agent开发框架，正在集成越来越多的工具调用能力。为这些框架开发一个“Figma解析器”或“设计规则检查器”插件，是实现Vibe Design工作流的关键一步。
• “缝合”工具：Stitch所代表的概念，可能由一些低代码平台、代码生成器（如GPT Engineer、Claude Code）或构建系统（如Vite、Webpack的特定插件）来实现，负责将设计规则、业务逻辑和数据进行最终组装。

个人体会是，现阶段完全自动化的、端到端的Vibe Design工作流还不成熟，但我们可以从今天开始，有意识地在项目中实践其核心思想：用结构化的、机器可读的方式描述设计。哪怕只是从一个清晰的、包含语义化令牌的tokens.json文件开始，或者为你的核心组件库编写一份详细的、面向开发者的（同时也是未来面向Agent的）COMPONENT_SPEC.md，都是在为未来的AI协作铺路。当Agent的能力到来时，那些设计系统规范、文档健全的项目，将能最快地享受到生产力跃升的红利。