Google Stitch实操流程：我用 Claude 拆需求、Gemini 写提示词，定好产品界面风格

先说我踩过的坑：会写功能，不等于能稳定做出“像样的界面”

我之前做产品时，最痛苦的一段不是功能实现，而是界面一致性。

功能页、设置页、报表页我都能很快做出来，但一旦页面多起来，问题马上出现：颜色体系漂移、间距节奏失控、按钮和卡片风格不一致。每页单看都能用，组合在一起却不像一个产品。

后来我把流程改了，不再让模型“直接开画面”，而是先把需求拆清楚，再生成可执行提示词，最后才进 Stitch 做风格和页面。这个顺序一换，返工明显下降。

今天这篇我就只讲这条实操链路：Claude（Cloud）分析需求 → Gemini生成提示词 → Google Stitch生成风格。

我现在固定用的主流程（就是这三步）

第一步：先用 Claude 把需求拆成“设计可执行输入”

我现在不会一上来就说“做个高级 SaaS 页面”。

我会先让 Claude 帮我产出一份“设计输入简报”，至少包含：

• 目标用户是谁
• 核心使用场景是什么
• 页面清单（首页/列表/详情/设置）
• 每个页面的主任务和优先级
• 想要的品牌气质（稳重、极简、工具感、数据感）
• 明确不要什么（太花、太重装饰、信息密度过高）

我常用的提问模板是：

你是产品设计策略助手。请把下面业务目标拆成可直接喂给 UI 生成工具的需求简报。
输出结构必须包含：用户画像、核心任务、页面清单、信息层级、视觉气质、禁用风格、交互重点。

业务目标：
[粘贴你的产品目标]

这一步的价值非常大：它把“模糊想法”变成了后面两步可以稳定复用的输入。

第二步：再用 Gemini 把简报转成 Stitch 友好的提示词

我把第一步的简报丢给 Gemini，不是让它再讲一遍理论，而是让它输出 可直接粘贴到 Stitch 的提示词包。

我要求 Gemini 一次给我 3 类内容：

1. 主提示词（主风格方向）
2. 变体提示词（偏商务、偏极简、偏数据）
3. 负向约束（明确不要出现什么）

我常用模板：

基于以下设计简报，生成 Google Stitch 可直接使用的提示词。
要求：
1）先给主提示词（1段）
2）再给3个风格变体（每个1段）
3）再给“不要出现”的约束列表（5-8条）
4）语言简洁、可执行，避免空话

设计简报：
[粘贴第一步输出]

这里我自己的经验是：提示词质量决定了 Stitch 的起点质量。这一步偷懒，后面就会在 Stitch 里反复重来。

第三步：把提示词放进 Google Stitch，先定风格再定页面

进入 Stitch 后，我会按这个顺序操作：

1. 先用主提示词生成第一版方向。
2. 再用 2-3 个变体提示词做横向对比。
3. 从不同版本里挑“可用元素”，而不是只认第一张图。
4. 明确继续迭代：层级、留白、密度、按钮状态、表单可读性。
5. 最后导出设计规则文件（常见是 design.md/DESIGN.md），用于后续开发约束。

这一步我只看一件事：它是否能形成一套可持续扩展的风格系统，而不是一张“看起来好看”的海报图。

我是怎么把这三步接回开发阶段的

当我拿到 Stitch 的设计结果后，会立刻做两件事：

1. 把设计规则文件放到项目根目录。
2. 在 CLAUDE.md 写死约束，要求后续 UI 生成必须遵循这套规则。

我通常会加这几条：

• 只能使用 design.md 中定义的颜色、字体、间距
• 禁止新增未定义 token
• 组件状态（hover/focus/disabled）必须完整
• 新页面优先复用已有组件模式

这样做之后，Claude Code 不会每次会话都“重新猜风格”，而是沿着同一套系统持续扩展。

这套流程里最容易翻车的 5 个点

1）第一步需求拆解太粗

如果只给一句“做个后台”，第二步再强也救不回来。先把场景和页面任务写清楚。

2）第二步只生成一个提示词

只给一个提示词，等于把选择权全交给随机性。至少准备主提示词 + 2 个变体。

3）第三步拿第一版就收工

第一版通常只是方向，不是答案。必须做对比和迭代。

4）只导出图，不导出规则

没有规则文件，后续代码阶段一定会漂。图能展示，规则才能复用。

5）没有把规则写入 CLAUDE.md

文件放着不等于模型会遵守。要把“如何使用规则”写成明确约束。

我现在的最小闭环（可直接照着做）

如果你想今天就跑一遍，按这个顺序来：

1. 用 Claude 产出设计需求简报。
2. 用 Gemini 生成 Stitch 提示词包（主提示词 + 变体 + 负向约束）。
3. 在 Stitch 里生成并迭代风格与页面。
4. 导出 design.md / DESIGN.md。
5. 回到项目，更新 CLAUDE.md 约束。
6. 先落一个核心组件和一个核心页面做校准，再扩展全站。

总结：先“拆需求”和“写提示词”，再进 Stitch，成功率高很多

我现在已经不再追求“AI 一把生成最终 UI”，而是追求可复制、可迭代、可维护。

这条链路里，真正决定结果的不是最后一步作图，而是前两步：

• 需求有没有拆清楚
• 提示词有没有写到位

所以我的建议很明确：先用 Claude（Cloud）分析需求，再用 Gemini 生成提示词，最后进 Google Stitch 做风格与页面。

你把顺序跑对了，界面质量会稳定很多，后续开发也会轻松很多。