为什么 Google Stitch 的 DESIGN.md 值得关注：AI UI 正从出图工具走向设计基础设施

最近连续看了两份关于 Google Stitch 的内容：

• 一份是官方文档，讲 DESIGN.md 的格式规范
• 一份是一线使用者在 X 上的实战分享，讲 Stitch 2.0 到底好用在哪

把这两份内容放在一起看，我的感觉很明确：

Google Stitch 值得关注的，不是它能不能再快一点生成 UI，而是它正在把“设计系统”变成一种 AI 可读、可执行、可复用的基础设施。

而 DESIGN.md，就是这个方向里最关键的一层。

---

先说结论：Stitch 的重点已经不是“生成页面”，而是“稳定生成整套一致的页面”

现在市面上大部分 AI UI 工具，都能做到一句话出个页面。

问题不在于“能不能出”，而在于：

• 第二页开始风格就飘了
• 颜色、字号、组件逻辑不统一
• 换个项目就得重新讲一遍设计风格
• 设计意图传到 coding agent 那里就失真了

所以真正难的从来不是生成一张图，而是：

如何生成一整套风格统一、可持续迭代、能交给后续 agent 接着干的 UI 系统。

Stitch 现在做的，明显是在解决后者。

---

DESIGN.md 到底是什么？

从官方文档来看，DESIGN.md 不是普通的 Markdown 说明文件。

它有两层含义：

第一层：给人看的设计摘要

你可以把它理解成一份设计系统说明书，里面会写：

• 整体风格是什么
• 颜色怎么定义
• 字体怎么搭配
• 组件有什么约束
• 什么该做，什么不该做

这一层适合设计、产品、开发一起读。

第二层：给机器消费的结构化 token

文档里明确讲了一个重点：DESIGN.md 背后其实对应的是 Stitch 维护的 structured tokens。

也就是说：

• 你看到的是 Markdown
• Stitch 实际消费的是结构化设计数据

这就很关键。

因为它意味着：

DESIGN.md 不是随手写的设计笔记，而是一种“人类可读 + 机器可执行”的设计规范格式。

这和传统设计文档的区别非常大。

---

为什么这件事重要？因为 Prompt 不够了

今天很多人做 AI 设计，还是靠 prompt：

• 做一个科技感强一点的 landing page
• 用深色主题
• 风格参考 Linear 和 Stripe
• 卡片圆角柔和一点

这当然能出图。

但问题是 prompt 有天然缺陷：

• 不稳定
• 复用差
• 跨页面不一致
• 很难传递给后续 coding agent
• 很难变成团队长期资产

DESIGN.md 的价值就在这里。

它相当于在 prompt 上面加了一层“持久规范层”：

• 这次定义完，下次还能用
• 可以导入导出
• 可以跨项目迁移
• 可以给 agent 直接读
• 可以让整个设计系统成为长期资产

如果类比一下，它有点像：

• 产品里的 PRD
• 前端里的组件规范
• 代码里的 API schema

只是它现在作用在“设计”这一层。

---

Stitch 2.0 的升级，证明它想做的不只是出图

那篇 X 上的实战文章其实很有价值，因为它不是讲概念，而是讲具体体验。

里面提到几个点，我觉得和 DESIGN.md 一起看特别有意思。

1. 主题系统

Stitch 现在支持：

• 选择主题
• 切换多种色彩搭配
• 手动改主题色
• 改完之后自动全局更新已有页面

这说明什么？

说明 Stitch 底层处理的已经不是单张页面，而是一套全局设计变量。

这和 DESIGN.md 背后的设计 token 逻辑完全一致。

2. 无限画布

作者提到，现在界面更像 Figma 了，有一个可无限延展的画布。

这意味着 Stitch 的目标已经不是“帮你生成一页落地页”，而是在往多页面产品设计空间演进。

3. 即时可交互原型

多个页面可以 Stitch 在一起，系统还能自动推断点击某个按钮后该跳转到哪个页面。

这说明它已经在覆盖：

• 静态视觉设计
• 页面关系
• 原型交互逻辑

也就是从“画图”往“设计流程”走。

4. HTML 导出 + AI 编码重构

作者的实际工作流是：

1. 先用 Stitch 生成 UI
2. 导出 HTML 和设计图
3. 丢给 Claude Code / Codex 做实现
4. 再让 sub-agent 审计间距、字号、颜色、布局层级
5. 审计不过就反复修

这个工作流很值得注意。

因为它已经不是传统设计师工作流，而是典型的：

AI-native 设计 → AI-native 开发 → AI-native 审计

如果把 DESIGN.md 放进去看，它就像这条流水线里的“视觉规范中间件”。

5. MCP Server

作者还提到 Stitch 已经有 MCP Server，可以直接接进 Claude Code 或 Cursor。

这说明 Stitch 的野心不只是做个网页工具，而是想成为：

AI IDE 里的设计能力供应商。

这件事如果做成，意义会很大。

---

两篇内容合起来，最值得记住的 3 个洞察

洞察一：设计资产正在文本化

过去设计资产主要是：

• Figma 文件
• 色板
• 组件库
• 一堆零散规范文档

未来设计资产会越来越像：

• Markdown 规范
• Design tokens
• 可供 agent 消费的 schema
• 可以在项目之间传递的设计说明文件

DESIGN.md 就是这个趋势的典型产物。

---

洞察二：设计系统第一次真正能被 Agent 稳定消费

以前 AI 写前端，设计输入基本靠：

• 截图
• prompt
• 口头描述
• Figma 截屏

这些都不稳定。

而 DESIGN.md 这样的格式出现之后，设计系统第一次有机会变成一种：

• 可读
• 可解析
• 可执行
• 可传递

的 agent 输入。

这对 AI 编程工作流其实是个很大的变化。

---

洞察三：Stitch 更像 AI 时代的新设计基础设施，而不是 Figma 替代品

如果只看表面，会觉得 Stitch 是“AI 生成设计稿工具”。

但如果把这些能力放一起看：

• 主题系统
• 设计 token
• DESIGN.md
• 交互原型
• HTML 导出
• MCP Server

你会发现它真正想打通的是：

设计描述 → 设计系统 → 页面原型 → 代码实现 → 一致性审计

这已经不是单纯的出图工具逻辑了。

它更像在做一层新的设计基础设施。

---

这对独立开发者和 Agent 工作流玩家意味着什么？

我觉得至少有三个实际启发。

1. 以后做产品，设计系统也许可以先于代码沉淀

以前很多独立开发者是：

• 先写页面
• 再慢慢修 UI
• 最后风格越来越乱

未来可能更合理的顺序是：

1. 用 Stitch 出原型
2. 用 DESIGN.md 固化设计系统
3. 再让 coding agent 去实现
4. 再加审计 agent 保证还原度

这样设计系统反而变成了更早期的资产。

2. 多 agent 协作会越来越自然

一个很自然的链路可能是：

• Stitch 负责设计源头
• DESIGN.md 负责设计规范传递
• Coding agent 负责实现
• Audit agent 负责校验设计一致性

这比“一个 agent 从头干到尾”更靠谱。

3. AI 设计的胜负手不是速度，而是一致性

未来真正能拉开差距的，不是谁 10 秒钟出一张页面， 而是谁能：

• 做出一整套像同一个产品的页面
• 改主题后全局生效
• 在多个项目之间继承设计系统
• 让后续实现 agent 不跑偏

这才是产品化价值。

---

最后总结

如果只把 Google Stitch 看成一个“生成 UI 的 AI 工具”，会低估它。

真正值得关注的是，它正在把设计系统做成一种：

• 人类可读
• 机器可执行
• 跨项目可复用
• 可被 Agent 消费

的中间层。

而 DESIGN.md，就是这一层的核心。

一句话总结：

Stitch 的目标，不只是帮你画几张页面，而是把设计系统变成 AI 时代可以传递、执行和复用的基础设施。

如果这个方向成立，那它带来的变化，可能不会小于当年设计系统本身对前端工程的影响。