Google Stitch：从对话生成走向可操作的 AI 原生画布
Introducing “vibe design” with Stitch
01 · 先读这里
为什么推荐
这篇不是教你怎么写 Prompt，而是展示 AI 生成之后，设计师如何继续探索、约束和试用。无限画布接住多模态输入，DESIGN.md 维持规则一致性，Play 让屏幕连接成流程。适合研究 Chat + Canvas 与 Generative UI 的交互范式。
02
这篇讲什么
Google Labs 在 Stitch 的 2026 年更新中，把 AI UI 生成器重构为无限画布：用户不仅输入自然语言，还能将图片、文本、代码作为画布上下文，在同一空间发散和收敛。配套设计 Agent 与 Agent manager 追踪不同方向，DESIGN.md 将视觉规范变成可导入导出的机器可读约束；屏幕还能串成可点击原型，通过 Play 检查流程。官方文章提供画布、设计系统与预览按钮的界面截图。值得关注的是，AI 不再只输出最终界面，而是参与探索、约束、试用与交接的完整设计过程。
扩展评分
一句话带走
生成结果不应是终点，而应成为可编辑、可约束、可预览的工作对象。
交互范式
交互到底改变了什么
- 原来的交互
- 先写 prompt 等待单张/单屏结果，再通过反复描述修改；设计系统和原型验证通常在其他工具里完成。
- Agent 带来的变化
- 以无限画布承载多模态上下文和多方案；设计规则由 DESIGN.md 共享；静态屏幕可快速形成可交互原型。
- 用户的新成本
- 用户需要管理画布上下文、多个方案与设计规范，检查自动推断的流程是否符合真实业务。
- 关键交互机制
- 多模态无限画布；Agent manager；DESIGN.md 导入导出；Stitch 屏幕串联与 Play 预览。
- HCI 依据
- 原文提及设计过程的发散/收敛与快速反馈需求，但未提供用户研究或 HCI 实验。
- 团队设计信号
- 将探索、规范和交互预览放在同一产品路径，并提供面向开发工具的交接。
设计策略
从具体设计中学习
01
让画布承接多模态上下文，而非让 Prompt 承担全部表达
- 看图重点
- 看文本、图片与 UI 方案如何在同一画布并置，支持探索与收敛。
- 图像作用
- 官方产品截图
- 问题
- 单条文字指令难以表达已有界面、灵感与业务目标。
- 方案
- 无限画布直接接纳图像、文字、代码，并由设计 Agent 结合上下文生成。
- 为什么这样做
- 保留视觉与空间关系，让设计师不必把全部信息翻译成文字。
- 取舍
- 根据方案推断：上下文越多，用户越需要清理无效素材和管理关联。
原文依据与解读
images, text or even code
- 译文
- 图像、文本，甚至代码。
- 解读
- AI 的输入界面从输入框升级为多模态工作空间。
可迁移规则需要空间关系的任务，优先允许直接投放、选择、移动上下文对象。
02
将设计规范做成 Agent 可交换的约束文件
- 看图重点
- 看设计规则与项目界面之间的连接，而非只看视觉风格。
- 图像作用
- 官方产品截图
- 问题
- 多次生成容易偏离品牌或组件规则。
- 方案
- 通过 DESIGN.md 导入导出设计规则，并支持从 URL 提取设计系统。
- 为什么这样做
- 把一致性约束交给可复用的结构化上下文，减少重复描述。
- 取舍
- 根据方案推断：规则文件需维护版本，旧规则可能限制新探索。
原文依据与解读
export or import your design rules
- 译文
- 导出或导入设计规则。
- 解读
- 这是将隐性设计经验转成 AI 可消费的约束资产。
可迁移规则让 Agent 输出遵守可版本化的设计规则，而非每次依赖提示词重复强调。
03
把静态屏幕直接接成可点击流程，尽早暴露断点
- 看图重点
- 看 Play 入口和屏幕串联后的预览行为。
- 图像作用
- 官方产品截图
- 问题
- 单屏看起来正确，不代表跨页面流程可用。
- 方案
- 屏幕可快速连接成互动原型，点击 Play 预览，系统还可推断后续屏幕。
- 为什么这样做
- 把验证对象从像素画面推进到任务路径。
- 取舍
- 根据方案推断：自动推断的下一屏可能不符合真实权限或业务规则，必须人工校验。
原文依据与解读
click “Play” to quickly preview
- 译文
- 点击 Play 即可快速预览。
- 解读
- 从“生成一张图”转向“生成可走通的用户旅程”。
可迁移规则AI 生成多屏后，应提供流程连接、预览与异常路径检查。
推理链
从问题到设计判断
- 问题
- 一次性 UI 生成缺少多方案探索、规范复用和流程预览。
- 证据
- 官方展示多模态画布、DESIGN.md 及 Play 原型截图；无用户实验。
- 判断
- 设计过程需要持续操作的共享工作空间。
- 设计策略
- 无限画布 + 设计系统文件 + 多屏交互预览。
- 结果
- 功能层面实现从输入到可点击原型的链路；质量提升或节省时间的量化结果原文未提供。
迁移原则
带回自己的项目
- 允许用户把真实业务素材直接拖入画布作为 Agent 上下文。
- 为生成结果提供可版本化的规则/组件约束。
- 多屏生成必须支持点击预览并人工检查异常分支。
03
它真正解决的问题
自然语言生成 UI 容易停留在一次性结果，难以并行探索、保持一致性或验证多屏流程。
04
作者用了什么依据
Google 官方文章展示无限画布、DESIGN.md 和 Play 原型功能的截图与操作说明。
05
核心设计洞察
生成式设计的核心工作对象应是可操作、可约束、可验证的画布，而非一次性聊天答案。
06
具体做了什么
将多模态上下文直接放入无限画布；以 DESIGN.md 固化和迁移规则；让多屏生成结果可连接并 Play 预览。
07
为什么这样做
Problem：单轮生成难覆盖完整设计流程 → Evidence：官方展示多模态输入、设计系统和原型能力 → Judgment：AI 需要参与持续设计过程 → Strategy：无限画布 + DESIGN.md + Play → Result：支持探索到预览的连续工作流；用户成效原文未提供。
08
有什么关键取舍
更强的画布能力与规范复用提高可控性，但也增加上下文维护和结果审核成本（根据方案推断）。
09
最终有没有验证
原文未提供
从这篇学习
值得学什么
让 Agent 理解整个项目演化与多模态上下文，而非只看最后一条 prompt。
生成结果必须能被直接操控、连接和试用。
原文未提供
把发散方案、收敛约束和可用性预览串成连续的设计循环。
设计系统从样式资产升级为 Agent 可读取的决策约束。
按画布、规则、原型三层展示 AI 如何改变工作流。
10 · 迁移
可以带走什么
复杂业务 Agent 的输出采用画布/流程图承载，并让用户直接修改节点、约束与预览。
你的反馈
这篇对你有用吗？
反馈只会记录下来，不会自动改变推荐算法。