Stitch一句话生成可交互原型

Google Stitch 到底是什么，以及为什么”一句话生成整站”是个陷阱

Google Stitch 是 Google Labs 出品的免费 AI 界面设计工具，入口在 stitch.withgoogle.com。它的前身是被 Google 收购的 Galileo AI，2025 年 Google I/O 上作为其后继者正式亮相。引擎是 Google 自家的 Gemini 模型，部分资料指的是 Gemini 2.5 系列。2026 年 3 月 19 日，Stitch 2.0 发布，带来了五项关键能力：多屏生成（一次最多 5 个互相连接的屏幕，字体、颜色、组件保持一致）、AI 原生无限画布、更强的设计 Agent 与语音控制、即时原型（把静态屏变成可点击流程）、以及 DESIGN.md——一种可移植的纯文本设计系统格式。

几乎所有第一次打开 Google Stitch 的人都会做同一件事：在输入框里写一句”帮我设计一个 SaaS 产品的官网”，然后盯着生成结果发呆。生成出来的东西通常不难看——Gemini 的审美底子不差——但你会发现它不像一个产品，而像五张各自为政的漂亮海报。第一屏是深色科技风，第二屏忽然变成浅色杂志排版，按钮圆角从 8px 跳到 999px，主色从靛蓝飘到薄荷绿。

这不是 Stitch 的锅。这是提示方式的锅。一句话要整站，本质上是把”定义设计系统”和”消费设计系统”这两个完全不同的阶段压缩成了一次采样，模型只能凭运气在两者之间随机摆动，每一屏都重新掷一次骰子。

一句话生成整站的三个结构性缺陷

我把这个问题拆成三层，因为后面所有的操作都是为了绕开这三层。

第一层，上下文预算被浪费在重复推导上。每一屏生成时，模型都要重新决定一次主色、字阶、间距、圆角、阴影。这些决策本该只做一次。当你在一条提示词里要求 8 个页面时，模型实际上做了 8 次独立的设计决策，而它们之间没有任何强约束把它们绑在一起。

第二层，没有可审计的中间产物。你拿到的是 8 张图。图里有什么、为什么这么定，你无从追溯。想把”主色再深一点”这种要求贯彻到全部页面，你只能逐屏重新描述，而且每次描述都可能引入新的偏差。

第三层，无法增量维护。整站生成之后，你的下一次修改只能是”重新生成”或者”在单屏上手调”。重新生成意味着丢掉所有已经满意的部分，手调意味着 8 屏之间的一致性靠肉眼维护，越改越散。

“先规范后组件”为什么能解决跨页风格漂移

这是本文的核心论点，值得单独说清楚。

“先规范后组件”的做法是：先把设计决策从生成过程里抽出来，固化成一份纯文本的设计系统（DESIGN.md），再让每一次组件或屏幕生成都以这份文本为唯一事实来源。

它之所以能解决风格漂移，原因有三个，每一个都对应上面的一层缺陷。

其一，决策只做一次。主色、字阶、圆角、间距梯度全部在你确认 DESIGN.md 时被钉死。之后每一次生成，模型不是”凭感觉配色”，而是”读一份明确的规格然后执行”。上下文里有了硬约束，采样空间被压缩到只剩布局和内容，漂移的物理可能性就被消除了。

其二，有了可审计的中间层。设计规范是纯文本，你可以逐行改。”主色改成 #1A56DB”只需要改一行，然后让所有依赖它的屏重生成或者局部替换。这在整站一句话生成里是不可想象的，因为那里根本没有”一行”可以改。

其三，支持真正的增量。当设计规范稳定后，新增一个页面只是新增一次组件级生成，而不需要动其他任何东西。这是从”生成艺术品”转向”生成符合规范的交付物”的关键一步。

我的判断很明确：把 Google Stitch 当”一次成型的生成器”用，它会让你失望；把它当”设计规范的执行器”用，它是目前免费工具里最顺手的一个。这个视角转换比任何提示词技巧都重要。

读者定位与本文的组织方式

如果你是不写代码的产品经理、独立开发者、创业公司唯一的设计负责人，这篇是写给你的——每一步都有可以直接照抄的文本。如果你是前端工程师，你可能更关心导出的代码质量和落地路径，第六、七节会正面回答。

全文遵循一条主线：一句话立项目 → 产出 DESIGN.md → 逐组件生成 → 多屏一致性维护 → 框选多页连跳转 → 导出落地 → 认清边界。你可以顺序读，也可以直接跳到你现在卡住的那一步。

Stitch 2.0 的五项新能力，和它们各自解决什么问题

在动手之前，先把 2.0 的能力和你的工作流对上号。很多人不知道某个能力存在，于是用笨办法解决问题，这是最常见的效率损失来源。

能力与问题的一一映射

Stitch 2.0 能力	具体表现	解决什么问题	在本工作流中的位置
多屏生成	一次最多生成 5 个互联屏幕，字体、颜色、组件保持一致	早期探索阶段的批量出稿，快速看整体骨架	第二阶段，用于生成首版骨架屏
AI 原生无限画布	画布无边界，可自由摆放、缩放、分组、连线	多屏管理与原型连线需要空间	第四阶段，维护一致性与连线
更强的设计 Agent 与语音控制	多轮对话式修改，支持语音描述调整	局部微调时不想重写长提示词	第三、四阶段，局部改
即时原型	静态屏直接连成可点击流程，画布上预览跳转	交付物从”看图”升级为”可点”	第五阶段，框选多页连跳转
DESIGN.md	可移植的纯文本设计系统格式，可在设计与编码工具间传递	设计决策无处沉淀、无法跨工具复用	全程主线，第二阶段产出

DESIGN.md 是 2.0 里最被低估的能力

多屏生成很直观，即时原型很酷，但 DESIGN.md 才是真正改变工作方式的那一项。它把设计系统从”存在设计师脑子里的感觉”和”存在 Figma 里的样式文件”变成了”可以进版本库、可以 diff、可以交给另一个 AI 工具的纯文本”。

Stitch 支持从网址提取设计系统，也就是你给它一个现成的网站地址，它能反推出色彩、字体、组件风格，产出对应的规范文本。反过来，DESIGN.md 也能在设计工具和编码工具之间传递。这意味着你可以在 Google Stitch 里定义规范，导出给 Claude Code 或 Cursor 去写组件，再拿回来对齐。这个闭环在一年前是不存在的。

四种输入方式，分别适合什么场景

Stitch 支持从提示词、手绘草图、截图、语音四种输入开始。选择哪一种，取决于你手上已经有什么：

纯提示词适合从零开始、心里有明确方向的项目。这是本文主推的方式，因为最容易版本化。手绘草图适合你已经画了线框图、只想要高清稿的情况，比文字描述布局更快。截图适合”照着这个改”的场景，配合网址提取设计系统效果更好。语音适合在画布上做即时微调，说一句”这个按钮再大一点”比打字快。

四种输入可以混用。我的习惯是：提示词立项目，草图定布局，语音做微调。截图留给参考竞品。

第一步：一句话立项目，把”要什么”钉死

“一句话”不是让你随便说一句话，而是要求你用一句话把项目的约束条件说全。这句话最终会成为整个项目的锚点，后面写 DESIGN.md、写组件提示词时都要回归它。

一句话里必须包含的四要素

我总结为：产品类型 + 目标用户 + 核心动作 + 风格倾向。

举个反例：”帮我设计一个记账 App。”这句话信息量接近零，模型只能猜。猜出来的是一个通用的、谁都能用的、看完记不住的 App。

正例：”为一个经常出差的自由职业者设计一款移动端记账 App，核心动作是拍摄票据后三秒内完成分类记入，风格偏向冷静克制的财务感，主色偏深蓝，不要插画不要圆角卡通元素。”

这一句话里，产品类型（移动端记账）、目标用户（出差的自由职业者）、核心动作（拍票据→三秒归类）、风格（冷静克制、深蓝、非卡通）全部到位。模型不需要猜任何东西，它从一个明确起点开始。

为什么这一句不要写页面清单

关键的反直觉点在这里：第一步的一句话里不要列页面。

如果你在这一句里写”包含首页、记账页、报表页、我的页”，Stitch 会立刻试图生成这些页面。这正是我们要避免的——此时你还没有设计规范。一旦它生成了四个页面，你就有了四份各自决策的产物，后面清理它们比重做更费劲。

正确的做法是：第一句话只定义产品与风格，让 Stitch 先生成一到两个标志性屏幕作为视觉锚点（通常选最有代表性的那一屏，比如首页或核心操作页），确认方向对了，再进入规范阶段。

这是我的一个明确主张：第一屏的任务不是交付，是校准。它只需要让你确认”打光、配色、密度”这三件事是否对味。

实操：在 Stitch 里跑第一屏

打开 Google Stitch，在输入框粘贴上面那句话，模型选择先用 Flash（快、省额度），生成 1 屏。生成完成后看三件事：配色的冷暖对不对、信息密度是疏是密、文字层级是不是你要的那种克制感。不对就重跑一次，最多两次。

两次之内还对不上，说明问题不在提示词，而在你还没想清楚。这时候停下来，去找三张你觉得对味的参考图，用截图输入，或者直接问一句”给我三种明显不同的方向让我选”。

这一步的产出不是可用的设计，而是一个方向确认。记住这句话，因为它决定了下一节的心态。

第二步：让 Stitch 立刻产出 DESIGN.md，这是全流程的分水岭

方向确认后，进入本文最关键的一步：先要规范，不要要页面。

在 Google Stitch 的画布上，基于第一屏，输入这样一条指令：

基于当前这一屏的视觉语言，生成一份完整的 DESIGN.md 设计规范。包含：色彩系统（含语义色与状态色）、字体与字阶、间距梯度、圆角与阴影、组件基础规格、图标风格、动效时长建议、以及"不要做什么"的负面清单。所有数值必须是具体值，不要写"适中""柔和"这类模糊描述。

最后那句”所有数值必须是具体值”非常重要。AI 天然倾向于写”主色为一种沉稳的蓝色”，这种描述对人类设计师是提示，对下一次生成是噪声。你需要的是十六进制色值和像素数值。

DESIGN.md 的标准字段拆解

一份能在 Google Stitch 里稳定工作的 DESIGN.md，我建议至少包含以下字段。这是我在多个项目里收敛出来的结构，少一个都会在后面某个环节付出代价。

字段	内容	为什么不能省	常见错误
项目锚点	产品一句话定义、目标用户	给后续每次生成提供语境	写成了营销文案
色彩系统	主色、辅助色、语义色（成功/警告/危险/信息）、中性色阶 50-900、状态色（hover/active/disabled）	跨屏一致性最难守的就是颜色	只给主色，缺中性色阶
字体与字阶	字体族、字重、8 级字阶的具体字号与行高	字阶乱会导致所有页面密度不一	只写”标题 24px”没给行高
间距梯度	4/8/12/16/24/32/48/64 这类固定序列	避免每屏自己发明间距	写成百分比或”舒适间距”
圆角与阴影	3 档圆角、3 档阴影的具体参数	圆角是最容易漂移的视觉细节	圆角写满整个文件不统一
组件基础规格	按钮高度、输入框高度、卡片内边距、图标尺寸	让组件级生成有可对齐的物理尺寸	只描述外观不描述尺寸
栅格与布局	移动端 4 列 / 桌面 12 列、边距、最大宽度	决定多屏在画布上的对齐关系	移动端和桌面混在一份
图标与插画风格	线性/面性、线宽、圆角端、禁止的图形元素	图标风格不统一最伤质感	没写，模型混用两种风格
动效时长	快速/标准/强调三档时长与缓动曲线	原型连起来后节奏感靠它	完全省略，原型显生硬
负面清单	明确禁止的元素与手法	比正面描述更有效地约束模型	只写要什么，不写不要什么

可直接复制的 DESIGN.md 模板

下面这份模板你可以原样粘贴给 Google Stitch，让它按结构填充；也可以自己先填好再喂给它。我建议后者——人手填关键数值，AI 补全细节，这样质量更可控。

# DESIGN.md — 项目设计规范

## 1. 项目锚点
- 产品：自由职业者移动端记账 App
- 目标用户：经常出差、需要快速记录票据的自由职业者
- 核心动作：拍摄票据 → 3 秒内完成分类记入
- 调性关键词：冷静、克制、可信、非娱乐化

## 2. 色彩系统
### 品牌色
- Primary-600: #1A56DB（主按钮、选中态、关键强调）
- Primary-500: #3B7BEA（悬停）
- Primary-100: #E3ECFD（浅底、标签背景）

### 语义色
- Success-600: #0E9F6E（收入、正向）
- Warning-600: #D97706（额度提醒）
- Danger-600: #DC2626（支出、删除、超支）
- Info-600: #0284C7（提示）

### 中性色阶
- Neutral-900: #111827（主文字）
- Neutral-700: #374151（次文字）
- Neutral-500: #6B7280（辅助文字、占位）
- Neutral-300: #D1D5DB（分隔线、边框）
- Neutral-100: #F3F4F6（页面背景）
- Neutral-0:   #FFFFFF（卡片、弹层）

### 状态色
- Disabled 背景 Neutral-100，文字 Neutral-300
- Focus 环 Primary-500 2px，外扩 2px

## 3. 字体与字阶
- 字体族：中文 Noto Sans SC，数字与拉丁 Inter
- 字重：400 / 500 / 600，不使用 700 以上
- Display 32px / 行高 40 / 字重 600
- H1 24px / 32 / 600
- H2 20px / 28 / 600
- H3 17px / 24 / 500
- Body 15px / 24 / 400
- Caption 13px / 20 / 400
- Micro 11px / 16 / 500（仅用于标签）
- 数字强调：等宽数字（tabular-nums）

## 4. 间距梯度
4 / 8 / 12 / 16 / 24 / 32 / 48 / 64
- 组件内部：4-12
- 组件之间：16-24
- 区块之间：32-48
- 页面边距：移动端 16，桌面 24

## 5. 圆角与阴影
### 圆角
- sm 8px（输入框、标签）
- md 12px（按钮、卡片）
- lg 20px（底部弹层、大卡）
- 胶囊仅在状态标签上使用，禁止用在按钮

### 阴影
- shadow-1: 0 1px 2px rgba(17,24,39,.06)
- shadow-2: 0 4px 12px rgba(17,24,39,.08)
- shadow-3: 0 12px 32px rgba(17,24,39,.12)（弹层）

## 6. 组件基础规格
- 按钮高度：主 48，次 40，文字按钮 32
- 输入框高度：48，内边距 0 16，边框 1px Neutral-300
- 卡片内边距：16，卡片间距 12
- 图标尺寸：20（行内）/ 24（导航）/ 32（空态）
- 头像：32 / 40 / 56 三档
- 列表项高度：56，分隔线 1px Neutral-100，缩进 16

## 7. 栅格与布局
- 移动端：4 列，边距 16，列间距 12
- 桌面端：12 列，最大宽度 1200，边距 24，列间距 24
- 导航：移动端底部 4 项 Tab，桌面端左侧 240 宽

## 8. 图标与插画
- 线性图标，线宽 1.5，圆角端点，24 网格
- 不使用彩色插画与 3D 元素
- 空态允许使用单色线性插画，最多两种中性色

## 9. 动效
- fast 120ms，standard 200ms，emphasis 320ms
- 缓动：进入 cubic-bezier(.2,0,0,1)，退出 cubic-bezier(.4,0,1,1)
- 页面切换横向滑动 240ms，弹层自底部上移 320ms

## 10. 负面清单（禁止）
- 禁止使用渐变作为大面积背景
- 禁止纯黑 #000 文字
- 禁止大于 20px 的圆角用于卡片
- 禁止多于两种字重同时出现在一个区块
- 禁止拟物阴影与内阴影叠加
- 禁止在数字金额上使用非等宽数字

拿到规范后必须做的一件事：人工过一遍

Google Stitch 生成的 DESIGN.md 通常结构完整，但有三个高频问题需要你手动修：

一是语义色与品牌色打架。模型有时会让成功色与主色撞在一起，导致界面上一片蓝绿不分。检查方法很简单：把主色和四个语义色并排看，如果两个色块的灰度值接近，就必须调整。

二是字阶没有拉开。常见的是 H1 24px 与 H2 20px 只差 4px，实际渲染几乎看不出层级。健康的关系是每一级之间至少差 3px，并且行高要同步变化。

三是负面清单太短。模型天生不爱写”不要什么”。我的做法是至少补到 6 条，而且每条都要具体。”不要花哨”没意义，”禁止渐变大面积背景”才有效。

这一步花 10 分钟，能省掉后面两小时的返工。Design 规范是资产，不是草稿——把它当成资产对待，它才会成为资产。

第三步：逐组件生成的提示词写法（三段式）

规范有了，接下来不要一次生成”记账 App 全套页面”。正确粒度是组件 → 区块 → 屏幕，从最小的可复用单元开始往上搭。

为什么从组件开始，而不是从屏幕开始

屏幕是组件的排列组合。如果你先生成屏幕，屏幕里就包含了若干临时拼出来的组件，这些组件在下一屏里不会自动复用，模型会再造一批相似的——于是你得到五套稍有差异的”卡片”。而如果先生成组件并确认其规格，后续屏幕生成时可以用”使用已确认的 X 组件”来引用，复用率大幅提升。

这也解释了一个常见困惑：为什么有些人用 Google Stitch 生成的界面看起来像一个系统，有些人看起来像拼贴。区别就在于是不是先固化了组件。

三段式结构：身份 + 规格 + 约束

一条好的组件级提示词由三段组成，缺一不可：

第一段，身份（我是谁）：说明当前上下文和要生成的对象，让模型知道它在项目里而不是在真空中。第二段，规格（长什么样）：引用 DESIGN.md 里的具体数值，越具体越好。第三段，约束（不要什么）：负面清单，针对这个组件可能出现的偏差进行封堵。

三段的比例大概是 2:5:3。约束占三成，这个比例很多人会意外——但实测下来，约束部分的投产比最高。

可复制的组件级提示词模板

【身份】
这是「自由职业者记账 App」项目，遵循已确定的 DESIGN.md 规范。
现在只需要生成一个组件，不要生成整屏，不要附带页面外框。
项目锚点：拍摄票据后 3 秒内完成分类记入。

【规格】
组件名：票据分类卡（Receipt Category Card）
- 尺寸：宽 160，高 96，圆角 12
- 内边距：16
- 背景：Neutral-0 #FFFFFF，边框 1px Neutral-300 #D1D5DB
- 布局：左上图标 24（线性 1.5 线宽），右上勾选圈 20
- 标题：Body 15/24 字重 500，Neutral-900，单行省略
- 副标题：Caption 13/20 字重 400，Neutral-500，显示"最近使用次数"
- 选中态：边框 1.5px Primary-600，右上勾选圈填充 Primary-600
- 悬停态：背景 Neutral-100
- 阴影：默认无阴影，选中使用 shadow-1

【约束】
- 不要使用渐变、不要使用彩色插画
- 不要使用胶囊圆角
- 不要在卡片里放按钮
- 不要在标题上加粗到 600 以上
- 图标必须是线性风格，禁止面性图标

把这条提示词发给 Google Stitch，你会得到一个独立的、规格精确的组件。如果它多生成了整屏，说明第一段的”不要生成整屏”被忽略了——这是常态，不必惊讶，删掉多余部分重新来一次即可，或者在提示词开头再加一句”仅输出该组件的单个画板”。

组件提示词的四个实操细节

细节一：用 DESIGN.md 的字段名，不要用形容词

“一个轻盈的卡片”会让模型自由发挥。”Neutral-0 背景 + 1px Neutral-300 边框 + 12px 圆角”才是可执行指令。规范的价值就在于把形容词换成了数值，提示词必须享受这个红利。

细节二：一次只生成一个组件，最多两个状态

Google Stitch 一次生成多个组件时，一致性会下降。如果你需要默认态和选中态，可以一次要两个，但要明确说”同一组件的两个状态，规格完全一致，仅列出的属性不同”。超过两组，拆开做。

细节三：把”不出现的内容”写清楚

组件生成最常见的失败不是画错了，而是画多了——模型自作主张加了一个角标、一个省略号菜单、一个副标题。在约束段里写”不要放按钮””不要加角标”，比事后删省事得多。

细节四：组件确认后立刻命名并固定

在画布上给确认过的组件起一个语义化名字（如 card.receipt.category），后续屏幕提示词里就可以直接引用。命名混乱是后面组件库失控的头号原因。

组件清单：先列完再开工

开工前花五分钟列出这个产品需要的组件清单，按”原子 → 分子 → 组织”三档归类。以记账 App 为例：原子层有按钮（主/次/文字）、输入框、标签、图标按钮、头像、分隔线；分子层有票据分类卡、交易列表项、金额输入条、日期选择器、空态块；组织层有底部 Tab 栏、顶部导航、筛选抽屉。

清单不需要百分百完整，但必须覆盖高频复用的那批。生成顺序建议原子先行，因为后两层都会引用它们。

第四步：多屏一致性的维护方法，何时重生成何时局部改

这是实战里最消耗耐心的一节。Google Stitch 的多屏生成能一次出 5 屏并保持基础一致，但只要你开始调整，一致性就会松动。你需要一套明确的判断规则，而不是每次凭感觉决定。

一致性的四个受力点

界面风格漂移，本质上是四个地方在松动：颜色（同一语义用了不同色值）、字阶（同一层级用了不同字号）、间距（同类型区块用了不同间距）、组件形态（同一功能用了不同形态的组件，比如一个页面用圆角按钮另一个用方形）。

四个受力点的维护成本不同：颜色和字阶最容易统一（改规范即可），间距次之，组件形态最难（涉及重生成）。所以维护策略应该按这个顺序逐级升级。

重生成还是局部改：一张决策表

改动类型	波及范围	推荐动作	理由	额度成本
单个元素文字/图标不对	1 处	直接在画布上改，不调用模型	纯内容问题，无需重绘	零
某个间距、圆角不合规范	1 屏内几处	局部改：对话式指令指出具体元素	决策未变，只是执行偏差	低
某屏组件形态与规范不符	1 屏	局部重生成该组件，再替换	避免整屏重来丢掉满意的布局	低
规范中某个色值要调整	全部屏	改 DESIGN.md，然后逐屏重生成	颜色是全局语义，必须统一	高
字阶整体调整	全部屏	改规范，重生成受影响最大的 2-3 屏，其余局部改	全量重生成不必要，肉眼看不出差异的屏可保留	中高
布局结构推翻重来	1 屏	整屏重生成，附上明确的结构描述	局部改无法改变骨架	中
产品方向变更	项目级	重新立项目、重写 DESIGN.md	锚点变了，旧规范失效	极高

这张表的判断逻辑可以浓缩成一句：改的是”决策”还是”执行”？改决策，先改规范再重生成；改执行，局部改就行。大部分人的浪费在于把执行问题当决策问题处理，一遇到小毛病就整屏重生成。

局部改的正确说法：指认 + 期望 + 保持

局部改的提示词也有结构，三段：指认对象 → 说明期望 → 声明保持不变。

反例：”这个页面感觉不太对，再调整一下。”模型会大改，改完你发现原本满意的部分也被动了。

正例：”只修改交易列表里的金额文字：按照 DESIGN.md 的 Body 15/24 字重 500，使用等宽数字，颜色 Neutral-900。其他所有元素、布局、间距保持完全不变。”

第三句”保持完全不变”是最容易被省略的一句，也是最有效的抗漂移手段。它相当于告诉模型：这是一次外科手术，不是重画。

多屏批量生成时的一致性锚点

当你用 Google Stitch 的多屏生成一次做 5 屏时，有一个技巧能显著提升一致度：在提示词里显式列出这批屏共用的组件。

比如：”一次生成 5 个互联屏幕：首页、票据拍摄、分类确认、报表、我的。5 屏共用同一套顶部导航、同一套底部 Tab 栏、同一套票据分类卡。所有屏幕遵循 DESIGN.md，主色仅在关键操作按钮与选中态出现。”

把”共用”这个词写进去，相当于给模型一个显式的复用指令。实测下来，比只写”保持一致”有效得多——因为”一致”是抽象要求，”共用同一套 X”是具体动作。

一个反直觉的建议：不要追求 100% 一致

这是我的一条个人经验。Google Stitch 生成的界面，如果你把所有屏都手动修到像素级一致，往往会变得僵硬——因为真实的界面本来就需要在不同页面有节奏差异。首页可以密一点，设置页可以疏一点，这是设计而不是漂移。

判断标准应该是：同一层级的元素必须有相同规格，不同层级的元素允许有节奏差异。所有卡片都是 12px 圆角，这是必须一致的；首页卡片间距 12 而设置页间距 16，只要符合间距梯度就没问题。

把这条原则写进 DESIGN.md 的开头，可以省下大量无谓的争论。

第五步：画布上框选多页，直接连跳转做可交互原型

设计出完之后，最值钱的交付物不是静态图，而是可交互原型。Google Stitch 2.0 的即时原型能力，让你在无限画布上直接框选多个屏幕，把它们连成可点击的流程，并在画布内预览跳转。这一节讲具体怎么连、连什么、连得漂亮有哪些技巧。

连跳转的三种接线类型

原型里的连线不只是”点 A 去 B”，按语义分三档，建议在连线时就做好区分：

主导航线（Tab / 侧边栏）：底部 Tab 四个入口互相连通，架构上应该形成网状，任意两 Tab 之间可直达。这类线最容易漏连，导致演示时点进设置页就回不去。

任务流线（线性推进）：拍摄 → 分类确认 → 保存成功，这是一条单向链，每步只有一个前进方向和一个返回。连的时候要记得连”返回”，否则演示到一半卡死。

分支线（条件跳转）：比如报表页的空态点击”去记一笔”跳到拍摄页；筛选抽屉里的分类点击后回到列表并应用筛选。分支线最能体现产品思考，也是原型评审时最容易被追问的地方。

框选多页连线的具体操作顺序

推荐顺序是：摆位 → 分组 → 连线 → 命名 → 走查。

摆位：在画布上按用户的真实动线摆屏幕，从左到右是主流程，从上到下是分支。摆放规整会发现很多架构问题——比如你发现”设置”离任何一个页面都很远，说明它在信息架构里被边缘化了。

分组：把属于同一任务流的屏幕框选成一组，命名如”记一笔流程”。分组后连线视图不被噪声干扰，评审时也能按住一组单独讲解。

连线：进入原型模式，从触发元素（按钮、卡片、Tab 项）拖到目标屏幕。注意起点是元素而不是屏幕——如果整屏都能点，演示时用户会误触，体验很差。

命名：每条连线写清楚触发条件，比如”点击’保存并继续’→ 拍摄页（清空状态）”。这一条在交付给开发时价值巨大，因为它把交互规格写进了连线。

走查：从首页开始，只用鼠标点击，完整走一遍三条主流程。卡住的地方就是漏连的地方。

可交互原型最容易踩的四个坑

坑一：连了屏与屏，没连状态

最有说服力的原型，不是”能点通”，而是”点了之后状态变了”。比如点了”保存”，回到列表时列表里多了一条新记录。Google Stitch 支持在原型里预览跳转，但状态联动需要你在静态屏里预先做出”空态”和”有数据态”两个版本，然后把连线指向对应版本。这一点提前规划，效果差别巨大。

坑二：返回路径缺失

几乎所有任务流原型都会漏掉返回。检查清单很简单：每一条前进线，都要有对应的返回线或明确的”完成”终态。

坑三：过渡太花

原型过渡用规范里定义的动效时长（fast 120 / standard 200 / emphasis 320），不要每个跳转都配不同的动画。原型的作用是传达流程，不是展示动画库。

坑四：屏幕数量失控

一个可演示的原型，主线 6-8 屏足够。超过 12 屏时，评审者会失去方向感。把边缘流程（比如忘记密码、帮助中心）做成”占位屏”，一句话说明即可。

原型演示的节奏设计

连线完成后，建议提前设计一条演示路径并自己走三遍。演示路径的黄金结构是：痛点场景 → 核心动作 → 结果反馈。以记账 App 为例：从报表页的空态开始（痛点：看不到数据）→ 点”去记一笔”进拍摄（核心动作）→ 三秒后回到列表并看到新记录（结果）。

这条路径走完只需要 40 秒，但完整传达了产品价值。比逐个页面讲一遍强得多。

第六步：导出的七种框架，选哪个不是看喜好

Google Stitch 支持导出多种框架代码，常见的目标包括 HTML/CSS、Tailwind、Vue、Angular、Flutter、SwiftUI 等七类。选择不是审美问题，而是技术栈与交付形态的问题。

七种导出目标的选择表

导出目标	适合的项目形态	代码可用度	典型后续动作	注意事项
HTML/CSS	活动页、静态展示、快速验证	高，结构清晰可直接用	直接部署，或接入任意后端模板	响应式需要自己补断点
Tailwind	现代前端项目、需要快速定制	高，类名即样式	贴进现有 Tailwind 工程	类名顺序较乱，建议格式化
Vue	中后台、国内团队主栈	中高，单文件组件结构	拆成组件、接状态管理	组件拆分粒度偏粗，需手工切
Angular	企业级大型应用	中，模板可用逻辑需重写	迁入 Angular 工程并改用独立组件	样式作用域需要核对
Flutter	跨端移动应用	中，UI 结构可参考	重写为可维护的 Widget 树	布局嵌套深，需重构
SwiftUI	iOS 原生应用	中，视图结构接近可用	接入状态与导航	可访问性属性缺失需补
Figma 导入	需要在专业工具里精修	不适用（是设计文件）	交给设计师继续打磨	自动布局与组件化需重建

选择的判断顺序建议是：先问交付形态（Web / 移动 / 桌面），再问团队栈，最后才问代码质量。如果团队用 Vue，就导出 Vue，别因为”HTML/CSS 看起来最干净”而导 HTML 再手抄成 Vue——那等于把迁移成本翻倍。

导出的代码该怎么看待：草稿还是资产

这是第二个人们容易误判的地方。我的观点：Google Stitch 导出的代码，在拿到的那一刻是”高质量草稿”，只有经过一轮结构化改造之后才是”资产”。

理由是：AI 生成的界面代码通常在三件事上不合格——组件粒度（一张 400 行的页面文件而不是 8 个组件）、状态管理（所有数据硬编码在模板里）、可访问性（缺 aria、缺焦点管理、缺键盘操作）。这三件事恰恰是无法靠”再生成一次”解决的，因为它们是结构问题。

所以正确的用法是：把导出的代码当”像素级规格说明书”使用，而不是当”代码底稿”直接提交。开发照着它把组件拆开、把数据抽出去、把 a11y 补上——这个过程比从零写快得多，但你不能省略。

落地的三条路径

路径 A：原型验证（最快）。导出 HTML/CSS 或 Tailwind，直接部署一个静态版本，用来做用户测试或者内部评审。这条路当天就能出结果，适合创业公司快速验证。

路径 B：进 Figma 精修（最稳）。把 Google Stitch 的设计导出到 Figma，由设计师补齐交互标注、补状态、建立组件库，再交给开发。这条路慢一些，但交付质量最可控，也最适合有设计团队的场景。

路径 C：直接进工程（最快到可用）。导出对应框架代码，塞进现有工程，然后按上面说的方法做结构化改造。适合独立开发者或小团队。

三条路径不是互斥的。常见组合是：先用 A 验证方向，方向对了走 B 或 C。

第七步：导出与落地的命令与配置

Google Stitch 的导出在界面上是点几下就完成的事，但把导出物接进工程、并且让后续维护不失控，需要一点点脚手架。下面是一套我常用的最小配置，可以直接套用。

把导出的 Tailwind 接进现有工程

Google Stitch 导出的 Tailwind 版本通常使用了一些自定义色值，直接粘贴会因为工程里没有对应的主题变量而失色。正确做法是先把 DESIGN.md 的色值翻译成主题配置，再贴代码。

// tailwind.config.js —— 把 DESIGN.md 的色彩与字阶翻译成主题
module.exports = {
  content: ['./src/**/*.{html,js,ts,jsx,tsx,vue}'],
  theme: {
    extend: {
      colors: {
        primary: {
          100: '#E3ECFD',
          500: '#3B7BEA',
          600: '#1A56DB',
        },
        success: { 600: '#0E9F6E' },
        warning: { 600: '#D97706' },
        danger:  { 600: '#DC2626' },
        neutral: {
          0:   '#FFFFFF',
          100: '#F3F4F6',
          300: '#D1D5DB',
          500: '#6B7280',
          700: '#374151',
          900: '#111827',
        },
      },
      fontFamily: {
        sans: ['Inter', 'Noto Sans SC', 'system-ui', 'sans-serif'],
      },
      fontSize: {
        display: ['32px', { lineHeight: '40px', fontWeight: '600' }],
        h1:      ['24px', { lineHeight: '32px', fontWeight: '600' }],
        h2:      ['20px', { lineHeight: '28px', fontWeight: '600' }],
        h3:      ['17px', { lineHeight: '24px', fontWeight: '500' }],
        body:    ['15px', { lineHeight: '24px', fontWeight: '400' }],
        caption: ['13px', { lineHeight: '20px', fontWeight: '400' }],
      },
      borderRadius: { sm: '8px', md: '12px', lg: '20px' },
      spacing: { 4: '4px', 8: '8px', 12: '12px', 16: '16px', 24: '24px', 32: '32px', 48: '48px', 64: '64px' },
      boxShadow: {
        s1: '0 1px 2px rgba(17,24,39,.06)',
        s2: '0 4px 12px rgba(17,24,39,.08)',
        s3: '0 12px 32px rgba(17,24,39,.12)',
      },
    },
  },
  plugins: [],
}

把 DESIGN.md 带进编码工具

DESIGN.md 的价值在于可移植。把它放到仓库根目录，并在工程协作规则里显式引用，能让后续所有 AI 编码操作都遵循同一套规范。这是一个成本极低、收益极高的动作。

# AGENTS.md —— 放在仓库根目录，让编码工具先读规范
## 设计规范
本项目所有界面代码必须遵循根目录的 DESIGN.md。
- 颜色：只使用 DESIGN.md 定义的色值，禁止出现规范外的十六进制色
- 字号：只使用 8 级字阶，禁止出现自定义字号
- 间距：只使用 4/8/12/16/24/32/48/64
- 圆角：只用 sm 8 / md 12 / lg 20 三档
- 组件：新增组件前先检索 components/ 目录是否已有同类

## 提交前检查
1. 运行 npm run lint:design（校验色值与字号是否越界）
2. 新增的组件必须导出 types，禁止 any
3. 所有交互元素必须有可访问名称

## 代码来源说明
styles/ 下部分文件源自 Google Stitch 导出，属于草稿，
修改时必须按 components/ 的分层规则拆分为独立组件。

设计规范越界校验脚本

规范写在纸上不会自动生效，最好的办法是让违规在提交时就被拦下。下面这个脚本足够简单，可以放在 pre-commit 里跑，几十行代码就能省掉大量评审返工。

// scripts/lint-design.mjs —— 校验界面代码是否偏离 DESIGN.md
import { readFileSync, readdirSync, statSync } from 'node:fs';
import { join, extname } from 'node:path';

const DESIGN = readFileSync('DESIGN.md', 'utf8');

// 从 DESIGN.md 里抽取允许的色值
const allowedColors = new Set(
  [...DESIGN.matchAll(/#[0-9A-Fa-f]{6}\b/g)].map(m => m[0].toUpperCase())
);
// 从 DESIGN.md 里抽取允许的字号
const allowedSizes = new Set([...DESIGN.matchAll(/(\d+)px/g)].map(m => Number(m[1])));

const problems = [];
function walk(dir) {
  for (const name of readdirSync(dir)) {
    const p = join(dir, name);
    if (statSync(p).isDirectory()) { walk(p); continue; }
    if (!['.css', '.vue', '.tsx', '.jsx', '.html'].includes(extname(p))) continue;
    const code = readFileSync(p, 'utf8');
    for (const m of code.matchAll(/#[0-9A-Fa-f]{6}\b/g)) {
      if (!allowedColors.has(m[0].toUpperCase())) problems.push(`${p}: 色值 ${m[0]} 不在规范内`);
    }
    for (const m of code.matchAll(/font-size:\s*(\d+)px/g)) {
      if (!allowedSizes.has(Number(m[1]))) problems.push(`${p}: 字号 ${m[1]}px 不在字阶内`);
    }
  }
}
walk('src');

if (problems.length) {
  console.error('设计规范越界：\n' + problems.join('\n'));
  process.exit(1);
}
console.log('设计规范校验通过');

这个脚本不追求完美，只做一件事：把”规范外的色值和字号”挡在门外。实践中这一条就能拦住 70% 的漂移问题。更重要的是，它在团队里建立了一个心理契约——规范不是建议，是门禁。

Google Stitch 与 v0、Lovable、Uizard、Figma Make 的对比

这些工具经常被放在一起讨论，但它们的定位差异其实很大。选错工具的痛苦，往往在第二周才显现。下面这张表按”你到底想要什么”来组织。

维度	Google Stitch	v0	Lovable	Uizard	Figma Make
核心定位	AI 界面设计与原型，输出设计规范	对话式生成前端界面与组件	对话式生成完整 Web 应用	快速低保真原型与线框	在 Figma 内做 AI 生成
产出物重心	屏幕 + 可点击原型 + DESIGN.md	React/Tailwind 组件代码	带数据库与后端的应用	线框与简单原型	Figma 图层
设计系统能力	强，DESIGN.md 可移植	中等，靠提示词维持	中等	弱	中，依赖 Figma 变量
多屏一致性	强，规范锚定 + 多屏生成	中，多轮迭代易漂移	中	中偏弱	中
可交互原型	强，画布框选连线	弱，需部署后体验	强，生成即应用	中	中
后端能力	无	无	有，内置数据库与鉴权	无	无
上手门槛	低	中，需懂前端	低	低	中，需熟悉 Figma
费用	免费，有月度额度	有免费层，重度需付费	有免费层，功能需付费	有免费层	与 Figma 订阅绑定
最适合	先把界面与流程想清楚的团队	已有工程，需要补界面代码	独立开发想做完整产品	早期概念沟通	已有 Figma 工作流

三个判断口径

口径一：你需要”想清楚”还是”跑起来”？如果你现在处于产品定义阶段，需要的是把界面、流程、规范讲清楚，选 Google Stitch。如果你已经想清楚，只需要一个能跑的东西，Lovable 更直接。

口径二：你的团队有没有设计工作流？有 Figma 重度工作流的团队，Figma Make 的接入成本最低。没有设计团队的，Google Stitch 从零起步更顺。

口径三：你要不要后端？Google Stitch 明确不建后端。如果你的项目第一版必须有数据库和登录，不要指望它——它生成的是界面，不是应用。

它们其实可以组合

这三者在很多团队里是串起来用的：用 Google Stitch 定规范、出原型和连线，导出代码或图片给前端，再由 v0 或手写补足动态部分，最后用 Lovable 一类的工具做内部演示环境。工具不是单选题，流程才是。

能力边界：清楚的预期比强大的功能更重要

我把边界单独写一节，因为这是最容易被忽略、也最容易造成失望的部分。免费工具尤其容易让人产生”它能做所有事”的错觉。

它不建后端

Google Stitch 生成的是界面层。没有数据库、没有鉴权、没有接口、没有业务逻辑。你在 Stitch 里连好的跳转，是屏幕与屏幕之间的跳转，不是”提交数据后跳转”。这意味着你拿到的可交互原型，在演示层面非常有用，在功能层面是零。

如果你需要真实的数据流，路径是先 Stitch 出界面和规范，再交给编码工具或团队实现。这条路上的衔接质量，取决于你的 DESIGN.md 写得够不够细。

它不替代设计系统工具

DESIGN.md 是一个很好的轻量规范载体，但它不等于一套成熟的设计系统工具。真正的设计系统需要组件版本管理、Token 平台、文档站、多主题切换、跨产品复用治理——这些 Google Stitch 都不提供。

定位应该是：DESIGN.md 是项目级的设计契约，是把 AI 生成拉回正轨的缰绳。当团队成长到需要真正的设计系统时，你会把它迁移到更专业的体系里，但那份契约本身是有价值的中间产物。

它还在变，而且是实验品

Google Stitch 来自 Google Labs，官方也说明它仍是实验性质产品，功能和界面会变更。这一点必须写进你的项目计划：不要把它当成不可替代的基础设施。

具体建议有两条。第一，把 DESIGN.md 保存在你自己的仓库里，不要只依赖工具里的版本——它是纯文本，天然可以迁移。第二，导出的代码和设计文件及时归档，工具迭代时你的成果不会跟着蒸发。

免费，但有额度

Google Stitch 免费使用，但有每月生成额度，而且 Flash 与 Pro 模型的额度是分开计算的。这直接影响你的工作策略：探索阶段用 Flash 多试，定稿阶段用 Pro 少跑。

我把额度当成一种预算来管理。第一屏校准用 Flash，最多两次；组件生成用 Flash；最终屏与原型细节用 Pro。这样一个月做两三个中小项目通常够用，不至于中途断粮。

把整套流程固化成一份清单

最后把整个流程压缩成一份可以贴在工作区旁边的清单。这份清单的价值在于：当你在某个环节卡住时，回来看一眼就知道该往哪走。

七步流程速查

第 1 步 一句话立项目。产品类型 + 目标用户 + 核心动作 + 风格倾向，不列页面。用 Flash 生成第一屏，最多校准两次。

第 2 步 产出 DESIGN.md。基于第一屏的视觉语言生成规范，要求全部为具体数值。人工检查语义色冲突、字阶层级、负面清单长度三项。把文件存进仓库。

第 3 步 列组件清单，逐组件生成。原子 → 分子 → 组织，一次一个组件，用三段式提示词（身份 + 规格 + 约束），确认后命名并固定。

第 4 步 逐屏生成。引用已确认的组件，明确”5 屏共用同一套 X”，优先用多屏生成一次出 5 屏骨架，再逐屏精修。

第 5 步 维护一致性。先判断是”决策问题”还是”执行问题”，决策问题改规范后重生成，执行问题局部改并声明”其余保持不变”。

第 6 步 框选多页连跳转。摆位 → 分组 → 连线 → 命名 → 走查。连三类线：主导航线、任务流线、分支线。设计一条 40 秒的演示路径。

第 7 步 导出落地。按交付形态和团队栈选导出目标，把代码当规格说明书使用，按路径 A/B/C 落地。

三个最容易被跳过、也最值得做的动作

动作一：把 DESIGN.md 提交到版本库。这一步几乎没人做，因为它看起来多余。但它是从”一次性生成”转向”可维护资产”的分界点。

动作二：给组件起语义化名字。命名混乱的代价在第二次生成时就会显现。

动作三：写完原型后自己走三遍演示路径。能发现 80% 的漏连和状态问题。

常见问题

Google Stitch 免费吗，每月额度够用吗

免费。但每月有生成额度，且 Flash 与 Pro 模型的额度分开计算。按本文流程，一个中小型项目（1 个规范 + 15 个组件 + 8 个屏幕 + 若干次局部改）通常在一个月内可以完成。关键是不要在探索阶段用 Pro 反复试错——那是额度消耗最快的方式。探索用 Flash，定稿用 Pro，是控制额度的核心策略。

DESIGN.md 写好了，为什么生成的界面还是不太一样

三个排查方向。第一，看提示词里有没有引用具体字段名——如果只写了”按设计规范”，模型经常只读到规范的前几段。第二，检查组件级提示词是否包含”用已有组件 X”的显式引用，引用比描述有效。第三多屏生成时是否写了”共用同一套 X”，抽象的一致性要求不如具体的共用声明。如果三项都做了还有明显偏差，通常是 DESIGN.md 里的负面清单太短，补到 6 条以上会明显改善。

多屏生成一次最多 5 屏，超过 5 屏怎么办

分批。第一拨打底生成 5 屏，第二拨基于第一拨的成果生成剩余的，并在提示词开头明确”延续已有 5 屏的视觉语言，共用相同的导航、Tab 栏、卡片组件”。分批的关键是第二批必须显式引用第一批的产物，否则模型会重新决策。另外，超过 10 屏的项目建议先做信息架构，避免生成出来才发现结构不对。

导出的代码能直接上线吗

不建议。Google Stitch 导出的代码在视觉还原上通常不错，但存在三个结构性问题：组件粒度太粗（常见是一个几百行的页面文件）、数据硬编码（没有状态管理）、可访问性缺失（缺 aria 与键盘支持）。正确用法是把它当作像素级规格说明书，照着它拆分组件、抽取数据、补齐无障碍。这样做的速度仍然远快于从零开始。

没有设计基础的人能用好 Google Stitch 吗

能，但需要用规范来补足经验。没有设计基础的人最容易犯的错是”看起来不错就通过”，结果项目做到第十屏时发现风格散了、层级乱了。本文的流程正是为此设计的：强制你先产出 DESIGN.md，把设计决策显性化。哪怕你自己判断不了好坏，一份写清楚数值的规范也能保证后续生成的一致性。至于”好不好看”，找一个你喜欢的网站，用网址提取设计系统，站在成熟作品的肩膀上起步。

Google Stitch 会取代 Figma 或设计师吗

不会，至少在它还是 Labs 实验品的时候不会。它改变的是工作起点：过去从空白画布开始，现在从一句话和一份规范开始。设计师的价值从”画出界面”前移到”定义规范、判断好坏、把规范变成可维护的系统”。至于 Figma，Google Stitch 明确支持把设计导出到 Figma 继续精修，两者更像是流水线的上下游。真正的变化是：会写规范的团队，产出速度会比不会写的快一个数量级。

回到文章的标题。Google Stitch 能做的事，一句话就能概括：把一句描述变成可点击的界面。但决定结果质量的，不是模型的强弱，而是你有没有在生成之前，先把规范写下来。先规范后组件，不是一个技巧，是这套工具唯一可持续的用法。