·10 分钟阅读

Google Stitch Web App 设计指南

用 Google Stitch 设计 Web App：页面结构、仪表盘与落地页布局、响应式组件、提示词示例，以及从设计到代码的完整工作流。

S
Stitch Prompt Team
Content Team
提示词设计风格工作流

Web App 不是“多了一个登录按钮的落地页”。它有导航、权限、数据表格、表单、设置、空状态和响应式布局。只要提示词描述的是产品结构，而不只是视觉风格，Stitch 就能生成一版可信的初稿。

本文聚焦让 Web App 真正可用的页面与系统：七类核心页面、主要布局模型、可复用的提示词公式，以及从设计到代码的交付。

Web App、落地页和移动 App 的区别

落地页只有一个转化目标，讲一条线性的故事。Web App 支持反复发生的任务，所以需要导航、状态、数据密度和权限。移动 App 优先触控、单手操作和短会话。如果用同一套结构提示三者，至少有一个会出错。

在提示词第一句写清楚载体，然后写页面类型。因为即使在同一个产品里，“仪表盘”和“设置”需要的组件也完全不同。

每个 Web App 都需要的七类页面

登录与注册

登录、注册、重置密码和验证。布局保持简单，主操作要明显，并覆盖错误和加载状态。

引导流程

只收集产品交付第一个有用结果所必需的信息。用进度提示、一步一个决策，并给用户跳过或返回的出口。

仪表盘

仪表盘用于扫描和对比。优先放少量指标、一条趋势，以及进入待处理工作的路径。不要把它变成产品里所有图表的陈列柜。

列表与表格

列表需要排序、筛选、分页、行选择、批量操作和清晰的空状态。表格要能承载真实数据，同时保持可读。

详情页

详情页要回答三个问题：这是什么、发生了什么、下一步能做什么。主操作保持可见，次要操作分组收纳。

设置与账单

设置页管理身份、偏好、团队权限和付款。用清晰的分区、安全的默认值，并对破坏性操作做确认。

空状态与错误状态

新账号是空的，网络会失败，权限会变化。主动设计这些状态，而不是让界面直接崩掉。

Web App 的布局系统

侧边栏 + 内容区

最常见的 SaaS 布局：固定导航、带搜索和账号操作的顶栏，以及可在列表、详情和设置之间切换的内容区。它很适合信息密度高的产品。

顶部导航

适合较简单的 Web App 和偏营销的产品。内容区更宽，但分区和角色一多就会拥挤。

分栏视图

适合收件箱、客服工具，以及需要“列表 + 详情”对照的场景。左栏负责选择，右栏负责上下文和操作。

响应式断点

先从 1440px 开始，再检查 1280px、1024px 和 768px。收起侧边栏、减少表格列、把次要操作收进菜单。生成多尺寸之前，先读 Stitch 的设备类型说明。

Web App 提示词公式

每个页面都用这个结构，把方括号替换成产品细节。

Design a [web app type] for [audience].
Page: [page type] whose primary job is [job].
Navigation: [sidebar / top nav / split view].
Layout: [columns, density, max width].
Components: [table, filters, forms, charts, modals].
States: [loading, empty, error, success, permission denied].
Style: [design system or visual direction].
Constraints: [breakpoints, accessibility, data volume].

这个公式把页面、导航和状态放进同一条提示词。它通常决定你得到的是“好看的 mockup”，还是“能用的应用界面”。

仪表盘提示词示例

Design a B2B analytics web app dashboard for a customer support platform.
Page: dashboard; primary job is to show queue health and surface the most urgent conversations.
Navigation: left sidebar with Inbox, Analytics, Team, Settings; top bar with date range and search.
Layout: 12-column grid, four KPI cards, two charts, and a conversation table below.
Components: KPI cards, line chart, stacked bar chart, sortable table, filter bar.
States: loading skeletons, empty queue, error banner, permission-denied state.
Style: clean SaaS interface with neutral surfaces and one blue accent.
Constraints: 1440px first, responsive to 1024px; table must remain scannable.

落地页提示词示例

Design a landing page for a developer tool that turns API logs into dashboards.
Audience: backend engineers at small SaaS teams.
Primary goal: start a free trial.
Sections: hero with code sample, three feature blocks, integration logos, pricing preview, FAQ, final CTA.
Style: technical editorial, monospace accents, restrained color, generous whitespace.
Constraints: mobile-first; one primary CTA repeated; no stock-photo hero.

落地页不是 Web App，但同一个产品可能两者都需要。保持视觉系统一致，同时改变导航和信息密度。

组件与状态

表格是大多数 Web App 成败的关键。写清楚排序、筛选、分页、批量操作、列优先级，以及没有数据时会发生什么。表单需要标签、校验、错误提示、成功反馈和明确的主按钮。弹窗和 toast 应该留给决策和短反馈，而不是塞进本应独立成页的内容。

向 Stitch 要状态，而不只是“顺利路径”。一条包含加载、空、错误和权限状态的提示词，会产出更完整的界面，也更早暴露布局问题。

保持页面一致

写一段共享的提示词前缀，包含产品、用户、风格规则和约束。然后每个页面复用同一套颜色、字体、间距、圆角和组件词汇。页面跑偏时，修共享约束，而不是靠提示词绕过去。

Stitch 的变体可以帮助测试布局替代方案，同时不改变视觉系统。要覆盖更大的系统，可以把设计规则写进 DESIGN.md，在多个屏幕和编码智能体之间复用。

从设计到代码

Web App 设计只有能被开发者实现才有价值。先保证布局干净、组件命名清晰、状态有文档。然后把 Stitch 的 HTML、React 或 Tailwind 结果当作起点，上线前再评审。

导出能力见下载产物，终端工作流见 CLI 教程，在代码库和设计系统之间往返见从代码到设计的工作流。

QA 检查清单

交付 Web App 页面前，检查：

  • 是否只有一个主操作和清晰的页面标题；
  • 导航是否匹配用户角色和任务；
  • 表格或列表在 1024px 下是否仍然可读；
  • 是否覆盖加载、空、错误、成功和权限状态；
  • 表单是否有标签、校验和确认；
  • 颜色、字体、间距和圆角是否一致；
  • 是否为下一个断点准备了响应式方案；
  • 是否存在重复或冲突的操作。

常见问题

Stitch 适合复杂后台吗？

它适合做布局、层级和视觉方向的第一版。复杂后台仍然需要真实的数据建模、权限和可用性测试。用 Stitch 探索和对齐，再用用户验证。

如何生成响应式 Web App 页面？

先生成桌面布局，再要求同一页面在 1024px 和 768px 下的具体变化：收起侧边栏、减少表格列、卡片堆叠。不要假设 AI 会自动推断每个断点。

如何把 Web App 设计导出成代码？

使用 Stitch 的导出选项，并评审生成的 HTML、React 或 Tailwind 结果。把它当作起点，再套用你的架构、无障碍和测试标准。需要可重复的流程时，使用 SDK 或 CLI。

下一步

如果需要更完整的设计流程，阅读 Google Stitch AI UI 设计指南。也可以浏览 Web App 风格、试用编辑器，或按照教程系统练习。

← ← 返回博客