Vibe Design:面向 Agent 的设计规则来了

0 阅读10分钟

每次让 AI 做页面,很多人都会遇到同一个问题。
第一屏看着还行。
第二屏开始跑偏。
按钮、字体、间距、卡片阴影,越做越像另一个项目。

这件事很难彻底解决。你可以给它截图,可以给它一句句描述风格,也可以把 Figma 链接甩过去,但这些信息对 AI 来说都不够稳定。它能看懂一部分,也会脑补一部分。页面一多,风格就散。

这也是 DESIGN.md 出现的背景。

Google 在 2025 年 5 月 20 日的 I/O 上推出了 Stitch,这个工具的目标很直接,就是把自然语言或图片提示,尽快变成高保真的 UI 和前端代码。

到了 2026 年 3 月 18 日,Google 又给 Stitch 补上了一个很关键的东西,也就是 DESIGN.md。官方把它定义成一种适合 agent 阅读的 Markdown 设计规则文件,可以从 URL 抽取设计系统,也可以在 Stitch 和其他设计、编码工具之间导入导出设计规则。

awesome-design-md 是社区整理的示例库,作用很像现成模板库,帮你快速拿到一批可直接使用的 DESIGN.md 文件。Google 官方推出的是 DESIGN.md 这个思路和 Stitch 里的相关能力,社区仓库做的是把这个思路变成一堆可落地的样本。

为什么这东西值得学

DESIGN.md 的价值,说白了就是把设计约束从脑子里的感觉,变成项目里的文件。

以前你跟 AI 说做得高级一点、极简一点、像 Vercel 一点,这种信息都偏模糊。AI 生成出来的结果有时能看,有时完全飘。现在你可以直接把颜色、字体、字号层级、按钮风格、圆角、阴影、留白原则写进一个文本文件里,让 AI 先读规则,再生成页面。这样做页面就会更稳定了。

它真正有意思的地方还不止这里。

过去设计系统更多是设计团队的资产,放在 Figma、Design Token 平台或者一堆规范文档里。现在这套东西开始变成 AI 能直接消费的项目上下文。

也就是说,设计不再只是给人看的说明书,它开始变成机器也能执行的配置文件。这件事如果继续往下走,未来很多团队的设计交付方式都会变。交付物不再是设计稿,而是一份 AI 可以持续读取、持续执行的设计规则文件

所以我会建议现在就开始用:
第一,它成本很低。就是一个 Markdown 文件。
第二,它见效很快。尤其适合独立开发者、前端、产品经理,或者没有完整设计团队的小项目。
第三,它和现在的 AI 编码工作流天然契合。AI 本来就擅长读文本,DESIGN.md 恰好给了它一份足够结构化、又足够轻量的设计说明。
第四,越早养成这种习惯,后面你和 AI 的配合成本越低。项目一大,再补设计规则,通常会更痛苦。

插图1_工作流位置信息图.jpg

DESIGN.md 到底长什么样

如果你直接看社区仓库里的示例,会发现它本质上就是一份写得很细的设计系统说明。以仓库里的 Vercel 示例为例,一份典型的 DESIGN.md 通常会覆盖这些内容:

  1. 整体视觉气质
  2. 颜色体系和颜色角色
  3. 字体与字号层级
  4. 按钮、卡片、输入框、导航这些组件的样式规则
  5. 布局与留白原则
  6. 阴影和层级关系
  7. 推荐做法和禁止做法
  8. 响应式行为
  9. 给 agent 的提示语模板

你可以把它理解成一份为 AI 重写过的设计规范。它保留了设计系统的核心信息,但写法更适合模型读取和执行。

开始前,先准备这几样东西

如果你是第一次上手,不需要准备太复杂的环境。你只要有下面几样就够了:

  • 一个现成项目,哪怕只是空的前端项目
  • 一个 AI 编码工具,比如 Codex、Cursor、Claude Code 这类
  • 一份你看得顺眼的 DESIGN.md
  • 最好再有一个清楚的目标页面,比如官网首页、登录页、产品介绍页

如果你还没有自己的设计语言,最简单的起步方式,就是直接从 awesome-design-md 里挑一个风格。

标准上手教程

第一步,先选一个参考风格

对小白来说,第一步别想着自己写完整的 DESIGN.md。先借一份成熟样本更省时间。

你可以去仓库里挑一个你喜欢的网站风格,比如 Vercel 示例。每个站点通常都带三份文件:

  • DESIGN.md
  • preview.html
  • preview-dark.html

其中最有用的,其实不只是 DESIGN.md,还有 preview.html。因为它能让你先肉眼确认这套规则到底会产出什么感觉。很多人一上来就复制文件,结果做完才发现整体气质不对,白费一轮。

第二步,把 DESIGN.md 放进项目根目录

这一步非常重要。别把它扔进某个角落文件夹里。

大多数 AI 编码工具读取项目上下文时,都会优先关注根目录里的关键说明文件。你可以把目录整理成这样:

my-project/ DESIGN.md package.json src/ public/

如果你是直接用社区仓库里的样本,就把目标站点里的 DESIGN.md 复制出来,放到这里。

插图2_项目目录结构.jpg

第三步,先读一遍文件,别急着生成

这一步很多人会省掉,然后在第五步开始骂 AI。

你至少要先看三件事。

第一,这份 DESIGN.md 的整体气质是不是你要的。
第二,它写得细不细,有没有明确的颜色、字体、组件规则。
第三,它有没有你根本不想要的东西,比如重阴影、强渐变、很夸张的圆角。

如果这些都不对,后面再怎么提示,AI 也会带着错误的设计规则一路跑偏。

第四步,给 AI 的第一条指令要具体

很多人把 DESIGN.md 放进去之后,就只说一句做个首页。这个指令太粗了。

更稳的做法,是明确告诉 AI 先读 DESIGN.md,然后再限定页面目标、信息结构和输出范围。比如:

请先完整阅读项目根目录的 DESIGN.md。 基于其中的颜色、字体、间距、按钮、卡片和响应式规则, 先实现一个 SaaS 官网首页的首屏。 页面包含: 1. 顶部导航 2. 主标题和副标题 3. 两个 CTA 按钮 4. 一张产品预览图 要求: 1. 严格遵守 DESIGN.md 2. 先做桌面端,再兼顾移动端 3. 不要自由发挥新的颜色和组件风格 4. 先只完成首屏,不要一次铺满整页

你会发现,DESIGN.md 的作用不是替代提示词,是给提示词加地基。没有地基,AI 靠猜。有了地基,AI 才开始靠规则。

第五步,先做一屏,再扩整页

这是非常实用的一条经验。

不要一上来就让 AI 做完整站点。先让它做一屏,原因很简单。你需要先验证它有没有真正读懂 DESIGN.md。

你重点看这些地方:

  • 字体气质对不对
  • 按钮像不像同一套系统
  • 间距有没有明显失衡
  • 卡片、边框、阴影是不是按规则来
  • 移动端有没有直接塌掉

如果首屏都没站住,后面继续往下扩,只会把错误复制成更多页面。

第六步,不满意时,优先改 DESIGN.md,别只改提示词

这一步是很多人从试玩进入会用的分水岭。

如果你发现 AI 每次都把按钮做得太圆,或者阴影太重,或者标题不够克制,第一反应通常是继续加提示词。这样能救一次,但救不了下一次。更稳的办法,是直接修改 DESIGN.md 里的规则。

比如你可以这样改:

## Buttons - Primary button radius: 6px - Do not use full pill buttons for primary actions - Shadow should stay subtle and low contrast ## Typography - Headings should feel compact and restrained - Avoid oversized letter spacing

你把规则写进文件,AI 后面每一轮都会自动继承。这个时候,DESIGN.md 才真正开始像设计系统,而不只是一次性提示词附件。

第七步,开始扩展到第二屏、第三屏

首屏确认没问题之后,再继续往下做功能区、案例区、价格区、FAQ、页脚这些模块。

这时你要观察的重点已经变了。前面看的是单个模块像不像。到了这一轮,要看的是整站一致性。

比如:

  • 第二屏和第一屏是不是还像一个产品
  • 卡片体系有没有突然换了风格
  • 正文段落和标题层级有没有乱
  • 新增模块有没有偷偷发明新颜色

如果有,继续回头补 DESIGN.md,而不是只在当前模块打补丁。

第八步,如果你在用 Stitch,可以走官方工作流

如果你是直接用 Google Stitch,那它的玩法会更完整一些。

根据 Google 2026 年 3 月 18 日的官方更新,Stitch 已经支持两件事。
一件是从任意 URL 提取设计系统。
另一件是通过 DESIGN.md 在 Stitch 和其他工具之间导入导出设计规则。

对小白来说,最稳的用法是这样的:

  1. 先找一个你喜欢的网站,或者先在 Stitch 里做出第一版风格
  2. 让 Stitch 抽取或整理出设计系统
  3. 导出为 DESIGN.md
  4. 把这份文件放进你的代码项目根目录
  5. 再让编码 agent 按这份规则生成页面
  6. 如果代码侧改得更合理,再把规则回写到 DESIGN.md
  7. 需要时再带回 Stitch 继续迭代

这里我刻意没有去写某个按钮的瞬时文案,因为 Stitch 还在快速迭代,界面细节以后可能会变。但这个工作流本身是稳定的,今天能用,后面大概率也还成立。

第九步,学会把它当项目资产,而不是临时文件

当你项目里已经有 3 到 5 个页面都在按这份规则生成时,DESIGN.md 就别再把它当成一次性的实验文件了。

你应该把它放进版本管理。
每次改设计方向时,也同步改它。
如果团队里有多人协作,也让大家都认这一份规则。

到了这一步,它的价值才真正体现出来。你不再每次开新页面都重新讲一遍风格,转而在复用一套已经跑通的设计上下文。

最容易踩的几个坑

  1. 是把 DESIGN.md 当万能药。它能显著提升一致性,但页面的信息架构、文案质量、业务理解,还是得靠你自己给清楚。
  2. 是样本抄得太满。你用 Vercel 风格起步没问题,但如果连信息组织、文案口气、组件布局都一股脑复制,最后做出来的东西很容易像高仿站。更好的方式,是借它的设计语言,不要借它的业务表达。
  3. 是文件写得太抽象。像高级、现代、科技感这种词,AI 能理解一点,但不够稳。真正有效的,还是颜色值、字号层级、圆角、阴影、布局密度、组件约束这类具体规则。

最后

如果你今天还把 AI 做页面理解成多写几句提示词,那大概率已经开始落后了。

DESIGN.md 让设计规则第一次开始像代码规则一样,能被保存、复用、传递、版本化,也能被 agent 直接执行。这个方向一旦成立,后面的 UI 工作流会越来越成工程体系插图3_对比图.jpg

所以我的建议很简单。

如果你是小白,今天就去找一份现成的 DESIGN.md,先跑通一个首页。
如果你已经在用 AI 写前端,把 DESIGN.md 放进项目根目录,别再只靠口头描述风格。
如果你有自己的产品,尽早把那套隐性的审美偏好写成文件。越早写下来,后面返工越少。

这东西现在还早,但已经足够有用了。
早点用起来,收益是立刻的。